Modelling Inter-organizational Trade Procedures Using ... · Modelling Inter-organizational Trade...

Proceedings of the 28th Annual Hawaii International Conference on System Sciences - 1995

Modelling Inter-organizational Trade Procedures Using Documentary Petri Nets

Roger W.H. Boris*, Ronald M. Lee*, RenC W. Wagenaar* and Clive D. Wrigley**

*EURIDIS, Erasmus Universit , P.O. Box 1738,300O DR Rotterdam, The Netherlands **McGill University, 1 80 1 Sherbrooke St. West, Montreal, P.Q., Canada

Abstract.

Organizations engaging in electronic commerce typically are faced with defining detailed bilateral agreements between business partners. This implies that set-up costs for new electronic linkages can be quite high. There is a growing need to model and simulate this firm of interorganizational interaction to lower these costs. The research presented in this paper contributes to this problem in two ways by: I) stipulating requirements on representation languages to be used for modelling trade procedures; and, 2) presenting a common graph-based representation language, Documentary Petri Nets, which satisfies these requirements. Thepractical implementation of Documentary Petri Net models is illustrated using a modelling environment, Case/Open-edi, a tool that may be used for the design and analysis of trade procedures. A simplified documentary credit procedure is acted to give an example of such a Documentary Petri Net model. Finally, conclusions and directions for research are given.

1. Facilitating electronic commerce.

The introduction of ED1 can have tremendous benefits for the efficiency of the execution of trade procedures, both among and within organizations. The most obvious benefit is the reduction of time needed for the execution of the transaction. Exchanging documents electronically eliminates delays caused by the postal exchange of paper documents between organizations, and offers opporhmi- ties to reduce the processing time of documents within organizations. Using EDI, it is no longer required to re- key incoming or outgoing data manuaIly. as the structured form of the messages enables automatic processing by computer systems. It is now possible to replace many paper documents with electronic equivalents, particubnly since standards for the structure of the messages have matured.

Regarding these benefits, it could be expected that many organizations would be eager to start with ED1 implementation. However, this is not reflected in the current status of ED1 diffusion. In reality, successful ED1 implementations have been realized mainly in trading relationships that can be characterized as ‘electronic hierarchies’ in Williamson’s terms, i.e. trading

relationships with frequent transactions, mostly over a long period of time (Value Adding Partnerships, [14]). In these kind of relationships, parties can gain extra benefits by closely coordinating each others’ actions, thus compensating for the extra start-up costs stemming from detailed trading partner negotiations.

However, when the partnership is established for a limited period, covering a few transactions only, ED1 linkages are seldom observed since the costs of the necessary negotiations cannot be recovered from ED1 efficiency gains. These shorter-term partnerships could be called ‘electronic market relationships’. The aim of this research is to decrease the set-up costs for ED1 linkages, thereby facilitating the introduction of electronic market relationships.

1.1 Trade procedures.

One of the reasons for the complexity of this negotiation process is the fact that parties have to know about each others’ “way of doing business” before they can start exchanging data electronically. Extm knowledge about the preferred way of doing business of one trading partner has to be conveyed to the other; in other words, the parties have to agree upon the trade procedure l they are going to follow. We defme a trade procedure as the mutually agreed upon set of rules that governs the activities of all parties involved in a set of related business transactions. Thus, a trade procedure controls all interactions between the roles involved. A trade procedure stipulates which actions should be undertaken by which parties, the order in which these actions should be performed and possibly the timing constraints on the performance of these actions. Actions of parties include the sending and/or receiving of goods, documents or funds.

The efforts to agree upon a trade procedure are not introduced by the implementation of EDI; these procedures already exist in the paper-based world. This is illustrated by observing trading terms and conditions on

1 It should be noted that although we call these agreements ‘trade procedures’, the principle is applicable to other societal areas than trade. The main focus of this paper however is electronic commerce which explains the term ‘trade’ in the definition. Other terms used to describe this concept are: trade scenarios, business scenarios and business protocols Wrigley, 19921.

189 1060-3425/95 $4.00 Q 1996 IEEE

Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95) 1060-3425/95 $10.00 © 1995 IEEE


