SOFT-CODED

TRADE PROCEDURES

FOR OPEN-EDI

Ronald M. Lee
Roger W.H. Bons

Erasmus University Research Institute for
Decision and Information Systems (EURIDIS)

Erasmus University Rotterdam
PO Box 1738
3000 DR Rotterdam, the Netherlands
tel. 31-10-4082601
email: rlee@fac.fbk.eur.nl

Abstract:

Organizations engaging in electronic commerce typically are faced with high set-up costs for new electronic linkages due to the need for detailed bilateral agreements. This paper contributes to this problem in three ways by: 1) stipulating requirements on representation languages to be used for modeling trade procedures; 2) presenting a common graph-based representation language, Documentary Petri Nets, which satisfies these requirements; and 3) presenting a 'soft-coding' architecture and protocol for sharing and negotiating trade procedures. A modeling environment, Case/Open-edi, is demonstrated using a documentary credit procedure example to illustrate these three aspects. Finally, conclusions and directions for further research are given.

PROCEDURAL CONTROLS FOR OPEN ELECTRONIC COMMERCE

Global information infrastructures are rapidly becoming a reality. Such worldwide networks help companies to operate not only on a local or regional level, but also on a global level. Especially for small and medium enterprises (SMEs) this would offer tremendous opportunities to do global business electronically. However, communication networks alone are not sufficient to enable international electronic trade.

In the past it has been shown that the introduction of Electronic Data Interchange (EDI) can have tremendous benefits for the efficiency of trading both between and within organizations (see for instance previous proceedings of the Bled conference). On the other hand it can also been shown that in many cases long and costly negotiations are necessary between the trading partners before they can exchange their first EDI message1.

As a result, most successful EDI implementations have been realized in what could be called 'closed trading relationships', i.e. long-lasting trading relationships, involving a high number of transactions, between parties that have a high level of trust and possibly a close coordination of the parties' business processes (Table 1). 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 and on an 'at arm's length' basis, EDI linkages are seldom observed since the costs of the necessary negotiations cannot be recovered from the benefits. These shorter-term partnerships could be called 'open trading relationships' (Table 1). The main aim of our research is to contribute to the lowering of the barriers for using EDI in these open trading relationships.

Open Closed
Level of Trust Low High
Number of Transactions Low High Duration of Relationship Short Long Level of Coordination Low High

Table 1. Open vs. closed trading relationships.

However, when the partnership is established for a limited period, covering a few transactions only, EDI linkages are seldom observed since the costs of the necessary negotiations cannot be recovered from EDI 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 EDI linkages, thereby facilitating the introduction of electronic market relationships.

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. Extra 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 2 they are going to follow. We define a trade procedure as the mutually agreed upon

1 Baker (Baker 91) gives an example of the size of such negotiations: 'At one conference on EDI law, James Pitts, a purchasing manager at R.J. Reynolds, said he spent 18 months negotiating a single trading partner agreement. That left him with only 349 other trading partners to go '.
2 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

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 need and usefulness of trade procedures is easy to demonstrate. Consider only a simple post-payment contract for goods. The buyer assumes that an invoice will be sent after delivery to trigger the payment obligation. The seller, on the other hand, abides by the practice that payment becomes due from the time of delivery, and does not send an invoice. Thus, the goods arrive, and the buyer does not pay, waiting for an invoice. Meanwhile the seller becomes irked, and initiates collection proceedings. This is an example of the so-called 'battle of the forms'. Each party utilizes standardized documents such as a purchase order, delivery agreement, etc. which contain (typically on the backside, in small print) the terms and conditions that are their style of doing business. Unfortunately, the small print is often ignored by the receiving party. For trade in a well-established industry area, standardized practice becomes generally accepted, and there usually is not a problem3. However, in more open trading situations, that cross national, cultural or sectorial boundaries, such conflicts are much more likely to arise.

Open-edi

One approach to decrease these negotiation costs is to define standard trade procedures. Although EDI messages can be structured using an international standard like UN/EDIFACT or ANSI X.12, there are no standards yet for the semantics and context of those messages, i.e. the business scenarios that describe the trade procedures used by the several parties involved in a business transaction4 (Wrigley, Wagenaar, and Clarke, 1994). 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 ISO/IEC sub-committee (ISO/IEC JTC1/SC30) is working on the definition of standard, EDI based, trade procedures. This initiative is called 'Open-edi'.

