The choices involved in each of these questions impact the organization’s ability to maintain

database integrity. The preservation of audit trails and the accuracy of accounting records are key
concerns. Clearly, these are decisions that the modern accountant should understand and influence
intelligently.

Lesson 4 – Advanced Technologies in Accounting Information

Learning Objective:

After studying this Lesson 4, the student should:

• Recognize the economic foundations of the resources, events, and agents
(REA) model.
• Understand the key differences between traditional entity relationship modeling
and REA modeling.
• Understand the structure of an REA diagram.
• Be able to create an REA diagram by applying the view modeling steps to a
business case and be able to create an entity-wide REA diagram by applying
the view integration steps to a business case.
• Understand the general functionality and key elements of ERP systems.
• Understand the various aspects of ERP configuration including servers,
databases, and the use of bolt-on software.
• Understand the purpose of data warehousing as a strategic tool and recognize
the issues related to the design, maintenance, and operation of a data
warehouse.
• Recognize the risks associated with ERP implementation and be aware of the
key considerations related to it.
• Understand the internal control and auditing implications associated with ERPs.
• Be acquainted with the topologies that are employed to achieve connectivity
across the Internet.
• Possess a conceptual appreciation of protocols and understand the specific
purposes that several Inter-net protocols serve.
• Understand the business benefits associated with Internet commerce and be
aware of several Internet business models.
• Be familiar with the risks associated with Intranet and Internet electronic
commerce.
• Understand issues of security, assurance, and trust pertaining to electronic
commerce.
• Be familiar with the electronic commerce implications for the accounting
profession.

I. Traditional Approaches: User-View Orientation

When data-modeling and IS design is too oriented toward the user’s views, problems arise:
▪ multiple information systems

63
 ▪ duplication of data
▪ restricted user-view leads to poor decision- making
▪ inability to support change
II. Resources, Events, and Agents Model (REA Model)

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

REA model consists of three entity types and the associations linking them.
▪ Resources
▪ Events
▪ Agents
Resources in the REA Model

❖ Resources
▪ 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
o for example, accounts receivables
Events in the REA Model

❖ Events
▪ 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
Agents in the REA Model

❖ Agents

64
 ▪
can be individuals or departments
▪
Participate in events
▪
Affect resources
o Have discretionary power to use or dispose of resources
▪ Can be inside or outside the organization
o Clerks
o Production workers
o Customers
o Suppliers, vendors
o Departments, teams
❖ Another key feature of the REA model is economic duality.
▪ Events occur in pairs
▪ Represent the give event and receive event of an economic exchange

ER Diagrams (ERD’s) versus REA Diagrams (READ’s)

❖ Classes of entities
▪ ERD’s – one class
▪ READ’s – three classes (resources, events, and agents)
❖ Arrangement of entities
▪ ERD’s – determined by cardinality and readability
▪ READ’s – organized into constellations by class
❖ Sequencing of events
▪ ERD’s – static
▪ READ’s – chronological sequence of business processes
❖ Naming conventions
▪ ERD’s – all nouns
▪ READ’s – nouns (R’s and A’s) and verbs (E’s)
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:
1. identify the event entities to be modeled
2. identify the resource entities changed by events
3. identify the agent entities participating in events
4. determine associations and cardinalities between entities
Step 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

65
 ❖ Event entities
