Accounting Information System Week 2 – Database Concept II (REA Accounting Model & ER Modeling) Prepared by Nuril Kusumawardani ST., MKM
Acknowledgement These slides have been adapted from Considine , B et al. (2012). Accounting Information Systems: Understanding Business Processes, 4 th edition. Chapter 4 Bina Nusantara
Acknowledgement These slides have been adapted from Hall, James A. (2013). Accounting Information Systems, 8 th edition, South-Western : Cengage Learning. Chapter 10 Bina Nusantara
Learning Objectives Discuss the REA (resources–events–agents) Accounting Model as a template for modeling accounting systems Understand the differences between REA and entity-relationship modeling Economic foundations of the REA model Key differences between traditional ER modeling and REA modeling The structure of an REA diagram Create an REA diagram by applying the view modeling steps to a business case Create an entity-wide REA diagram by applying the view integration steps to a business case
Sub Topics The REA Accounting Model The REA Approach Developing an REA Model View integration : Creating an enterprise-wide REA Model
The REA Accounting Model
The Rea Accounting Model Another way to model data is to use the REA Accounting Model This model is based on the premise that in every exchange in a process there is a resource , event and agent involved
The Rea Accounting Model SALES PROCESS
The Rea Accounting Model Expanded E-R diagram showing entities and exchanges between them
The Rea Accounting Model
The Rea Accounting Model
Despite the reluctance of businesses to use REA to implement accounting systems, one of the REA model’s greatest advantages is that it can store non-financial data as well as financial data It is possible for organizations to use REA to model their business processes, but then implement the relationships via a traditional accounting system The Rea Accounting Model
The REA Approach
Traditional Approaches: User-View Orientation When data-modeling and IS design is too oriented toward the user’s views, problems arise: multiple information systems duplication of data restricted user-view leads to poor decision-making inability to support change The REA Approach
REA is an approach to database design meant to overcome problems with traditional approaches: formalized data modeling and design of IS use of centralized database use of relational database structure collects detailed financial and non-financial data supports accounting and non-accounting analysis supports multiple user views supports enterprise-wide planning The REA Approach
The REA Approach The Elements of REA
the ‘assets’ of the company things of economic value objects of economic exchanges able to generate revenue objects that are scarce and under the control of the organization can be tangible or intangible Does not include some traditional accounting assets : artifacts that can be generated from other primary data for example, accounts receivables Resources The REA Approach
Resources The REA Approach www.injuryfinancing.com www.tilwood.com
Events Events are phenomena that effect changes in resources . a source of detailed data in the REA approach to databases Events fall into two groups: Economic – increases or decreases resources Support – control, planning, and other management activities; but do not directly affect resources Events The REA Approach
Economic Events The REA Approach www.thetrendystyle.com 1aled.fotomaps.ru www.thesquawkshoppe.com
Support Events The REA Approach inventorymanagementextension.com Inventory Checking do not directly affect resources
Agents can be individuals or departments. Participate in events Affect resources Have discretionary power to use or dispose of resources Can be inside or outside the organization Clerks Production workers Customers Suppliers, vendors Departments, teams Agents The REA Approach
The REA Approach Agents sevenqueenshop.blogspot.com www.pivotalretailmarketing.co.uk mansab.upp.al
Developing an REA model
View Modeling: Creating an Individual REA Diagram View modeling is a multistep process for creating an individual REA model. The result is a single view of the entire database. The four steps involved are: identify the event entities to be modeled identify the resource entities changed by events identify the agent entities participating in events determine associations and cardinalities between entities
The Narration Apex Supply Company is a downtown Philadelphia wholesaler of electrical products that sells to electrical retailers. It carries an inventory of approximately 10,000 items. Customers place orders by phone and buy on credit through a line-of-credit arrangement with Apex. A typical transaction involves the customer first contacting the customer services department to verify availability and check the price of the item or items being sought. If the customer decides to buy, he or she is transferred to a sales agent, who takes the order. The shipping clerk sends the products to the customer by a common carrier. The billing clerk records the sale in the sales journal, prepares an invoice, and sends it to the customer, who is given 30 days to make payment. The accounts receivable clerk also receives a copy of the invoice and records it in the accounts receivable ledger. Subsequently (within 30 days) the customer sends a check and the remittance advice to Apex. The cash receipts clerk receives the check, records it in the cash receipts journal, and updates the cash account. The remittance advice goes to the accounts receivable clerk, who updates (reduces) the customer’s account receivable.
1. Identify the Event entities Identify the events that are to be included in the model Include at least two economic events (duality) May include support events Arrange events in chronological sequence Focus on value chain events Do not such invalid events such as: bookkeeping tasks accounting artifacts, e.g., accounts receivable Developing an REA Model
Verify Availability Take Order Ship Product Receive Cash EVENTS Order of Events Arrangement of Events Entities in Order of Occurrence
2. Identify the Resources entities Identify the resources impacted by events identified in step 1 Each event must be linked to at least one resource. Economic events directly affect resources Support events indirectly affect them Developing an REA Model
Verify Availability Take Order Ship Product Receive Cash EVENTS Inventory Inventory Inventory Cash
3. Identifies the Agents entities Each economic event entity in an REA diagram is associated with at least two agent entities. One internal agent One external agent It is possible to have only an internal agent when no exchange occurs, as with certain ‘internal’ manufacturing processes Developing an REA Model
Verify Availability Take Order Ship Product Receive Cash EVENTS Inventory Inventory Inventory Cash RESOURCES AGENTS Customer Service Clerk Customer Sales Representative Customer Shipping Clerk Customer Cash Receipt Clerk Customer
4. Determine Associations and Cardinalities Association – reflects the nature of the relationship between two entities Represented by the labeled line connecting the entities Cardinality – the degree of association between the entities Describes the number of possible occurrences in one entity that are associated with a single occurrence in a related entity Cardinality reflects the business rules that are in play for a particular organization. Sometimes the rules are obvious and are the same for all organizations. Sometimes the rules differ, e.g., whether inventory items are tracked individually or as quantity on hand.
Source: Hall (2008:507) cardinality between entities using the crow’s foot notation method.
Source: Hall (2008:506) Alternative Techniques for Representing Cardinality
Many-to-Many Associations Many-to-many (M:M) associations cannot be directly implemented into relational databases. They require the creation of a new linking table. This process splits the M:M association into two 1:M associations. The linking table requires a ‘composite primary key’.
Link Tables in an REA Diagram Source: Hall (2008:509)
View integration: creating an enterprise wide rea model
View integration – combining several individual REA diagrams into a single enterprise-wide model The three steps involved in view integration are: consolidate the individual models define primary keys, foreign keys, and attributes construct physical database and produce user views View Integration: Creating an Enterprise-Wide REA Model
1. Consolidate the Individual Model Merging multiple REA models requires first a thorough understanding of the business processes and entities involved in the models. Individual models are consolidated or linked together based on shared entities. For example, procurement (expenditures) and sales (revenue) both use inventory and cash resource entities. View Integration: Creating an Enterprise-Wide REA Model
Source: Hall (2008:507-511)
Source: Hall (2008:507-513)
2. Define Primary Keys, Foreign Keys & Attributes Implementation into a working relational database requires primary keys, foreign keys and attributes in tables. Primary key – uniquely identifies an instance of an entity (i.e., each row in the table) Foreign key – the primary key embedded in the related table so that the two tables can be linked Attribute – a characteristic of the entity to be recorded in the table View Integration: Creating an Enterprise-Wide REA Model
Tables, Keys & Attributes
Tables, Keys & Attributes (Cont.) Source: Hall (2008:507-515)
3. Construct Physical Database & Produce User Views The database designer is now ready to create the physical relational tables using software. Once the tables have been constructed, some of them must be populated with data. Resource and Agent tables Event tables must wait for business transactions to occur before data can be entered. The resulting database should support the information needs of all users. SQL is used to generate reports, computer screens, and documents for users. View Integration: Creating an Enterprise-Wide REA Model
Source: Hall (2008:507-517) User-View #1 Past Due Accounts Name Amount James $500.00 Henry $100.00 … … Sales Report User-View #2 REA Database View Integration: Creating an Enterprise-Wide REA Model