Open-edi is 'EDI among autonomous, multiple participants using public standards and aiming towards inter-operability over time, business sectors, information technology systems and data types, capable of multiple, simultaneous transactions, to accomplish a explicit shared business goal' (ISO, 1994). The main goal of Open-edi is to lower the barriers for the establishment of EDI links between business partners by minimizing the need for multiple, bilateral Interchange Agreements. This will be done by providing industry-wide and/or cross-sectoral Open-edi standards, which will be available to all parties involved in a business transaction. These standards include Open-edi scenarios, which can be either designed for specific situations, or may be customized from generic scenarios. These scenarios will be stored in a repository, governed by an international body.

business protocols (Wrigley, 1992).
3In some cases, 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 Uniform Customs and Practices for Documentary Credits, issued by the ICC (1994)).
4 We use the term 'procedure' to refer to the formalized, computable sequence of document exchanges and related deductions; the term 'scenario' is used in a more informal and generic sense, referring not only to such procedures, but also to related informal explanations and contextualizations.

Soft-Coding of Trade Procedures

Evidently, any existing EDI application embeds the sequencing of the several message types that are exchanged in a trade procedure. However, these sequences are normally 'hard coded' into the application programs, as specified in the terms of the trading partner agreement (Mitrakas, 1994), a legal, textual document.

A key aspect of the architecture presented here is that trade procedures are 'soft coded', in a declarative, rule-based form5. This has the virtue that they may be down-loaded from e.g. a central library to meet the needs of a particular contractual situation.

More significant, however, is that such procedures can be analyzed and managed using computational tools. For example, analytical techniques can be applied to check for formal correctness (boundedness, etc.), as well as fraud potential and other audit controls. Further, soft-coding allows for the representation of generic models that are parameterized for specific circumstances. Additionally, soft-coding enables the navigation, synthesis and negotiation of procedures from different trading sectors or regulatory environments.

The remainder of this paper is as follows. First, we briefly discuss the representation of trade procedures using the Documentary Petri Net formalism. Then, an architecture for the softcoding of such procedures is presented, followed by a description of a modeling and simulation environment called Case/Open-edi. An example from international trade, the documentary credit procedure, is used to illustrate these ideas. Finally, conclusions are drawn.

REPRESENTATION OF TRADE PROCEDURES

In order to maintain coherence with the Open-edi standardization efforts, a representation formalism should include the modeling primitives as proposed by this sub-committee (ISO 1994). Open-edi Scenarios refer to the models of the trade procedures that govern the transactions between organizations participating in Open-edi. These Open-edi Scenarios include Roles, Information Parcels and Scenario Attributes. Roles are used to model the behavior of organizations as it is observable by the other organizations involved in the transaction. Information Parcels are used to model the information that is exchanged among the roles. Finally, Scenario Attributes give further details about the context in which these Open-edi Scenarios are used.

Our research has shown that further requirements should be posed on a representation language. These requirements are 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.

? Formal requirements include the possibility to express concurrency, choice (internal to a party) and contingency (external to a party) and the representation of deontic and/or legal relationships and changes thereof. It should also be possible to explicitly model time, both absolute and relative.

? Notational requirements include the possibility to represent trade procedure designs in a graphical way. Also, there should be a way to hierarchically 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.

5 In the terminology of programming languages, this is like the distinction between interpreted (soft) vs. compiled code. In AI terms, these are declarative representations, as used for instance in expert systems.

? Finally, automated verification and/or performance evaluation of the models should be possible. This verification includes, but is not limited to, properties such as boundedness and liveness of a trade procedure, but also constraints such as the legal soundness of a procedure and measures whether insufficient or superfluous controls are established in the trade procedure.

We found Petri Nets as being one of the few acceptable candidates that offer both a graphical representation and a formal basis for the 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 kinds of both formal and informal analysis methods, which make Petri Nets especially suitable for modeling 'Discrete Dynamic Systems' (Van der Aalst 1992a). We have extended the classical Petri Net formalism to satisfy the formal, notational and verification requirements. It is assumed that the reader is familiar with the classical Petri Net formalism (Peterson, 1981). In the proceedings of the 1994 Bled conference a more detailed description of the Documentary Petri Net formalism is presented (Bons et al., 1994)6. In the remainder of this section we summarize the main extensions to the classical Petri Net formalism.

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. Absolute time is modeled in Documentary Petri Nets using timers. Setting a timer is modeled by putting a token in a place labeled X:TimerSet. This place is the input place of a transition that is labeled timer: Timer_condition. This transition has an extra constraint on its firing rule: the timer condition has to be satisfied, in addition to the availability of tokens in each of the input places. It then fires a token into a place labeled X:TimerExpired. This place will be in most cases one of the input places of a transition representing the action to be taken if the timer expires. An example of such a timer condition is timer: current_date > > expiry_date.

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' (Peterson 1981; Jensen 1990). A similar extension of the classical Petri Nets are the Predicate/Transition nets, in which logical predicates are associated with transitions (Genrich and Lautenbach 1979 & 1981). Documentary Petri Nets use colors and predicates to specify the different information parcel types, goods, funds and deontic states.

