Establishing and Specifying the REA model as a Domain Ontology for Business

Original specification of the REA Ontology – McCarthy, Geerts et al at University of Michigan

Transitional efforts to formalize REA Ontology using UML Diagrams – Poels, Paemeleire, Gailly et al at Ghent University

Formalization of the REA Enterprise Ontology using OWL and the UML Profile of OWL – Poels, Gailly et al at Ghent University

Background

The REA Ontology is an “event ontology” (Allen, GN and ST March, 2006) that focuses on events occurring within the realm of a company, their participating agents, affected resources, and regulating policies. REA can be used as a reference for modeling a single business cycle (e.g. sales-collection) or a chain of business cycles, connected through resource flows. Applications supported by REA-driven modeling include the design of accounting and operations management systems, auditing and internal control, and conceptual data modeling. REA has been used in a number of international standardization efforts for e-collaboration systems. For instance, REA was the basis for the business process ontology in the UMM business process and information model construction methodology, the ECIMF system interoperability enabling methodology, and the Open-EDI business transaction ontology which is part of the ISO/IEC 15944-4 standard. REA has further been proposed as a theoretical basis for the reference models that underlie ERP systems.

The Project

Frederik Gailly and Geert Poels (Ghent University) set out with two goals:

  1. To establish the REA ontology as a domain ontology – specifically a domain ontology for business, using a semiotic framework (Stamper et al, 2000; Burton-Jones et al , 2005). Within this framework, the authors sought assistance with their evaluation of the ontology’s syntactic quality specifically from Welty et al (1999) and Lassila and McGuiness (2001), and with their evaluation of the ontology’s social quality from Guarino (1998) and Uschold and Jasper (1999).
  2. To enhance the specification of the REA ontology using both a formal language representation (the Web Ontology Language or OWL) and a graphical representation (the Unified Modeling Language or UML Profile for OWL) .

We will leave it largely up to the readers to familiarize themselves with the details of how the authors achieved their goal of establishing the REA ontology as a domain ontology for business. We simply present the semiotic framework (Burton-Jones et al , 2005) in Table 1 and highlight the authors’ evaluation of the REA ontology against this framework in Table 2. Finally, we note that the authors define business as “the activity of providing goods and services involving financial, commercial and industrial aspects”.

Metric Attribute Description
Syntactic quality Lawfulness Correctness of syntax
Richness Breadth of syntax used
Semantic quality Interpretability Meaningfulness of terms
Consistency Consistency of meaning of terms
Clarity Average number of word senses
Pragmatic quality Comprehensiveness Number of classes and properties
Accuracy Accuracy of information
Relevance Relevance of information for a task
Social quality Authority Extent to which other ontologies rely on it
History Number of times ontology has been used

Table 1. Metrics  for evaluating ontologies (Burton-Jones, A et al, 2005)

Metric Attribute REA evaluation
Syntactic quality Lawfulness
  • The REA ontology has a semantically rich internal structure (say) that is not limited to the IS-A relations as found in a typical thesaurus, and that defines axioms that allow for semantic reasoning.
  • However, many details of the REA ontology internal structure and underlying logic are not explicitly specified (e.g., disjointness of concepts).
Richness
Semantic quality Interpretability
  • The authors don’t evaluate the semantic quality of the REA ontology because of their focus on the applicability of the ontology.
Consistency
Clarity
Pragmatic and
Social quality
Comprehensiveness
  • Both the pragmatic and social qualities of the REA ontology are evaluated largely in terms of the ontology’s applications and the extent to which the ontology is useful for users and their agents, irrespective of syntax and semantics.
  • The REA ontology supports a wide range of applications and users:
    • education in accounting and business
    • model-driven systems and software design
    • supply chain and e-collaboration
    • knowledge representation and retrieval
Accuracy
Relevance
Social quality Authority
History

Table 2. Evaluation of the REA ontology.

The authors’ evaluation of the syntactic quality of the REA ontology as a domain ontology for business highlighted the following deficiencies:

  • the REA ontology was a somewhat incoherent mix of textual and graphical elements that spoke to its relative immaturity
  • while some researchers (Bialecki 2001; Chou 2006; Geerts 2004) had taken steps to represent the REA ontology in a machine-readable format, none of these formalizations was widely known or generally accepted
  • like Geerts and McCarthy (1999), the authors recognized the importance of better specifying the REA ontology

Again, we will leave it largely up to the readers to familiar themselves with the details of how the authors enhance the specification of the REA ontology. The main principles of their approach included:

  • the authors apply formal procedures – the METHONTOLOGY framework (Fernandez-Lopez et al. 1997; G6mez-Perez and Rojas 1999) and the Operational Data Model (OMG, 2006) – to re-engineer the existing REA ontology
  • Three main activities are identified in this re-engineering process (Figures 2 and 3):
    • reverse engineering – the conceptualization of the REA ontology is recovered from whatever representation formats are available (e.g. text, tables, modeling diagrams)
    • re-structuring – the recovered conceptualization of the REA ontology is re-designed and expressed in a graphical representation with well-defined syntax and semantics (like the UML Profile for OWL) 1
    • forward engineering – the re-designed conceptualization is transformed into a re-engineered, formal language representation (like OWL)

 

A Business Domain Ontology Re-engineering Methodology - Process, Activities and Artifacts

Figure 2. A Business Domain Ontology Re-engineering Methodology – Process, Activities and Artifacts.

 

REA Ontology Transformation and Tools

Figure 3. The recovery, re-design, and formalization of the REA domain ontology for business.

With this overview of the methodology used by Geerts, Laurier and Poels to re-engineer the REA ontology in 2007 – 2008, we can turn to the resulting graphical representation (UML Profile of OWL) and formal language representation (OWL) of the REA domain ontology for business.

Next: Graphical representation of the REA domain ontology for business (UML Profile for OWL)

 

 

 

  1. Using UML in the re-design of the REA ontology capitalizes on the familiarity of many end-users  in the business domain with this technology.

ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Introduction – 20071101

ISO/IEC 15944 consists of the following parts under the general title “Information technology – Business Operational View”:

  • Part 1: Operational aspects of Open-edi for implementation
  • Part 2: Registration of scenarios and their components as business objects
  • Part 4: Business transaction scenarios — Accounting and economic ontology
  • Part 5: Identification and referencing of requirements of jurisdictional domains as sources of external constraints
  • Part 6: Technical introduction to e-Business modelling [Technical Report]
  • Part 7: eBusiness vocabulary
  • Part 8: Identification of privacy requirements as external constraints on business transactions
  • Part 9: Business transaction traceability framework for commitment exchange
  • Part 10: IT-enabled coded domains as semantic components in business transactions
  • Part 11: Descriptive techniques for foundational modelling in Open-edi
  • Part 20: Linking business operational view to functional service view

Introduction

Purpose and overview

This work is motivated with important ideas from the ISO Open-edi specifications as represented in ISO/IEC 15944-1. In ISO/IEC 15944-1 and in some of its earlier foundational expositions, such as ISO/IEC 14662, there were important concepts defined and interrelated such as business transaction, fundamental activities of a business transaction, commitment, Person, role, scenario, and others. A need for relating all of these concepts in a formal framework for the Open-edi work is apparent.

This is a question of ontology: a formal specification of the concepts that exist in some domain of interest and the relationships that hold them. In this case, the domains of interest are those that encompass Open-edi activities, that is, law, economics, and accounting in an extended sense, not the internal accounting of one particular firm, but the accountabilities of each of the participants in a market-based business transaction.

Ontologies are generally classified as either upper-level ontologies, dealing with generalized phenomena like time, space, and causality, or domain ontologies, dealing with phenomena in a specific field like military operations, manufacturing, medical practice, or business. The economic and accounting ontology being used in electronic business eXtended Markup Language (ebXML), in the UN/CEFACT modelling methodology, and E-Commerce Integration Meta-Framework (ECIMF) work is entitled the Resource-Event-Agent (REA) ontology 1. REA is used here as an ontological framework for specifying the concepts and relationships involved in business transactions and scenarios in the Open-edi sense of those terms. The resulting framework is titled the Open-edi business transaction ontology (OeBTO).

The REA ontology is actually an elementary set of concepts derived from basic definitions in accounting and economics. These concepts are illustrated most simply with a UML class diagram. See Figure 1, which illustrates the simple Resource-Event-Agent structure that gives REA its name. A business transaction or exchange has two REA constellations joined together, noting that the two parties to a simple market transfer expect to receive something of value in return when they trade. For example, a seller, who delivers a product to a buyer, expects a requiting cash payment in return.

Basic economic primitives of the Open-edi ontology

Figure 1 Basic economic primitives of the Open-edi ontology.

There are some specific points of synergy between the REA ontology and the ISO Open-edi specifications as represented in ISO/IEC 15944-1.

ISO/IEC 15944-1, 3.9 defines commitment as “the making or accepting of a right, obligation, liability, or responsibility by a Person…”. Commitment is a central concept in REA. Commitments are promises to execute future economic events, for example, to fulfill an order by executing a delivery event.

ISO/IEC 15944-1, 6.1.3, Rule 1 states: “Business transactions require both information exchange and commitment exchange.” REA firmly agrees with and helps give definition to this assertion. Reciprocal commitments are exchanged in REA via economic contracts that govern exchanges, while information exchange is tracked via business events that govern the state transitions of business transaction entities that represent various economic phenomena.

ISO/IEC 15944-1, 6.3.1, Rule 39 states: “Conceptually a business transaction can be considered to be constructed from a set of fundamental activities. They are planning, identification, negotiation, actualization, and post-actualization.” For REA, actualization is the execution of economic events that fulfill commitments. Planning and identification involve business partners with types of economic resources, events, and persons, while negotiation is finalized by an economic contract which is a bundle of commitments. The UN/CEFACT Business Process Group has also defined negotiation protocols that assist in forming commitments. The Open-edi set of activities and the REA economic concepts will help each other tie together all the activities into a cohesive business transaction, and then unite that transaction definition with its related information models.

Finally, with regard to the preliminary agreement between Open-edi and REA, the two major sets of ideas that characterize the Open-edi work, the specification of business transactions and the configuration of scenarios, correspond well at the aggregate level to what the REA ontology calls the accountability infrastructure and the policy infrastructure. A business transaction specifies, in a descriptive sense, actual business events of what has occurred or has been committed to. Conversely, a scenario is more prescriptive: it configures what could be or should be. The realm of both descriptions and prescriptions is important both to Open-edi and REA, and they can work well in developing standards for each.

Definition of Open-edi Business Transaction Ontology (OeBTO)

According to the most widely accepted definition from Tom Gruber, an ontology is a formal, explicit specification of a shared conceptualization. The individual components of this meaning are each worth examining.

  • formal = machine-readable
  • explicit specification = concepts, properties, relations, constraints, and axioms are explicitly defined
  • of a shared = consensus knowledge
  • conceptualization = abstract model of some phenomenon in the real world

At present, the REA model is certainly an explicit specification of a shared conceptualization of economic phenomena in the accounting community.

A formal, machine-readable specification is not proposed in this part of ISO/IEC 15944; however, such extensions may follow in other standards work.

This part of ISO/IEC 15944 focuses on integrating the Gruber definition of ontology with a REAbased approach. It does so from an accounting and economic ontology perspective within an Openedi Reference Model context. This is achieved through the introduction of the concept (or construct) of “Open-edi Business Transaction Ontology (OeBTO)”, which is defined as follows:

formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among those concepts.

Use of the “independent” and “trading partner” perspective in the Open-edi ontology work

In normal business use, the naming perspective for the ontological primitives would be that of the entrepreneur or of one of the two trading partners engaged in collaborative commerce. The other trading partner would ordinarily have a mirror-image view. Thus, a sale, a cash receipt, or a resource inflow for a particular entrepreneur would become a purchase, a cash disbursement, or a resource outflow for a corresponding trading partner. From this perspective, business events and their accompanying economic phenomena would be modeled twice, once in the database of each trading partner. However, for Open-edi purposes, or for that matter for any other independent modeling of business collaborations like the Business Requirement View BRV level of the UN/CEFACT modeling methodology, this redundancy is not acceptable because it allows the states of the two representations to become inconsistent. This difference in naming perspective is explained below and illustrated in Figure 2.

Different views of business collaboration

Figure 2. Different views of business collaboration.

Figure 2 illustrates three independent value chains for three different enterprises. Each company has a connected network of business processes that takes its initial input of resources (called factor inputs for their production functions) and transforms them via cumulative flows of goods, services, rights, and/or cash into an output for that firm’s downstream customers. For Open-edi collaboration modeling, these internal processes are not relevant until a resource flow crosses enterprise boundaries, as is illustrated for Enterprise #2 which accepts materials from Enterprise #1 and which delivers materials to Enterprise #3 (most probably in both cases for cash payments in return). The two dotted lines with double-headed arrows show these inter-enterprise events.

