ACCOUNTING INFORMATION SYSTEM DESIGN

FOR A REVENUE CYCLE

Zheng Wang

PROJECT

Submitted in partial satisfaction of

the requirements for the degree of

MASTER OF SCIENCE

in

ACCOUNTANCY

at

CALIFORNIA STATE UNIVERSITY, SACRAMENTO

SPRING
2009
 ACCOUNTING INFORMATION SYSTEM DESIGN
FOR A REVENUE CYCLE

A Project

by

Zheng Wang

Approved by:

, Committee Chair
Yan Xiong, Ph.D. 1

II,- Oq
Date I A

ii
Student: Zheng Wang

I certify that this student has met the requirements for format contained in the University

format manual, and that this Project is suitable for shelving in the Library and credit is to

be awarded for the Project.

Monica Lam, Ph.D., Associate Dean for Graduate and External Programs Date

College of Business Administration

iii
 Abstract

of

ACCOUNTING INFORMATION SYSTEM DESIGN

FOR A REVENUE CYCLE

by

Zheng Wang

Accounting Information System (AIS) is an important system using modem information

technology resources together with traditional accounting controls and methods to provide

users the financial information necessary to manage their organizations.

In this project, Resource-Event-Agent diagram (REA) is used as a tool for conceptual data

modeling, and Data Flow Diagram (DFD) is used as a tool for process modeling. The

simple REA and DFD Diagrams are used to explain what they are and how to design them.

Based on the nine-step design and implementation process, a sample accounting

information system is demonstrated for the revenue cycle of the Wale's Wholesaler. In the

example, REA model and DFD model for the revenue cycle are established first. Then

these two models are converted to Microsoft Access relational database using primary keys

iv
and foreign keys. In addition, Microsoft Access forms are designed for recording,

maintenance, and report processes in the revenue cycle.

Committee Chair
Yan Xiong, Ph.D.

Date: -S IV. 0I'

v
 TABLE OF CONTENTS

Page

List of Tables ........................................................ viii

List of Figures ...................................................... ix

Chapter

1. INTRODUCTION ....................................................... 1

1.1 Purpose of This Project ...................................................... 1

2. AIS, REA AND DFD OVERVIEW ...................................................... 2

2.1 AIS Overview ...................................................... 2

2.2 REA Overview ...................................................... 4

2.3 DFD Overview ...................................................... 6

I
3. SYSTEM DESIGN AND IMPLEMENTATION ............................................... 8

3.1 Business Overview ...................................................... 8

3.2 Nine-step Process Design Overview ...................................................... 9

3.3 Applying Event-oriented Modeling Approach ............................................. 9

STEP 1: Identify significant events ...................................................... 10

STEP 2: Identify related resources ................................................... ... 10

STEP 3: Identify related agents ...................................................... II

STEP 4: Identify all relationships ....................................................... 11

STEP 5: Specify the optionality and cardinality of relationships ..................... 12

STEP 6: Identify the attributes of events, resources, and agents ...................... 13

STEP 7: Identify the information processes .............................................. 15

STEP 8: Design the structure of the data repository ..................................... 18

vi
 STEP 9: Microsoft Access Implementation ...................................... 21

4. SUMMARY ...................................... 28

References ........................................ 29

vii
 LIST OF TABLES

Page

1. Table 1 Inventory ...................................... 18

2. Table 2 Cash ...................................... 19

3. Table 3 Returned Merchandise ...................................... 19

4. Table 4 Sales Call/ Contact Customer ...................................... 19

5. Table 5 Sales Order ...................................... 19

6. Table 6 Distribution ...................................... 19

7. Table 7 Cash Receipts ...................................... 20

8. Table 8 Returns ...................................... 20

9. Table 9 Employee ................. 20

10. Table 10 Customer .20

11. Table 11 Sales Items .21

12. Table 12 Return-Items .21

viii
 LIST OF FIGURES

Page

1. Figure I A simple Accounting Information System .............................................. 2

2. Figure 2 A simple Data Flow Diagram .......................................................... 7

3. Figure 3 REA Diagram for Wale's Wholesaler Revenue Process ............................ 15

4. Figure 4 Context Diagram for Wale's Wholesaler Revenue Process ....................... 16