▪ Verify Availability
▪ support event because it does not directly increase or decrease a resource
▪ decision to add this entity to the model will depend on management’s need
for information regarding customer inquiries
▪ Take Order
▪ could be either an economic or support event
▪ involves only a commitment on the part of the seller to sell goods to the
customer
▪ Ship Product
▪ an economic event
▪ the give half of an economic exchange and reduces the inventory resource
directly
▪ Receive Cash.
▪ an economic event
▪ the receive half of the exchange that increases the cash resource
❖ Focus on value chain events
▪ activities that use cash to obtain resources including equipment, materials, and
labor and then employ those resources to earn new revenues
❖ Do not such invalid events such as:
▪ bookkeeping tasks
▪ accounting artifacts, e.g., accounts receivable
Step 2. Identify the Resource 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
Step 3: Identify the Agent Entities
❖ Each economic event entity in REA diagram is associated with at least two agents:
1. Internal agents: customer which is associated with all four events.
2. External agents:
a. Customer service clerk- that participates in the verify ability event
b. Sales representative- participates the take order event
c. Shipping clerk- participates in the ship product
d. Cash receipt clerk- participates in the receive cash event
❖ Each of these internal agents is in fact an instance of the employee entity type, which is a
separate entity.

Step 4: Determine Associations and Cardinalities between Entities

❖ Associations- is the nature of the relationship between two entities, as the labeled line
connecting them represents.
❖ Cardinality- (degree of association between the entities) describe the number of
occurrences in one entity that are associated with a single occurrence in related entity.

66
 ❖ Four basic forms of cardinality are possible: zero or one (1,0), one and only one (1,1), zero
or many (0,M) and 1 or many (1,M)

Three Alternative Methods Representing Cardinalities in REA Diagram

➢ Alternative 1: Crow foot notation

This example illustrates that, Single occurrence in in Entity A is associated with zero
or many occurrences in Entity B. (lowest cardinality is zero, highest is many)
On the other side, Single occurrence in Entity B is associated with one and only one
occurrence in entity A.
➢ Alternative 2: Cardinalities are explicitly written
➢ Alternative 3: Shows only upper cardinality and presume lower cardinality as zero.

Cardinality between the Verify Availability and Take Order Entities.

Each occurrence of verify ability entity is the result of a customer inquiry.

However, not all inquiries will result in a customer order. The cardinality
on take order side is 0,1 and 1,1 on verify ability side.

Cardinality between the Take Order and Ship Product

The 0,1 cardinality on the ship product side relation reflects the timing
differences between order taken and shipped. Since sales are not
processed instantly, we can assume that the order exist that has not yet
been shipped.

Cardinality between the Ship Product and Receive Cash Entities

Since business terms and payments policies vary greatly, this

would result in many cash receipt occurrences for a single shipment.
Some customers are business customers typically expect payment in
full when due.

67
Cardinality between the Cash and Receive Cash Entities

The cash resources of an organization are composed of several different accounts such as
general operating account, payroll, imprest petty cash and so on. The cash received from many
customers and is deposited in one account.

Many to Many Associations

This means that an order may contain one or many different items in inventory and an item
may have never been ordered or may have been ordered many times during a period.

View Integration: Creating an Enterprise-Wide REA Model

The view modeling process described in the previous section produced an individual REA
model of the revenue cycle for Apex Supply. This section explains how multiple REA diagrams,
each created in its own view modeling process, are integrated into a single global or enterprise
model. The section then explains how the enterprise model is implemented into a relational
database and user views constructed.

The view integration process involves three basic steps:

1. Consolidate the individual models.
2. Define the primary keys, foreign keys, and attributes.
3. Construct the physical database and produce user views.

Step 1: Consolidate the Individual Models

Since this company is wholesale supply company with no production facility, model
consideration for them will include revenue model cycle and expenditure cycle model for
purchases and cash disbursements and payroll.

Purchases and Cash Disbursement Procedures

This shows 3 event entities:
1. Order product entity, support event that does not directly increase the inventory
(resource). Upon recognizing the need for inventory, which sales to customers (revenue
cycle) depleted, the purchasing clerk (internal agent) selects a supplier (external agent) and

68
 places the order. This act does not constitute an economic event but is a commitment to
buy. It must show on-order information to prevent double order and expect for due dates
for out of orders.
The 1:M association between supplier and order product indicates that each order
goes to only one supplier and that supplier may have received zero or many orders during
the period.
2. Receive product, economic event that causes change in economic resource.
The 0,1 cardinality in the association between the Order Product and Receive
Product entities implies that at any point in time, an order may exist (occurrence of Order
Product) that has not yet been received (no occurrence of Receive Product).