? The exchange of information is based upon the concept of information parcels in the Open-edi reference model. Information parcels are modeled using document places . A document place is represented by a square box. These kind of places have labels that identify the information parcel type. Information parcels can be sent or received by a specific role. Sending such 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 a information parcel is modeled by a transition labeled Y from X: D. This transition has a document place of type D as an input place. This will be part of the sub-net for role Y.

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

6 It should be noted that some minor modifications to the DPN formalism have been introduced since the 1994 conference. Especially the modeling of sending and receiving documents has slightly changed. Furthermore, a new transition type to model internal decisions has been added. Finally, the possibilities to have hierarchical decomposition is extended. Since the context of this paper is more focused on the use of the formalism rather than the formalism itself, these modifications will not be discussed.

? The exchange of funds is modeled similar to the modeling 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 specified in the structure of these documents.

A state transition is enabled by receiving an information parcel, goods or funds, or the expiration of an internal timer. Firing a transition can lead to sending information parcel(s), goods or funds and/or setting an internal timer. Some examples of DPN models are presented in Figures 1-47 in the example Documentary Credit procedure below.

One important aspect of modeling complex scenarios is the ability to model the view of each party as a separate Documentary Petri Net. This allows the decomposition of a trade procedure into a number of logically separate sub-nets. This modeling 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.

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 a document output place of type D. In the description of role Y there should be a transition labeled Y from X: D with a input document place of type D. The two roles can now be connected by replacing the two document places 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 modeling of trade procedures.

ARCHITECTURE FOR SOFT-CODED PROCEDURES

We now consider the architectural aspects of this proposal -- how trade procedures should be made available and shared among contracting parties. Generally, we distinguish three broad modalities: centrally standardized procedures; uni-lateral coordination; and bi- or multi-lateral coordination.

Centrally Standardized Procedures

This first modality is where there is a generally accepted style of practice to which all parties conform. This is typical of situations where an organized market has been established, e.g. as for commodities. In this case, a 'boiler-plate' contract is available, which stipulates delivery and payment terms, handling of contingencies and, possible, arbitration mechanisms in case of dispute. In electronic form, this entails that standardized trading procedures be made available, via a publicly accessible library, so that (role) procedures can then be down-loaded and executed by each of the parties.

7 All figures in this paper are prepared using the Case/Open-edi software running on a Apple Macintosh Quadra 900 computer.

Uni-lateral Coordination

The second modality is typified by situations where one trading partner dominates the relationship, such as a large corporation, or otherwise is inflexible in its control policies, e.g. a governmental regulatory agency. The electronic interpretation of this case is where (role) procedures for the other parties are down-loaded from a library provided by this dominant party. Such libraries expressing the 'way of doing business' of a particular party we call a regime.

Multi-lateral Coordination

The third modality is bi- or multi-lateral, and includes situations where several of the parties have established control policies. This is typical of situations where multiple regulatory agencies are involved. The electronic interpretation here would again be that each of these major players has their trade procedures available in network accessible regimes. For a particular contract, each of the relevant procedures is collected and assembled.

This third modality introduces the potential for conflict among control policies of the parties. In conventional trading circumstances, such conflicts (assuming they are detected!) are typically resolved in one of two ways: be negotiating compromise, or by seeking other partners.

A Messenger Model

To help cope with cases of conflicting control policies, we introduce an additional computational device, called a messenger. A messenger is a kind of computational agent8, specialized in navigating procedure libraries or regimes, and where needed, negotiating procedural alternatives.