5. Figure 5 Event Recording Level 0 DFD for Wale's Wholesaler Revenue Process ....... 17

6. Figure 6 Tables ............................................................... 18

7. Figure 7 Customer Table Design View .......................................................... 22

8. Figure 8 Customer Table Datasheet View ..................................................... 23

9. Figure 9 Inventory Table ............................................................... 23

10. Figure 10 Relationship among Tables ......................................................... 24

11. Figure 11 Sales Order Form ............................................................... 25

12. Figure 12 Inventory Form ............................................................... 26

13. Figure 13 Employee Form ............................................................... 26

14. Figure 14 Customer Balance Query Design View ............................................ 27

15. Figure 15 Customer Balance Query ............................................................ 27

ix
 1

Chapter I

INTRODUCTION

1.1 Purpose of This Project

The purpose of this project is to design an Accounting Information System (AIS) for Wale's

Wholesaler's business revenue cycle. Wale's Wholesaler is a hypothetical food and beverage

wholesaler that purchases goods in large lots from producers, breaks bulk, repacks and distributes

in small lots to local grocery stores.

In this project, Resource-Event-Agents (REA) is used as a tool to design logical data model for

Wale's Wholesaler, and Data Flow Diagram (DFD) is used as a tool to design logical process

model. REA and DFD diagrams are then mapped to relational tables and forms in a Microsoft

Access Database Management System (DBMS).

This project is completed under the direction of Professor Xiong, Yan. I appreciate her guidance

and helpful comments she's provided.

 2

Chapter 2

AIS, REA AND DFD OVERVIEW

2.1 AIS Overview

An accounting information system (AIS) invented by esteemed professor Karen Osterheld is

the system of records a business keeps to maintain its accounting system. This includes the

purchase, sales, and other financial processes of the business. An AIS combines the study and

practice of accounting with the design, implementation, and monitoring of information systems.

Such systems use modem information technology resources together with traditional accounting

controls and methods to provide users the financial information necessary to manage their

organizations.

Figure I shows an example of the data inputs and information outputs from an accounting

information system.

Inputs Processes outputs

tdaatoiancialstatemefts

. Accoun-ingSstem invoices
amendments to data receipts
-- f_ 1 management infotation
_ _ __ L _ _ _~~~~~~~A~

Figure 1: A simple Accounting Information System

 3

AISs cover all business functions from backbone accounting transaction processing systems to

sophisticated financial management planning and processing systems.

Financial reporting system starts at the operational levels of the organization, where the transaction

processing systems capture important business events such as normal production, purchasing, and

selling activities. These transactions are classified and summarized for internal decision making

and for external financial reporting.

Cost accounting systems are used in manufacturing and service environments. These allow

organizations to track the costs associated with the production of goods and/or performance of

services. In addition, the AIS can provide advanced analyses for improved resource allocation and

performance tracking.

Management accounting systems are used to allow organizational planning, monitoring, and

control for a variety of activities. This allows managerial-level employees to have access to

advanced reporting and statistical analysis. The systems can be used to gather information, to

develop various scenarios, and to choose an optimal answer among alternative scenarios.

The development of an AIS includes five basic phases: planning, analysis, design,

implementation, and support. The time period associated with each of these phases can be as

short as a few weeks or as long as several years. The first phase is the planning of the project.

This entails determination of the scope and objectives of the project, the definition of project

responsibilities, control requirements, project phases, project budgets, and project deliverables.

The analysis phase is used to both determine and document the accounting and business processes
 4

used by the organization. Such processes are redesigned to take advantage of best practices or of

the operating characteristics of modem system solutions. The design phase takes the conceptual

results of the analysis phase and develops detailed, specific designs that can be implemented in

subsequent phases. It involves the detailed design of all inputs, processing, storage, and outputs of

the proposed accounting system. The implementation phase consists of two primary parts:

construction and delivery. The support phase has two objectives: 1) to update and maintain the

AIS and 2) to continue development by continuously improving the business through adjustments

to the AIS caused by business and environmental changes.

2.2 REA Overview

Resources, Events, Agents (REA) is a model of how an accounting system can be reengineered

