Modelling Inter-organizational Trade Procedures
Using Documentary Petri Nets
Roger W.H. Bons*, Ronald M. Lee*, René W. Wagenaar* and Clive D. Wrigley**
*EURIDIS, Erasmus University, P.O. Box 1738, 3000 DR Rotterdam, The Netherlands
**McGill University, 1001 Sherbrooke St. West, Montreal, P.Q., Canada
(This paper will be published in the Proceedings of the Hawaii International Conference on System Sciences 1995)
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 form of inter-organizational interaction to
lower these costs. The research presented in this paper
contributes to this problem in two ways by: 1)
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. The practical 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 used 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 EDI 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 opportunities to reduce the processing time of
documents within organizations. Using EDI, it is no
longer required to re-key incoming or outgoing data
manually, 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, particularly 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 EDI
implementation. However, this is not reflected in the
current status of EDI diffusion. In reality, successful
EDI 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'
1
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, 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.
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. 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 1 they are going to follow. We define 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 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
cases, guidelines by international bodies such as the
International Chamber of Commerce or the UNCID
have been issued to diminish these ambiguities (an
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, 1992].
example is the Uniform Customs and Practices for
Documentary Credits, issued by the ICC [10]).
In electronic commerce however, when the
execution of the trade procedure is governed by
automated systems, trade procedures should be
stipulated in a common formal, computable and
executable language. Such a language would allow the
specification of downloadable procedures and would ease
the negotiation process since all parties can express
their requirements unambiguously in the same
language. But this is just the first step towards
electronic 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 EDI linkages with more partners this can lead
to the existence of several slightly different trade
procedures. Clearly, this does not encourage companies
to set-up new EDI linkages.
1.2 Open-edi.
One approach to decrease these negotiation costs is
to define standard trade procedures. Although EDI
messages can be structured using an international stand-
ard like UN/EDIFACT (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 scenarios that describe the
trade procedures used by the several parties involved in a
business transaction [31]. 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
interoperability over time, business sectors,
information technology systems and data types, capable
of multiple, simultaneous transactions, to accomplish a
explicit shared business goal" [12, 17]. 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 reposi-
tory, governed by an international body.
Summarizing this section, it was 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. 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 ISO 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
coherence with the Open-edi initiative, Section 2 uses
the Open-edi 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 Case/Open-edi, a Case tool for the design of
"open" inter-organizational trade procedures. Section 5
gives an example of a trade procedure specified in the
Documentary Petri Net representation. Finally, Section
6 contains conclusions and directions for future
research.
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-edi
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
BOV will include formal description techniques to be
used for the representation of trade procedures. In the
near future ISO/IEC JTC1/SC30 will start working on
the stipulation of requirements to these formal
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 required business
information to be interchanged" [12]. As such,
an Open-edi scenario is the specification of a
trade procedure.
• Roles are specifications of the behavior of
parties involved in a business transaction as
seen by other parties. They include a
representation of the current state of the role.
• Information parcels are used to specify the
semantics of the information that is exchanged
among roles.
• Finally, scenario attributes are used to
formally specify information relevant to an
Open-edi scenario, not included in the
2
 specification of the roles and information
parcels. This includes interoperability
information, registration information and
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 modelling 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) and 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 and relative.
• Concurrency: Since trade procedures
inherently consist of multiple parties
performing their actions in parallel it is
essential to be able to effectively model
concurrency.
• Decision 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 visible externally should be modelled.
• 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 representation 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 and 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 organizations need to
be able to evaluate a trade procedure on
through-put time and 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 procedures without the need
to become experts in formal representation
languages as well. As Streng pointed out [27],
several intangible properties of EDI linkages
cannot be validated using quantitative
techniques. He mentions strategic match,
competitive advantage, management
information, competitive response and project
uncertainty as properties that can only be
evaluated using a graphical/animated dynamic
modelling technique.
• A hierarchical (de)composition of trade
procedures is necessary to reduce the
complexity of the specifications. Furthermore,
it allows the reusability of parts of the
specification. For example, the expected
behavior of a bank in a documentary credit
procedure is similar in most documentary credit
transactions, whereas the behavior of the other
roles involved may differ.
2.3 Verification requirements.
Finally, automated verification and/or performance
evaluation of the models must be possible. This
verification includes, but is not limited to, properties
3
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.
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
(boundedness) etc. Pattern recognition can be used to
reason about control issues [5]. 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 [1] in the context of Open-edi scenario
modelling, including an extensive list of representation
languages such as Petri Nets, Entity Relationship
Diagrams, Data Flow Diagrams etc. When the
requirements, set out in Section 2, are mapped on these
FDTs only very few FDTs match all requirements.
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 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 requirements in Section 2.
Classical Petri Nets [24, 25] satisfy the need for
expressing concurrency and choice. A classical Petri Net
is a bi-partite, directed graph. It has two disjunct sets of
nodes: places (represented as circles) and transitions
(represented as bars). Arcs connect places 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., arcs
exist from those places to the transition) contain 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.,
an arc exists from the transition to the place). This is
called the 'firing' of a transition. 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, 24]. Documentary Petri Nets allow the
specification of timers in the following manner. Setting
a timer is modelled by putting a token in a place labeled
X : T i m e r S e t . This place is an input place for a
transition labeled timer: Timer_condition. This
transition has an extra constraint on its firing rule: not
only all input places need to have a token, but the timer
condition needs to be 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 [2].
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, 24]. A similar extension of the classical Petri Nets
are the Predicate/Transition nets, in which logical
predicates are associated with transitions [8, 9].
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 information parcels in the Open-edi
reference model. Information parcels are
modelled using document places 2 . A
document place is represented by a square box.
These kind of places have labels that identify
the information parcel 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 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 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
specified in the structure of these documents.
2 We use the term 'document' since most information parcels in
business practice are mapped on paper documents. In the electronic
version, these are electronic messages.
4
• 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 deontic
state. An example of such a description is
'oblig(X,A)' which means that party X has
an obligation to perform action A.
One important aspect of modelling complex
scenarios is the ability to model roles as 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 13
. Upon 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.
3 All figures in this paper were prepared using Case/Open-edi
running on an Apple Macintosh Quadra 900 computer.
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,
23]. 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
modelled 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 [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
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.
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
5
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 2), the
seller (called "shipper", Figure 5), 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 [10]). 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 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. @ c o n s i g n e e t o @ i s s u i n g _ b a n k :
lc_request. (Figure 2, Figure 3)
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 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: lc.
(Figure 4, Figure 5)
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 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),
modelled 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 3, Figure 4)
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 4)
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 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_of_lading,
commerc_invoice, gsp_a, rejection_notify.
(Figure 4, Figure 5)
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 2, Figure 3)
If the issuing bank approves the documents, it will
forward them to the consignee.
6
Figure 2: A DPN model of the consignee.
Figure 3: A DPN model of the issuing
bank.