The notion of messenger is based on a metaphor to physical messenger services. Such physical messengers are normally charged with delivering a message or parcel to some recipient. More importantly, they often make delivery of performative communications such as contractual offers (bids), legal summons, as well as payments. If obstacles arise, (recipient is not home), the messenger has some limited discretion to resolve the problem (leave parcel at neighbor's). If this is not possible, the messenger is to contact the client for further instructions. Our notion for electronic messengers goes beyond this physical metaphor to include not only the execution of certain contractual actions, but also the navigation and (limited) negotiation of control procedures.

A brief scenario: Lee, an American, lives abroad in Holland. His passport renewal is due. Normally he would need to travel to the US Consulate in Amsterdam, wait in line, fill out the forms, pay the fee, etc. In all, this could easily cost an entire afternoon (if all goes well; if not, for instance if the passport photo is the wrong size, a return trip might be needed). Instead, Lee logs on (to InterNet) and initiates a messenger with the goal: US passport renewal. The messenger contacts the US Consulate's on-line regime, and identifies the procedural subset relevant to Lee's case. Since the messenger has access to the relevant personal data for Lee (including digitized passport photo), it can do most of the form-filling automatically. It then returns to Lee with a request for confirmation (plus requests for any additional data, e.g. choice of delivery mode), and release of payment for the fee. Lee gives the OK, and the messenger then returns to the Consulate and executes the transaction. The passport is sent via post or conventional messenger service. (Perhaps someday the passport itself will be electronic).

8 The notion of computational agents is currently receiving attention in a wide range of applications. See for instance the special issue of CACM (Reicken, 1994).

The reader is no doubt acquainted with various other bureaucratic duties of this ilk. They include driver's license applications, voting registrations, building permits, visa applications, credit card applications, phone card applications, etc. These illustrate the use of messengers in a uni-lateral situation. In bi- or multi-lateral cases, the messenger needs to navigate among multiple regimes and attempt to synthesize the various procedural requirements. Failing this, the messenger may attempt to locate another company or agency that offers similar goods or services, but with more compatible control requirements (either stricter or more lenient as the case may be). Or, the messenger may request a compromise in the control requirements of a current party, e.g. include the sending of an invoice where none was required. As outlined, messengers have four kinds of capabilities:

1. navigation of regimes (procedural requirements)
2. synthesis of procedures (from multiple regimes)
3. detection of procedural conflicts
4. suggestion of remedies for conflicts

These are the subject of our continuing research. To address these four areas, we are developing a generalization of the DPN representation called Procedure Constraint Grammars (PCG's). Like language grammars, which give rules of well-formedness, PCG's specify the characteristics of a family of procedures at various levels of abstraction. Just as a generative grammar for a language can produce various sentences, so too a PCG can generate particular procedures, given specified parameters. Representing regimes in this formalism, procedures specific to individual cases are extracted and presented as Documentary Petri Net procedures.

Unlike language grammars, however, which are typically represented as an integrated hierarchy of rules, PCG's are organized as constraints on a target procedure. It is the job of the PCG constraint solver to identify a (minimal) solution procedure (according to some preference ordering of the user -- e.g. minimal duration vs. minimal risk). This mechanism is essential for the other three areas of messenger functionality: synthesis, conflict detection, and conflict resolution.

Presently, an initial representation of PCG's has been defined and is operational. Work continues on the procedural constraint solver design (possibly incorporating constraint logic programming, CLP). Aspects of the conflict detection problem (for static deontic rules) are addressed in Ong and Lee (1993), using abductive reasoning. Aspects of the constraint resolution problem, again for static deontic rules, are discussed in Ryu and Lee (1992), using defeasible reasoning.

PROTOTYPING ENVIRONMENT: CASE/OPEN-EDI

All modeling examples in this paper are made using Case/Open-edi, a modeling tool developed by Lee (1992). Case/Open-edi offers 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 modeled trade procedures. Formal properties of trade procedures, such as liveness and boundedness, can be analyzed using algorithms based on the formal properties of Petri Nets. 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 (1992).

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 modeled by these nets. In the current implementation of Case/Open-edi, each role description is represented as a separate Documentary Petri Net. Each role modeled in Case/Open-edi has its own window on a screen. A view of the total trade procedure can be achieved by opening all windows containing the role descriptions. The communication between the roles is done by exchanging data among these

windows. Internally, the exchange of goods is represented 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 Open-edi scenarios. These scenarios may be constructed either top-down or bottom-up. In the first 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 EDI 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 control on the trade procedure is distributed among the individual organizations.

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 being 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 the same country.

The solution that the banks offer to international business is that they take over the risk for the buyer and seller. 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 1), the seller (called 'shipper', Figure 4), the consignee's bank ('issuing bank', Figure 2) and the shipper's bank ('corresponding bank', Figure 3). Almost all documentary credit procedures conform to the guidelines issued by the ICC (Uniform Customs and Practices for Documentary Credits, ICC, 1994). By including a sentence such as 'this LC has been issued under the rules of ICC/ 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 included; 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 @ shipper: purchase_order. (Figure 1, Figure 4)
The consignee (buyer) sends a purchase order to the shipper (seller).

2. @ shipper to @ consignee: p_o_acknowledgment. (Figure 1, Figure 4)
The shipper confirms the purchase order to the shipper. They now have a sales contract.

3. @ consignee to @ issuing_bank: lc_request. (Figure 1, Figure 2)
Based upon the sales contract, the consignee enters a contract with the issuing bank to issue a 'Letter 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 requirements 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 1, Figure 2, Figure 3) 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: lc. (Figure 3, Figure 4)
The corresponding bank informs the shipper of the LC and advises the shipper about the documentary requirements.

6. @ shipper to @ corresponding_bank: bill of lading, commerc_invoice, gsp_a. (Figure 3, Figure 4) 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), modeled as @ shipper: gather_documents). He presents the documents to the corresponding bank.