The independent or collaboration perspective of resource flows is anchored on the view of the eye outside of Enterprise #2. This view sees both exchanges as conceptually similar with flows of materials being requited by flows of funds. Such a perspective is quite different from that of the eye inside of Enterprise #2, which sees the flow between Enterprise #1 and Enterprise #2 as a “purchase” and the flow between Enterprise #2 and Enterprise #3 as a “sale”. Note that an eye inside of Enterprise #1 (not shown on diagram) would have modeled the “purchase” of Enterprise #2 as a “sale” of Enterprise #1, hence the redundancy and the inevitable inconsistency.

Business process modeling can take either of the perspectives shown by the eyes of Figure 2, but the independent perspective is clearly the choice for Open-edi. This leads to the concept of a business collaboration that is illustrated in Figure 3. Most generally, there is a value exchange between two Persons, with one assuming the role of a “buyer” (has money, desires goods, services, and/or rights) and the other assuming the role of a “seller” (has goods, services, and/or rights, desires money). It is also possible to anchor the independent view on time, with one event being the initiating flow and the requiting event being the responding flow. For internal database purposes of corporate accountability, “trading partner perspective” terms are directly derivable from “independent perspective” terms.

Concept of a business collaboration

Figure 3. Concept of a business collaboration.

The “Open-edi Business Transaction Ontology” (OeBTO)

“Definition of Open-edi Business Transaction Ontology (OeBTO)” and “Use of ‘independent’ and ‘trading partner’ perspective in the Open-edi ontology work” have suggested:

  • that the components of the REA domain ontology model are sufficiently well-defined, stable, and well-known that they can clearly serve as the basis for an ontological specification of the concepts involved in collaborative exchanges between trading partners, and
  • that the components of that model must be viewed from the outside perspective of a modeler viewing the economic phenomena independently.

Because the primitive economic terms are being adopted here for use with the operational aspects of Open-edi from ISO/IEC 15944-1, the ontology to be defined will be termed the “Open-edi Business Transaction Ontology” (OeBTO). Its definition is

formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among these concepts

From the definitional foundations of both ISO/IEC 15944-1 and the REA model, it follows that the OeBTO will follow these five principles:

  • as a business transaction ontology, a distinguishing characteristic of OeBTO is that in addition to information exchange, it incorporates commitment exchange among autonomous Persons
  • an OeBTO requires the use of clear and pre-defined rules, principles, and guidelines (see ISO/IEC 15944-1, 5.1)
  • an OeBTO is neutral in terms of technology, representation, and application
  • the scope of an OeBTO covers all areas of business transactions (public/private, industry sectors, international, regional, etc.)
  • the semantics of the concepts represented in an OeBTO are explicitly specified and constrained.

Organization and description of Part 4 of  ISO/IEC 15944

Clause 1 and Clause 2 provide scope and normative references for OeBTO. The basic OeBTO definitions are first enumerated in Clause 3, while Clause 4 provides a table of symbols and abbreviations. Clause 5 provides the declarative substance for this part of ISO/IEC 15944, which is a set of UML class diagrams and conceptual explanations that circumscribe the Open-edi Business Transaction Ontology. Clause 6 explains the mechanics of a business transaction state machine, which is the procedural component of an OeBTO, while Clause 7 explains the (internal) constraint component of OeBTO, which is its repository for business rules.

At the end of this part of ISO/IEC 15944 are some helpful Annexes that provide elaboration on the points raised in the main body. Normative Annex A is a consolidated list of all the terms and definitions used in this part of ISO/IEC 15944 in both ISO English and ISO French. The other normative annex is Annex C, which is common to ISO/IEC 15944-2, ISO/IEC 15944-4, ISO/IEC 15944-5, and ISO/IEC 15944-8. Annex B is informative text providing more detailed background information on the REA Model. This part of ISO/IEC 15944 concludes with a bibliography.

Appendix B – REA Ontology

Note: The text of this annex has been adopted from the UN?/CEFACT Simple Guide to the UMM, 2003.

Introduction

Ontology, according to the most generally accepted e-commerce definition of that word, is a “specification of a conceptualization”. The REA (Resource-Event-Agent) ontology is a specification of the declarative semantics involved in a business process. The theory behind REA came initially from the field of accounting where REA was first introduced, but its components clearly have microeconomic origins with specific ties in many instances to the use of economic definitions in the practice of building enterprise-wide information systems. In UN/CEFACT work, all of the REA ontology definitions are applied to the collaborative space between enterprises where market exchanges occur in closely synchronized fashion among two or more trading partners.

In its most simple form without a high degree of precision, REA can be portrayed as a UML class diagram with associations and generalizations relating the object classes. The intent of this annex is to display REA simply and to explain its basic rationale. To do so, the annex will use a set of three figures (Figures B.1, B.2 and B.3), plus two summary figures. The most advanced of the UML diagrams (Figure B.3) is a good overall guide to the BRV semantics, given both here and in the Unified Modeling Methodology (UMM) of UN/CEFACT.

B.2 The Basic REA Ontology

The Basic REA model was first published in the July 1982 issue of The Accounting Review, the most prominent, most reliable, and most tightly controlled outlet for theoretical-based accounting work in the world. Its basic premises have withstood all theoretical challenges in the 20 years since, and its components are used extensively in a variety of educational, practical, and theoretical contexts. The REA model work was given the first (and thus far only) Seminal Contribution to the Accounting Information Systems Literature Award in 1996 by the American Accounting Association (AAA), and in 2003, its use as a model for teaching enterprise information systems was awarded the Innovation in Accounting Education Award, also from the AAA. There are a number of textbooks in worldwide use that feature REA as a pattern-oriented teaching framework.

Figure B.1 illustrates the basic class structure of REA ontology. The left-to-right configuration of economic Resources, economic Events, and economic Agents (renamed in UMM as “Partner”) in a typical business collaboration pattern is the source of the model’s REA name.

A successful business collaboration involves first and foremost two types of Economic Events, each of which details the Economic Resources involved in an exchange between two Trading Partners. For example, a Supplier (Trading Partner) transfers ownership of an Automobile (Economic Resource) to a Customer (Trading Partner) in return for which (duality association) the Customer will provide Money (Economic Resource) to the Supplier. There are two mirror-image instantiations of the object pattern shown in Figure B.1 where one transfer represents the legal or economic consideration given for the other.

Basic REA ontology

Figure B.1. Basic REA ontology.

The declarative semantics shown here are central to all trading relationships. Economic Resources are objects that have value and are under the control of one of the two collaborative agents. Trading partners always expect requited transfers of resources when they engage in commerce. Hence, Figure B.1 is a pattern for all economic exchanges.

B.3 Adding Commitments to the Basic Exchange Ontology

In electronic commerce, the actual trading phase of an exchange is accommodated well by the object structure shown above in Figure B.1. However, trading partners in long-term relationships need more trusted and predictable structures where both parties contract for their exchange behavior in advance. The REA ontology accommodates this expansion with the addition of the classes shown as Economic Commitments, Economic Contract, and Agreement in Figure B.2.

REA ontology with Commitments

Figure B.2. REA ontology with Commitments.

A Commitment is a promise by a Trading Partner to initiate an Economic Event in the future. Performing the Economic Events fulfills that Commitment. Commitments should always be reciprocated by the other Trading Partner who commits to initiate another type of Economic Event in return. An Economic Contract is a bundle of reciprocating commitments between Trading Partners who bind themselves to one or more economic exchanges in the future. A Contract is a subtype of the more general object class called Agreement, and Agreements can regulate other Agreements.

In the case of the automobile-for-money exchanges discussed in the prior section, Commitments would involve the Customer agreeing to accept delivery of an Automobile on a certain date in return for which he or she would be contractually obligated to making a series of Cash payments to the Supplier for that purchase.

In the bottom part of Figure B.2, two additional objects of the REA ontology are illustrated: Claims and Locations.

  • Materialization of Claims is sometimes needed when Trading Partners insist on documentation of partially completed exchanges (for example, when a Customer takes possession of an Automobile before paying for it in full). If needed, Claims can be instantiated by documents like invoices or by accounting artifacts like accounts-receivable. Their inclusion here is more a matter of business custom than ontological completeness.
  • A Location is another object that is sometimes needed to fill out the specification for a full economic transfer. Locations simply identify the place where Economic Events take place.

The economic and ontological foundations of commitments are explained more completely by Geerts and McCarthy.

Adding Types to the Basic REA Exchange Ontology

The object pattern portrayed in Figure B.2 above is primarily descriptive in the sense that it illustrates what actually occurred in an economic exchange or what has been committed to. In the UMM, these descriptive components have been augmented by prescriptive components that allow the specification of control policies or collaboration patterns. These prescriptive components are enabled by the inclusion of type images of the basic descriptive objects. The class diagram of Figure B.3 shows these additions.

The addition of Types to Figure B.3 proceeds in two stages:

  • The three base descriptive classes – Economic Resource, Economic Event, and Partner (Economic Agent) – have classes added for their types. These new classes are connected to the descriptive objects by typifies associations. An example of a Resource Type could be different models of automobiles. An example of Economic Event Type could be the classes of retail transaction and wholesale transactions, each with different pricing structures. An example of Partner Type could be different classes of employees, each type with separate training requirements. Additionally, the class Location is also typified. An example of Location Type might be different types of loading docks with different sizes and stress capability levels.
  • The full design of the Economic Commitment would necessitate associations between the commitment and each of the new type-level objects. These are illustrated in the figure with specifies associations.

REA Ontology with Types

Figure B.3. REA Ontology with Types.

In addition to these two groups of additions, there are other REA associations in the UMM that are not illustrated here in an effort to minimize diagram complexity. These include:

  • Contract – responsible – Partner
  • Economic Commitment – destination – Location
  • Partner – participates – Agreement
  • Partner – participates – Economic Commitment
  • Economic Commitment – reserves – Economic Resource

And finally with regard to Figure B.3, the partial integration of the elements of the REA ontology with the components of the UMM business collaboration framework is illustrated by showing the class for Business Collaboration (with dotted lines) and some of its associations with REA classes (also illustrated with dotted lines). Outside of its use with the UMM and the attendant specifications, the REA ontology has a three-level architecture that is explained by Geerts and McCarthy. In the UMM, this three-level architecture is effected by the integration of REA components within the business collaboration framework and by the connection of the Business Requirements View (BRV) to the Business Domain View (BDV) above it and the Business Transactions View (BTV) below it.

The Suitability of the REA Ontology within the Open-edi Model

The REA ontology is well known and well used throughout the field of accounting and to a lesser extent throughout the field of enterprise computing in general. It is the best example of a business domain ontology in existence today, and its measures well against the most commonly cited “ontology quality” criteria as proposed by Gomez-Perez. Her functional criteria and the REA explanation of their applicability are portrayed in Figure B.4. REA and Open-edi also fit very well together, as do REA and the Business Requirements View of the UN/CEFACT meta-model. Figure B.5 illustrates how these three systems correspond to each other on some very important points of emphasis. Continuing harmonization work with both the business process group and the core components group of UN/CEFACT is emphasizing these principles of commonality.

Functional Criteria REA Explanation
Does it express the consensus knowledge of a community of people? The original paper and all extensions since have been published in high quality refereed journals (The Accounting Review, IEEE Intelligent Systems, etc.) where its components are open to constant review and criticism. In 1996, the original paper was given the first Seminal Contribution to the Accounting Information Systems Literature Award by the American Accounting Association.  The Work was most recently awarded the 2003 Innovations in Accounting Education Award by the AAA.
Do people use it as a reference of precisely defined terms? The three leading textbooks on accounting systems analysis and design all use REA extensively to define system primitives and to explain modeling of accounting phenomena.
Is the language used expressive enough for people to say what they want to say? The REA primitives may be used to model any of the economic dealings of an enterprise.  The actual chain of entrepreneurial logic might itself be hard to explicate in a minority of cases (why for instance do firms support public charities or why is training important for employees?), but once those links are made at some level of granularity, REA primitives are able to document them.
Is it stable? The original paper was published in the top accounting journal in the world (The Accounting Review) in 1982.  No substantive criticisms of its features have been published in the intervening 20 years.
Can it be used to solve a variety of different sorts of problems or as a starting point to construct multiple sorts of applications? REA can be used to model and design the accounting components of software systems.  It has also been used to model external business processes or business collaborations for ebXML and TMWG of UN/CEFACT.  It has also been used to model inter-firm phenomena such as supply chains and to analyze the efficacy of a variety of enterprise software systems. Moreover, this documentation can be expressed at multiple levels of granularity, ranging from high level value chains and supply chains all the way down to the level of workflow tasks   The original model covered both inter- and intraenterprise transactions, but its use can be specialized for either case.

Figure B.4. Ontology criteria and the REA Ontology.

