Successfully reported this slideshow.

REA (Resources, Events, Agents)


Published on

Presentation at Vienna University of Technology, November 3, 2008

  • Be the first to comment

REA (Resources, Events, Agents)

  1. 1. REA (Resources, Events, Agents) Pavel Hruby Presentation at Vienna University of Technology November 3, 2008 This presentation is about the REA (resources, events, agents) model, which is going to revolutionize the way the software business applications are developed. We’ll compare two solutions of the same problem: 1. A business process in a successful state-of-the-art business software application (Microsoft Dynamics NAV) 2. The same process in an REA application. We will sketch other advantages of the REA model in the area of interoperability and e-commerce. Note: lower the screen resolution to 1024x768, because otherwise the demonstrations would be difficult to see. 1
  2. 2. Susan Meet page 2 Copyright 2008 REA Technology Let’s start with a specific problem. Susan is a manager of an ART GALLERY. 2
  3. 3. Works Here Susan page 3 Copyright 2008 REA Technology Susan is a manager of an ART GALLERY. Susan buys and sells fine art, and design furniture. 3
  4. 4. Susan Uses a State-of-the-Art Business Software to Keep Track of her Business (we use Microsoft Dynamics NAV as an example) page 4 Copyright 2008 REA Technology 4
  5. 5. Let’s take a closer look (demo) page 5 Copyright 2008 REA Technology I will show you that some tasks are very easy, but some are not. In fact, every software like this has some very serious problems, and I will show you just a little example. It is interesting that everyone with basic knowledge of REA can very quickly discover from a particular application’s data model, which common business scenarios will be supported and which will not be. 5
  6. 6. Why very easy to create a sales order. It is Why is it so difficult to find out whether an order has been paid? Using a State-Of-The-Art Business Application? page 6 Copyright 2008 REA Technology It is so difficult because Microsoft Dynamics NAV is a software for ACCOUNTANTS. For accountants, the process ends when an invoice is issued (at that time the revenue is recognized and tax is calculated). Accountants even call the transaction at that point ”REALIZED”. However, for Susan (an owner of the gallery) is very important to know whether invoices have been paid. You might know that companies sometimes receive a fraudulent letter, stating that a company forgot to pay a small amount, such as 30 or 50 USD, several years ago. Accountants sometimes pay that – because it is very difficult to verify this information in the current accounting software applications. 6
  7. 7. That’s You Business Analyst a and Software Designer page 7 Copyright 2008 REA Technology Accountants did not tell you about how important is to register a payment and link the payment to other transactions, such as to the sales order. But you would like to make a software application that satisfies Susan’s - the gallery manager’s requirements, not only the accountant’s requirements. 7
  8. 8. Identify User Requirements that How do You Have not Been Communicated to You? page 8 Copyright 2008 REA Technology User requirements are certainly an important input to software design, but we also know that they are always incomplete. But how could we possibly know something we do not know about? 8
  9. 9. Identify User Requirements that How do You Have not Been Communicated to You? REA model, You could consider the (Resources, Events, Agents). all business The general principle that applies to systems. REA is for business systems what Einstein’s e=mc2 is for physics. page 9 Copyright 2008 REA Technology You can use REA to determine the unknown pieces of the software design, similarly as you use the laws of physics to determine the unknown pieces of a technical construction. 9
  10. 10. Fundamental Principle of Business The economic activities of an entity are a sequence of exchanges of resources the process of giving up some resources to obtain others. Therefore, we have to not only keep track of increases and decreases in the resources that are under the control of the entity but also identify and Yuji Ijiri record which resources were exchanged for which others.” Yuji Ijiri : The Foundations of Accounting Measurement, Prentice-Hall 1967. page 10 Copyright 2008 REA Technology 10
  11. 11. The REA (Resources, Events, Agents) model with Commitments and Contracts William McCarthy McCarthy WE: The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review (July 1982) pp. 554-78 Guido Geerts Guido L. Geerts and William E. McCarthy: The Ontological Foundations of REA Enterprise Information Systems, 1999. page 11 Copyright 2008 REA Technology Bill McCarthy made a data model based on Ijiri’s ideas. Bill McCarthy with Guido Geerts later extended the model with the concepts of Commitment and Contract, and several other concepts such as Group, Type and Policy. REA specifies the rules that every real business system conforms to, such as: -every economic event has a provider and a recipient agent; -every economic event is related to a resource, -every economic event is related to another economic event explaining what the agent receives in return. -every commitment is fulfilled by an economic event. 11
  12. 12. Axioms of the REA Ontology for exchange processes, independent view Each economic event must be related by stockflow relationship to exactly one economic resource. Each economic event must be related to exactly one provider and one recipient economic agent. Each economic event must eventually be related by duality relationship to another economic event, in which the provider agent receives an economic resource which has more value to this agent in its pursuit of its entrepreneurial goals. Each economic resource must be related by stockflow relationship to at least one economic event where an agent is a recipient, and to at least one other economic event where the same agent is a provider. Each commitment must be eventually related by fulfillment relationship to at least one economic event. Each commitment must be related by reservation relationship to exactly one economic resource. Each commitment must be related to exactly one indented provider and one intended recipient economic agent. page 12 Copyright 2008 REA Technology Similar axioms exist for conversion processes, where the rules regarding the number of agents in each process is different. 12
  13. 13. Trading Partners of Susan’s Gallery Sale Acquisition Rental Variations: Payment by cash / credit card Payment beforehand / afterwards the Sale/Purchase Payment on account, by subscription, in installments page 13 Copyright 2008 REA Technology We’ll create an REA model for Susan’s gallery. 13
  14. 14. Sales Process The page 14 Copyright 2008 REA Technology Sale of Artwork does not need to occur at the same time as Cash Receipt. The time order of the events emerges at runtime. Cash receipt can occur after or before the Sale of Artwork, can occur in installments, or some Cash can be received as a prepayment beforehand and the rest after the Sale. This flexibility is very useful when designing software applications that has to deal with unexpected user requirements. 14
  15. 15. Acquisition Process The page 15 Copyright 2008 REA Technology The acquisition process follows the same pattern. 15
  16. 16. Rental Process The «exchange process» Exhibition Cash Rental Area page 16 Copyright 2008 REA Technology The rental process follows the same pattern. 16
  17. 17. Business Processes of Susan’s Gallery page 17 Copyright 2008 REA Technology This is an REA version of Porter’s value chain. REA gives a precise definition of the term “business process”. A business process is a set of economic events related by duality relationship. 17
  18. 18. Gallery Services Process of page 18 Copyright 2008 REA Technology Process of gallery services is not an exchange process. It is a conversion process, an example how Susan’s Gallery uses its resources to add value to Artwork. Presumably, artwork on display in a gallery has more value to gallery’s customers than an artwork that nobody knows about. All production processes are modeled in this way. 18
  19. 19. Complete REA Model for Susan’s Gallery page 19 Copyright 2008 REA Technology This model satisfies all REA axioms. 19
  20. 20. Sales Order? How to model not economic events. Order lines are Order lines are promises of economic events. This is not an error page 20 Copyright 2008 REA Technology The price of 1000 USD is not an error because what really matters are the resources exchanged: 2 pieces of Pedestal and 1 piece of Table are exchanged for 1000 USD. The way how the value of 1000 USD is obtained is a technical detail that might be specific to an industry and a branch of business, and might be different in each individual case, or even determined by software applications. In electronic commerce we should focus on the things that really matter from economic point of view, not on technical algorithms how individual software applications work. 20
  21. 21. REA Commitment page 21 Copyright 2008 REA Technology Commitments represent obligations of economic agents to execute economic events in the future. Commitments are related to intended provider and recipient agents, and by the reservation relationship to an economic resource. 21
  22. 22. Sales Order of Susan’s Gallery page 22 Copyright 2008 REA Technology 22
  23. 23. Let’s take a closer look (demo) page 23 Copyright 2008 REA Technology The demo shows an REA-based software application developed by Christian Scheller with my contribution. We used Bill McCarthy’s and Guido Geerts’ ideas to build a model-driven framework for developing business software applications. The information whether orders were paid is easily accessible, because we were aware of the REA rule ”every commitment is fulfilled by an economic event”. Consequently, the REA applications eliminate the fundamental economic errors and omissions that exist in probably all other business applications. 23
  24. 24. The Enron Scandal Could not Happen if an REA Software Were Used REA provides: Full traceability of all transactions Prediction of consequences of actions of the management. Up-to date financial statements available on demand Is understandable to non-accountants. Enron scandal The could not happen if an REA software was used. page 24 Copyright 2008 REA Technology As you saw, the REA application presents you the real economic data, what has been purchased, sold, and the contracts determining the future purchases and sales. Not the fictitious accounting data such as adjusting entries, depreciations and retained earnings. The fictitious data are needed in the real life. For example, many government authorities, including the tax office, require them. But you, as a manager or investor, can easily distinguish in an REA application what is real and what is fictitious. Therefore, ”creative accounting” in an REA application is much more difficult than in the state-of-the-art accounting applications. 24
  25. 25. Sufficient? Is the REA Model The REA model determines a structure of an application. However, We need more than just a structure For example, what about attributes and methods? Should they be part of the ontology? Let’s see some examples page 25 Copyright 2008 REA Technology 25
  26. 26. Economic Resource (from a product catalogue) Athens Pedestal Brushed steel, glass $219,50 Artist Eric Laxman Dimensions Height: 36 in Width: 20 in Depth: 20 in page 26 Copyright 2008 REA Technology Should we extend the REA ontology to include price, material, and dimensions? 26
  27. 27. Economic Resource (from a product catalogue) Auchentoshan Nose Fruity. Raisins, especially dates, Single Malt Scotch Whisky orange peel. 12 year old Lowland Palate 44,3% Beautiful balance of dark, syrupy, fruity, maturation 70cl flavours and cedary, oily, £33.99 marshmallow, characteristics from the spirit itself. Finish Gentle, long, warming, lemon grass, spice. page 27 Copyright 2008 REA Technology Should also alcohol percentage, nose, palate and finish be part of the REA ontology? 27
  28. 28. Economic Resource (from a product catalogue) T-shirt with Miami Beach Topics $14.99 Relax in this high quality (Hanes-Beefy- T) white T-shirt with Miami Beach Topics silk-screened on the front. The back is plain. page 28 Copyright 2008 REA Technology Should also suggestions how to relax be part of the REA ontology? 28
  29. 29. Conflict Ontologies are designed to be general the same categories for all systems in the domain E-commerce applications are all different They must meet specific user requirements page 29 Copyright 2008 REA Technology I would prefer to keep the REA ontology small and focused. The but a software applications, as well as e-commerce standards need placeholders to accommodate variability. 29
  30. 30. Two Parts of an Application 1. REA is the stable core never change, and REA describes principles that apply to all e-commerce and production planning applications 2. Reusable components that change often are designed to are industry and application specific extend the REA model in a consistent manner can be implemented, for example, as SOA services page 30 Copyright 2008 REA Technology “Never change” is a strong statement, and, of course, also the basic laws of physics change once in every couple of hundred years. But for the purposes of creating a particle accelerator it is safe to assume that e=mc2 is not going to change. Likewise, it is safe to assume that the basic laws of business, defined by the REA ontology are stable, for the purposes of designing e-commerce applications. 30
  31. 31. Model-Driven Design of Business Applications page 31 Copyright 2008 REA Technology The REA ontology can be extended by other ontologies covering the specific requirements. Software applications can be developed by “weaving” other ontologies into the REA ontology. This is especially useful in model-driven design. The “weaving” is sometimes referred to as “model merge”. 31
  32. 32. E-Commerce and Interoperability SAP Financing Money Sage Sales Marketing Item Brand Name Labor Microsoft Dynamics Human Procurement NAV Resources Peoplesoft Legend: Resource Flow Port (semantics of flow and port specified in UML 2.0) page 32 Copyright 2008 REA Technology Interoperability can be based on shared business semantics defined by the REA ontology. This will assure a conceptually consistent model, where also some requirements, unknown to committees developing the e-commerce standards, will be fulfilled. 32
  33. 33. Electronic Document Standards (non-REA standards) Examples Universal Business Language (UBL), developed by OASIS. OIOXML (Offentlig Information Online) in e-Government in Denmark Cross-Industry Invoice, developed by UN/CEFACT XBRL GL (eXtensible Business Reporting Language, Global Ledger) They are driven by requirement of compatibility with all of the data and document formats that exist in the world, domain semantics and instead of being driven by conceptual integrity. page 33 Copyright 2008 REA Technology UBL and UN/CEFACT are two leading standards developed independently on each other. OIOXML – “Offentlig Information Online XML” (“Public Information Online” in Danish) is based on UBL. 33
  34. 34. Example: Cross Industry Invoice – UN/CEFACT A non-REA approach (adapted from UN/CEFACT) Invoice is a message claiming payment for goods or services supplied under conditions agreed between the supplier and the customer. XML Schema Definition <xsd:complexType name=quot;CrossIndustryInvoiceTypequot;> <xsd:sequence> <xsd:element name=quot;SupplierPartyquot; type=quot;ram:SupplierPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;CustomerPartyquot; type=quot;ram:CustomerPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;BuyerPartyquot; type=quot;ram:BuyerPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;SellerPartyquot; type=quot;ram:SellerPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;ConsignorPartyquot; type=quot;ram:ConsignorPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;ConsigneePartyquot; type=quot;ram:ConsigneePartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;InvoiceePartyquot; type=quot;ram:InvoiceePartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;ManufacturerPartyquot; type=quot;ram:ManufacturerPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;PayeePartyquot; type=quot;ram:PayeePartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;InvoiceIssuerPartyquot; type=quot;ram:InvoiceIssuerPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;TaxRepresentativePartyquot; type=quot;ram:TaxRepresentativePartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;CustomerAccountantPartyquot; type=quot;ram:CustomerAccountantPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;SupplierAccountantPartyquot; type=quot;ram:SupplierAccountantPartyTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;InvoiceTradeLineItemquot; type=quot;ram:InvoiceTradeLineItemTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;BillingPeriodquot; type=quot;ram:BillingPeriodTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;TradeTransportMeansquot; type=quot;ram:TradeTransportMeansTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;TradeTransportModequot; type=quot;ram:TradeTransportModeTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;PayableAccountingAccountquot; type=quot;ram:PayableAccountingAccountTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;ReceivableAccountingAccountquot; type=quot;ram:ReceivableAccountingAccountTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> XSD covers MOST COMMON, but not all, scenarios. </xsd:element> <xsd:element name=quot;BillingCurrencyExchangequot; type=quot;ram:BillingCurrencyExchangeTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;PaymentCurrencyExchangequot; type=quot;ram:PaymentCurrencyExchangeTypequot; minOccurs=quot;0quot;> </xsd:element> Allows interoperability by using brutal force (i.e. legislation) <xsd:element name=quot;AlternativePaymentCurrencyExchangequot; type=quot;ram:AlternativePaymentCurrencyExchangeTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;TaxCurrencyExchangequot; type=quot;ram:TaxCurrencyExchangeTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;PayeeFinancialAccountquot; type=quot;ram:PayeeFinancialAccountTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;TradeAllowanceChargequot; type=quot;ram:TradeAllowanceChargeTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;BillingAdjustmentquot; type=quot;ram:BillingAdjustmentTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> Sources: </xsd:element> <xsd:element name=quot;TradeNotequot; type=quot;ram:TradeNoteTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;TradeDeliveryTermsquot; type=quot;ram:TradeDeliveryTermsTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;BillingDocumentquot; type=quot;ram:BillingDocumentTypequot;> </xsd:element> <xsd:element name=quot;BillingPaymentquot; type=quot;ram:BillingPaymentTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;AdvancePaymentquot; type=quot;ram:AdvancePaymentTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;ReferencedDocumentquot; type=quot;ram:ReferencedDocumentTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> <xsd:element name=quot;BillingMonetarySummationquot; type=quot;ram:BillingMonetarySummationTypequot; minOccurs=quot;0quot;> </xsd:element> <xsd:element name=quot;CategorySubtotalTaxquot; type=quot;ram:CategorySubtotalTaxTypequot; minOccurs=quot;0quot; maxOccurs=quot;unboundedquot;> </xsd:element> </xsd:sequence> </xsd:complexType> page 34 Copyright 2008 REA Technology UN/CEFACT - United Nations Centre for Trade Facilitation and Electronic Business. UNECE – United Nations Economic Commission for Europe. 34
  35. 35. Cross Industry Invoice – a Better Model A possible solution epistemologically adequate to REA Invoice is a message claiming goods or services, for goods or services supplied under conditions agreed between the supplier and the customer. materialized 1..* Materialized Claim Economic Event settlement 1..* +DateOfIssue +SerialNumber 0..* Terms Covers ALL scenarios. Allows interoperability at semantic level - economic semantic of the document can be interpreted by a software application. Source: Adapted from International standard ISO/IEC FDIS –15944-4 Information technology — Business Operational View — Part 4: Business transaction scenarios — Accounting and economic ontology page 35 Copyright 2008 REA Technology Details about REA claims are here: -Geerts G., McCarthy W.: Augmented Intensional Reasoning in Knowledge- Based Accounting Systems. Journal of Information Systems, Volume 14, No. 2, 2000, pp. 127-150. -International standard ISO/IEC FDIS –15944-4 Information technology — Business Operational View — Part 4: Business transaction scenarios — Accounting and economic ontology 35
  36. 36. Why is REA Better than Your Other Favorite Ontology? “Ontology is a study of the categories of things that exist or may exist in some domain...” Sowa, J.: Knowledge Representation: Logical, Philosophical, and Computational Foundations, Course Technology, 1999. “…based on some fundamental idea beyond the things immediately present.” Inspired by George Polya: How to Solve it, Princeton University Press, 1982. The REA ontology is based on the fundamental idea of modeling business as exchanges of economic resources between business partners. page 36 Copyright 2008 REA Technology 36
  37. 37. The REA Model is Also Good For Domain-specific language for modeling business systems REA-based DSL for modeling business systems really works. Providing complete past, present and future information about an enterprise Available on demand and understandable to non-accountants Electronic business The REA model enables interoperability based on understanding of fundamental principles of business domain, rather than on political consensus. Design method for long-living applications The REA model enables to separate the stable core and the changeable part of the system. page 37 Copyright 2008 REA Technology 37
  38. 38. REA as a Design Method Other modeling WHAT - the economic resource approaches underemphasize or WHEN - the economic event completely omit WHO - the economic agents the WHY. HOW – services (extending REA) WHERE – the address service WHY – the duality and fulfillment An example of an REA-based design method is UMM, the 2003 version: UN/CEFACT Modeling Methodology User Guide, 2003, document CEFACT/TMG/N093 page 38 Copyright 2008 REA Technology The REA model is the only known business modeling method that can provide the answers to why business processes occur, why an enterprise performs its business processes, and why a specific modeling element is part of the model. An example is: “Why do customers need to pay this shop?” The answer, which an REA-based model can provide, is: “Because they received the goods.” This answer cannot be given by any alternative business modeling method, because the business interpretation of the modeling elements, and business validation of the model, are not available to a tool and are left solely to the modeler. 38
  39. 39. My Favorite Books on Business Patterns page 39 Copyright 2008 REA Technology Here are examples of excellent books containing a lot of domain knowledge. But they describe the domain knowledge as independent pieces of information, with no relationships between each other, without a common backbone. 39
  40. 40. Business Patterns with the REA Backbone Pavel Hruby, Jesper Kiehn, Christian Vibe Scheller: Model-Driven Design Using Business Patterns Springer, 2006 (English edition) Nikkei BP, 2007 (Japanese edition) “The best book on REA so far” Dave Feinstein at Selected chapters are in: Capitalism in UML: Designing Service-Oriented Applications that Understand your Business page 40 Copyright 2008 REA Technology Our book describes business patterns with the REA backbone. Dave Feinstein wrote at “I came across Fowler's book and I think it was great and I liked it so much, especially modeling the account and the related entries. But that was about it as far as the simplicity goes. It started to get a bit more complex as I started to get more patterns. I started to do some more searches till I got to the REA, Resources- Events- Agents and that was it. I was blown away. The model is so simple but powerful in capturing the most fundamental concepts in the accounting and business domain. So I think, REA model will change the business information modeling arena in the same way object oriented programming changed the programming world, and like design patterns impacted the design world. I also predict that this book will be for the business application architecture community as the GoF book to the software designers community at large. “ 40
  41. 41. Other REA Books for Students of Accounting Chang et al, 2007 shows how easy is to develop REA applications using Microsoft Access. Dunn et al. 2004 is targeted to students of accounting. Hollander et al. 1999 describes the REAL model (Resources, Events, Agents and Locations). page 41 Copyright 2008 REA Technology 41
  42. 42. REA Community REA Bootcamps (SMAP - Semantic Modeling of Accounting Phenomena) for teachers in accounting information systems, held every January in the USA. International workshops 2009, 8-9 February, in Stockholm, Sweden 2008, June, in Montpellier, France 2006, June, on Santorini, Greece 2004, April, in Copenhagen, Denmark International conference REA-25, Newark, Delaware, USA, 2007 REA Software page 42 Copyright 2008 REA Technology REA Technology offers probably the most pure and complete REA application so far, which is also model-driven, and with clear separation of the REA part and the designed-for-change part. Workday’s goal is to offer an alternative to ERP. The REA model is one of many of their differentiators to traditional ERP systems. Group Accounting offers an REA solution for cooperatives – groups of independent individuals working together. This is very hard in traditional accounting solutions, which only work from the viewpoint of a proprietor. REA supports the “independent view” out of the box, allowing, for example, modeling the supply chain. 42
  43. 43. Summary Features of REA Business Solutions 1.Independent view (a trading-partner-independent model) REA applications provide supply-chain management and accounting for groups out of the box. Traditional applications are limited to the viewpoint of a proprietor. 2.Both monetary and non-monetary elements of transactions REA applications seamlessly integrate production and finances. Based on”The best book on REA so Traditional accounting is limited to financial transactions, and far2)”, by Pavel Hruby, Jesper non-monetary transactions are confusingly represented in financial units of measure (e.g. as a dollar value). Kiehn and Christian Vibe Scheller Traditional production-planning concepts are irreconcilable with traditional financial accounting concepts. 3.REA balance sheet comprising : REA dynamic management solutions Expected (e.g. plans, budgets) transactions Precise, up-to-date, clear, complete and reliable description, explanation and prediction of the Agreed (e.g. orders, contracts) transactions economic consequences of the actions of people and organizations Realized transactions (e.g. claims, invoices) Traditional solutions Transferred (transactions made) Confusing images of the past events3) transactions 3) REA applications fully comply with existing legislation, page 43 1) Copyright 2008 REA Technology because the concepts of traditional accounting are a 2) Dave Feinstein on subset of REA concepts. 43
  44. 44. Contact Pavel Hruby page 44 Copyright 2008 REA Technology 44