7. @corresponding_bank to @issuing_bank:
bill of lading, commerc_invoice, gsp_a. (Figure 2, Figure 3)
The corresponding bank checks the conformance of these documents with the LC and if they conform it sends the documents to the issuing bank for approval.

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

9. @ issuing_bank to @ corresponding_bank:
bill of lading, commerc_invoice, gsp_a, rejection_notify. (Figure 2, Figure 3) 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 of lading, commerc_invoice, gsp_a, rejection_notify. (Figure 3, Figure 4) If the documents have been rejected by the issuing bank and the corresponding bank has been notified, it notifies the shipper 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 does 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 1, Figure 2) If the issuing bank approves the documents, it will forward them to the consignee.

12. @ issuing_bank to @ corresponding_bank: money. (Figure 2, Figure 3)
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 1, Figure 2)
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 an account with the issuing bank.

14. @ corresponding_bank to @shipper: money. (Figure 3, Figure 4)
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)

Figure 1: A DPN model of the consignee. Figure 2: The corresponding bank.

Figure 3: A DPN model of the issuing bank. Figure 4: A DPN model of the shipper.

CONCLUSIONS AND FUTURE RESEARCH DIRECTIONS

This paper has proposed three steps toward procedural controls for electronic commerce. 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 requirements. The second step is the definition 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 ISO 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 modeling platform and a testing environment for proposed trade procedure designs. In the near future, several kinds of analysis will be supported. The third step is development of an architecture and a protocol for sharing these procedures among contracting parties. Three modes were suggested: globally standardized procedures; uni-lateral coordination; and bi- or multi-lateral coordination.

