OOPSLA'96Business Object Workshop III


The Timeless Way of Building Accounting Information Systems: The ‘Activity’ Pattern

Guido L. Geerts
Accounting Department, The Eli Broad College of Business
N259 North Business Complex
East Lansing, MI 48824-1122, USA.
Tel. 517-432-2927, Fax. 517-432-1101
E-Mail: geerts@pilot.msu.edu


ABSTRACT

The Resource-Event-Agent (REA) pattern (McCarthy 1982) is a domain-specific pattern for the analysis and design of accounting information systems. The REA pattern lacks reusability and extendibility. In this paper we transform one of REA’s domain primitives, economic event, into a new pattern using modeling techniques described in Hay(1996) and Fowler(1997). The resulting ‘Activity Pattern’: (i) illustrates the timeless way of building accounting information systems, (ii) integrates reusable procedures, and (iii) preserves the strengths of REA as a domain theory and integrates REA elements with non-REA elements.


What is REA Accounting ?

The Resource-Event-Agent (REA) pattern (McCarthy 1982) is a domain-specific pattern for the analysis and design of accounting information systems. The lower part (I) of the model in figure 1 results from applying the REA template. The REA template can be considered as a generic description of "economic event." At least the following aspects of an economic event must be described:

1. Its stock-flow relationship with economic resources. A sale results in the outflow of products, a purchase results in the inflow of products.

2. Its control relationship with economic agents outside of the firm. Customer is the external agent for sale and vendor is the external agent for purchase.

3. Its duality relationship with another economic event where the increment events are paired with decrement events in a give-take relationship. Sale is paired with cash receipt and purchase is paired with cash disbursement.

The sales order and purchase order in Figure 1 (II) are no part of the REA model since they do not result in a physical inflow or outflow of resources.

Figure 1: REA model(I)

 

What is wrong with the REA pattern ?

The REA pattern lacks reusability and extendibility. Reusability is the ability of software elements to serve for the construction of many different applications (Meyer 1997, p. 7). Extendibility is the ease of adapting the accounting information system to changes in the economic activities of a company. An example will help to clarify this statement. The REA model in figure 2 has two parts. For part I, the assumption is that all operations are done manually. Labor service and raw material are economic resources. Labor service consumption and raw material consumption represent the release or outflow of resources. The production order represents resource consumption (labor and raw material) resulting in WIP (chocolates). The cost of a chocolate is the sum of the labor cost and the cost of the ingredients needed to produce the chocolate. Next, we extend the model in part I with the model in part II. The chocolate manufacturer decides to use machines for the production of chocolate. Changes in the company’s economic activities require structural redesign as well as redesign of procedures. For example, the existing cost calculation can’t be reused and need to be redesigned. We assume that the product cost includes the cost of using the machines.

Figure 2: REA model(II)

 

The Activity Pattern

The activity pattern (figure 3) redesigns REA’s economic event using modeling techniques described in Hay(1996) and Fowler(1997). The economic events in the figures 1 and 2 (sale, cash receipts, production order, etc.) are subtypes of activity (not shown in figure 3). The activity relationships, such as the dual relationship between sale and cash receipt, are no longer hardwired in the conceptual structure. If the chocolate company decides to use machines for production it suffices to define equipment consumption as a subtype of activity. The cost calculation procedure is now defined as the sum of the cost of the outflow events (‘resource consumption’ events) linked to the inflow event (production order.) Changes in the economic activities have no effect on this procedure.

Figure 3: the "Activity" pattern

 

The colored part of the model (Figure 3) represents the knowledge level specifications (Fowler 1997). An example of an activity relationship type is an exchange relationship between sale and cash receipt. Activity relationship instances are constrained by activity relationship type instances. Examples of relationship types are: exchange (sell chocolates for cash), transformation (make chocolates) and commitment (sales order). Exchanges and transformations are refinements of the duality relationship. Transformation and exchange are terms taken from Fisher(1906). Transformations represent activity relationships where resources are converted into other resources. A manufacturing process such as the making of chocolate is a good example of a transformation: labor, raw material and equipment are transformed into chocolate. Exchanges represent activity relationships where resources are traded with an outside party. Selling chocolates to a customer for cash is a good example of an exchange. Different rules apply for transformations and exchanges. For transformations the cost of the inflow economic activity is the sum of the costs of the outflow economic activities. The cost of a chocolate is the sum of all the resources needed to manufacture the chocolate. This is not true for an exchange. The cost of a cash receipt is not the sale amount. The monitoring of imbalances of an exchange relationship is very important. How much does a customer owe us? How much do we owe a vendor, an employee, etc. This is not true for a transformation. Commitment is a term taken from Ijiri (1975). Ijiri(1975, p. 130) describes commitment accounting as ‘recognizing changes in resources when parties in the exchange commit themselves to the delivery of resources, even if no such commitments have yet been fulfilled.’ A good example of a commitment is a sales order. We explained above that a commitment such as sales order is excluded from the REA model. The activity pattern integrates REA elements with non-REA elements.

Pattern types are a powerful instrument to isolate domain-specific behavior and as such to enhance reusability. An example of a pattern type is ‘bulb.’ Our pattern type names are based on metaphors. A bulb is either on or off. The same is true for the participation of sale in the exchange relationship with cash receipt, and for the participation of purchase in the exchange relationship with cash disbursement. A sale is paid or not paid, installments are not allowed. Standardized procedures, such as the calculation of claims, can be defined for all activities for which the participation in the exchange relationship has the same pattern. Pattern types can be constrained by relationship types. Bulb is relevant for exchange relationships only.

Pattern is an objectified relationship describing the pattern type that applies to the participation of an activity in an activity relationship at a certain point in time. For example, bulb applies to (i) the participation of sale in the exchange relationship with cash receipt, and (ii) the participation of purchase in the exchange relationship with cash disbursement. To determine the unpaid balance for a sale (accounts receivable), the sale instance will delegate balance calculation to the bulb pattern type. To determine the unpaid balance for a purchase (accounts payable), the purchase instance will delegate balance calculation to the bulb pattern type.

Summary

- The activity pattern is a good example of ‘the timeless way of building accounting information systems.’ Changes in the economic activities of a company do not necessarily imply substantial redesign efforts.

- The use of pattern types can dramatically improve reusability. Accounting procedures can be shared across accounting cycles. The claim procedure for the bulb pattern can be shared by the accounts receivable, accounts payable and payroll systems.

- The activity pattern preserves the strengths of the REA model as a domain theory (Geerts and McCarthy 1994) and integrates non-REA elements such as commitments.

References

Fisher,I. (1906), The Nature of Capital and Income, MacMillan.

Fowler,M. (1997), Analysis Patterns: Reusable Object Models, Addison Wesley.

Geerts and McCarthy (1994), The Economic and Strategic Structure of Accounting Information Systems, working paper MSU.

Hay, David. C. (1996), Data Model Patterns. Convention of Thought. Dorset House Publishing.

Ijiri,Y. (1975), Theory of Accounting Measurement, American Accounting Association.

McCarthy, W. E. (1982), The REA accounting model: a generalized framework for accounting systems in a shared data environment. The Accounting Review (July): 554-78.

Meyer, B. (1997), Object-Oriented Software Construction, Prentice Hall.


OOPSLA'96Business Object Workshop III