Abstract
The presented paper proposes a state machine of REA (Resource–Event–Agent) model. This model constitutes a fundamental building block for value modeling applications. Contrary to other approaches to this issue, the paper proposes the state machine “inside” the REA model utilizing the DEMO (Design & Engineering Methodology for Organizations) generic approach and its other features. This means that the states of the REA model itself are taken into consideration. One of the advantages of DEMO is its perception of an enterprise as a social system, of which the elements are human subjects that are in their roles of social individuals. It is obvious that human subjects have appropriate authority and bear the corresponding responsibility. From a wider perspective, the REA model can be considered a social system because the fundamental elements of the model are human subjects (economic agents). For this reason, the REA model and its relationships can be viewed from the DEMO transaction pattern perspective despite possible differences in modeling. The core relationships of the REA model acquire a new meaning and bearing. The result of this approach is the introduction of a clear and unambiguous state machine. This approach inherently integrates the current, past and future event into one structure (transaction) and simplifies the traditional REA distinction between current and past events and future events modeled by commitments. The paper also analyzes the phases of a business transaction to prove that the proposed solution is in compliance with the business transaction declaration.
Introduction
The REA model originated from the accounting domain and matured to a conceptual framework and ontology for Enterprise Information Architectures (Geerts & McCarthy, 2000, 2006). This ontology is known as the REA Enterprise Ontology because three of the fundamental concepts are Resources, Events and Agents. Economic resources are things of economic value that have utility for economic agents and for this reason they used to be planned, monitored, and controlled. Examples of economic resources are money, raw materials, labor, tools, products, and services. Economic events are activities within an enterprise that represent either an increment or a decrement in the value of economic resources. Some economic events occur instantaneously, others occur over a period of time. Examples of economic events are sales of goods, rentals, and provision and use of services. Economic agents are individuals or organizations that participate in the control and execution of economic events. They include customers, vendors, employees and enterprises.
These three concepts and the relationships between them make up the REA core pattern, the core block of REA ontology (McCarthy, 1982; Dunn et al., 2004). This core pattern originates from double entry accounting systems. With regard to economic resources, the REA model distinguishes between the exchange process and conversion process. The former represents the permanent or temporary transfer of rights to economic resources from one economic agent to another, whereas the conversion process involves the creation of new economic resources or the changing of features of existing resources by using or consuming resources of the same or another kind.
The REA core pattern represents an exchange process such as the Pizza Shop illustrated in Fig. 1. It comprises two complementary economic events: an increment event Money Receipt and a decrement event Sale. These events are related to each other by exchange duality. Both events and the exchange duality relationship play a crucial role in this pattern because all other entities participating in the pattern (economic agents and economic resources) are related to the economic events. One of the economic resources whose property rights are exchanged is Money and the other is Pizza. Each of the economic agents is related to the increment and the decrement event, which represents either the loss of rights to the given resource or the gaining of rights to the other resource. More specifically, the agent, Mia’s Pizzeria, loses rights to a Pizza and gains rights to Money. The customer agent loses rights to Money and gains rights to a Pizza. This core pattern is depicted in the so-called ‘dependent’ view, which means that it ‘prefers’ the view of one of the agents, namely Mia’s Pizzeria. For this reason, the increment event is related by an inflow relationship to the Money resource and the decrement event is related by an outflow relationship to the Pizza resource. Both economic agents are related by the provide and receive relationships to the decrement and increment events. The provide relationship is represented by the economic resource to which the agent loses property rights as a consequence of the corresponding event. In a similar way, the receive relationship is represented by the economic resource to which the agent gains property rights as a consequence of the corresponding event. The economic agents themselves are the human beings who are in interaction and thus take part in the exchange process. The economic agents have appropriate authority and bear adequate responsibility. Thus the REA core pattern might be regarded as a social system.
As the mutually bound events cannot occur simultaneously, the claim entity is utilized for deferred revenue, prepaid expenses, accounts payable and so on. The claim entity balances any inequalities that may occur during the exchange process.