for the computer age. The REA model was first conceptualized in a 1982 Accounting Review

paper as a framework for building accounting systems in a shared data environment that

anticipated the collaborative information systems settings of the present, both within enterprises

and between enterprises. It describes a business as a set of economic resources, economic events

and economic agents as well as relationships among them.

The model's core feature was an object pattern consisting of two mirror-image constellations

that represented semantically the input and output components of a business process. The

REA acronym derives from that pattern's structure, which consisted of economic Resources,

economic Events, and economic Agents.

 5

REA treats the accounting system as a virtual representation of the actual business. It creates

computer objects that directly represent real-world-business objects. There is a separate REA

model for each business process in the company. A business process roughly corresponds to a

functional department, such as sales, purchases, conversion or manufacturing, human resources,

and financing.

Use of the REA approach can yield: (Ir)more efficient operations by helping identify

non-value-added activities, by storing financial and nonfinancial data in the same central database,

and greater support for management decisions; (2) increased productivity through the elimination

of non-value-added activities; (3) competitive advantages.

The key elements of REA model are resources, events and agents. Economic resources are

defined by Ijiri [1975, pp 51-2] to be objects that (1) are scarce and have utility and (2) are under

the control of an enterprise. Cash and inventory are the example of economic resource. Economic

events are defined by Yu [1976, p 256] as 'a class of phenomena which reflect changes in scarce

means resulting from production, exchange, consumption, and distribution." Examples of

economic events are sale, purchase and cash receipts. Economic agents include persons and

agencies who participate in the economic events of the enterprise or who are responsible for

subordinates' participation, including internal agents and external agents. Employees, such as

salespersons, cashiers, are internal agents. The venders and customers are external agents.

There are many types of relationships in the REA framework: (1) stock-flow relationships, (2)

duality relationships, and (3) participation and control relationships. Relationships between
 6

economic events and economic resources are called stock-flow relationships because they either

increase or decrease the resource-there is inflow or outflow of the resource as a result of the

event. In an economic exchange context, every resource increasing (decreasing) economic event

will eventually have a corresponding resource decreasing (increasing) economic event. This

coupling between resource increasing and decreasing events is referred to in REA terms as a

duality relationship. Duality relationships link each increment in the resource set of the enterprise

with a corresponding decrement. (Ijiri, 1975, Ch.5). Increments and decrements must be members

of two different event entity sets: one characterized by transferring in (purchase or cash receipts)

and the other characterized by transferring out (sale or cash disbursement). Control relationships

are 3-way associations among (1) a resource increment/decrement (event), (2) an inside party, and

(3) an outside party. The responsibility relationships indicate that higher level units control and

are accountable for the activities of subordinates.

2.3 DFD Overview

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system. It is one of the most commonly used systems-modeling tools. DFDs show

the flow of data from external entities into the system and how the data moved from one process

to another. They are composed of four simple components: processes, flows, stores, and

terminators. The first component of the DFD is known as a process. It shows a part of the system

that transforms inputs into outputs. The process is represented graphically as a circle. Its name

will describe what the process does. A flow is represented graphically by an arrow into or out of a

process. It is used to describe the movement of chunks, or packets of information from one part of
 7

the system to another part. The store is used to model a collection of data packets at rest. The

notation for a store is two parallel lines. A terminator is graphically represented as a rectangle,

represent external entities with which the system communicates. Typically, a terminator is a

person or a group of people, such as customers. Figure 2 is a simple DFD.

Database Input System tput

Figure2: A Simple Data Flow Diagram

Usually, the overall DFD is organized in a series of levels so that each level provides successively

more detail about a portion of the level above it. The context diagram shows the overall context

of the system and its operating environment and shows the whole system as just one process. It is

a top level data flow diagram, and only contains one process node that generalizes the function of

the entire system in relationship to external entities. The level 0 diagram shows the main

processes of the system. Each of these processes can be broken into further processes. A process

model will have one, and only one, level-I diagram. A level 0 diagram must be balanced with its

parent context level diagram. Each process in the level 0 diagram is decomposed into an

even-lower-level (level 1) diagram containing its subprocesses, then continues on the subsequent

subprocesses, until a necessary and sufficient level of detail is reached.

 8