Figure 4: The corresponding bank.

Figure 5: A DPN model of the shipper.

7
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 an 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 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 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 [5]
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, can be performed automatically using 'audit
daemons'. This approach could be extended to inter-
organizational procedures.
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 Aalst, W.M.P. "Timed coloured Petri Nets and
their application to logistics", 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, R.W. "Interactive EDI in
the Netherlands", EURIDIS working paper, RP
93-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-1, 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. 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
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. ISO/IEC JTC1/SWG-EDI "The Open-EDI Conceptual
Model", Document N222, 1991
12. ISO/IEC JTC1/WG3 "The Open-EDI Reference Model",
Working Draft document N305, 1994
8
13. Jensen, K. "Coloured Petri Nets: A High Level
Language for System Design and Analysis",
Advances in Petri Nets 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
Partnership", Harvard Business Review, July-
August 1988, page 94-101
15. 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
16. 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)
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, R.M. "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, K.T. "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-Hall, 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
27. Streng, R.J. "Dynamic Modelling to Assess the Value
of Electronic Data Interchange", PhD thesis
University of Delft, Netherlands, November 1993
28. 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
29. Williamson, O. E. "The economic institutions of
capitalism", Free Press, New York, 1985
30. Wrigley, C.D. "EDI transaction protocols in
international trade", Proceedings Conference on
interorganizational systems in the global
environment, Bled, 1992
31. 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