3. Disburse cash, economic event that constitute the give half of an economic exchange.
The 1:M association with the Supplier entity implies that each disbursement is
made to only one supplier, but each supplier may receive zero or many disbursements
during the period. The 1:M association between Disburse Cash and Receive Product
implies that each product receipt is paid in full (no multiple partial payments), but many
receipts may be combined and paid with a single disbursement to reduce check writing.
Payroll Procedures

❖ The model consists of two economic events

➢ Get time- is the receive half of economic exchange. This involves (internal agent)
worker giving up his or her time which is represented by the employee service
resources. The supervisor (external agents) assumes control of resources. The get
time event captures the daily time-giving instances of employees through a
timekeeping mechanism such as electronic time clock.
The zero cardinality in the associations between the Get Time and the
Worker and Supervisor entities reflects the possibility that some employees may
not have contributed time during the period. This would include, for example, new
employees or employees on sick leave.

➢ Disburse Cash- event is the give half of the economic exchange. This involves
distributing cash to an employee (now the external agent) for services rendered.
The 0,1 cardinality on the Disburse Cash side of the association implies that
at a point in time (midweek), a Get Time instance will exist that has not yet been
paid. Each Get Time instance, however, is paid only once.

Merge Individual REA Diagram

We are now ready to consolidate them into a single enterprise-wide diagram. To simplify
the diagram, redundant event, agent and resource entities has been collapsed into a simple entity
where possible.

Step 2: Define Primary Keys, Foreign Keys and Attributes

What are the rules to define Primary keys?
➢ The analyst should select a primary key that logically defines the non-key attributes and
uniquely identifies each occurrence in the entity.
What are the rules to define attributes?

69
 ➢ Every attribute in an entity should appear directly or indirectly (a calculated value) in one
or more user views. Entity attributes are, therefore, originally derived and modeled from
user views.
What are the rules to define Foreign keys?
➢ The degree of association between tables (that is, 1:1, 1:M, or M:M), meaning designer
must clearly have defined first the degree of association in order to have a proper foreign
key.

After we define keys the next step is to normalize tables as discussed in chapter 9
normalizing table can prevent any anomalies in the model created and classified as Third Normal
Form (3NF).

Condition for normalizing tables

➢ All non-key attributes will be wholly and uniquely dependent on (defined by) the primary key.
➢ None of the non-key attributes will be dependent on (defined by) other non-key attributes.

Step 3: Construct Physical Database and Produce User Views

Through this system will process all information and transactions related in the operations
and it should be rich enough to support the information needs of all users of the system being
modeled such as financial statements or other accounting reports.

Value Chain Analysis

➢ This analysis distinguishes between primary activities and support activities: primary
activities create value; support activities assist in the achievement of the primary activities.
By applying value chain analysis, an organization can look beyond itself and maximize its
ability to create value

Advantage in using REA approach

➢ Helps managers focus on the key elements of economic events and identify the nonvalue-
added activities that can be eliminated from operations.
➢ Improves operational efficiency which will also result to increase to overall productivity.
➢ Storage of data gathered reduces the need for multiple data collection, storage, and
maintenance procedures.
➢ Storing financial and nonfinancial data about business events in detailed form permits a
wider range of management decisions by supporting multiple user views.
➢ The REA model provides managers with more relevant, timely, and accurate information.
This will translate into better customer service, higher-quality products, and flexible
production processes

Enterprise Resource Planning (ERP) is business process management software that allows an
organization to use a system of integrated applications to manage the business and automate many back-
office functions related to technology, services, and human resources. ERP systems are multiple module
software packages that evolved primarily from traditional manufacturing resource planning (MRP II)
systems. The Gartner Group coined the term ERP, which has become widely used in recent years. The

70