Chapter 3

SYSTEM DESIGN AND IMPLEMENTATION

3.1 Business Overview

Wale's Wholesaler (Wale) is a food and beverage wholesaler, located in the south Bay Area

California. It purchases goods in large lots from producers, breaks bulk, repacks and distributes in

small lots to local grocery stores. The revenue process of Wale's Wholesaler is very simple and

classic. Upon employment each salesperson is assigned to serve a separate group of customers. When

customer data are initially entered into Wale's information system, the customer is immediately

assigned to a salesperson. The new salesperson may works with a senior salesperson for a period. The

salespersons contact customers including potential customers by call or personal visits. These

contacting may get orders from customers. The sales order is transmitted to distributing team. The

distribute clerks distribute merchandise from warehouse to customers. One distribution may

contain one or several sales. One sales order may be distributed more than once if the items

ordered are not currently in stock. Then cashiers collect accounts receivables. Although the vast

majority of cash receipts come from customers (any particular cash receipt would be from only one

customer) for sales, some cash receipts come from other sources (e.g., bank loans). For this project,

we assume that all cash receipts are from customers. Every cash receipt is processed by exactly one of

Wale's several cashiers and is deposited into one of Wale's bank accounts. Some merchandise may

be returned for some reason. The return clerks process the return and issue allowance.

The key events relating to this revenue processes can be summarized as following:
 9

* Contacting existing and potential customers

* Executing sales orders

* Distributing merchandise to customers

* Collecting payments from customers

* Accepting returns and granting allowances to customers

3.2 Nine-Step Process Design Overview

STEP 1: identify significant events (what is occurring?).

STEP 2: identify related resources (what is being used/obtained?).

STEP 3: identify related agents (who is involved?).

STEP 4: identify relationships.

STEP 5: specify the optionality and cardinality of relationships.

STEP 6: identify the attributes of events, resources, and agents.

STEP 7: identify the information processes.

STEP 8: design the structure of the data repository.

STEP 9: implement the design.

As a result of applying the first eight steps, we will have a REA diagram, context diagram and a

level 0 DFD, and a set of tables. Then in step 9, we use Microsoft Access to implement a database

oriented revenue system.

3.3 Applying event-oriented modeling approach

 10

Let's now specify a detailed process of developing a REA model and related set of DFDs by

using the nine-step modeling approach.

Step 1: Identify significant events

What is occurring is the significant event in the business cycle. The significant events related to

revenue processes in Wale's Wholesaler include: (1) Contacting existing and potential customers,

(2) Taking sales orders from customers, (3) Distributing ordered merchandise to customers, (4)

Collecting account receivables from customers after merchandise are distributed to them and (5)

Processing returns from customers and allowances to customers. In a REA diagram, the events

entities should be arranged in the middle with the earliest event at the top and the last at the

bottom.

Step 2: Identify related resources

When we consider the resource, we are looking for what is being used or obtained? Resources

typically have an "asset" connotation, such as inventory, cash. It's possible that there are multiple

resources associated with a single event. In this project there are three related resources:

inventory merchandise, cash and returned merchandise. Inventory is not a classical resource in

"sales call" event, but the main purpose to contact costumers is to get inventory sold. Inventory

decreases as a result of "sales order" event. Cash receipt leads to cash increase. The returned

merchandise is a result of "return and allowance" event. In the REA diagram, resources are drawn
 11

to the left of events. A label is used to describe the relationship between the resource and the

event.

Step 3: Identify related agents

Agents are those who are involved in the business process. Agents could be within or outside the

organization, internal or external. Customers are the main external agents in the revenue process.

Customers are contacted by salesperson, sales orders are made to customers, and merchandises

are distributed to customers. The company receives returns and collects cash from customers.

Internal agents included in the project are salesperson, distribution clerk, cashiers and return clerk.

Salespersons contact the existing customers and the potential customers and take the sales orders.

Distribution clerks distribute the ordered merchandise. Cashiers collect accounts receivables.

Return clerks accept and process returns and allowance. There are also other employees in the

company, such as purchase representative, receiving clerks. But they are not involved in business

revenue process. However, all employee data would be stored in one employee table. In the REA

