Summary of The REA Approach to Database Modeling

By -

Summary

This chapter examined the REA model as a means of specifying and designing accounting information systems that serve the needs of all users in an organization. It began by defining the key elements of REA. The basic model employs a unique form of an ER diagram called an REA diagram, which consists of three entity types (resources, events, and agents) and a set of associations linking them. The rules for developing an REA diagram were then explained and illustrated in detail.

Each event in an REA diagram is linked to at least one resource and to at least two agents. An important aspect of the model is the concept of economic duality, which specifies that each economic event must be mirrored by an associated economic event in the opposite direction. These dual events constitute the give and receive activities in an economic exchange.

The chapter went on to illustrate the development of an REA database for a hypothetical firm following a multistep process called view modeling. The steps involved are: (1) identify the event to be modeled, (2) identify the resource changed by events, (3) identify the agents participating in events, and

(4) determine associations and cardinalities between entities. The result of this process is an REA diagram for a single organizational function. This next section in the chapter explained how multiple REA diagrams (revenue cycle, purchases, cash disbursements, and payroll) are integrated into a global or enterprise-wide model. The enterprise model was then implemented into a relational database structure and user views were constructed. The view integration process involved three steps: (1) consolidate the individual models; (2) define primary keys, foreign keys, and attributes; and (3) construct the physical database and produce the user views.

The chapter concluded with a discussion of how REA modeling can improve competitive advantage by allowing management to focus on the value-added activities of their operations. For financial statement reporting purposes, however, many companies compromise the pure REA model by maintaining a traditional general ledger system.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont
Read more

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout
Read more