We have two broad directions for future research. One of these relates to the above mentioned protocol for negotiating procedures among contracting parties with differing control requirements. This includes further refinement of the messenger model and the constraint resolution mechanism for Procedure Constraint Grammars (PCG's).

The other research direction relates to normative modeling of trade procedures: given situational goals and the parties' risk, cost and time preferences, what constitutes a 'good' trade procedure? This research will result in automated verification tools that may be used 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 and Lee (1992) applied to Petri Net specifications of internal accounting control structures. They have shown that the detection of undesirable patterns, for example when the ordering and payment tasks are assigned to the same person, can be performed automatically using 'audit daemons'. This approach could be extended to inter-organizational procedures.

ACKNOWLEDGMENTS:

We would like to thank Professors Steven Kimbrough (Wharton, University of Pennsylvania), Clive Wrigley (McGill University) as well as Yao-Hua Tan and Ren? Wagenaar (both of Euridis, Erasmus University) for many stimulating discussions and debate on topics of deontics and performatives in electronic commerce. The authors would also like to thank Prof. Aernoud Schmidt (University of Leiden) and Herman Roos and Taco de Vries (KPMG Management Consultants) for the challenging discussions about EDI law and security in the EDIBOL project.
The research has been partially funded by the ESPRIT III Basis Research Working Group no. 8319 Modelage.

REFERENCES:

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

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

Bons, R.W.H., Lee, R.M., Wagenaar, R.W. and Wrigley, C.D. "Computer Aided Designs of Interorganizational Trade Procedures", Proceedings of the Seventh International Conference Electronic Commerce and Electronic Partnerships, Bled, Slovene, June 6-8, 1994.

Bons, R.W.H., Lee, R.M., Wagenaar, R.W. and Wrigley, C.D. "Modelling Inter-organizational Trade Procedures Using Documentary Petri Nets", Proceedings Hawaii International Conference on System Sciences (HICSS) 28, Volume 3, pp. 189-198, Hawaii, USA, January 1995.

Cathomen, I. "EDI Security Services in International Trade", Working Paper Competence Center Electronic Markets, University of St.Gallen, Switzerland, 1994

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

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

Dewitz, S.D. "Contracting on a Performative Network: using IT as a legal intermediary", PhD Thesis, University of Texas, Austin, 1992

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

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

Genrich, H.J. and Lautenbach, K. "The Analysis of Distributed Systems by Means of Predicate/Transition Nets", Semantics of Concurrent Computation: Lecture Notes in Computer Science, Kahn G. (Ed.), Vol. 70 pp 123-146, Springer Verlag, 1979

ICC, "Incoterms 1990", International Chamber of Commerce publication 461, 1990

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

ISO, "The Open-EDI Reference Model", Working Draft document N075, ISO/IEC JTC1/SC30, 1994.

ISO, "The Open-EDI Conceptual Model", ISO/IEC JTC1/SWG-EDI, Document N222, 1991.

Johnston, R., Laurence, P.R. " Beyond Vertical Integration - the Rise of the Value- Adding Partnership", Harvard Business Review, July-August 1988, page 94-101

Kimbrough, S., Lee, R.M. and Ness, D.N. "Performative, Informative and Emotive Systems: The First Piece of the PIE", Proceedings of the Fifth International Conference on Information Systems, Fall, 1984, pp.141-148

Kimbrough, S.O. and Lee, R.M. "On Illocutionary Logic as a Telecommunications Language", Proceedings of the International Conference on Information Systems (San Diego; December, 1986)

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

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

Lee, R.M. , Dewitz, S.D. and Chen, K.T. "AI and Global EDI," Hawaii International Conference on System Sciences, January, 1991

Lee, R.M. "A Logic Model for Electronic Contracting", Decision Support Systems, Vol. 4, No. 1, 1988, pp. 27-44

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

Lee, R.M. and Dewitz, S.D. "Finding International Contracting Opportunities: AI Extensions to EDI," Proceedings of the International Conference on Information Systems, Copenhagen, Denmark, December 16-19, pp. 1-13, 1990.

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

Lee, R.M., Bons, R.W.H., Wrigley, C.D. and Wagenaar, R.W. "Automated Design of Electronic Trade Procedures Using Documentary Petri Nets", Proceedings Fourth International Conference on Dynamic Modeling and Information Systems, Noordwijkerhout, September 1994.

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

Mees, "Documenten en de Internationale Handel", Bank Mees Hope (now Mees Pierson), edition 1988 (in Dutch)

Mitrikas, A. "Model Trading Partner Agreements", Euridis Working Paper, 94-12-01.

O'Hare W.L. "An Introduction to Documentary Credits", The Chartered Institute of Bankers, UK, 1990

Ong, Kay Liang and Lee, Ronald. "A Formal Model for Maintaining Consistency of Evolving Bureaucratic Policies: a Logical and Abductive Approach", Euridis Research Monograph (RM 93.01.01), January, 1993.

Peterson, J. L. "Petri Net Theory and the Modeling of Systems", Prentice-Hall, 1981

Petri, C.A. "Kommunikation mit Automaten", PhD thesis University of Bonn, Germany, 1962.

Reicken, D. (ed.) Intelligent Agents, Special Issue of Communications of the ACM, 37:7, July, 1994.

Richardson J.D. (ed.) "The Merchant's Guide New International Edition", P&O Containers Ltd., 1994.

Ryu, Young and Lee, Ronald. "A Formal Representation of Normative Systems: A Defeasible Deontic Reasoning Approach", Euridis Research Monograph (RM 92.08.01), August, 1992.

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

Streng, R.J. "Dynamic Modelling to Assess the Value of Electronic Data Interchange", PhD thesis University of Delft, Netherlands, November 1993

Van der Aalst, W.M.P. "Timed coloured Petri Nets and their application to logistics", PhD thesis Eindhoven University of Technology, 1992

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

Williamson, O. E. "The economic institutions of capitalism", Free Press, New York, 1985

Wrigley, C.D. "EDI transaction protocols in international trade", Proceedings Conference on interorganizational systems in the global environment, Bled, 1992

Wrigley, C.D. and Wagenaar, R.W. and Clarke, R.A. "EDI in International Trade: Frameworks for the Strategic Analysis of Ocean Port Communities", Journal of Strategic Information Systems, Volume 3, number 3 (forthcoming), 1994