diagram, agents are drawn to the right of the events and a label descriptive of the relationship

between the agent and the event is used.

Step 4: Identify all relationship

The relationship between the events, resources, and agents identified in step1 to 3 must be

specifically identified. The "inventory" resource is related to the "salesperson" and "customers"

agents through the "contact customers" and "sales order" events. The "inventory" resource is also
 12

related to the "distribution clerks" and "customers" agents through the "distribution" event. The

"cash" resource is related to the "cashiers" and "customers" agents through the "cash receipts"

event. The "returned merchandise" resource is related to the "returns clerks" and "customers"

agents, through the "return and allowance" event. There is no direct relationship between

inventory and cash resources. Returned merchandise represents inventory that is sold early but is

returned later for all kinds of reasons. Not all inventory sold would be returned by customers.

There is no direct relationship between any two agents. There are interrelationships between

events. "Contact customer" event may result in a "sales order" event. The delivery of

merchandise ordered is a relationship between "sales order" event and "distribution" event. The

payment of distributed merchandise directly connects the "distribution" and "cash receipts"

events. There is also a direct relationship between "distribution" and "return and allowance"

events, for the merchandise delivered might be returned for any reason.

Step 5: Specify optionality and cardinality

A basic diagram will result from application of the first four steps. Now we can expand the basic

diagram into an REA diagram by adding the optionality and cardinality of relationships. A

salesperson might have no customer contacts or have many customer contacts. Each customer

contact must be performed by at least one salesperson (two or more salespersons may visit

customers together). Each contact may talk about many inventory items, or none (some contact

might for other reasons). Each contact may result in one or more sales order. It's also possible

there is no sales order at all. Every sales order comes from one or several contacts. The loyal

customers may call salesperson to place orders without contact. One customer may have either
 13

one or many sales orders or no orders. One salesperson can take more than one sales orders or no

order (new salesperson). A sales order must be placed by one customer and taken by one

salesperson. Every sales order may have at least one distribution. It is possible that the items

in-stock are not enough to fulfill one order. That will result in two or more distributions. Each

distribution may have at least one order. Sometimes, Wale combines two orders in one

distribution. Each distribution may have at least one inventory item. One type of inventory can be

on many distribution or no distribution (the item is never sold). Every distribution is exactly

distributed by one clerk, and one clerk can deliver many distributions, or none (new hired clerk).

A customer may be related to many cash receipts and every cash receipt is associated with one

customer. One cash receipt is related to at least one distribution, and one distribution has at least

one cash receipts. One cash receipt is collected by exactly one cashier, but one cashier can have

many cash receipts or none (new cashier). A customer may have one or more returns, but one

return is made by exactly one customer. Every return clerk may process many returns, or none

(new clerk). However, every return is taken by exactly one return clerk. A distribution may result

in many returns or no return. A customer may return many items from different distributions. So

one return may related to many distributions. One returned merchandise must relate to at least one

return.

Step 6: Identify the attributes of events, resources, and agents.

Each resource, event and agent has a number of attributes. Attributes related to the "inventory"

resource include item number, price for sale, quantity on hand, reorder point, item name and

description. The attributes for the "returned merchandise" have a little different, including item
 14

number, name, quantity returned, reason for return. For cash resource, it is necessary to record

account number, bank name and current balance.

Regarding the "contact customers" event, it is necessary to record the contact date, time, the

salesperson who made the contact, the customer to whom the contact was made, and the contact

result. The attributes of the "sales order" event include sales order number, date, items ordered

(name, price, quantity), salesperson who takes the order and customer who places the order. For

distribution events, the attributes include sales order number, the name and quantity distributed,

date, distribution clerk. The "cash receipts" event has following attributes: Check number,

customer, amount, date and cashier who make the receipt. Regarding the "returned merchandise"

event, it is necessary to record the customer who makes the return, date, returned item and

quantity, reason for return, returns clerk who accept the returns. It is also important to record the

distribution number that the returned item is related to.

All internal agents have the same attributes, including employee number, name, hired date,

birthday, address, telephone number, salary and the department. The customers' attributes include

customer number, name, contact information, account balance, and the credit limits.

Attributes can be more clear by using tables in Figure 4.