Overall Concept ISO Open-edi REA Ontology UN/CEFACT
Emphasis on “economic value” as foundation for business process and business collaboration definitions A business transaction pertains to the exchange of something of value Involves requited economic events wherein one economic resource –which is something of value under the control of an enterprise – is exchanged for another economic resource A business collaboration is an activity where one thing of measurable value is created, either as a service performed or as a product created
Designated “actors” or agents who participate in the economic activities within or between business enterprises Person is a legal or human entity having the ability to make commitments and to fulfill resulting obligations, and to be held accountable for those obligations Economic Agents include persons and agencies who participate in the economic events of the enterprise Partner is an actor in a business collaboration
The ability to make and impart information about “commitments” as a critical component of e-commerce A key property of a business transaction is that it involves commitment exchange among persons A commitment is an agreement to execute an economic event in a well-defined future that will result in either an increase of resources or a decrease of resources A commitment is an obligation to perform an economic event (that is, transfer ownership of a specified quantity of a specified resource type) at some future point in time
Preestablished patterns for different classes of e-commerce collaboration An Open-edi Scenario is a formal specification of a class of business transactions having the same business goal A scenario is a configuration of event types, resource types, commitment types, and agent types aggregated together Declarative Collaboration Patterns are being developed based on the BRV components of the UMM metamodel

Figure B.5. Correspondence of ISO, REA, and UN/CEFACT.

Next: ISO/IEC 15944-4 – Terms and definitions – 20071101

  1. Elements of the REA ontology as they are used in other standards work are explained in Annex B

ISO/IEC 15944-4 – Terms and definitions – 20071101

Scope

This part of ISO/IEC 15944 provides a set of UML class diagrams and conceptual explanations that circumscribe the Open-edi Business Transaction Ontology. It explains the mechanics of a business transaction state machine — the procedural component of an OeBTO — and the (internal) constraint component of OeBTO — its repository for business rules.

This part of ISO/IEC 15944 addresses collaborations among independent trading partners as defined in ISO/IEC 15944-1. This part of ISO/IEC 15944 applies to both binary collaborations (buyer and seller) and mediated collaborations (buyer, seller, third-party). The ontological features described herein propose standards only for the BOV — that is, the business aspects of business transactions as they are defined in ISO/IEC 15944-1.

Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the editiNoon cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 15944-1:2002, Information technology — Business agreement semantic descriptive techniques — Part 1: Operational aspects of Open-edi for implementation

ISO/IEC 15944-5:2006, Information technology — Business Operational View — Part 5: Identification and referencing of requirements of jurisdictional domains as sources of external constraints

Terms and definitions

agent

Person acting for another Person in a clearly specified capacity in the context of a business transaction

NOTE: Excluded here are agents as “automatons” (or robots, bobots, etc.). In ISO/IEC 14662, “automatons” are recognized and provided for but as part of the Functional Services View (FSV) where they are defined as an “Information Processing Domain (IPD)”.

[ISO/IEC 15944-1:2002 (3.1)]

attribute

characteristic of an object or entity

[ISO/IEC 11179-3:2003 (3.1.3)]

bilateral transaction

subtype of a business transaction where the Persons include only the buyer and the seller, or alternatively other Persons acting as agents for the buyer and/or seller

business

series of processes, each having a clearly understood purpose, involving more than one Person, realized through the exchange of recorded information and directed towards some mutually agreed upon goal, extending over a period of time

NOTE          Adapted from ISO/IEC 14662:2004 (3.1.2).

business event

occurrence in time that partners to a business transaction wish to monitor or control

NOTE 1: Business events are the workflow tasks that business partners need to accomplish to complete a business transaction among themselves. As business events occur, they cause a business transaction to move through its various phases of planning, identification, negotiation, actualization and post-actualization.

NOTE 2: Occurrences in time can either be internal as mutually agreed to among the parties to a business transaction; and/or, reference some common publicly available and recognized date/time referencing schema (e.g. one based on using ISO 8601 and/or ISO 19135).

business location geographic site where an economic event is deemed to occur with its attendant transfer of an economic resource from one Person to another

Business Operational View – BOV

perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among Persons, which are needed for the description of a business transaction [ISO/IEC 14662:2004 (3.1.3)

business transaction predefined set of activities and/or processes of Persons which is initiated by a Person to accomplish an explicitly shared business goal and terminated upon recognition of one of the agreed conclusions by all the involved Persons although some of the recognition may be implicit

NOTE: Adapted from ISO/IEC 14662:2004 (3.1.4).

business transaction entity

computable representation of any real-world entity that participates, occurs or is materialized during a business transaction

business transaction entity type

abstract specification of a business transaction entity, detailing its recommended characteristics, its recommended methods and its recommended life-cycle states

NOTE: A business transaction entity type will usually specify the types of business events that cause a business transaction entity of this type to proceed through its different states as the business transaction itself progresses through its phases of planning, identification, negotiation, actualization and post-actualization.

buyer

Person who aims to get possession of a good, service and/or right through providing an acceptable equivalent value, usually in money, to the Person providing such a good, service and/or right [ISO/IEC 15944-1:2002 (3.8)]

collaboration space

business activity space where an economic exchange of valued resources is viewed independently and not from the perspective of any business partner

NOTE: In collaboration space, an individual partner’s view of economic phenomena is de-emphasized. Thus, the use of common business and accounting terms like purchase, sale, cash receipt, cash disbursement, raw materials and finished goods is not allowed because they view resource flows from a participant’s perspective.

commitment

making or accepting of a right, obligation, liability or responsibility by a Person that is capable of enforcement in the jurisdiction in which the commitment is made

[ISO/IEC 15944-1:2002 (3.9)]

constraint

rule, explicitly stated, that prescribes, limits, governs or specifies any aspect of a business transaction

NOTE 1: Constraints are specified as rules forming part of components of Open-edi scenarios, i.e. as scenario attributes, roles and/or information bundles.

NOTE 2: For constraints to be registered for implementation in Open-edi, they must have unique and unambiguous identifiers.

NOTE 3: A constraint may be agreed to among parties (condition of contract) and is therefore considered an “internal constraint”. Or a constraint may be imposed on parties (e.g. laws, regulations, etc.) and is therefore considered an “external constraint”.

[ISO/IEC 15944-1:2002 (3.11)]

custody

association between a Person and an economic resource where the Person has physical control only over the resource or controls access

NOTE: Having custody of a good, service and/or right does not imply and is differentiated from having economic control of the same (e.g. a Person may have economic control of a good even though it is not under its custody).

data

business transaction〉 representations of recorded information that are being prepared or have been prepared in a form suitable for use in a computer system

[ISO/IEC 15944-1:2002 (3.14)]

defined market model

trade model where the buyer and seller accept the entry terms of a specified market in advance and where that market has an accepted and recognized source for business rules and conventions

NOTE: In a defined market, the phases of a business transaction — planning, identification, negotiation, actualization and post-actualization — are governed by the rules and conventions of the particular defined market.

duality

\association between economic events where one is the legal or economic consideration for the other in an exchange

NOTE: Duality is the conceptual analog of double entry in traditional bookkeeping. For example, a shipment from a partner requires a matching flow in, like a payment, to balance accounts between the parties.

economic agreement

arrangement of reciprocated economic commitments between two partners where the abstract specification of terms of trade is incomplete and not subject to legal enforcement

economic bundle

association between economic commitments and the economic contract that bundles those promises and binds them to the two partners who negotiated them

economic claim

expectation of one Person to receive a future inflow of economic resources from another Person because of an economic exchange which is currently incomplete

economic commitment

type of commitment by one Person to transfer economic resources to another Person at some specified point in the future

economic contract

bundling of reciprocated economic commitments between two partners where the abstract specification of the proposed economic exchange is deemed to be complete

economic control

association between a Person and an economic resource where the Person either owns the economic resource or is otherwise able to derive economic benefit (utility) from it

economic event

occurrence in time wherein ownership of an economic resource is transferred from one Person to another Person

NOTE: Occurrences in time can either be internal as mutually agreed to among the parties to a business transaction; and/or reference some common publicly available and recognized date/time referencing schema (e.g. one based on using ISO 8601 and/or ISO 19135).

economic event type

abstract specification of an economic event where its grouped properties can be designated without attachment to an actual, specific occurrence in time

NOTE: Example of attributes at the type level for events might be expected-duration or standard-pricing-percentage.

economic exchange

type of a business transaction where the goal is an exchange of economic resources between two Persons where both parties derive higher utility after the completed business transaction

NOTE: An economic exchange usually involves two economic events with different types of economic resources flowing in opposite directions. For example, an exchange of cash for a good involves a shipment with a requited payment following.

economic resource

good, right or service of value, under the control of a Person

economic resource type

abstract specification of an economic resource where its grouped properties can be designated without attachment to an actual, specific economic resource

NOTE: Example attributes at the type level for an economic resource like an automobile might include its designated fuel capacity or its maximum expected range.

economic role

abstract specification of a Person for economic purposes where its grouped properties can be designated without attachment to an actual Person

NOTE: An example economic role might be qualified buyer or approved shipper, i.e. from an economic perspective only.

economic specification

association between an economic commitment and the abstract properties of an economic event, an economic resource, a partner or a business location

entity

concrete or abstract thing that exists, did exist or might exist including associations among these things

EXAMPLE: A person, object, event, idea, process, etc.

NOTE: An entity exists whether data about it are available or not.

[ISO/IEC 2382-17:1999 (17.02.05)]

external constraint

constraint which takes precedence over internal constraints in a business transaction, i.e. is external to those agreed upon by the parties to a business transaction

NOTE 1: Normally external constraints are created by law, regulation, orders, treaties, conventions or similar instruments.

NOTE 2: Other sources of external constraints are those of a sectorial nature, those which pertain to a particular jurisdiction or mutually agreed to common business conventions (e.g. INCOTERMS, exchanges, etc.).

NOTE 3: External constraints can apply to the nature of the good, service and/or right provided in a business transaction.

NOTE 4: External constraints can demand that a party to a business transaction meet specific requirements of a particular role.

EXAMPLE 1: Only a qualified medical doctor may issue a prescription for a controlled drug.

EXAMPLE 2: Only an accredited share dealer may place transactions on the New York Stock Exchange.

EXAMPLE 3: Hazardous wastes may only be conveyed by a licensed enterprise.

NOTE 5: Where the information bundles (IBs), including their Semantic Components (SCs), of a business transaction are also to form the whole of a business transaction (e.g. for legal or audit purposes), all constraints must be recorded.

EXAMPLE: There may be a legal or audit requirement to maintain the complete set of recorded information pertaining to a business transaction, i.e. as the information bundles exchanged, as a “record”.

NOTE 6: A minimum external constraint applicable to a business transaction often requires one to differentiate whether the Person, i.e. that is a party to a business transaction, is an “individual”, “organization” or “public administration”. For example, privacy rights apply only to a Person as an “individual”.

[ISO/IEC 15944-1:2002 (3.23)]

fulfillment

association between an economic commitment and an economic event where the event executes the promised resource flow from one Person to another

NOTE: For example, a delivery to a customer would fulfill that customer’s sale order.

governed

association between an economic agreement and the business transaction whose conduct and phases are subject to that economic agreement

individual

Person who is a human being, i.e. a natural person, who acts as a distinct indivisible entity or is considered as such

[ISO/IEC 15944-1:2002 (3.28)]

information bundle – IB

formal description of the semantics of the information to be exchanged by Open-edi Parties playing roles in an Open-edi scenario

[ISO/IEC 14662:2004 (4.1.2.2)]

internal constraint

constraint which forms part of the commitment(s) mutually agreed to among the parties to a business transaction

NOTE: Internal constraints are self-imposed. They provide a simplified view for modeling and re-use of scenario components of a business transaction for which there are no external constraints or restrictions on the nature of the conduct of a business transaction other than those mutually agreed to by the buyer and seller.

[ISO/IEC 15944-1:2002 (3.33)]

location type

abstract specification of an economic location where its grouped properties can be designated without attachment to an actual place

NOTE: An example location type might be an accepted shipping facility or approved hospital location.

materialized

association between an economic event and an economic claim where the occurrence of the economic event causes the economic claim to come into existence

mediated transaction

subtype of a business transaction where a third party mediates between the partners as mutually agreed to by the partners

object

anything perceivable or conceivable

NOTE: Objects may be material (e.g. an engine, a sheet of paper, a diamond), immaterial (e.g. a conversion ratio, a project plan) or imagined (e.g. a unicorn).

[ISO 1087-1:2000 (3.1.1)]

Open-edi

electronic data interchange among multiple autonomous Persons to accomplish an explicit shared business goal according to Open-edi standards

[ISO/IEC 14662:2004 (3.1.9)]

Open-edi Business Transaction Ontology – OeBTO

formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among those concepts

Open-edi Party – OeP

Person that participates in Open-edi

NOTE 1: Adapted from ISO/IEC 14662:2004 (3.1.11).

NOTE 2: Often in ISO/IEC 15944 referred to generically as “party” or “parties” for any entity modeled as a Person as playing a role in Open-edi scenarios.

Open-edi scenario – OeS

formal specification of a class of business transactions having the same business goal [ISO/IEC 14662:2004 (3.1.12)]

organization

unique framework of authority within which a person or persons act, or are designated to act, towards some purpose

NOTE: The kinds of organizations covered by this part of ISO/IEC 15944 include the following examples:

  • an organization incorporated under law;
  • an unincorporated organization or activity providing goods and/or services including:
    • partnerships,
    • social or other non-profit organizations or similar bodies in which ownership or control is vested in a group of individuals,
    • sole proprietorships,
    • governmental bodies;
  • groupings of the above types of organizations where there is a need to identify these in information interchange. [ISO/IEC 6523-1:1998 (3.1)]
  • organization part department, service or other entity within an organization, which needs to be identified for information interchange

[ISO/IEC 6523-1:1998 (3.2)]

organization Person

organization part which has the properties of a Person and thus is able to make commitments on behalf of that organization

NOTE 1: An organization can have one or more organization Persons.

NOTE 2: An organization Person is deemed to represent and act on behalf of the organization and to do so in a specified capacity.

NOTE 3: An organization Person can be a “natural person” such as an employee or officer of the organization.

NOTE 4: An organization Person can be a legal person, i.e. another organization.

[ISO/IEC 15944-1:2002 (3.46)]

participates

association between an economic event and each of the two Persons participating in the economic event

NOTE; Usually there is a “from” association and a “to” association, depending upon the direction of the flow of the economic resource.

partner

subtype of Person that includes buyer and seller

Person

entity, i.e. a natural or legal person, recognized by law as having legal rights and duties, able to make commitment(s), assume and fulfill resulting obligation(s), and able to be held accountable for its action(s)

NOTE 1: Synonyms for “legal person” include “artificial person”, “body corporate”, etc., depending on the terminology used in competent jurisdictions.

NOTE 2: Person is capitalized to indicate that it is being utilized as formally defined in the standards and to differentiate it from its day-to-day use.

NOTE 3: Minimum and common external constraints applicable to a business transaction often require one to differentiate among three common subtypes of Person, namely “individual”, “organization” and “public administration”. [ISO/IEC 15944-1:2002 (3.47)]

process

series of actions or events taking place in a defined manner leading to the accomplishment of an expected result

[ISO/IEC 15944-1:2002 (3.53)]

public administration entity

a Person, which is an organization and has the added attribute of being authorized to act on behalf of a regulator

[ISO/IEC 15944-1:2002 (3.54)]

reciprocal

association between economic commitments where the promise by one partner to execute an economic resource transfer in the future is reciprocated by the other partner promising a requited transfer in the opposite direction

recorded information

information that is recorded on or in a medium irrespective of form, recording medium or technology utilized, and in a manner allowing for storage and retrieval

NOTE 1: This is a generic definition and is independent of any ontology (e.g. those of “facts” versus “data” versus “information” versus “intelligence” versus “knowledge”, etc.).

NOTE 2: Through the use of the term “information”, all attributes of this term are inherited in this definition.

NOTE 3: This definition covers: any form of recorded information, means of recording, and any medium on which information can be recorded; and all types of recorded information including all data types, instructions or software, databases, etc.

[ISO/IEC 15944-1:2002 (3.56)]

regulator

Person who has the authority to prescribe external constraints which serve as principles, policies or rules governing or prescribing the behavior of Persons involved in a business transaction as well as the provisioning of goods, services and/or rights interchanged

[ISO/IEC 15944-1:2002 (3.59)]

resource-flow

association between an economic event and an economic resource

NOTE: A common example would be a resource-flow between some inventory and the shipment that caused control of that inventory to flow from one Person to another.

responsibility

association between Persons where one is responsible for the other or between a Person and an organization Person where that Person is assigned

NOTE Subtypes of Persons include individuals, organizations and public administrations. An “individual” is nondivisible but organizations and public administrations are and as such will assign specific responsibilities to organization Persons (see further 6.2.7 and Figure 17 in ISO/IEC 15944-1:2002).

role

specification which models an external intended behaviour (as allowed within a scenario) of an Open-edi Party

[ISO/IEC 14662:2004 (4.1.2.1)]  

seller

Person who aims to hand over voluntarily or in response to a demand or a request, a good, service and/or right to another Person and in return receives an acceptable equivalent value, usually in money, for the good, service and/or right provided

[ISO/IEC 15944-1:2002 (3.62)]

Semantic Component – SC

unit of recorded information unambiguously defined in the context of the business goal of the business transaction

NOTE: An SC may be atomic or composed of other SCs.

[ISO/IEC 14662:2004 (4.1.2.2)]

settlement

association between a requiting economic event and an economic claim where the occurrence of the event causes the economic claim to expire

site

association between an economic event and the business location where the transfer of economic resources involved in that event is deemed to have occurred

third party

Person besides the two primarily concerned in a business transaction who is agent of neither and who fulfills a specified role or function as mutually agreed to by the two primary Persons or as a result of external constraints

NOTE: It is understood that more than two Persons can at times be primary parties in a business transaction.

[ISO/IEC 15944-1:2002 (3.65)]

typification

association between a concrete entity and the abstract specification of its grouped properties

undefined market mode

trade model where participants are not registered in advance and where that market does not have accepted and recognized sources for business rules and conventions

Abbreviated terms

BOV Business Operational View
BTE Business Transaction Entity
BTET Business Transaction Entity Type
ebXML electronic business eXtended Markup Language
ECIMF E-Commerce Integration Meta-Framework
EDI Electronic Data Interchange
IB Information Bundle
OCL Object Constraint Language
OeBTO Open-edi Business Transaction Ontology
OeP Open-edi Party
OeS Open-edi Scenario
REA Resource-Event-Agent
SC Semantic Component
UML Unified Modeling Language
UMM Uniform Modeling Methodology
UN United Nations
UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business

Previous: ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Introduction – 20071101
Next: ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Declarative component of an OeBTO – 20071101

ISO/IEC 15944-4 – The declarative component of an OeBTO- 20071101

An ontology has a declarative component – which specifies the categories into which collaboration data exchanged among Persons in a business transaction may be slotted; a procedural component – which specifies how that data is to be used in deriving conclusions; and a constraint component – which specifies the business rules for both data and procedures.

Primitive and Derived Data Classes

Persons and Economic Resources

One of the most fundamental ideas in Open-edi is the category of Person as an entity recognized as having legal rights and duties, able to make commitments, and fulfill resulting obligations. Based on applicable external constraints, a Person can be decomposed into three separate subtypes, namely, “individual”, “organization”, and “public administration” 1. These subtypes are illustrated in the UML class diagram of Figure 1.

In this part of ISO/IEC 15944, the focus is on the OeBTO from an internal constraints perspective only 2. However, users of this part of ISO/IEC 15944 should note that where and whenever Person is utilized, it covers the three sub-types of individual, organization, and public administration.

Subtypes of Person based on External Constraints

Figure 1. Subtypes of Person based on External Constraints.

Rule 1:

Irrespective of the use of any particular information technology and related devices, Persons are the only entities which are legally recognized as able to make commitments, agree to the rights and obligations entered into, can be held accountable for their actions, etc., i.e. Persons are the only entities able to participate in a business transaction and able to make commitments for exchanges of value 3.

Persons are the entities who drive the economic exchanges forward in Open-edi collaborations. Ontologically and normatively, they are considered as homo economicus in the classical microeconomic sense; that is, they are parties interested in commercial activity as a means of maximizing utility.

Besides Person, a second very important notion in the OeBTO is the concept of an Economic Resource which is something of value under the control of a Person. These two fundamental categories appear on the left of Figure 2, connected by an economic control relationship which indicates that the Person either owns the resource or is otherwise able to derive economic value (utility) from it.

Person and Economic Resource as the Basis for Exchange

Figure 2. Person and Economic Resource as the Basis for Exchange.

Onto the right side of Figure 2 (inside the dotted lines) is now added an additional Person and economic resource association, thus setting the stage for a possible exchange where both parties might view control of the other Person’s resource as a means of deriving higher utility than present circumstances render. This “value exchange” as it is titled in the collaboration space (Figure 3 of previous post) is the basis for what Open-edi calls a business transaction between the two Persons.

Rule 2:

An Open-edi Business Transaction is an economic exchange occasioned by the presence of two

Persons as trading partners, each possessing a resource of value desirable to the other party. These Persons shall be autonomous parties with competing economic interests, able to commit to a requited exchange with the other Person.

The Open-edi Business Transaction Ontology does not construct exhaustive classification hierarchies for the primitive classes of Person and economic resource, but it does provide a limited taxonomy for both. The hierarchical decomposition of both of these ontology items beyond 2-3 levels becomes very dependent upon the context of industry structure. Particular de-compositions beyond the second or third level may be joined to the minimum classification structures illustrated here to give more detailed taxonomies for a particular industry domain.

In addition to being classified on identity, Persons may also be classified on the basis of their roles, which are the abstract specification of the functions they perform in business transactions. This functional decomposition through three levels is illustrated in the UML class diagram of Figure 3 and explained below.

  • Partner which itself further specializes to Buyer (has money, desires goods) and Seller (has goods, desires money).
  • Regulator which represents Persons who impose external constraints on Business Transactions.
  • Third Party which specializes to a number of other classes such as Escrow, Guarantor, Mediator, and
  • Agent which is a special sub-type in Open-edi that can act for any other Person in a clearly specified capacity, most commonly for a buyer or a seller.

Subtypes of Person based on Roles in a Business Transaction

Figure 3. Subtypes of Person based on Roles in a Business Transaction.

When fully-specified business transactions occur, Persons are able to play roles as indicated by the different sub-typing shown in Figure 3. Again, this taxonomy could be extended with industry-specific specializations of these role levels 4.

Figure 4 illustrates some of the possible sub-typing for the other OeBTO primitive – economic resource – illustrated in Figure 2. This taxonomy has a second level derived directly from the text of 15944-1 which categorizes resources as:

  • Goods which are tangible resources to include: o Materials including capital assets (like trucks), basic raw materials and natural resources (like steel or petroleum) plus sub-components of a larger assembled product (like seats for an automobile).
    • Real Estate like office buildings or warehouses.
    • Funds like money or marketable securities.
  • Services which are the provision of value-adding activities by a provider to a consumer to include:
    • Human Services like temporary workers or consultants. o Transportation Services like packing/picking or actual shipments.
    • Regulatory Services such as the right to import/export or the right to do business in a certain segment or area.
    • Warranty Services such as the automatic provision of replacement goods under faulty judgments.
    • Insurance Services such as guaranteed payment under exigent circumstances.
    • Rights which are intangible resources to include examples like Intellectual Products (IPR) and Rightsof-way 5.

ISO 15944-4 Figure 7 Subtypes -possible- for Economic Resource

Figure 4. Subtypes (possible) for Economic Resource.

Rule 3:

Economic Resources may be classified as goods, rights, or services. Particular industry level classifications can further specialize this first level of decomposition.

Figure 4 also shows a recursive association that is especially important in ontological terms because it reflects an important aspect of economic reality – that economic resources often have component structures. This means that their value is often derived from an assemblage of other resources.  For a product example, those components could be the physical material, its advertised cache, its delivered-to-the-door-status, and its warranty.

Rule 4:

Economic Resources in the vast majority of trading cases will have component structures that can be identified and treated differentially in economic exchanges.

As an example of the logic of Rule 4, example goods that are termed free-on-board at source (FOB source) would be missing a delivery component that free-on-board destination (FOB destination) would have included.

In Open-edi, a business transaction involves an economic exchange of resources between Persons with competing economic interests, each attempting to maximize his or her own economic utility. As portrayed in 15944-1 and shown in Figure 5, there are two additional fundamental elements of a Business Transaction Model besides PERSON (discussed amply above). The first of these is the DATA involved in the transaction, and the ontological categories for capturing that data will be the topic for the rest of this Clause 5. The other fundamental element is the PROCESS involved in a business transaction and that will be the main topic for the following Clause 6. Clause 7 illustrates the constraint component where the business rules concerning both data and processes are enumerated.

Fundamental parts of a business transaction

Figure 5. Fundamental parts of a business transaction.

Normative Data Categories for a Business Transaction involving an Economic Exchange: Resources, Events, and Persons plus their fundamental Relationships

The UML class diagram of Figure 6 illustrates the high level semantic view of the essentials of an economic exchange. In Open-edi, the full details of this exchange are realized within the scope of a single business transaction as trading partners identify each other, negotiate commitments, and engage in the actual exchange of resources with value.

As a starting point for ontological definition, this collaboration space diagram concentrates on the object answers to four fundamental questions:

  • Who is involved in the collaboration (Persons)?
  • What is being exchanged in the collaboration (Economic Resources)?
  • When (and under what trading conditions) do the components of the exchange occur (Economic Events)?
  • Why are the trading partners engaged in the collaboration (duality relationships between resource flows)?

The normative infrastructure of the Open-edi Business Transaction Ontology (OeBTO) encompasses these essential question components, as explained in Addition of Business Event to Basic Exchange Pattern below. Extension of the OeBTO into Types below illustrates the ontological components that result from typifying the OeBTO normative infrastructure, while Locations and Claims below deals with the non-normative extensions of claims and business locations. Adding Commitments to Economic Exchanges below discusses the elaborate commitment structures of the OeBTO, and Business Transactions with Contracts below accounts for the extended ontology objects of scenarios and markets.

Figure 6 illustrates the basic economic primitives of OeBTO in a UML class diagram. An actual value exchange in the collaboration space of Open-edi between a buyer and a seller would involve two instances of this object pattern. That is, there would a resource-event-person pattern instance for an initial resource transfer from one partner to the other; this would then be followed by a connected (with duality associations) resource-event-person pattern instance for a requiting resource transfer. A full example of this is shown in Figure 7 with a delivery of product followed by a payment of cash. In very general terms, a full economic exchange of value in collaboration space is defined as a Business Transaction in the Open-edi ontology. It is important to remember that Bilateral Transactions between a buyer and a seller constitute the basic collaborative unit in Open-edi. These bilateral transactions may be aggregated to Mediated Transactions involving more than two Persons.

Basic exchange primitives of the Open-edi Ontology

Figure 6. Basic exchange primitives of the Open-edi Ontology.

Exchange of value in collaboration space involves two symmetrical Resource-Event-Agent clusters

Figure 7. Exchange of value in collaboration space involves two symmetrical Resource-Event-Agent clusters.

Entity Definitions:

  1. A Person is a natural or legal person unit empowered to control the flow of economic resources (including his or her own labor) by engaging in economic events. Persons are also empowered to make commitments or promises to execute resource flows in the future. The Person class may also include persons who are responsible for subordinates’ participation in economic events. A subset of Person is Partner; partners are Persons who play the leading roles in business transactions as sellers and buyers (or alternatively, as producers and consumers of services).
  2. An Economic Resource is a scarce good, right, or service that possesses utility (economic value) and that is presently under the identifiable control of a particular Person.
  3. An Economic Event most simply is an inflow or outflow of an economic resource. Economic events reflect changes in economic resources resulting from exchanges, conversions, or transportation.

Relationship Definitions:

  1. A resource-flow relationship is an association between an economic resource and an economic event. From the independent perspective, resource-flow instances are matched in bi-directional fashion with each party both giving and taking in the same exchange.
  2. A participates relationship is an association between a Person and an economic event. Economic events normally have two participates relationships with independent parties who have competing economic interests (that is, they are said to have an arm’s length relationship with each other). One of these is specialized on the class diagram of Figure 6 as “from” and the other as “to”, indicating again the independent perspective of collaboration.
  3. A duality relationship is an association between two (or more) economic events where one is the economic or legal consideration for the other in an economic exchange. Dualities are needed for every binary component of mediated transactions.
  4. A custody relationship is an association between a Person and an economic resource where physical control or access to physical control possession is indicated.
  5. Responsibility is a relationship between (among) two or more Persons. These responsibility associations indicate hierarchical orderings within an enterprise that are necessarily revealed to trading partners in a collaboration model.

Rule 5:

The minimum normative constellation of business transaction entities needed for a valid business transaction includes Economic Resources, Economic Events, and Persons plus their exchange relationships (resource-flow, duality, and participates).

Rule 6:

Custody and responsibility relationships are not required for a valid economic exchange, but they provide critical additional data to the basic exchange template.

Addition of Business Event to Basic Exchange Pattern:

In Figure 8, the primitive Business Event has been added to the basic OeBT ontology pattern in a UML class diagram. A business event is an occurrence in time in collaboration space that Persons wish to plan, control, monitor, or evaluate. To bring about the occurrence of an economic event, it is often necessary to perform multiple business events. Additionally, business events may also be aggregates of other, finer-grained business events, so the UML component structure for a business workflow is shown as recursive business events. In a state machine sense where many elements of the OeBTO become business transaction entities (representing business transaction entity types as explained in Clause 6) with defined object states and defined object lifecycles, a business event can be defined more precisely as an occurrence that causes a state change in one or more business transaction entities.

Rule 7:

Business Events can either occur instantaneously or have duration. For a business event that has duration, it will be possible to specify as its components, both starting and finishing events of instantaneous nature.

Addition of Business Event to Basic Business Transaction Pattern

Figure 8. Addition of Business Event to Basic Business Transaction Pattern.

Extension of the OeBTO into Types

Abstract concepts are information structures used to describe the intangible components of actual phenomena. For ontologists, this is an important distinction. In the OeBT ontology, “type images” are used to represent the abstract structure of economic phenomena. For the construction of abstract concepts, the common abstraction mechanism of typification is used.6  This abstraction method is portrayed in Figure 9.

The bottom of Figure 9 represents things that really exist or have actually happened, like a digital product or some real material or an event that has transferred ownership of such resources. In concrete economic terms, this is where accountability for past and near future activities lies. At the top of the figure is where policies are specified in terms of the abstract economic future: things that could be or should happen. Typification works by abstractly specifying the grouped properties of real things, and policies can then be derived by associating those abstract entities.

In the UML class diagram of Figure 10, three of the economic primitives defined previously (Economic Resource, Economic Event, and Person), are typified to produce their abstract specification classes shown at the top of the figure (Economic Resource Type, Economic Event Type, and Economic Role).

Abstract specification with typification

Figure 9. Abstract specification with typification.

When type images are connected with each other as illustrated in the top constellation of Figure 10, policy artifacts often emerge, such as the association between an Economic Event Type (for example, large amount sales) and an Economic Role (such as the managerial position needed to authorize such a class of transactions). This kind of abstract specification is especially important to the pre-actualization components (planning, identification, and negotiation) of an Open-edi business transaction. For example, parties often specify in advance the types of goods they desire to be shipped under different delivery categories by different types of shipping agencies. Typification is strongly linked to the concept of Open-edi Scenarios which are formal specifications of particular classes of business transactions designed for reusability. As discussed in Clause 6, connected type images also result many times in control artifacts such as the rules embodied in internal and external Open-edi constraints. Such constraints supply pre- and post-conditions on state machine transitions.

Type connections for policy and planning

Figure 10. Type connections for policy and planning.

Typification is a non-normative extension of the components of a basic economic exchange. Connecting typified entities specifies the abstract rules or business policies under which business transactions occur.

Locations and Claims

The UML class diagram of Figure 11 illustrates two non-normative additions to the basic Open-edi ontological framework.

  1. A Business Location designates the site where an economic event occurs if such information is needed. Locations also indicate the targeted delivery points for Economic Commitments. Location Types indicate grouped instances like an approved kind of delivery warehouse or an acceptable medical facility.
  2. An Economic Claim is an optional materialization of a temporal imbalance in a duality relationship where an economic event has occurred without its requited correspondence to another economic event. An initial economic event materializes the claim, while the requiting economic event settles it.

Addition of Business Location and Economic Claim

Figure 11. Addition of Business Location and Economic Claim.

Adding Commitments to Economic Exchanges

In the Open-edi ontology, a business transaction pertains to the exchange of something of value as illustrated in the delivery-payment example of Figure 10. An additional key property of an Open-edi business transaction is that it involves commitment exchange as illustrated in Figure 12. In economic terms however, commitments do not occur in isolation because partners simply do not agree to value exchanges without reciprocation. Commitments are bundled in Economic Contracts between trading partners where, for example, a commitment to deliver some product is reciprocated by a commitment to pay cash.

Contract as a Bundle of Commitments

Figure 12. Contract as a Bundle of Commitments.

Rule 9:

Economic commitments are fulfilled by economic events; these commitments are the promised analog of economic events which are connected by duality relationships. Thus, commitments also occur in reciprocal pairs where the promise of one party is requited by the promise of the other.

In Figure 13, the ex ante nature of commitments is illustrated further. At a minimum, an Open-edi economic commitment should specify the type of economic resource expected in the fulfilling economic event. For example, a catalogue order chooses from a product list for delivery. Additionally, the economic commitment often will specify:

  1. the type of event to fulfill it (such as an expedited delivery or a purchase under wholesale pricing), and
  2. the business roles needed in the eventual exchange (such as a buyer, a seller, a seller agent, and a third-party escrow).

Economic commitments may less commonly specify types of locations, like an approved class of warehouse.

 Abstract specification of Commitments

Figure 13.  Abstract specification of Commitments.

Business Transactions with Contracts

The UML class diagram of Figure 14 formally adds Economic Commitment structures to the basic notion of an economic exchange. As mentioned previously, commitment is one of the defining features of Open-edi, so these structures are extremely important ontological components.

  1. An Economic Commitment is a promise to execute an Economic Event at some point in the future. The specification of an Economic Commitment may involve relationships with four type-level classes: Economic Resource Type, Location Type, Economic Event Type, and Economic Role. Economic Commitments may also have relationships with Economic Resource (reserves), Person (participate), and Business Location (target).
  2. A fulfillment relationship is an association between an Economic Commitment and the Economic Event that executes that commitment.
  3. A reciprocal relationship is an association between Economic Commitments that each in turn individually fulfills compensating economic events.
  4. An Economic Contract is a bundle of reciprocating commitments wherein two Parties agree to a future schedule of exchanges with compensating economic events. An Agreement is similar to an economic contract, but it is not legally enforceable.
  5. An economic bundle relationship is an association between an Economic Contract and its pair of reciprocal Economic Commitments.

Business Transaction Model with Bundled Commitments

Figure 14. Business Transaction Model with Bundled Commitments.

Rule 10:

An Economic Contract is a reification of the reciprocal relationship among groups of Economic Commitments. When the paired commitments have simple structures and there are no legal needs for a formal agreement, the Economic Contract entity becomes optional.

Figure 15 illustrates the full addition of the “commitments to type specification” by combining Figures 13 and 14. Additionally, it extends the concept of a Bilateral Transaction to that of a Mediated Transaction by including the previously-defined Third Party subtype of Person as an essential ingredient of mediated collaborations. Figure 15 also indicates the essential roles of Regulators who are Persons who constrain business transactions.

Collaboration with Commitment structures

Figure 15. Collaboration with Commitment structures.

Rule 11:

A Bilateral Business Transaction includes just the two basic kinds of Partner: the Buyer and the Seller (or an Agent for one or both). Mediated Business Collaborations involve the participation of a Third Party like a Guarantor or a Notary.

Rule 12:

All Open-edi business transactions, which include the modeling of external constraints in addition to internal constraints only, are subject to the participation of a Regulator – a Person with the authority to prescribe external constraints which serve as principles or rules governing the behavior of other types of participants in a business transaction.

Typifying Agreements and Business Transactions

Figure 16 and Figure 17 illustrate typification of Economic Agreements and Business Transactions.

  1. All Business Transactions are set in both Defined Markets and Undefined Markets, both of which are overseen by various Jurisdictional Domains.
  2. Business Transactions may be classified into different kinds of Open-edi Scenarios such as the 2x2x2 (overall giving eight combinations) factoring shown in the cloud at the bottom of Figure 16. 7.

An Agreement can be decomposed into classes like Leases/Rentals, Service Agreements, Consignments, and Purchases. Agreements have Pricing Methods like reverse auctions, open and closed bids, and individual quotes. These methods can in turn be typified into classes (Pricing) like bid, auction, or matching. These are all illustrated in Figure 17.

The modeling specifications illustrated in Figure 1 through Figure 17 give specific conceptual definition to many of the Open-edi Business Transaction terms used in ISO/IEC 15944-1. In the following clause, the behavioral use of these components is explained with explicit reference to the Open-edi notion of business transaction phases. According to ISO/IEC 15944-1, a business transaction proceeds through the stages of planning, identification, negotiation, actualization, and post-actualization, and an ontologically-based state machine model of this progress is explained there.

Addition of markets and scenarios for Business Transactions

Figure 16. Addition of markets and scenarios for Business Transactions.

Agreement Types with Pricing Methods

Figure 17. Agreement Types with Pricing Methods.

Previous: ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Terms and definitions – 20071101
Next: ISO/IEC 15944-4 – The procedural component of an OeBTO – 20071101

  1.   See further in ISO/IEC 15944-1:2002, 6.2 “Rules governing Person” and in particular, 6.2.7 “Person and external contraints: individual, organization and public administration.”
  2.   With respect to incorporating external constraints, see further ISO/IEC 15944-5:2006; in particular, see 5.2.2 “Collaboration space — internal constraints only” and 5.2.3 “Collaboration space — the role of ‘regulator’ representing “external contraints”, and Annex G.
  3.  Rule 1 is based on ISO/IEC 15944-1:2002, 6.2, Rule 11.
  4.  Because of this industry specificity, these hierarchical decompositions should be viewed as informative rather than normative. This is especially true of the decomposition of “third party” where industry specificity gives rise to many different types of role names.
  5.  Again as in Figure 3, these hierarchical de-compositions should be viewed as informative rather than normative. This is especially true of the third level decomposition in Figure 4 which is clearly designed as an example enumeration.
  6. For an explanation of typification, see Geerts, GL and McCarthy, WE – Using object templates from the REA Enterprise Information Systems, Journal of Information Systems, 2006
  7. A more complete explanation of this classification scheme for Open-edi Scenarios is given in ISO/IEC 15944-2

ISO/IEC 15994-4 – The procedural component of an OeBTO – 20071101

An ontology has a declarative component – which specifies the categories into which collaboration data exchanged among Persons in a business transaction may be slotted; a procedural component – which specifies how that data is to be used in deriving conclusions; and a constraint component – which specifies the business rules for both data and procedures.

In an operational use of the Open-edi Business Transaction Ontology, the various declarative components specified in Clause 5 – for example all of the classes illustrated in Figure 15 – become defined as Business Transaction Entity Types (BTET). BTETs represent the abstract specification of Business Transaction Entities (BTE), detailing their recommended attributes, their recommended methods, and their recommended life-cycle states. Additionally, a business transaction entity type will usually specify the types of business events that cause a BTE of this type to proceed through its different states as the business transaction itself progresses through its own phases of planning, identification, negotiation, actualization, and post-actualization. A BTE thus is a particular real instance of a business transaction entity type.

Rule 13:

A Business Transaction Entity (BTE) is the computable representation of any real world entity that participates, occurs, or is materialized during a particular business transaction. For procedural materialization of conclusions during the business transaction, the combined use of the BTE attributes, methods, and states may be used to determine its status as a component in an economic exchange.

Relating Ontological Components to the Open-edi Business Transaction Phases

From ISO/IEC 15944-1, the paragraphs below enumerate the five identified phases of an Open-edi Business Transaction. This phase specification is one of the major building blocks of ISO/IEC 15944-1.

  1. Planning: In the Planning Phase, both the buyer and seller are engaged in activities to decide what action to take for acquiring or selling a good, service, and/or right.
  2. Identification: The Identification Phase pertains to all those actions or events whereby data is interchanged among potential buyers and sellers in order to establish a one-to-one linkage.
  3. Negotiation: The Negotiation Phase pertains to all those actions and events involving the exchange of information following the Identification Phase where a potential buyer and seller have:
    1. identified the nature of good(s) and/or service(s) to be provided; and,
    2. identified each other at a level of certainty. The process of negotiation is directed at achieving an explicit, mutually understood, and agreed upon goal of a business collaboration and associated terms and conditions. This may include such things as the detailed specification of the good, service, and/or right, quantity, pricing, after sales servicing, delivery requirements, financing, use of agents and/or third parties, etc.
  4. Actualization: The Actualization Phase pertains to all activities or events necessary for the execution of the results of the negotiation for an actual business transaction. Normally the seller produces or assembles the goods, starts providing the services, prepares and completes the delivery of good, service, and/or right, etc., to the buyer as agreed according to the terms and conditions agreed upon at the termination of the Negotiation Phase. Likewise, the buyer begins the transfer of acceptable equivalent value, usually in money, to the seller providing the good, service, and/or right.
  5. Post-Actualization: The Post-Actualization Phase includes all of the activities or events and associated exchanges of information that occur between the buyer and the seller after the agreed upon good, service, and/or right is deemed to have been delivered. These can be activities pertaining to warranty coverage, service after sales, post-sales financing such as monthly payments or other financial arrangements, consumer complaint handling and redress or some general post-actualization relationships between buyer and seller.

Rule 14:

Conceptually, a business transaction can be considered to be constructed from a set of fundamental activities. They are planning, identification, negotiation, actualization and post-actualization.

Figure 18 adds the definition of these Business Transaction Phases to the OeBTO declarative primitives for a bilateral collaboration.

Open-edi Ontology with Business Transaction Phases and Business Events

Figure 18. Open-edi Ontology with Business Transaction Phases and Business Events.

Figure 18 also specifies that these Open-edi business process phases have Business Events as components, illustrating the behavioral progress through each phase as marked by collaborative activities. A Business Event is defined as an occurrence in time that partners to a business transaction wish to monitor or control.  Business events are the fuel that drives a business transaction state machine, as they progress that dynamic representation through its five phases by changing the states of the ontological components illustrated in Figure 18. Additionally, Business Events have component structures as illustrated by the recursive relationships in Figure 18, and this facilitates the modeling of activities in business collaboration space at whatever level of granularity is needed. Business Event components of instant duration can drive the state of a higher-level Business Event with extended duration from start to completion, and that higher level component may then effect a state change in one of the other Business Transaction Entities for a particular transaction.

Figure 19 illustrates the approximate correspondence of the Open-edi Business Transaction phases with the categories of ontological components defined in Clause 5.

ISO Open-edi Phases with Components

Figure 19. ISO Open-edi Phases with Components.

  • Planning and Identification involve business events wherein potential buyers and sellers identify each other by matching on proposed types of resources to be exchanged and their actual trading partners.
  • Negotiation involves business events wherein linked business partners cooperate on the abstract specification of their proposed exchange (its type of resources, events, and roles as stipulated in a contract).
  • Actualization and Post-Actualization involve business events that aggregate to the performance of resource transfers (the actual economic events) between the buyer and seller.

Business Events are the specific activities that mark the explicit states that trading partners expose to each other as they complete an exchange. For example, supplying a quote on a listed product during negotiation may progress an Economic Commitment from status (or state) “unspecified” to “proposed” while simultaneously marking a Resource Type and an Event Type as “specified”. If this Business Event of supplying a quote was followed by a quote acceptance and then a payment terms acceptance, an Economic Contract might move into status “in-force” and then the entire Negotiation Phase might move into state “completed”. This completed negotiation would keep the entire Business Transaction in state “in progress”, whereas an unsuccessful negotiation might have moved the overall Business Transaction into state “aborted” or state “suspended”.

Rule 15:

Business Events are the activities or messages that collaborative business partners use to communicate their progress through a Business Transaction.

Figure 20 portrays the individual phases of a Business Transaction and the targeted object states that would signal to each business partner that a particular phase was now complete.

  1. Planning is complete when both trading partners have formulated an abstract vision of an exchange. This involves moving the entities representing the potential partner and the potential type of resource into “candidate” states.
  2. Identification is complete when the corresponding partners have been identified along with their identified resource types. This establishes a 1-to-1 linkage between the partners concerning a common trading interest.
  3. Negotiation is complete when the abstract specification of economic commitments is done and when all the commitments and a contract move to an “in-force” condition. Generally, this would mean that the entities for the types of resources to be exchanged are in state “specified”. It could also mean that economic specifications are complete for the type of event, the economic roles, and the types of location.
  4. Actualization is complete when the requiting Economic Event entities are both in state “complete”, thus marking the completion of the full exchange.
  5. Post-Actualization is complete when the possible warranty (or similar post-exchange exception condition) component of an Economic Resource is invoked, and the conditions of the exchange reach their final values.

Phases of a Business Transaction and Object States for Completion

Figure 20. Phases of a Business Transaction and Object States for Completion.

Figure 21 illustrates how the declarative ontological components of Open-edi (referred to here as Business Transaction Entity Types) can be augmented to account for state machine mechanics. Each ontological component is envisioned as a possible Business Transaction Entity with a defined Business Transaction Entity Lifecycle consisting of multiple Business Transaction Entity States. The transition to these states is effected by the occurrence of a Business Event.

Business Transaction Entities, Lifecycles, States, and Events

Figure 21. Business Transaction Entities, Lifecycles, States, and Events.

Figure 22 illustrates some example states that could be identified for some of the Open-edi Ontology components defined thus far. In a full ontological specification, all of the business transaction entity types defined in this document would be given fully-enumerated lifecycles of object states (as specified in Figure 21). However, these would change from one business context to another, so the exposition here is limited to these four samples.

Rule 16:

In the OeBTO, all declarative components become candidates for Business Transaction Entities, and each of these in turn will have a defined life cycle of states that will mark its progressive use in the representation of a real economic exchange.

Sample States for Business Transaction Entities

Figure 22. Sample States for Business Transaction Entities.

Figure 23 lists an example set of Business Events involved in a typical instance of a Business Transaction. These 14 Business Events represent a full collaboration between an example buyer and seller, as it proceeds through the Open-edi phases. Again, each Business Event might cause multiple state changes. For example:

  1. The fourth activity – Buyer sends Availability and Price Request to Seller – would cause:
    1. the Economic Resource Type to move into its Specified state, and
    2. the Identification Phase to move into its In-Force state.
  2. The ninth activity – Buyer sends an Order Acceptance to Seller for parts – would cause:
    1. the Economic Resource Types, the Economic Event Types, and the Economic Roles to move into their Specified states, and
    2. the Economic Contract and the Economic Commitment entities to move into their In-Force
  3. The eleventh activity – Buyer sends Receiving Report to Seller when inspected goods are accepted – would cause:
    1. the Economic Event to move into its Completed state, and
    2. the Economic Resource to move into its Transferred

An Example Business Transaction with Business Events Grouped in Phases

Figure 23. An Example Business Transaction with Business Events Grouped in Phases.

A UML state machine diagram is the best formal specification of dynamic object behavior with state changes. Such a specification is illustrated in Figure 24 for the Business Entity Type “Economic Resource Type” as it moves through the example collaboration.

  1. The Economic Resource Type (for example a type of inventory) would become a Candidate when the Publish-Catalog event occurs, moving from its initial undefined state (black dot).
  2. The Send-Availability-And-Price-Request event would then move the inventory into state This same event would move the Identification Phase of the Business Transaction into state In-Service (not shown in Figure 24).
  3. The Return-Availability-And-Price-Result would cause the inventory to become This same event would move the Identification Phase of the Business Transaction into state Complete (not shown).
  4. The Send-Offer event would shift the example inventory into its Proposed state.
  5. The Accept-Offer would cause the Economic Resource Type to become Specified.
  6. And finally, a Send-Shipping-Notice action would cause the resource type to move to an Actualization state (end of object life cycle). 1

State Machine Diagram for Economic Resource Type

Figure 24. State Machine Diagram for Economic Resource Type.

Figure 24 illustrates the progress of a collaboration between two trading partners from the perspective of one Business Transaction Entity as it progresses through its state changes. Figures 24-27 provide a different, but much more comprehensive view of progress through the first three phases (planning, identification, and negotiation) 2 the same business transaction. 3 Each of these figures illustrates a UML activity graph with various business events (such as “Publish-Catalog” at the top right of Figure 25) being performed by either the buying partner (left column) or the selling partner (right column). The collaboration space between the buyer and seller (first illustrated in Figure 3) is where the shared business entity states reside that allow each partner to determine simultaneously what the exact status of the overall business collaboration is. For example in Figure 25, the Publish-Catalog event at the upper right causes the entity Economic Resource Type to move into state Candidate (as earlier illustrated in Figure 24) and the entity Planning Phase to move into state Waiting Start. For purposes of parsimony, Figures 25-28 do not illustrate all of the state changes that would occur in a collaboration, only an illustrative subset. For example, it would commonly be the case that the Completed state of one transaction phase (such as Identification) would cause the following phase (such as Negotiation) to move into a Waiting Start state. However, this state transition is not shown.

Activity Graph 1 for Collaboration

Figure 25. Activity Graph (1) for Collaboration.

Activity Graph 2 for Collaboration

Figure 26. Activity Graph (2) for Collaboration.

Activity Graph 3 for Collaboration

Figure 27. Activity Graph (3) for Collaboration.

Activity Graph 4 for Collaboration

Figure 28. Activity Graph (4) for Collaboration.

To summarize the state machine presentation, it is necessary to understand how the definitions of Clause 5 and Clause 6 work together.

  1. Clause 5 defined the declarative components of the Open-edi ontology. This is a specification of the primitive classes as they model the components of a business transaction. These primitive classes become candidates for Business Transaction Entity Types, and their realization during an actual business collaboration would become Business Transaction Entities.
  2. Clause 6 defined the procedural components of the Open-edi ontology. This illustrated the dynamic mechanics of tracking business collaboration through each of the five Open-edi phases using state machine mechanics. This progress was illustrated with the UML, first from the perspective of a single business transaction entity (state machine diagram) and second from the perspective of the entire workflow (activity graphs).

With partners communicating with each other through shared states of Business Transaction Entities, the actual status of an Open-edi collaboration is exactly determined for each at any point in time.

Rule 17:

In the OeBTO, the declarative components – the Business Transaction Entities – and the procedural components – the shared collaboration space state machines – work in tandem to fully track the activities and progress in an economic exchange. A realization of the OeBTO requires integrated specification of both of these features in the conduct of an Open-edi business transaction.

Previous:  ISO/IEC 15944-4 The declarative component of an OeBTO – 20071101
Next: ISO/IEC 15944-4 The constraint component of an OeBTO – 20071101

  1. In reality, this state machine example for Economic Inventory is slightly more complicated as the individual state changes would need to be tracked through a UML association class between the Economic Inventory Type and the Business Transaction.
  2. The exposition here is limited to these first three phases for parsimony sake. Including the phases of actualization and post-actualization would make the activity documentation twice as long with little gained in explanatory power.
  3. Figures 25-28 are intended to be read consecutively. For example, the start of Figure 26 (illustrated as a  filled-in circle) connects with the finish of Figure 25 (illustrated as a target circle.

ISO/IEC 15944-4 The constraint component of an OeBTO – 20071101

Business Rules and Open-edi Constraints

Business rules specifying computational procedures, approved sequences of actions, valid inferences, and effective control monitoring govern the day-to-day operations of business enterprises. A useful definition of a “business rule” from Eriksson and Penker is:

… a statement that can control or affect the execution of a business process as well as the structure of the resources in a business. The statement specifies a condition that must be upheld, or a condition that controls which activity should follow next. It can express a business goal, specify the way a process should execute, detail the conditions of a relationship, or constrain the behavior of a resource.

In the database world somewhat synonymously, “constraints” are defined as rules governing the integrity of data that prevent a database from moving from one representation state to another without proper validation, and in the most simple ontological case, their function is exactly congruous with the business rules definition given above. Database integrity constraints are also commonly referred to as assertions.

In ISO/IEC 15944-1, a constraint is defined as “a rule, explicitly stated, that prescribes, limits, governs, or specifies any aspect of a business transaction.” That same standard differentiates those constraints that are self imposed by the trading parties (internal) from those constraints created by law, regulation, orders, treaties, conventions, or similar instruments (external):

  1. internal constraint: a constraint which forms part of the commitment(s) mutually agreed to among the parties to a business transaction
  2. external constraint: a constraint which takes precedence over internal constraints in a business transaction,e., is external to those agreed upon by the parties to a business transaction.

Open-edi further divides the category of external constraints into:

  1. those that are common and horizontal in nature as introduced by the additional presence in a business transaction of a “regulator” as a third subtype of Person representing “public administration“, and
  2. those that are more sectorial in nature (involving standard rules, both across many sectors and across just one sector). Open-edi differentiates these classes of constraints in order to provide summaries of complex bundles of rules for scenario registration. For example, the simplest constraint bundle for a scenario could aggregate only internal constraints; the next most complex could add horizontal external constraints, etc.

In the OeBTO, constraints encapsulating business rules constitute the third major representation component. The first component was the declarative specification of domain classes and associations in Clause 5, while the second component was the procedural aspects associated with business transaction state machines and activity graphs as explained in Clause 6.

OeBTO Constraint Examples

Constraints may be expressed informally in natural language, such as the following accounting rule for separation of duties as applied to the class diagram of Figure 6:

“the Person who fills the participation role in an Economic Event that involves a certain Economic Resource should not be the same Person who has a custody relationship with that Economic Resource”

The need for this constraint to a business transaction could be derived for example from a sectorial application (an OeBTO external constraint) of the 2002 USA Sarbanes-Oxley internal control legislation.

Constraints may also be expressed more formally with the Object Constraint Language (OCL) of the UML. For example, a state sales tax rule for Michigan (another sectorial external constraint) on merchandise orders (a subtype of Economic Contract) could be specified as 6% of the gross amount of the order:

context Order inv michiganSalesTaxCalculation  salesTax = grossAmount × .06

Such a constraint could be placed in curly brackets on a UML class diagram next to the class definition for order (for example, a more specific form of Figure 16), and it then becomes an invariant (inv) or a condition that must be true for all objects of that class.

According to both Odell and Eriksson and Penker, constraints may be of two general behavioral kinds:

  1. Those that define how knowledge in one form may be inferred or derived from another form. Examples of this constraint category might be the Michigan sales tax calculation shown above. Another example might be a constraint that designates a scheduled shipment as “hazardous” if it exceeds a designated weight threshold of goods (economic resources) typed as “dangerous if unpackaged” shown in an inheritance taxonomy that would give domain level expansion to the three levels initially shown in Figure 4.
  2. Those that “constrain either the possible structure or the behavior of objects or processes, that is, the way objects are related to each other or the way objects or process state changes may occur.” An especially prominent illustration for the OeBTO of this class of constraints are rules that define preconditions and post-conditions for the types of state changes described in Clause 6. For example in Figure 26, the state machine diagram makes it clear that for Economic Resource Type to achieve its “proposed” state, it has a pre-condition of being in state “identified” and a post-condition of state “specified” and that these transitions are effected by the business events shown. These same types of rules can be specified as constraints in OCL and portrayed on UML class diagrams.

Both derivation business rules and constraint business rules are important to effective business operation in collaboration space, so their characterization in the Open-edi Business Transaction Ontology is an important third step in insuring interoperability and semantic integrity. To the extent that the declarative and procedural components of an ontology are specified correctly, the parties to a business transaction are given computable methods for ensuring compliance with both internal and external rules of business behavior.

7.3 Summary

There is certainly now a critical opportunity for developing coherence in worldwide standards for business level definitions of economic phenomena. Open-edi, especially in its prior work of ISO/IEC 15944-1, has standardized much of the technical and economic environment for economic exchanges, and the field of ontology provides an extended opportunity for unifying and coordinating that work. This part of ISO/IEC 15944 aims to provide that unity with an ontological analysis of the declarative, procedural, and constraint components of Open-edi. Certainly, the majority of the work in this document concentrates on the declarative components of the OeBTO – those data classes that model the fundamental categories of economic endeavors in collaboration space and the relationships that exist among those categories. This declarative emphasis is reasoned and deliberate. As noted by John Sowa, conceptual progress in a specialized domain is usually marked by an increasing percentage of the knowledge in that field being embedded in its declarative components. As ad hoc procedures and constraints become more structured and predictable, they lead naturally to better theoretical and conceptual structures.

In concert, the declarative, procedural, and constraint components of the Open-edi ontology provide a definitive specification that is formal, explicit, and conceptual. An ontological foundation is one of the key components of that coherence.

Previous: ISO/IEC 15944-4 The procedural component of an OeBTO – 20071101

Next:

REA-Hruby – Structural Patterns at the Policy Level

Structural Patterns at the Operational Level are used to model economic exchanges that have actually occurred.

Structural Patterns at the Policy Level are used to model economic exchanges that should, could, or should not occur under certain conditions.

Outline

  • Policy Pattern
  • Policy and the Exchange Process:
    • Commitment Pattern
      • Commitment Relationships:
        • Provide and Receive relationship between Commitments and Agents
        • Exchange Reciprocity and Conversion Reciprocity relationship between Increment and Decrement Commitments
        • Reservation relationship between Commitments and Resources or Resource Types
        • Fulfilment relationship between Commitments and Events
      • Commitment Properties:
        • Scheduled Date property
        • Scheduled Value property
      • Domain rules
    • Contract Pattern
      • Offer and Quote
      • Agreement
  • Policy and the Conversion Process:
    • Schedule Pattern
  • Supports for infrastructure at the policy level:
    • Group Pattern – typically supports Policies
    • Type Pattern – typically supports Commitments
  • Supports for business logic:
    • Linkage Pattern
    • Responsibility Pattern
    • Custody Pattern

Source: Hruby, P – Model-driven design using business patterns – 2006

Also see the REA-Hruby Mind Map [intlink id="2459" type="post"]local[/intlink] [web]

Next: REA-Hruby – Policy Pattern

 

 

 

 

 

 

 

REA-Hruby – Policy Pattern

A policy is a rule of practice or procedure to guide decisions and actions.

Business reality: Not everything is allowed – there are laws, systems, traditions, cultures, and internal company rules that constrain the economic exchanges or conversions that are possible or desirable in a given situation.

Core REA model: The core REA application model specifies the economic resourcesevents, and agents in a given business. The model allows users to plan and register any kind of economic event that is part of the application model; however, the model does not provide for rules that govern what economic events are allowed or not allowed in a given situation.

Problem: How do we make the business application aware that some economic events are not allowable or desirable in certain circumstances, and even prevent users from doing something that is prohibited?

Considerations:

  • The users of a business application should be able to create and modify policies that apply to economic resources, events, and agents.
  • It should be easy to find any policy in the business application. It should be easy to determine what policies apply to a specific group of agents.
  • If a policy changes, the application should be able to retain the old version of the policy, and also to execute the business logic according to the old policy.

Solution: The policy entity encapsulates rules or constraints on economic exchanges and conversions in the business application.

Example

Figure 1 illustrates an example of the REA application model with a Sale Policy. The Sale Policy can apply to Item Group, Event Group, and Customer Group.

Policy in the REA application model

Figure 1. Sale Policy in the REA application model.

The Sale Policy can specify that, for all Events related to specific Items and to specific Customers, certain rules apply.

Consider the policy specifying that an enterprise is not allowed to supply tobacco products to minors. The Supply Policy “Tobacco to Minors” is ap­plied to the groups “Tobacco Products,” “Supply,” and “Minors.” Figure 2 illustrates that if a user of the business system attempts to register an in­stance of the Sale economic event with “PM Box” as an Item and “Addy” as a Customer (illustrated by dashed lines), the policy would be enforced and the sale would not be allowed.

Sale Policy  in the REA application model

Figure 2. Sale Policy  in the REA application model.

What would really happen if the business application depends on the implementation of the policy. The system response could range from noti­fying the user of the business system about the violation of the policy (by raising an information event) to preventing him from registering the event.

Groups of moment in time

There are policies applicable only during certain time intervals. For ex­ample, the Sunday Rule Policy specifies that the Joe’s Pizzeria does not sell alcoholic beverages on Sundays. The REA application model in Figure 3 contains a group Period of Sale, representing a group of moments in time. The Period of Sale has the value “Sunday,” and Item Group, has the value “Alcoholic Beverages,” and they are related to the Sale Policy entity. If Joe’s Pizzeria attempts to sell an item that belongs to the group “Alcoholic Beverages” and the time of sale belongs to “Sunday,” the pol­icy would be enforced. Note that the Sunday Rule Policy is re­lated to the Customer Group, which means that it applies to all customers.

Sale Policy with time parameters in the REA application model

Figure 3. Sale Policy with time parameter in the REA application model.

Managing versions

If a policy is revised or even becomes obsolete, users of the business application need to be able to restrict its applicability in time, rather than deleting the policy altogether. As economic events are always registered af­ter they have occurred, users need to be able to register events against the the policies that applied when the event occurred.

The functionality of a policy can be implemented in a behavioral pattern like a Matrix Rule – a representa­tion of a policy where the columns represent groups or types of entities and the rows represent applicable policies.

Semantic Considerations

Policies should relate to entities at the policy level, i.e. to groups or types of entities, rather than to  individual entities at the operational level. Such policies have more explanatory power and allow for reasoning about the policy.

A policy entity does not have to be related to groups of commitments, as information about whether the commitments conform to the policy can be derived from the policies applied to groups of events.

Software Considerations

Users of a REA business application need to identify the right groups; other­wise, they cannot specify the policies.

It should be easy to determine which policies apply to a specific entity by identi­fying the group(s) of which this entity is member, and traversing the rela­tionships between groups and policies.

The information necessary to evalu­ate the applicability of a policy must be in the system. For example, if there is a policy not to supply alcoholic beverages to people under a certain age, the age of the buyer must be in the system.

We need to consider the intended results of individual policies, and to establish the infrastructure that supports these results. The results of policies always prohibit some events, but they can be implemented with varying levels of enforcement, from notifying the user of the application to preventing him from executing the prohibited action.

The Policy Pattern should express rules and constraints in the form of relations (instead of code) – then users can add, modify and remove rules without modifying code.

Source: Hruby, P – Model-driven design using business patterns – 2006

Previous: REA-Hruby – Structural Patterns at the Policy Level
Next: REA-Hruby – Commitment Pattern

REA-Hruby – Commitment Pattern

Outline

  • Commitment Relationships:
    • Provide and Receive relationship between Commitments and Agents
    • Exchange Reciprocity and Conversion Reciprocity relationship between Increment and Decrement Commitments
    • Reservation relationship between Commitments and Resources or Resource Types
    • Fulfilment relationship between Commitments and Events
  • Commitment Properties:
    • Scheduled Date property
    • Scheduled Value property
  • Domain rules

Business reality: Most economic events do not occur unexpectedly. Economic events are usually scheduled or agreed upon beforehand by economic agents. E.g. a sales order line is a promise to sell goods to a customer; the total price is a customer’s promise to pay for the goods, and the seller’s promise to accept the payment.

Problem: How do we model promises of future economic events?

Considerations:

  • General:
    • Application designers would like to have a mechanism in the application model specifying details about the promises of economic events. Eco­nomic events cannot be used for this, because economic events specify actual increments and decrements of resources, while promises result only in reservations of resources.
    • There might be (and usually is) a difference between plans and what ac­tually happens. The users of a business application would like to know whether the economic events occurred as they were promised, and in­formed about eventual differences.
  • Exchange processes:
    • If an enterprise promises to give its own resources to its trading part­ners, users of business application would, most likely, like to know, what resources to expect in return. Conversely, if an enterprise expects to receive some resources, the users of business application would like to know what resources its trading partners expect.
    • The users of a business application would like to know who should be responsible for the received or produced resources, and who should be responsible for the resources used or consumed during the production or given to other economic agents.
    • For each promised exchange, the users of a business application would like to know the trading partners to whom the resources should be trans­ferred, and from whom they should be received.
  • Conversion processes:
    • If an enterprise schedules the production of resources, users of a business application would like to know what resources it would require to use or consume. Conversely, if an enterprise plans to use or consume resources, the users of a business application would like to know what resources will be produced from them.

Solution: 

Model the promise of the economic event as a Commitment entity. A com­mitment in exchange processes represents obligations of economic agents to provide or receive rights to economic resources. A commitment in con­version processes represents schedules of usage, consumption, or production of economic resources.

Each commitment is related to an economic event by a fulfillment rela­tionship, representing the fact that commitments are fulfilled in the future by one or more economic events executed by the participating economic agents (Figure 1).

Commitments usually have properties for the Sched­uled Date or period of the economic event, and the Scheduled Value of the event.

The Scheduled Value does not need to be expressed as an actual num­ber, but, for example, as a rule. For example, the price of a service can be determined according to actual costs.

Commitment and economic events

Figure 1. Commitment and economic events.

Each promised exchange and conversion process consists of at least two com­mitments: increment commitments, which are expected to increase the value of economic resources, and are fulfilled by increment economic events, and their related decrement commitments, which are expected to decrease the value of economic resources, and are fulfilled by decrement economic events. The relationship between increment and decrement commitments identifies which resources are promised to be exchanged or converted to which others, and is called exchange reciprocity or conver­sion reciprocity.

Figure 2 illustrates relationships between commitments, economic events, economic agents, and economic resources in exchange processes.

Figure 3 illustrates the same relationships in conversion processes.

Relationships of commitments in exchange processes

Figure 2. Relationships of commitments in exchange processes.

Relationships of commitments in conversion processes

Figure 3. Relationships of commitments in conversion processes.

The Provide and Receive Relationship

Commitments are related by the provide and receive relationships to the economic agents that are scheduled to participate in economic events, and they consequently determine who should have rights to or the control over economic resources.

The provide and receive are one-to-many relation­ships. One economic agent can participate in zero or more commitments; an economic commitment must have exactly one committed provider and exactly one committed recipient economic agent.

The Exchange Reciprocity and Conversion Reciprocity Relationships

The exchange reciprocity relationship between the increment and decre­ment commitments identifies in the model which resources are promised to be exchanged for which others. Likewise, the conversion reciprocity iden­tifies which resources are promised to be used or consumed in order to produce others.

The commitments paired by the reciprocity relationship do not need to be instantiated (created at runtime) at the same time. For example, the in­surance process illustrated in the Modeling Handbook contains an example of an increment commitment (insurance payment) that is instantiated only under certain conditions specified by the insurance contract. Another ex­ample is a commitment to buy shares of a company, paired with a recipro­cal commitment of dividend payments. The two commitments are instanti­ated at different times.

The Fulfillment Relationship

The purpose of the fulfillment relationship is to validate whether the eco­nomic events fulfill their commitments.

This can often be done automatically. For example, the RECONCILI­ATION PATTERN (Behavioral Patterns) can validate that quantity on the sales order line (i.e., the value of the commitment) is the same as the sum of the shipped quantities (values of the economic events).

Sometimes, a human decision is needed to determine whether the eco­nomic events fulfill their commitments. For example, if a payment com­mitment was fulfilled by payment in different currency, due to variable ex­change rates the monetary value of the commitment can differ from the monetary value of the economic event. In such cases, a human decision might be needed to judge whether the difference is sufficiently small to consider the commitment fulfilled.

The fulfillment relationship is a many-to-many relationship between the economic commitment and the economic event. One economic commit­ment can be fulfilled by several economic events, just as one shipment commitment can be fulfilled by partial shipments, and one economic event can fulfill several economic commitments, just as several installments can be paid once.

The Reservation Relationship

In order to specify what resources will be needed or are expected by future economic events, each economic commitment is related to an economic re­source or a resource type by a reservation relationship. For example, a sales order line is a decrement commitment to ship goods; the sales order line is related by the outflow reservation relationship to the goods or the goods type.

When sales persons accept customer orders, they want a business soft­ware application to check whether there are products available when the order is due, and to make sure that these products will be available to the customers during the economic event related to the economic commitment.

Reservation

Figure 3. Reservation relationship.

The reservation relationship between the resource and commitment represents the features of the resource and rights associated with the re­source that will be changed or transferred by a future economic event (Figure 3).

The commitment can be related to either a resource type or a resource. For example, a sales order for a new car contains a commitment to deliver a car of a certain model, (i.e., resource type); a sales order for a used car contains a commitment to deliver a physical car (i.e., resource). The reser­vation of a hotel room contains a commitment to provide a hotel room with certain characteristics, such as of a certain size and with certain number of beds (i.e., resource type); but sometimes a guest might require a specific room, in which case the commitment is related to an (actual) resource.

If economic commitment is related to resource type, at some point in the future, but always before the economic events starts, the commitment must also be related to an actual resource that conforms to the reserved resource type (Figure 4).

A commitment must eventually be related to an actual resource.

Figure 4. A commitment must eventually be related to an actual resource.

The time of allocation varies. For example, in the hospitality business, the reservation is related to a room specification until the day of the guest’s arrival. The morning of the day of arrival, the receptionist assigns (a hu­man assisted, and not an automated task) a room numbers for each reserva­tion that starts that day. In the airline business, physical seats are assigned at the time of reservation, with the possibility of replanning. In theatres and cinemas, the tickets are assigned at the time of reservation. The algo­rithm first reserves the best seats within a certain price group, such as those in the middle of the theatre, and later reserves the seats closest to the best places.

We call the commitment fully specified if it is related by the reservation relationship to an (actual) resource.

Domain Rules

The following domain rules apply to any REA application model. As commitments are a mirror image of the economic events at the policy level, the domain rules are similar to the rules for the REA model at opera­tional level, with one addition: commitments must be fulfilled by eco­nomic events. These rules can be used to ensure consistency of REA appli­cation models.

Each commitment must be related to a resource, and might (but does not have to) also be related to a resource type.

Each commitment must be related by provide and receive relation­ships to economic agents.

Each increment commitment must be related by a exchange or con­version reciprocity relationship to a decrement commitment, and vice versa.

Each increment commitment must be related by a fulfillment rela­tionship to at least one increment economic event, and each decre­ment commitment must be related to at least one decrement eco­nomic event.

A commitment that is part of a conversion must be related to the economic event of a conversion process; likewise, a commitment that is part of an exchange must be related to an economic event of an exchange process.

Outcome

The reciprocity relationship often has additional functionality that relates together the values of the increment and decrement commitments. For ex­ample, in economic exchanges, the reciprocity can calculate the total price (value of the outflow commitments) based on the line item prices (value of the inflow commitments). The reciprocity might also validate that the cost (value of the outflow commitments) is lower than the price (value of the inflow commitments). The functionality of the reciprocity relationship can vary in different implementations; but the fundamental point is that the in­crement and decrement commitments are related.

Source: Hruby, P – Model-Driven Design Using Business Patterns – 2006

Previous: REA-Hruby – Policy Pattern
Next: REA-Hruby – Contract Pattern

REA-Hruby – Contract Pattern

Contracts are statements of intent that regulate the behavior among organizations and individuals. Clauses of a good contract define what should happen in the cases of cancellation and violation of the commitments.

Business reality

Commitments represent the optimistic path of an exchange process. For example, a sales order contains commitments to deliver goods and commitments to pay. However, sometimes goods are not delivered as expected and pay­ments arrive late. Partners usually also agree upon what should happen if the initial commitments are unfulfilled.

Problem: How do we specify in the REA model what should happen if the commit­ments are unfulfilled?

Considerations

  • Commitments specify what economic events should occur. However, in the case in which they do not occur as they should, economic agents usually agree upon what should happen next. The rules specifying what should happen next can be very complex, and keeping track of what should happen, and when, can be cumbersome. Therefore, application developers would like this information present in the business applica­tion, so that these rules and actions can be monitored and triggered automatically.
  • There are usually several inflow commitments paired through exchange reciprocity with several outflow commitments. These commitments are often considered a unit. Sometimes, it does not make sense to fulfill only some commitments and not to fulfill others, but sometimes this is acceptable. Application designers would like some entity to contain such rules.
  • Intended recipients or providers of the resources might be different eco­nomic agents than the agents that agree about the exchange.

Solution

If a commitment is unfulfilled, the terms of a contract specify additional commitments.

A Contract is an entity in the REA application model containing incre­ment and decrement commitments that promise an exchange of economic resources between economic agents, and terms. Commitments were dis­cussed in the previous pattern. Terms are potential commitments that are instantiated if certain conditions are met. These conditions can be various, such as a commitment not being fulfilled, or a resource being at a certain location. For example, economic agents can agree upon penalties if the commitments are unfulfilled. If the commitments are unfulfilled, the con­tract will instantiate a new commitment to pay a penalty. The terms and commitments are the clauses of the contract.

Every contract must be related to two or more economic agents by a party relationship. These agents do not necessarily have to be the provider and recipient of economic resources. The economic agents that are parties in a contract can be different from the economic agents related to the commitments within the same contract, and different from the agents par­ticipating in the economic events which fulfill these commitments. For ex­ample, a flower shop can deliver flowers to a different person than the one who placed the order, and the flowers will be paid for by a third person, different from the persons who placed the order and received the flowers.

Contract, commitment and terms

Figure 1. Contract, commitment and terms.

Offer and Quote have the same structure as contracts that have not been accepted by all parties in a contract. Economic agents negotiate the content of the commitments and terms, and when they agree upon commitments and terms, the quote or offer becomes a contract that binds the agents that are parties in the contract. There is usually certain period of negotiations and draft versions from when the offers and quotes are created and until the contracts are accepted by both contracting parties.

Examples

Examples of Contracts are service contractsemployment contractssales orders, and purchase orders.

Figure 2 illustrates a business document for a simple sales order without delivery and payment terms.

A sales order is an example of a contract

Figure 2. A sales order is an example of a contract.

Figure 3 illustrates the REA application model for this sales or­der. The Sales Order contains two Sales Lines specifying the goods; the sales line entity corresponds to the line item in Figure 2. The Payment Line specifies the price (i.e. expected amount of re­ceived cash); the entity Payment Line corresponds to the Total line in Figure 2.

The REA application model of a sales order

Figure 3. The REA application model of a sales order.

A more complicated example of a sales order with shipment and payment terms is illustrated in Figure 4. For example, Joe’ Pizzeria and Addy agree that Joe’s Pizzeria will sell five units of Pizza Margherita to Addy on Tuesday, and Addy will pay for them on Friday. If Joe’s Pizzeria does not ship on Tuesday, Joe’s Pizzeria pays a 20 USD penalty to Addy on Friday. If Addy does not pay on Friday, he pays a 30 USD penalty to Joe’s Pizze­ria the following Monday. The informally sketched properties of the terms and commitments can be implemented as DUE DATE PATTERN and VALUE PATTERN (Behavioral Patterns).

Simple contract with shipment and payment terms

Figure 4. Simple contract with shipment and payment terms.

Outcome

The precise specification of commercial contracts is a subject of intensive research. A lan­guage for REA-compatible contracts is being developed by Fritz Henglein.

There are also higher level agreements between economic agents that regulate the behavior of the individual contracts.

Agreements differ from contracts in that they do not contain commitments, but only conditional clauses, and they are hierarchical in nature. Agreements are sketched in Figure 5.

An example of an agreement is a service level agreement for mainte­nance of equipment, which specifies, for example, that the enterprise may place maintenance orders (i.e. contracts) under specific conditions, and re­ceive discounts for specific services.

Agreement and contract

Figure 5. Agreement and contract.

Henglein, F – Semantics of contracts