the back side of documents, which supply the receiver with the knowledge needed to behave according to the terms of the business agreements. In a situation where human involvement is high, this information might be sufficient, although experience shows that many disputes can still arise because of ambiguous formulations in such terms and conditions. In some casea, guidelines by international bodies such as the International Chamber of Commerce or the UNCID have been issued to diminish these ambiguities (an example is the IJniform Customs and Practices for Documentary Credits, issued by the ICC [lOI).

In electronic commerce however, when the execution of the trade procedure is governed by automated systems, trade proctxiw~ &ould be sntipulated in a common formal, computable and exeartable language. Such a lauguage would allow the tiipedeatian of downloadable lxo&u~~ and would ease the negotiation process since alI parties can express their requirements unambiguously in the same language. But this is just the ftrst step towards dectronic market relationships, since although these trade procedures could be specified in a formal language, this still requires negotiations for each new partnership. Even if a party succeeds in creating such an agreement with one specific trading partner, if it then wants to establish ED1 linkages with more partners this cau lead to the existence of several slightly different trade proc&ures. Clearly, this does not encourage companies to set-up new ED1 linkages.

1.2 Open-edi.

One approach to decrease these negotiation costs is to define standard trade procedures. Although ED1 messages can be structured using an international staudard like UN/EDIFACI (EDI For Administration, Commerce and Transport) or ANSI X.12, there are no standards yet for the semantics and context of those messages, i.e. the business scenqrios that describe the trade procedures used by the several parties involved in a business transaction [3 11. For example, the type of response to the receipt of a purchase order can differ from company to company; one company might reply with a purchase order acknowledgment, another company might reply with a shipping notice. An ISOIIEC sub-committee (ISOIIEC JTClISC30) is working on the definition of standard, ED1 based, trade procedures. This initiative is called “Open-edi”.

Open-edi is “ED1 among autonomous, multiple participants using public standardrr aud aiming towards interoperability over time, business sectors. information technology systems and data types, capable of multiple, simultaneous transactions, to accomplish a explicit shared business goal” [12. 171. The main goal of Open-edi is to lower the barriers for the establishment of ED1 links between business partners by minimizing the need for multiple, bilateral Interchange Agreements. This will be done by providing industry-wide and/or cross-se&oral

Open-e& standards, which will be available to all parties involved in a business transaction. These standards include Open-edi scenatios, which can be either designed for specific situations, or may be customized from generic scenarios. These scenarios will be stored in a repository, govemed by au international body.

Summarizing this section, it was shown that two steps should be taken to facilitate electronic commerce in au electronic market relationship. The first step is the definition of a common, publicIy available language for the specification of trade procedures, which is formal, computable and executable. The second step is the definition of standard trade procedures using this common language. This definition will take place by industry-wide user groups and/or international bodies such as the IS0 and the ICC.

This paper presents such a representation technique for modelling trade procedures, the Documentary Petri Net formalism, and demonstrates how Documentary Petri Nets can be used for the modelling of trade procedures. The remainder of this paper is as follows. Section 2 discusses the requirements on the representation of trade procedures. In order to maintain cohf~ence with the Open- edi initiative, Section 2 uses the Open&i terminology. Section 3 proposes Documentary Petri Nets; a representation and representation language that satisfies these requirements. Section 4 deals with the practical implementation of Documentary Petri Net models using CaseQen-edi, a Case tool for the design of “open” interorganizational trade procedures. Section 5 gives an example of a trade procedure specified in the Documentary Petri Net representation. Finally, Se&on 6 contains conclusions and directions for future resear&.

2. Requirements for representing trade procedures.

The SC30 work group on Open-edi is currently in the process of defining a reference model for Open&i standardization activities [12]. In this reference model, two views are distinguished: the Business Operational View (BOV) and the Functional Service View (FSV). The former targets on business rules and semantics, the latter on technical implementations. This paper will be mainly concerning the BOV. Standards related to the BQV will include formal description techniques to be used for the representation of trade procedures. In the near future ISOlIEC JTCllSC30 will start working on the stipulation of requirements to these formaI description techniques. The modelling entities proposed by SC30 in their reference model include Open-edi scenarios, roles, information parcels and scenario attributes.

. An Open-edi scenario is defined as a “formal specification of a class of business transactions which includes the scenario attribution, the allowable behavior of business participants, as seen by other business participants, and the

190


required business information to be interchanged” [12]. As such, au Open&i scenario is the speciiicationofat.r4epmcedure.

. Roles are specifications of the behavior of parties involved in a business trausaction as seen by other parties. They include a representation of the current state of the role.

. Informatiorm parcels are used to specify the semantics of the information that is exchanged among roles.

. Finally, scenario attributes are used to formaRy specify information relevant to an Open-edi scenario. not included in the specification of the roles and information parcels. This inciudes interoperability information, registration information aud requirements on the FSV posed by the scenario definition [12].

In order to maintain coherence with the Open-edi standardization efforts, a representation language should include the modalling primitives as proposed by SC30. However, our research has shown that further requirements should be posed on such a language. Open- edi scenarios only focus on the (electronic) information exchanged among the roles. In order to reason about a trade procedure, we found it is necessary to model the exchange of goods and funds as well. We also found several additional requirements as listed below. It should be noted that this list is preliminary and may be extended as research progresses. In this stage, a distinction can be made between formal requirements, notational requirements and verification requirements.

2.1 Formal requirements.

Formal requirements include the possibility to express concurrency, choice (internal to a party) and contingency (external to a party) aud the representation of deontic and/or legal relationships and changes thereof. Furthermore, not only the static properties of the system should be modelled but also the dynamic properties. Finally, it should be possible to explicitly model time, both absolute aud relative.

l Concurrency: Since trade procedures inherently consist of multiple parties performing their actions in parallel it is essential to be able to effectively model concurmncy.

. De&loo; points: Since the execution of a trade procedure often depends on internal or external decisions, modelling constructs for such decision points should be included in the language. Since the focus is on inter-

organizational trade procedures, only decisions that are visibie externally should be mode&d.

. Deontics: Deontic Logic is a branch of logic that formalizes reasoning about normative vs. non-normative behavior by means of primitives such as obligations, prohibitions and permissions. The repxsentation of deontic and/or legal states in a model of a trade procedure is essential because organizations should be able to derive their obligations, rights and duties etc. at each point during the execution of the trade procedure. Changes in these states are mostly brought about by a party performing an action involving another party. For example, sending a purchase order to a seller will in most cases bring about an obligation to buy for the buyer. In Speech Act theory, these communications are referred to as ‘performatives’ [3,26]. Therefore, the intention of a communication between parties should be clearly specified so that each may reason about deontic states aud changes thereof. All actions must be unambiguously attributed to roles so that contract performance (or lack of performance ) may be evaluated.

. Dynamic properties: In the execution of a trade procedure, several dynamic properties have to be analyzed, such as deontic state changes. Therefore, a representation language should enable the expression of the dynamic behavior of the roles involved, in other words, it should be possible to monitor the execution of the trade procedure.

. Time: The modelling of absolute and relative time is essential because orgauizations need to be able to evaluate a trade procedure on through-put time aud they should be able to specify deadlines. Especially in cases where time is one of the most critical factors such as in just-in-time logistics, a thorough investigation of such timing properties is crucial.

2.2. Notational requirements.

Notational requirements include the possibility to represent trade procedure designs in a graphical way. Also, there should be a hierarchical way to decompose a trade procedure into a number of levels. This is also reflected in the need to be able to model roles as proposed by SC30.

. A graphical representation of trade procedures enables business experts to reason about the proposed procedure6 without the need to become experts in formal representation languages as well. As Streng pointed out [27], several intangible properties of ED1 linkages


191



cannot be validated using qurmtitative techniques. He mentions strategic match, competitive advantage, management information. competitive response and project uncertainty as properties that cau only be evaluated using a grapbicallW dynamic modelhng technique

. A hierarchical (de)composition of trade procedures is necessary to reduce the complexity of the speciGcation5. Furthermore, it allows the reusability of part5 of the specification. For example, the expected behavior. of a bank in a dotmmeatary aedit prtxedure is similar in most documentary credit transactions, whereas the behavior of the other roles involved may differ.

23 Verification requirements.

Finally. automated verification and/or performance evaluation of the models must be possible. This verification inchides. but is not limited to, properties such as boundcdne5s and liveness of a trade procedure, but also constraints such as the legal soundness of a procedure and measures whether iuauflicicnt or superfluous controls are estiibli5hed in the tr& procedure

Techniques that can be used to perform these validations include formal, mathematical algorithms, pattern recognition and gaming theory. Formal algorithms can be used to prove the absence or presence of deadlock states (liveness). never-ending loops (boundedncss) etc. Pattern recogoition can be used to reason about control issues [S]. Finally, gaming can be used to validate dynamic properties and to validate the properties mentioned in the previous sections.

3. Documentary Petri Nets.

Several taxonomies of Formal Description Techniques (FDTs) can be made, based upon the modelling perspective chosen and/or the formal basis upon which a FDT can be built. Such a taxonomy is presented by [l] in the context of Open-&i scenario modelling, including au extensive list of representation languages such as Petri Nets, Entity Relationship Diagrams, Data Flow Diagrams etc. When tbc requirements, set out in Section 2, are mapped on these FDTs only very few FDTs match ail rcquircment.5.

We found Petri Nets a5 being one of the few acceptable caudidates that offer both a graphical representation and a formal basis for tbe verification of various properties of these nets. The main advantage of the Petri Net formalism, in addition to its capability to graphically model both concurrency and choice, is that it offers various kind5 of both formal and informal analysis methods, which make Petri Nets especially suitable for modelling “Discrete Dynamic Systems” [2]. In the remainder of this section, we introduce the Documentary Petri Net representation: an extension to the classical

Petri Net formalism we developed to satisfy the requirement5 in Section 2.

Classical Petri Nets [24, 253 satisfy the need for expressing txmcumncy and choice. A classical Petri Net is a bipartite. directed graph It ha5 two disjunct sets of nodes: places (represented a5 circle9) and transitions (represented as bars). Arcs connect place5 with transitions or vice versa (it is not allowed to connect two places or two transitions). The dynamic behavior of the modelled system is represented by tokens flowing through the net (represented as dots). Each place may contain several tokens (the marking of the place); a transition is enabled if all its input places (i.e., arc5 exist from those place5 to the transition) coutain at least one token. If this is the case, the transition removes one token from each input place and instantaneously produces one in each output place (i.e., au arc exists from the transition to the place). This is called the ‘firing’ of a trausition. The transitions in Documentary Petri Nets are labeled in order to identify the role that brings about the transition. The syntax of these labels is Role(s) : Action.

Classical Petri Nets only allow the modelling of relative time, but not absolute time. However, it should be possible to specify timers, e.g. for modelling contractual deadlines. This is referred to as ‘timed Petri Nets’ [2, 241. Documentary Petri Nets allow the specification of timer5 in the following manner. Setting a timer is modelled by putting a token in a place labeled X:TimerSet. This place is an input place for a transition labeled timer: Timer condition. This transition has an extra constraint on& firing rule: not only all input places need to have a token, but the timer condition ncc& to bc satisfied. It then fires a token into a place labeled X:TimerExpired. An example of such a timer condition is timer: current-date > > expiry-date. This is similar to the timing properties of the Petri Nets as proposed by Van der Aalst [Z].

The classical Petri Nets only allow one kind of token. In order to distinguish between different types of information parcels, different types of tokens have to be distinguished. This is referred to as ‘colored Petri Nets’ [13, 241. A similar extension of the classical Petri Nets are the Predicate/Transition nets, in which logical predicates are associated with transitions [8, 91. Documentary Petri Net5 use colors and predicates to specify the different information parcel types. goods. funds and deontic states.

. The exchange of information is based upon the information parcels in the Open-edi reference model. Information parcels are modelled using document places l. A document place is repre5cnted by a square box. These kind of places have labels that identify the information parcel

’ We use the term ‘document’ since most information parcels in business practice am mapped on paper documents. In the electronic version, these are electronic messages.

192



type. Sending a parcel is represented by a transition labeled X to Y: D. in which X identifies the sender. Y the receiver and D the type of parcel that is exchanged. This transition has a document place of type D as an output place It will be part of the sub-net describing the behavior of role X. Conversely, receiving an information parcel is modelled by a transition labeled Y from X: D. This transition has a document place of type D a5 an input place This will be part of the sub-net for role Y.

. Goods are represented a5 cube places. A description of the goods. including quantity, weight, volume, quality etc. may be added. The transfer of goods among parties is modelled using the same primitives X to Y: G and Y from X: G as used in the modelling of information exchanges. but in this case G refers to the goods description.

. The exchange of funds is modelled similar to the modelling of information. Since the concept of money is closely related to documents (a 100 dollar bill is a performative document), we use the document places to denote funds transfer. In the description of these documents, the amount and currency are spe~i!kd in the structure of these documents.

. The deontic states of each individual role, as seen by the other roles, are modelled using the classical Petri Net control places and tokens. They are represented by circular places, and labeled with a description of the dcontic state. An example of such a description is ‘oblig(X,A)’ which means that party X has au obligation to perform action A.

One important aspect of modelling complex 5c4xztrios is the ability to model roles a5 separate Documentary Petri Nets. This allows the decomposition of an trade procedure into a number of logically separate sub-nets. This modelling style results in a clear “geographical” separation between the roles. As the role description is a sub-net in the scenario description, designers have some flexibility for experimenting with different role descriptions within the overall scenario constraints.

A state transition is enabled by receiving a information parcel, goods or funds, or the expiration of an internal timer (events). Firing a transition can lead to sending information parcel(s), goods or funds and/or setting an internal timer (actions). An example of a Documentary Petri Net model is presented in Figure l3 . Upon

3 All figures in this paper were prepared using Case/Open-edi running on an Apple Macintosh Quadra 900 computer.

receiving a certain information parcel of type D from role Y, role X is obliged to send goods G to role Y.

Figure 1.

The sub-nets of the several roles may need to be combined in order to build the model of the overall trade procedure. This can be simply done by connecting the roles at their communication points: the document and goods places. For example. in the role description of role X there is a transition labeled X to Y: D with an output document place of type D. In the description of role Y there should be a transition labeled Y from X:D and an input place of type D. The two roles can now be connected by replacing the two document places of type D in the sub-nets by one of the same type, with an incoming arc from the transition in role X and outgoing arc to the transition in role Y. Since this process can be reversed as well, the Documentary Petri Net representation allows both a top-down and a bottom-up approach for the modelling of trade procedures.

4. The practical implementation of Documentary Petri Net models.

All modelling examples in this paper are made using Case/Open-edi, a modelling tool developed by Lee [22, 231. Case/Open-edi offer5 a graphical user interface with which Documentary Petri Nets can be drawn. Furthermore, since Case/Open-edi is developed in Prolog, rule-bases can be added to a Documentary Petri Net model, allowing automatic reasoning about modelled trade procedures. Formal properties of trade procedures, such a5 liveness and boundedness, can be analyzed using algorithms based on the formal properties of Petri Nets [24]. A previous Petri Net based representation, combined with the functionality of Case/Open-edi, has allowed reasoning about control issues in the research conducted by Chen and Lee [5].

Case/Open-edi can not only be used to draw Documentary Petri Nets, it also offers the possibility to simulate and/or animate trade procedures modelled by these nets. In the current implementation of Case/Open- edi, each role description is represented as a separate Documentary Petri Net. Each role modelled in

193

- lir- -- Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS '95) 1060-3425/95 $10.00 © 1995 IEEE


Case/Open-edi has its own window on a screen. A view ofthetotaltradepmcedmecanbeachievedbyopeningall windows containing the role descriptions. The communication between the roles is done by exchanging data among these windows. Internally, the exchange of goods is represutted as a data exchange as well to be able to simulate the exchange of goods among the roles.

The practical contribution of this research is to provide organizations with a method and a tool to define and test OptXl-edi scenarios. These scenarios may be constructed either top-down or bottom-up. In the fist case, an overall trade procedure will be distributed over the individual roles. In the second case, the individual role descriptions of the parties have to be combined. In either case, the role descriptions can be distributed over multiple machines, where information parcels may be exchanged over a local or wide area network using an ED1 standard. This provides a realistic testing environment in which roles can be played and evaluated by different organizations.

Once tested and agreed upon, these scenarios may be stored in a public repository, governed by an international body. Since these scenarios are defined using a formal language such as the Documentary Petri Net formalism, it will be possible for organizations to then download the scenarios and execute them. During this execution the overall controi on the tmie procedure is distributed among the individual crganizations.

5. Example: documentary credits.

In this section we discuss an international trade example: documentary credit procedures. These procedures were introduced by the banking community in order to solve a common problem in business: the lack of trust among trading partners. When partners don’t know whether they can trust each other, the risk for both buyer and seller is very high. For example, the buyer might pay for the goods without being sure of receiving them or the seller may ship the goods without Mng sure of getting paid. These problems arise particularly when the trade is international, as a common legal and banking system exists when trade is conducted within lthe same country.

The solution that the banks offer to international business is that they take over the risk for the buyer and seIler. The buyer and seller may rely on a trusted relationship between their banks. In this example, we present a simple documentary credit procedure, including the buyer (called “consignee”, Figure 2). the seller (called “shipper”, Figure S), the consignee’s bank (“issuing bank”, Figure 3) and the shipper’s bank (“corresponding bank”, Figure 4). Almost all documentary credit procedures conform to the guidelines issued by the ICC (Uniform Customs and Practices for Documentary Credits [lo]). By including a sentence such as ‘this LC has been issued under the rules of ICC.1 UCP 500’ these guidelines become legally enforceable, independent of differences in national legislation of the! involved parties’ countries.

The sequence of actions performed in this trade procedure is described below. For each action, the equivalent label in the Documentary Petri Net model is mentioned. It should be noted that only the labels referring to sending actions are includetk for each sending action there is a correspondent label for the receiving action in the description of the receiving role. Deontic aspects are not included yet as these are still under development. Also, potential loops that might occur in a real-life situation are omitted to reduce the complexity of the example (i.e., when a document is rejected parties may iterate until an acceptable document is presented).

1. @ consignee to 0 shipper: purchase-order. (Figure 2, Figure 5) The consignee (buyer) sends a purchase order to the shipper (seller).

2. @ shipper to @ consignee: p-o-acknowledgment. (Figure 2, Figure 5) The shipper confirms the purchase order to the shipper. They now have a sales contract.

3. @ consignee to @ issuing-bank: lc-request. (Figure 2, Figure 3) Based upon the sales contract, the consignee enters a contract with the issuing bank to issue a titter of Credit (LC)‘. Such a LC contains a description of the goods, the amount of money involved, the delivery terms and conditions and some miscellaneous conditions. Furthermore, the LC contains documentary requirements. These requircmcnts are posed by the consignee based upon the sales contract. They stipulate which documents should be presented by the shipper to prove the performance of the required actions by the shipper, such as the actual shipping, in some cases insuring the goods, certificates of origin (referred to as ‘gsp-a’) etc.

4. @ issuing-bank to {@ corresponding-bank, @consignee): lc. (Figure 2, Figure 3, Figure 4) The issuing bank contacts a bank in the country of the shipper to become the corresponding bank and sends the LC both to the corresponding bank and the consignee.

5. @ corresponding-bank to @ shipper: Ic. (Figure 4, Figure 5) The corresponding bank informs the shipper of the LC and advises the shipper about the documentary requirements.

6. 0 shipper to @ corresponding-bank: bill-of-lading, commerc-invoice, gsp-a.

(Figure 4. Figure 5) The shipper performs his part of the deal. producing the

required documents (in this case a Bill of Lading, the Commercial Invoice and a certificate of origin (GSP-A),

194



Figure 2: A DPN model of the consignee.

Figure 4: The corresponding bank.

f T

Figure 3: A DPN model of the issuing bank.

.r IR.. ‘mrly.“:

Figure 5: A DPN model of the shipper.

195



modelled as @ shipper: gather-documents). He presents the documents to the corresponding bank.

7. @ corresponding-bank to 8 issuing-bank: bill_ofJading, commerc-invoice, gsp-a. CFigure3.Fip4) The correspondiug bank checks the conformance of these documents with the LC and if they umform it sends the documents to the issuing bank for approval.

8. @corresponding-bank: reject (Figure 4) If the documents presented by the shipper do not conform with the LC the bauk sends them back to the shipper with a rejection notification (continue at step 10).

9. @ issuing-bank to @ corresponding-bank: bill_ofJading, commerc&woice, gsp-a,

rejection-notify. (Figure 3, Figure 4) If the issuing bank disapproves of the documents as presented, it returns the documents to the corresponding bank. It also sends a rejection notification to the corresponding bank in which the arguments for rejecting the documents are stipulated.

10. @ corresponding-bank to @ shipper: bill_ofJading, commerc-invoice, wp-a, rejection-notify.

(Figure 4, Figure 5) If the documents have been rejected by the issuing bank aud the corresponding bank has been notified, it notifies the slipper of the rejection and returns the documents to the shipper. The shipper will not get paid; however, it should be noted that if the corresponding bank accepted the documents in stage 6 and forwards them to the issuing bank, it makes sure that all requirements of the LC are satisfied. If it doea this properly, the issuing bank needs to have very strong arguments to reject the documents.

11. @ issuing-bank to @ consignee: bill-of-lading, commerc-invoice, gsp-a. (Figure 2, Figure 3) If the issuing bank approves the documents, it will forward them to the consignee.

12. @ issuing-bank to @ corresponding-bank: money. (Figure 3, Figure 4) As soon as the issuing bank approves the documents, it has to transfer the money to the corresponding bank.

13. @ consignee to @ issuing-bank: money. (Figure 2, Figure 3) As soon as the consignee receives the documents from the issuing bank, payment is due to the issuing bank. In many cases, this is done automatically by the bank, as in most cases the consignee has au account with the issuing bank.

14. @ corresponding-bank to @shipper: money. (Figure 4, Figure 5) As soon as the corresponding bank receives the money from the issuing bank, it transfers it to the shipper.

(Numbers 7-8.9-10 and 11-14 are alternative outcomes of the procedure depending on the acceptance of the documents by the corresponding and issuing banks)

6. Conclusions and research directions.

This paper has shown that two steps should be taken to facilitate electronic commerce in an electronic market relationship. The first step is the definition of a common. publicly available language for the specification of trade procedures, which is formal, computable and executable. This paper has presented a list of requirements on such a language. The Documentary Petri Net formalism has been proposed satisfying these nquirements.

The second step is the &finition of standard business scenarios using this common language. This definition will take place by industry-wide user groups and/or international bodies such as the IS0 and the ICC. A CASE tool presented in this paper, Case/Open-edi, intends to support these groups in this task by providing both a modelling platform and a testing environment for proposed trade procedure designs. In the near future, several kinds of analysis will be supported.

Once tested and agreed upon, these scenarios may be stored in a public repository, governed by an international body. As these scenarios are defined using a formal, computer interpretable, language, organizations will be able to download these scenarios and execute them. During this execution the overall control on the trade procedure is distributed among the individual organizations.

Future research directions include the further development of theory and tools to enable the computer aided design of such trade procedures. Designers will be supported by automated verification tools in order to check whether a proposed trade procedure conforms to certain requirements. Examples of automated verification tools include algorithms stemming from graph theory to detect possible dead-lock situations. Another kind of analysis has been proposed by Chen [s] applied to Petri Net specifications of internal accounting control structures. Chen has shown that the detection of undesirable patterns, for example when the ordering and payment tasks are assigned to the same person, cau be performed automatically using ‘audit daemons’. This approach could be extended to inter-organizational procedures.

196


References.

1. Ahlsen, M.. Pelkonen, H., Walseth. S. “Concepts and Notations for Open-edi Scenarios”. Dedicate Project Report No 8, Swedish Institute for Systems Development SISU, February 1994

2. Van der AaIst, W.M.P. “Timed coloured Petri Nets and their application to logistias”, PhD thesis Eindhoven University of Technology, 1992

3. Austin, J.L. “How to DO things with words”, Harvard University Press, Cambridge, MA, 1962

4. Bons, R.W.H. and Wagenaar, RW. “Interactive EDI in the Netherlands”, EURIDIS working paper, RP 5% 09-01, Erasmus University Rotterdam. July 1993

5. Chen, K.T and Lee, R.M. “Schematic Evaluation of Internal Accounting Control Systems”, EURIDIS Research Monograph, RM-1992-08-L Erasmus University Rotterdam, August 1992

6. Dewitz, S. K. and Lee, R. M. “Legal Procedures as Formal Conversations: Contracting on a Performative Network”. Proceedings of International Conference on Information Systems, Boston, December 1989, pp. 53 - 65

7. EDICC, “Model form of Electronic Data Interchange Trading Partner Agreement and Commentary”, prepared by the Legal and Audit Issues Committee of the Electronic Data Interchange Council of Canada, 1990

8. Gemich, H.J. and Lautenbach. K. “The Analysis of Distributed Systems by Means of PredicateiTransition Nets”. Semantics of Concurrent Computation: Lecture Notes in Computer Science, Kahn G. (Ed.), Vol. 70 pp 123- 146, Springer Verlag, 1979

9. Genrich. H.J. and Lautenbach, K. “System Modelling with High-level Petri Nets”, Theoretical Computer Science, Vol. 13 pp 109-136, New York: North- Holland, 1981

10. ICC, “The Uniform Customs and Practices for Documentary Credit Procedures”, International Chamber of Commerce publication 500, Paris. France, January 1994

11. ISOlIEC JTClISWG-ED1 “The Open-ED1 Conceptual Model”, Document N222, 1991

12. ISOlIEC JTClIWG3 “The Open-ED1 Reference Model”, Worlcing Draft document N305, 1994

13. Jensen, K. “Coloured Petri Nets: A High Level Language for System Design and Analysis”, Advances in Petri Ner.s 1990, G. Rozenberg (ed.). Lecture Notes in Computer Science 483. pages 342-416. Springer Verlag, New York


14. Johnston, R, Laurence, P.R ” Beyond Vertical Integration - the Rise of the Value- Adding Partnershipn, Harvard Business Review, July- August 1988, page 94101

15. Kimbrough. S., Lee, RM. and Ness, D.N. “Performative, Informative and Emotive Systems: The First Piece of the PIE”, Proceedings of the Fi$h International Conference on Information Systems, Fall, 1984, pp.141-148

16. Kimbrough. S.O. and Lee, RM. “On Illocutionary Logic as a Telecommunications Language”, Proceedings of the International Conference on In&mation Systems (San Diego; December, 1986)

17. Knoppers, J “Importance of the “OPEN-EDI” reference model from a user and business perspective”, Proceedings Conference on interorganizational systems in the global environment, Bled, 1992

18. Lee. H.G. and Lee, R.M. “An Intelligent Electronic Market Approach for Commodity Auctions”, Proceedings of International Conference on Electronic Data Interchange and Interorganizational Systems, Bled, Slovenia, June. 1993

19. Lee, RM. “A Logic Model for Electronic Contracting”, Decision Support Systems, Vol. 4. No. 1, 1988. pp. 27-44

20. Lee, R.M. “International Contracting -- A Formal Language Approach”, Proceedings of Hawaii International Conference on Systems Sciences, Kona. Hawaii, January 1988 (Vol. I, Applications, ed. by R. H. Sprague), pp. 69-78

21. Lee, R.M. , Dewitz. S.D. and Chen. KT. “AI and Global EDI,” Hawaii International Conference on System Sciences, January, 1991

22. Lee, R.M. and Dewitz, S.D. “Facilitating International Contracting: AI Extensions to EDI”, International Information Systems, January, 1992

23. Lee, R.M.: “Dynamic Modeling of Documentary procedures: A CASE for EDI”, Proceedings of Third International Working Conference on Dynamic Modeling of Information Systems. Noordwijkerhout, NL, June 1992

24. Peterson, J. L. “Petri Net Theory and the Modeling of Systems”, Prentice-Hail, Englewood cliffs, N.J. 07632, 1981

25. Petri, C.A. “Kommunikation mit Automaten”, PhD thesis University of Bonn, Germany, 1962

26. Searle, J. “Speech Acts: An Essay in the Philosophy of Language”, Cambridge University Press, London, 1969

197


27.


Streng. R.J. “Dynamic Modelling to Assess the Value of Electronic Data Interchange”. PhD thesis University of De@, Netherlands, November 1993

28. Wagenaar, R. W. “Business network redesign - Lessons from the Port of Rotterdam Simulation game”, Proceedings Conjerence on interorganizational systems in the global environment, Bled, 1992

29. Williamson, 0. E ‘The economic institutions of capitalism”, Free Press, New York, 1985

30. Wrigley, CD. “ED1 transaction protocols in international trade”. Prxeedings Conference on interorganizational system in the global environment. Bled, 1992

31. Wrigley, C.D. and Wagenaar, R W. and Clarke. RA. “ED1 in International Trade: Frameworks for the Strategic Analysis of Ocean Port Communities”. Journal of Strategic Injknation Systems. Volume 3, number 3 (forthcoming), 1994


Modelling Inter-organizational Trade Procedures Using ... · Modelling Inter-organizational Trade...

Documents

Transcript of Modelling Inter-organizational Trade Procedures Using ... · Modelling Inter-organizational Trade...