Based on the above six steps, the REA diagram can be constructed now. For ease of exposition,

the Attributes are omitted. Resources are shown in the left column, events are shown in the

middle, and agents are shown in the right column. The "O" indicates an optional relationship. The
 15

"I" indicates a mandatory participate relationship. The "N" indicates the "many" relationship.

Figure 3: REA Diagram for Wale's Wholesaler Revenue Process

Step 7: Identify information processes.

Each significant event will need a recording process. Contact customers, sales orders, distribution,

cash receipts and returns and allowance are the events in this project requiring recording

information processes. Inventory, cash and returned merchandise are resource entities requiring
 16

maintenance information processes. Customers and employees are the agent entities requiring

maintenance information processes. There are a lot of documents and reports that must be

generated through a reporting process, such as sales invoice, distribution documents, receipts of

cash collection and confirmation of returns and allowances.

The entire system can be view as one overall business revenue process. Inputs to process are

received from customers and employees. Outputs of system, information about order

acknowledge, receipts, credit-memos, go to customers. Based on this high level event, a context

diagram can be created as shown below.

I Customers
items wantee

order

ditibt
UG~istribution
| Clerk | details i
CollecIton

9~~~~~ w~~~~elails

|Returns clerk|

Figure 4: Context Diagram for Wale's Wholesaler Revenue Process

 17

The context diagram only shows input to and output from the overall system. A level 0 DFD can

show further details about process. In particular, recording process Level 0 DFD should be

constructed for the events on the REA diagram, maintenance process Level 0 DFD should be

constructed for all resources and agents on the REA diagram, and reporting process Level 0 DFD

should be constructed for all reports to be generated. These Level 0 DFDs show the specific steps

involved in the overall process and the data stores accessed and updated. Figure 5 is the recording

process Level 0 DFD for the Wale's Wholesaler revenue process.

I Satfsersons I
Cumtomei table
Iv Order Contact

Add
1111
Relums asnd
Returnetd allowances table
maIUhandise table

Figure 5: Event Recording Level 0 DFD Diagram for Wale's Wholesaler Revenue Processes
 18

Step 8: Design the structure of the data repository

Now, we will convert the above REA diagram to relational tables-designing the data repository.

Following is a quickly review of the conversion rules:

(I) A separate table is created for each entity,

(2) Attributes are created for each entity and the primary key in each entity is identified,

(3) All optional relationships are treated as mandatory many relationships,

(4) The primary key of the entity on the "one" side of a relationship is posted to the table of the

entity on the "many" side of a relationship

(5) A separate table is created for the relationship itself for entities participating in a many-to-many

relationship with the primary key of each table being posted to the new relationship table to form a

composite key. (Advanced System Analysis &Design, Chapter 5)

Mechanically applying the conversion rule, we get the following tables.

Figure 6: Tables

Table 1: Inventory

Attributes Item ID, Name, Description, Price, Quantity, Reorder points

Primary Key Item ID

Foreign Key

Table 2: Cash
 19

Attributes Account Number, Bank, Balance

Primary Key Account Number

Foreign Key

Table 3: Returned Merchandise

Attributes Item ID, Name, Description, Reason for return, Quantity

Primary Key Item ID

Foreign Key

Table 4: Sales Call/Contact customer

Attributes Contact ID, Date, Time, Employee ID, Customer ID, Result

Primary Key Contact ID

Foreign Key Employee ID, Customer ID

Table 5: Sales Order

Attributes Sales Order ID, Date, Item ID, Employee ID, Customer ID, Item Quantity

Primary Key Sales Order ID

Foreign Key Item ID, Employee ID, Customer ID

Table 6: Distribution

Attributes Distribution ID, Employee ID, Customer ID, Sales order ID, Date, Item ID,

Quantity
 20

Table 7: Cash Receipts

Attributes Check Number, Customer ID, Employee ID, Amount, Date

Primary Key Check Number

Foreign Key Customer ID, Employee ID

Table 8: Returns

Attributes Returns ID, Item ID, Quantity, Reason, Date, Distribution ID, Customer ID,

Employee ID

Primary Key Returns ID

Foreign Key Item ID, Distribution ID, Employee ID, Customer ID

Table 9: Employee