REA core pattern. Adapted from Hruby (2006).
An REA model at a business process level is an extension of the REA core pattern. The most important extension of the REA core pattern concerns the possibility of modeling economic events that occur in the future. However, the principal feature of REA ontology that originates from accountancy systems is that it explicitly distinguishes between past and current events and events performed in the future. Therefore for events that occur in the future, REA introduces a new entity known as a commitment entity. The utilization of a commitment entity is not automatic but depends on the particular modeling context. That is, if the model does not address future events there is no need for a modeling commitment entity.

REA model at business process level. Adapted from Hruby (2006).
The commitment entity addresses the issue of modeling promises of future economic events and the issue of reservation of resources. Commitment entities and their relationships with other entities are shown in Fig. 2. In this case, Fig. 2 is an extension of Fig. 1 so only the commitment entities and their relationships to other entities are depicted. Figure 2 shows that the commitment entity copies the structure of the event entity to a significant extent, by which we mean the existence of an increment and decrement commitment and exchange reciprocity relationship.
The relationship of committed provide and committed receive means that an agreement about the future exchange must be achieved between economic agents. The exchange reciprocity relationship between the increment and decrement commitments identifies which resources are promised to be exchanged for which others. The reciprocity relationship is a relation of many-to-many (
Each commitment is related to an economic resource by a reservation relationship, which specifies which resources will be necessitated or expected due to future economic events. The reservation relationship between resource and commitment entities involves the obligation of economic agents to provide or receive rights to economic resources in exchange processes and includes scheduled usage, consumption or production of economic resources in conversion processes. REA models at business process level can be bound into an REA value chain with resource flows between business processes.
The REA model records information based on the coherence between the data of one or more economic events. The main benefit of the REA approach is that is facilitates the keeping track of primary and raw data about economic resources, thereby offering a wider, more precise, and more up-to-date range of reports. All accounting artifacts such as debit, credit, journals, ledgers, receivables and account balances are derived from the data describing exchange and conversion REA processes. Reports based on accounting artifacts are always consistent, being derived from the same data (Hruby, 2006). For example, data describing a sale event is used in warehouse management, payroll, distribution, finance and other application areas, without transformation or adjustment.
REA ontology also benefits from the presence of a semantic and application independent data model, its object oriented perspective, and its abstraction from technical and implementation details. These features enable the possibility of calculating the value of the enterprise’s resources on demand, as opposed to calculation at pre-determined intervals.
The remainder of the paper is organized as follows: states and state transitions modeling are described in Section 2. The basic features of the DEMO methodology that are utilized or used as inspiration are explained in Section 3. The proposal for the REA state machine is elucidated in Section 4. The mutual relation of business transaction to the REA model is clarified in Section 5. The resultant findings are discussed in Section 6 and the final section contains conclusions and a summary of future work.
To reduce ambiguity regarding the modeled system it is necessary to precisely define its states and ensure unique state transitions between these states. Ambiguity, incompleteness and anomalies in construction specifications occur in too many cases (van Kervel, 2012). The requirement for properly defined states and state transitions is crucial in view of the success of the model. In general, there are two different ways of introducing the state machine into developing models, especially into models that can be called ontological or essential models of reality. Both ways utilize the notion of transaction, or business transaction as an atomic unit that is responsible for “synchronization” between two business subjects. A business transaction can be comprehended as an interaction between business partners leading to a specific result. The first way of introducing states and state transitions into business process modeling is illustrated by Huemer et al. (2007, 2007). Their approach involves keeping track of business entity states. A business entity usually means a product represented by a resource entity. The states of business entity are declared by means of the phases of business transaction (see Section 5). In order to graphically describe business entity states, the authors of the above-mentioned papers developed UN/CEFACT’s modeling methodology (UMM) as a UML profile for the special purpose of modeling business collaborations (Hofreiter et al., 2006). UMM distinguishes between two one-way and four two-way types of business transaction. The application of this approach was demonstrated in Horiuchi and McCarthy (2011) presentation. Unfortunately, for introducing states and state transitions, the current conception of the REA model only offers the tracing of the states of the resource entity. However, keeping track of a relevant business entity is a difficult task as is the implementation of this approach, which is clear from the above-mentioned presentation. The inclusion of a business transaction into an REA model is illustrated in Fig. 9 (see p. 36).
The figure describes a business transaction as an aggregate that is composed of economic events and business transaction phases. A business transaction is something that is outside the REA model. In order to achieve unambiguous states of the REA model it is necessary to embody the states inside the REA model.
The alternative approach that primarily embodies states and state transitions in a business process is DEMO (Design & Engineering Methodology for Organizations), which is based on the theory of Enterprise Ontology (Dietz, 2006). A business process is defined by DEMO as a tree structure of transactions. The notion of the DEMO transaction has its origin in the
To summarize the two methodologies, they both consider the transaction as the basic building block for describing social communication between two subjects. The UMM approach focuses on tracking the states of business entity. DEMO zeroes in on states and state transitions within the scope of the transaction itself utilizing corresponding axioms of Enterprise Ontology.
DEMO
According to DEMO (Design & Engineering Methodology for Organizations) methodology (Dietz, 2006), an organization is composed of people (social individuals) that perform two kinds of acts, production acts and coordination acts. The result of successfully performing a production act is a production fact. Production facts are inherently either material or immaterial. An example of a production fact may be when a payment has been made, or an offered service has been accepted. All realization issues are fully abstracted out. Only the facts per se are relevant, rather than how they are achieved. The result of successfully performing a coordination act is a coordination fact. Examples of coordination acts are requesting and promising a production fact. A coordination act and a corresponding coordination fact are called a transaction step. In general, a state is determined by the set of facts that exist at that moment. A state change or state transition consists of one or more facts starting or ceasing to exist. The occurrence of a transition at a moment is called an event. Events are caused by facts in the system that the world is associated with and concern existentially independent facts.

The transaction axiom, the basic pattern. Source: Dietz, 2006. (Colors are visible in the online version of the article; https://dx-doi-org.web.bisu.edu.cn/10.3233/AO-150141.)

The Transition axiom, the standard pattern. Source: van Kervel, 2012.
The diagram in Fig. 3 shows the basic transaction pattern. The transaction axiom states that any transaction follows a precisely specified pattern; there are certain state transitions and rules that specify allowed and exclude forbidden state transitions. The transaction axiom contains two subject roles, the customer (initiator) and the performer (executor), and coordination and production acts that result in coordination and production facts between both subjects. This pattern includes only the so-called “happy path” of the transaction. Each transaction starts with the request coordination act made by the initiator. In response to the request (represented by the fact requested), the executor performs a promise coordination act. This coordination act results in the coordination fact promised. The promise goes on in a production act, which results in production fact. The production fact brings about the coordination act state which results in the coordination fact stated. The coordination fact stated causes the coordination act accept which results in the coordination fact accepted. The basic transaction pattern omits cancellation and revoking actions. In this way, facts stand for states. The transaction axiom, the standard pattern, which adds cancellation actions, is shown in Fig. 4.
For each transaction step, the standard transaction pattern includes the option for the other economic agents to deviate from the “happy path”. The diagram in Fig. 4 shows interrelated acts and facts (states) from the standard pattern. The partition of the initiator contains the coordination acts and the decisions represented by the diamonds in the diagram. The partition of the executor contains the corresponding coordination acts, the decisions and the production act and production fact. The production act and the production fact are depicted in grey. The reason for locating the production fact in the executor partition is that the production is usually placed separately from the initiator partition. The coordination facts are situated in the middle of the figure as states in bold.
After the request from the initiator, the executor has the option to promise or to decline the request. These facts result in the fact Promised or the fact Declined. After the fact is Promised, the executor executes the production act, which results in a production fact, which may represent, for example, baking a pizza in a pizzeria or the creation of a bouquet at a florist’s. An act state results in the fact Stated. The initiator may decide to either carry out the act accept resulting in the fact Accepted or the act reject resulting in the fact Rejected.
The standard transaction pattern makes it possible to go on after reaching the fact Rejected or Declined and the result depends on mutual communication between the initiator and executor. The coordination facts Quitted and Stopped are the final states of the transaction.
To facilitate comprehension of the essential operation of organizations, a distinction between three human abilities has been introduced (Dietz, 2006). This distinction concerns both coordination and production acts. The human abilities are shown in Fig. 5. The distinction axiom is another axiom that belongs to the

The three human capabilities. Source: Dietz, 2006. (Colors are visible in the online version of the article; https://dx-doi-org.web.bisu.edu.cn/10.3233/AO-150141.)
These abilities are called performa, informa and forma and are shown in Fig. 5. The forma ability addresses the form of communication and information. The informa ability deals with the content aspects of communication and information. This ability fully abstracts from the form aspects. The performa ability concerns the bringing about of new, original things, directly or indirectly performed by communication. This ability means engaging into commitments, making decisions or judgments. The performa ability is considered to be the essential human ability for doing business of any kind. The first abstraction DEMO consists in obtaining the essential structure of an organization by taking account of only the performa ability in coordination acts and leaving out the informa and forma levels. The second abstraction DEMO consists in obtaining the essential structure of an organization by taking account of only the performa ability in production acts and leaving out the production acts on the informa and forma levels.
Another important aspect of these human abilities is that they are mutually interrelated in a similar way, as layered structures in, for example an OSI network model.
DEMO distinguishes between the coordination and production that perform human subjects and introduces a generic transaction pattern with precisely defined states and state transitions that are proposed for interaction between human subjects. The distinction axiom results in the Performa–Informa–Forma analysis that divides the explored domain (reality) into three interrelated layers. The performa ability reveals the essential (ontological) model and thus abstracts from reality.
First, we start with the REA core pattern, which is depicted in Fig. 1, and then we extend our findings to the REA model shown in Fig. 2. The principal dynamic elements of the REA core pattern are economic events. The structure of the economic event is shown in Fig. 6. The basic attributes of the economic event are the quantity of resource, date and position. In the view of DEMO, the economic event represents production act and production fact. By production act it is meant that one of the economic agents has to perform certain activities that enable the event to occur. The occurrence of the event represents the production fact. In the example of a pizzeria, the vendor (executor) has to ensure that the pizza is ready to be delivered. In the example of a florist’s, the vendor (executor) has to select flowers usually with the help of the customer (initiator) and create a bouquet. The event itself represents the time or time interval when the production fact has been created.

Structure of economic event. Source: Hruby, 2006.
The REA core pattern contains two different economic events. From the DEMO perspective, these different economic events can be interpreted as two production acts and two production facts that are mutually interrelated by the exchange duality relationship. Next, we focus on economic agents in the REA core pattern because they represent human subjects. Each of the economic agents is related to the given economic event by provide and receive relationships. From the DEMO perspective, the provide relationship can be interpreted as the state coordination act and the stated coordination fact. The meaning of the state transaction step is that some material or immaterial production fact is stated to the initiator of the transaction. This fully corresponds with the meaning of the REA provide relationship. The following receive relationship relates the same economic event to the other economic agent. From the DEMO point of view, this relationship can be interpreted as the coordination act accept and the coordination fact accepted. The meaning of the accept transaction step is that some material or immaterial production fact is accepted. This fully corresponds with the meaning of the REA receive relationship. As mentioned earlier, the REA core pattern represents two transactions. The number of transactions corresponds to the number of economic events. From the DEMO perspective, it can be concluded that the REA core pattern contains two production acts and two production facts and that also contains two coordination acts of state and accept and two coordination facts of stated and accepted.
The REA model, which is depicted in Fig. 2, is an extension of the REA core pattern. To make interpretation between REA and DEMO modeling perspectives easy, we propose the REA model with only with two commitment entities as shown in Fig. 2. The relationships we are chiefly interested in are those that relate economic agents to commitment entities. Each economic agent is related to a given commitment entity by the committed receive and committed provide relationships. From the DEMO perspective, the committed receive relationship can be interpreted as the request coordination act and the requested coordination fact. The significance of the request transaction step is that some material or immaterial production fact is requested either now or sometime in the future. This fully corresponds with the meaning of the REA committed receive relationship. The subsequent relationship between the commitment entity and the economic agent is the committed provide relationship. From the DEMO point of view, this relationship can be interpreted as the promise coordination act and the promised coordination fact. The meaning of this promise transaction step is that a material or immaterial production fact is promised either now or sometime in the future. This fully corresponds with the meaning of the REA committed provide relationship. The DEMO point of view enables the modeling of the events that have occurred or are occurring in the present and those that are planned or expected to occur in the future in a unique way utilizing the DEMO transaction pattern and distinction between coordination acts and facts and production acts and facts. The coordination act itself is composed of the intended production fact and the intended time of the production fact creation. There is no difference for DEMO whether the intended time of the production fact creation is now or sometime in the future.
From the DEMO perspective, the REA model in Fig. 2 represents two transactions: a sales transaction (the customer wants a pizza) and a payment transaction (the vendor wants money). In REA, both transactions are related by exchange reciprocity and by exchange duality. In DEMO, both transactions are arranged in a tree structure. The sales transaction is usually the root transaction and the payment transaction is usually an enclosed transaction within the sales transaction. Each transaction has to have its initiator and its executor represented by actor roles (human beings are known as actors in DEMO). To make the issue of the two transactions more comprehensible we firstly introduce the problem utilizing the DEMO Construction Model, see Fig. 7, followed by a detailed model with the acts and corresponding facts (states) is shown, see Fig. 8.

DEMO Construction Model of the REA model.

Simple REA model as a state machine. Source: authors.
Figure 7 contains two kinds of transaction: T01 – the sales transaction, T02 – the payment transaction and two actor roles. The first actor’s role is the initiator of the sales transaction and the executor of the payment transaction. The second actor’s role is the initiator of the payment transaction and the executor of the sales transaction.
Figure 8 represents one of the possible sequences (interrelation) of two transactions: the sales transaction and the payment transaction. The coordination acts are drawn in the economic agent’s partitions (initiator, executor). The agent’s partitions also contain a production act and production fact corresponding to the economic agent. The placement of the production fact in the executor’s partition corresponds to a situation in which the production fact also arises separately from the initiator. The coordination facts are located in the middle of the agents’ partitions. In order to distinguish different coordination facts the suffix ‘_S’ was used for the sales transaction and the suffix ‘_P’ was used for the payment transaction. The diagram is somewhat simplified because it does not include quitted and stopped facts.
As previously mentioned, when utilizing the DEMO transaction pattern there is no difference between events that have occurred or are occurring in the present and events that are planned or expected to occur in the future. Planning for the future is done with a given time in the future in the request and promise transaction steps. The other important conclusion is that each transaction should include all process steps (coordination and production acts and facts) despite the fact that they can be performed tacitly.
The final important conclusion stemming from DEMO is the fact model. The DEMO fact model is one of the four aspect models that constitute DEMO methodology. The fact model contains all production facts together with other directly related entities. To give a brief explanation, a fact refers to ‘something’ that exists in reality and provides us with ‘factual’ knowledge of the world. Facts can be either concrete or abstract: a physical object is concrete while, for example, the ownership of an object is an abstract relationship between two objects. In REA it would mean that the fact model would contain event entities that represent production facts, and related economic agent entities and economic resource entities. These related entities (REA fact model) could thus constitute the core of the database system to preserve achieved production facts. The distinction between the REA model and the REA fact model would increase the expressiveness and clarity of the original REA model.
Introducing coordination and production acts and facts also means that the production fact comes into existence only after it is accepted by the corresponding coordination fact. This corresponds with the view of coordination and production in the transaction pattern.
Currently, REA ontology links its own states with the phases of the business transaction (also known as business process). The business transaction is defined by ISO International Standard (“ISO/IEC”, 2007) and the definition is as follows:
“A business transaction is a 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” (ISO/IEC, 2007).
A business transaction is understood as a reciprocal transaction similarly to the transaction in the REA core pattern. According to the same standard (ISO/IEC, 2007; Gal et al., 2011), a business transaction defines five individual phases:
The planning phase serves for the buyer and seller (actor roles) to decide what action to take to acquire or sell goods, services and so on.
The identification phase represents interchange of data and establishment one-to-one linkage.
The negotiation phase pertains to the exchange of information following the identification phase. This phase also leads to the reciprocal identification at a level of certainty, and achievement of an explicit mutual understanding. The process of negotiation is directed towards achieving an explicit, mutually understood, and agreed upon goal of business collaboration and the associated terms and conditions.
The actualization phase pertains to all activities for the execution of the results of the negotiation for an actual business transaction.
The post-actualization phase includes all activities that occur between the buyer and the seller after the exchange.
All relevant entities and relationships of business transaction are illustrated in Fig. 8 (“ISO/IEC”, 2007). Economic agreement represents either a contract or a schedule entity according to whether it is an exchange or a conversion process. The business transaction itself is governed by the economic agreement and serves as an aggregate of both a bundle of economic events bound by a duality relationship and a bundle of business transaction phases.

Business transaction declared by ISO/IEC (2007).
Currently, the REA model does not have implicitly declared states and state transitions so the business transaction phases are utilized explicitly to create the REA state machine. However, states and state transitions can be identified and declared inside the REA model, mainly within the commitment and event entities (see previous section). A different conceptual specification of the commitment entity and the event entity could lead to more rigorous definition of the business transaction and precise determination of the states and state transitions within the scope of the REA model.
In spite of the fact that the description of the business phases is somewhat brief, it captures its essence and is therefore sufficient for further steps. The ontological model should express the essence of the described reality so the Performa–Informa–Forma analysis will be applied to the individual phases. The reason for this is twofold. Firstly, the aim is to obtain the essential activities of the business transaction. Secondly, we would like to explicitly elucidate whether the REA model declared from the point of view of the DEMO transaction, see Fig. 8, is fully in compliance with business transaction phases. In fact, two abstractions will be applied to the business transaction. The first abstraction concerns coordination acts and facts and the second abstraction deals with the production acts and facts. We should keep in mind that the two abstractions are supportive in structuring the phases of business transaction in corresponding ‘layers’ that communicate with each other in a way that is standard in layered systems.
The planning phase mainly contains the informational production and documental production, which is performed by utilizing the informative and formative levels of coordination. We can judge from the description that both economic agents plan which actions they will perform.
The identification phase in its essence chiefly represents the formative level of coordination resulting in the documental production. This can be derived from the main tasks that are performed in this phase, namely interchanging data and establishing linkage. On the other hand, this phase can also contain the informational production, which is performed by utilizing the informative level of coordination, which can be concluded from the fact that both sides of the transaction can derive information from the exchanged data to be prepared for the next phase.
The negotiation phase is comprised of the informative level of coordination which results in informational production and of performative level of coordination, the transaction steps of request and promise which means the requested and promised coordination facts. One can thus judge from this assertion that the parties agreed upon the goal of business collaboration. The transaction step of request corresponds to the committed receive REA model relationship and the transaction step of promise corresponds to the committed provide REA model relationship.
The actualization phase represents original production. It means that both economic agents perform their production acts, which result in production facts. This phase corresponds to the occurrence of the increment and decrement events in the REA model.
The post-actualization phase contains the performative level of coordination that is the transaction steps of state and accept. The state transaction step corresponds to the provide REA model relationship and the accept transaction step corresponds to the receive REA model relationship. These relationships belong to the economic event entity.
Despite the fact that it is only a shallow analysis it reveals that the phases of business transaction cover all transaction steps of the REA model from the point of view of the DEMO transaction pattern. The planning phase and the identification phases are not part of the essential (ontological) model because they do not perform original production or services (they are on the lower levels of abstraction), but they are supportive of the essential model. Nevertheless, the planning and identification phases are indispensable to the business transaction because their results, the documental production and informational production, are utilized in the negotiation phase. Without the documental and informational production the negotiation phase would be certain to fail. The negotiation, actualization and post-actualization phases chiefly belong to the essence (ontological) model.
Conceiving of an enterprise as a social system is far more natural than modeling it by using traditional techniques that eliminate the human factor and primarily develop the models of enterprises on a work flow basis. The DEMO transaction pattern is a generic formal model of human subjects’ interaction with the aim of achieving a given production fact. Human subjects enter into and comply with mutual commitments regarding production acts.
Distinguishing between coordination and production acts and facts is the first step in conceiving a transaction pattern. The production act and fact are enclosed within the coordination acts and facts. That is why the production fact comes into existence after it is accepted by the corresponding coordination fact. For this reason, the core of any enterprise is in coordination processes (entering into and complying with commitments) and not in production processes themselves as is generally assumed. Applying the operation axiom and the transaction axiom perspective to the REA model bring the following findings. The committed receive and committed provide REA model relationships that relate the commitment entity to the corresponding economic agents can be interpreted as the request and promise DEMO coordination steps. (Coordination step is represented by coordination act and coordination fact.)
The REA economic event entities represent the DEMO production step (represented by production act and production fact). The provide and receive REA model relationships that relate the economic event to the corresponding economic agents, can be interpreted as the state and accept DEMO coordination steps.
From these findings, the commitment and event entities can be viewed as coordination steps. In addition, the economic event represents the production act and the production fact. In this context, we have to take into account that coordination acts are always, either directly or indirectly, about production acts and production facts and that the production fact comes into existence after the accepted coordination fact.
It is necessary to realize that DEMO or rather Enterprise Ontology, which creates the theoretical foundation of DEMO, can be characterized as a generic ontology in the true essence of the meaning. REA Enterprise Ontology can be characterized as a domain-specific ontology. Both modeling perspectives have a different granularity of elementary building blocks. A DEMO transaction is an elementary building block in DEMO. A business process is composed of these transactions. The elementary building block of REA ontology is an REA model at business process level. From a DEMO perspective, the REA model in its simplest form represents two transactions that are mutually interrelated by the exchange/conversion reciprocity and the exchange/conversion duality relationships. In addition, the essential REA model component is a resource entity.
The REA model can be treated as a social system because the core of the model is constituted by two economic agent entities representing human subjects. Detailed study of the REA model proves that all coordination and production acts and facts that have their origin in DEMO and can be revealed inside the REA model. Even the Performa–Informa–Forma analysis proves that any business transaction is in compliance with the DEMO transaction pattern. These findings provide the REA model with the following possibilities.
The first is connected with the closer binding between the commitment and event entities. This assertion stems from the fact that the commitment and event entities can be viewed as a firm part of coordination acts and facts. The first two coordination steps can be revealed in the commitment entity and the last two coordination steps can be revealed in the event entity. Introducing the DEMO transaction pattern view of the REA model would mean eliminating the difference between current economic events and events that are planned for the future because the commitment entity represents the beginning coordination steps and the event entity stands for the end coordination steps. In addition, the DEMO transaction pattern view of the REA model also enables to include cancellation and revoking actions. These actions are in full compliance with the DEMO complete transaction pattern. The second concerns the point that the states are declared inside the REA model, which means that the REA states are in compliance with the states of the REA transaction itself. In order to satisfy the REA transaction, each REA model has to be modeled utilizing the coordination and production steps, which means the commitment and event entities in mutual accordance that is given by the coordination steps. Naturally, it is possible to perform some of the coordination acts and facts tacitly. But actually all coordination acts and facts are inevitably parts of the REA model. The third regards the point that revealing the coordination and production steps inside the REA model makes it possible to distinguish the REA model itself, which contains all coordination and production acts and facts, and the so-called REA fact model, which would contain all production facts related to other REA core pattern entities. This REA fact model could create the core of the database system.
Conclusion
On the basis of the DEMO methodology, the article reveals the state machine in the REA model at its business process level acquired through a new perspective on the explored area. The principal entities dealing with the states are economic commitment, economic event and economic agent. The presence of the economic agent entity is enough to predetermine the REA model to be treated as a social system. Recognizing coordination acts and facts and production acts and facts within the REA model is the starting point for revealing the REA state machine. The relationships between an economic commitment and an economic agent and between an economic event and an economic agent are taken as coordination and production acts and facts.
Introducing states in the REA model means a closer integration of the commitment and event entities. In addition, the distinction between the coordination and production facts makes it possible to distinguish between the current REA model and newly revealed REA fact model. This distinction would increase the expressiveness and clarity of both models. Introducing the REA state machine within the scope of the REA model can help further development of REA ontology.
Footnotes
Acknowledgement
This research was supported by the grant no. SGS17/PRF/2014, provided by Ministry of Education, Youth and Sports of the Czech Republic.