Attributes Employee ID, Name, Date Hired, Contact Information, Gender, Date of Birth,

Salary, Department

Primary Key Employee ID

Foreign Key

Table 10: Customer

Attributes Customer ID, Name, Discount Term, Credit Limit, Contact Information,
 21

Balance

Primary Key Customer ID

Foreign Key

Table 11: Sales-Items

Attributes Sales Order ID, Item ID, Quantity

Primary Key Sales Order ID, Item ID

Foreign Key

Table 12: Return-Items

Attributes Return ID, Item ID, Quantity returned, Reason for return

Primary Key Return ID, Item ID

Foreign Key

Step 9: Microsoft Access implementation

Now we can implement the above design by using Microsoft Access.

1. Create tables, designate the primary key

The first step in the implementation process is to create tables and designate the primary key. By

Double-click on "create table on design view", we get a table, then define each field. Following
 22

are screen shots from Microsoft Access. Figure 7 and 8 are the design view and datasheet view of

Customer table. Figure 9 is the datasheet view of Inventory.

v Customer ID jText
Name _ _ Text
Balance Currency __
Address Text
City__ ____ ___ Text_____ _
jState Text
_ipo_ _ Text
Telenhone 'Text
Contact Person _ Text_____
1-VXCredit Limit _ _Number____
Term__ __
_. ___ _ ____Text - .....

Field Size
format ____
Inp t Mask __
'~Caption_ ___ _____ __ _
Default Value ________ _
Validation Rule__ _ ___

Validation Text __

Required_ ___ No _______

Allowi Zero Length__ Yes _____ _

Indexed 'Yes (No Duplicates _

Unicode Compression ,Yes
IME Mode _ On ___ _
i~S-entence Mod e one
-___N _
it gs_
_ ____ .____ _ _. _ _ __

Figure 7: Customer Table Design View

 23

r_ , _Snack
4 shop $2, 900. 00 1308 E El Cat~ino Rt,S~ant~aCisara~,,A. 905
_E4O02 __ Carson ' s Earl $1,896.00 968 He~nderson Ave sinyvale _-CA___ 94086
_ 03
_ Cash and Carry $3,500.00 244 17th Street San Jose CA 95120
E 4004 Woods gas stat- $1, 288. 00 355 1 Frement Ave. Sunnyvale -CA 94087
_ (4005 _ ini Mart $879.00 201 Ponetory Ave. Santa Clara CA 95051
_ ,4006 'Disks Shop $2,944.00 10855 Western Ave ,San Jose CA 95123
> 4007 _Korea_ arket $2, 888.00 1970 Mission Blvd Santa Clara CA 95050
K.4008 Dasah market $5, 879. 00 50505 Stevens Creel Cupertino CA 95014

Figure 8: Customer Table Datasheet View

_Coca Cola Classical Soda 2 . 1.50 1000 lOo Coca Cola $1.20
C 70002 _ Arizona Arnold Iced Tea 42 - $_1.00 1000 100 Arizona-_ $0. 70-
LE70003 Aquafina Purified Water 24- $6.50 100 _ 10 Aquafina $6.00
' 70004 Heinz Easy Squech ketchuip I _ S259. 500 ,50 Heinz $2.19
S 70005 Cheetos Crunchy 13 Oz $3.59 1000 100 Cheetos $3.20
E 70006 _ Lays Classic 11 Oz $3.00 1000 100 50
U 70007 Bud Light Lime Beer 12-12 1 $13.49 500 50 Bud Light $12.00
I_70008 Kelloggers Nutrigrain Chen_ $4. 49 1000 100 Kelloggers $4.00
f 70009 Carnation Instant breakfast $5.59 1000 100 Carnation $4. 49
I70010 General Kills cheerios Cere $3.59 . 1000 1OO Cheerios $3.00

Figure 9: Inventory Table

2. Establish relationships between tables

After all the tables are created, we have to establish the relationship between these tables. Figure

8 shows the relationships of tables in our project. It maps to the REA diagram: the resource tables

in the left, the event tables in the middle and the agent tables in the right. The tables are

interrelated through a series of one-to-many relationships.

 24

Figure 10: Relationship among Tables

Based on the above table structure, we can consider the various information processes involved

(i.e., recording, maintenance, reporting processes) and how they are implemented in Microsoft

Access. Step 3 is related to the recording and maintaining information processes. Step4 is related

to the reporting process.

3. Create forms

In this project, there are five significant events: contact costumer, sales order, distribution, cash

receipt and returns and allowance. For each event, a recording process database form is required.
 25

The "Sales Order Form" shown below will be used to record information about the sales order

event. This form maps to process 2.0 (record sales order) in the Level 0 DFD .

Sals Order ID >

Date 01/28/200
CustomerID 4001 _ i
Salesperson ID G001
Sales-Item I

Figure 11: Sales Order Form

Figure 12 and 13 are single table database forms. These forms related to maintaining information

process. Maintaining processes will be needed for each resource and agent entity on the REA

diagram. Figure 11 and 12 only show one resource (inventory) and one agent (employee). Each

form can be used to add, delete or update information about inventory and employee.
 26

_I ~~~~~~~~~~~~~~~
Item ID I
Name C1ColaoClassicalSoda2L '.
Sates Price t $1.50

Quantity u 1000
Reorder point E 100
Vendor Coca Cola
Cost $1.20 $

Figure 12: Inventory Form

Employee ID 'lmi HiredDate '6 6

Name Alice Brooks
Address l077Colkmbia Street

City Jose
-an -

State ICA
Zip _9512 _

Phone nrnber i408-555-1232 -

Gender F
Salary $36,0r0000
Date of Birth 4/23A19T
Commission rate l _ _ _

Figure 13: Employee Form

4. Create queries and report for all information processes

 27

Accounting and other non-finance reports are generated through queries in Access. The reporting

process merely extracts data from one or more tables to provide the information that user required.

For example, we want to get a list of customers whose account balance is greater than $2000. A

query can be performed on the Customer table by specifying a criteria on the Account Balance

field. The following figure 14 and 15 show the Access query design view and the report for the

example.

Customer ID _
| Namem
m Account Balance
Address

i.Custr
C ' B E _D
N _e Accounlt 5a'Bsace
st~
g Cus ~en-__ Cuseha r _ Custca -----
Sort,4Ascendirn

__ ~~~=2000

Figure 14: Customer Balance Query Design View

|ustomer II I Name IAccount BaLanceIg

_ |= !Snack shop $2,900.00
_ 4003 "Cash and Carry Mart $_3,500.
00
4006
4 _ Disks Shop _ _ $2,944.00 I
4007 _Korea Market $2, 88600
.
__
14008_
Dasah market
_ _ _ _ _ _ _
$5,879.00 _
Figure 15: Customer Balance Query
 28

Chapter 4

SUMMARY

This project presented a database view of business revenue cycle. An overview of related

business processes was first presented. A logical data model was then developed using the REA

approach. Applying the conversion rules, the REA model was converted to relational tables. From

a process modeling perspective, both a context diagram and a Level 0 data flow diagram (DFD)

were constructed. An Access implementation of the design was then demonstrated. Tables and

the relationships between tables in Access were described. A variety of Access forms for

implementing recording, maintaining, and reporting processes were also shown. Finally, the

process of generating a non-accounting report was shown. Using Access queries, listing of

customers with an account balance greater than $2000 was generated.

 29

REFERENCES

Uday S. Murthy, Ph.D., ACA. Advanced System Analysis & Design.

McCarthy, W.E. 1982. The REA accounting model: A generalized framework for accounting

systems in a shared data environment. The Accounting Review (July): 554-77.

McCarthy, W.E. 2003. The REA Modeling Approach to Teaching Accounting Information

Systems. Issues in Accounting Education: Vol. 18, No.4 November 2003 pp.4 2 7 - 4 4 1

James A. Hall Accounting Information Systems, 4h Edition

IDG's S-D visual Series Master Microsoft Office 2000 Visually

http://en.wikipedia.org/wiki/Resources, Events, Agents

http://en.wikipedia.org/wiki/Dataflowdiagram

http://openleam.open.ac.uk/mod/resource/view.php?id= 161611

http://www.enotes.com/business-finance-encyclopedia/accounting-information-systems

http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter 9