AIS Editeed Mod.
AIS Editeed Mod.
Introduction
In this chapter, we will first define systems, an information and data, define an accounting
information system. It should be obvious that all information systems are systems but not all
systems are information systems.
In addition this chapter discusses why AIS is an important topic to study, describes the
differences and relationships between Accounting information systems and Management
Information systems, the evolution of information System model-business and its effects on
business process, the roles of accountant, accountant as the users, accountant as the system
designers and accountant as a system audit designers and finally Discuss about Entity
relationship diagram and data flow diagram
Learning Outcomes
After studying this chapter you are able to:
Explain an information environment
Explain what an accounting information system (AIS) and Management Information
System (MIS) is all about.
Discuss the evolution of information system model.
Explain the E-business, types of E-commerce and its effects on business process
Describe role of accountant, accountant as the users, accountant as the system designers
and accountant as a system audit designers
Discuss about Entity relationship diagram and
Explain data flow diagram
For many, the term system generates mental images of computers and programming. In fact, the
term has much broader applicability. Some systems are naturally occurring, while others are
artificial. Natural systems range from the atom- a system of electrons, protons, and neutrons- to
the universe- a system of galaxies, stars, and planets. All life forms, plants and animals are
examples of natural systems. Artificial systems are man-made. These systems include everything
from clocks to submarines and social systems to information systems.
Elements of a system
Regardless of their origin, all systems possess some common elements. The following definition
specifies:
A system is a group of two or more interrelated components or subsystems that serve a
common purpose.
The general definition of a system can be analyzed to gain an understanding of how it applies to
business and information systems.
Multiple components. A system must contain more than one part. For example, a
combination of six colleges and one school of graduate studies and the infrastructures under
each college & school as well as the administrative forms a system called Jimma University.
Further example, a combination of four departments and resources under each department
forms a system called College of Business & Economics (CBE). Therefore, CBE is a system
as well as a subsystem of the largest system called Jimma University.
Relatedness. A common purpose relates the multiple parts of the system. Although each part
functions independently of the other, all parts serve a common objective. For example, even
if all colleges & the school are independent of each other, they serve for one common
objective that is to produce well qualified, competent manpower in different professions. If a
particular component does not contribute to the common goal, then it is not part of the
system
Purpose. A system must serve at least one purpose, but it serves several. Whether a system
provides a measure of time, electrical power, or information serving a purpose is its
fundamental justification. When a system ceases to serve a purpose, it should be replaced.
Information system: is the set of formal procedures by which data are collected, processed into
information, and distributed to users. Information system can be decomposed into; accounting
information system (AIS) and management information system (MIS). More often, AIS and MIS
applications will be integrated to achieve operational efficiency. The distinction between AIS
and MIS subsystems centers on the concept of a transaction.
The information flows: every business day, vast quantities of information flow to decision
makers and other users to meet a variety of internal needs. In addition, information flows out of
the organization to external users, such as customers, suppliers, and stakeholders who have an
interest in the firm. The figure below presents an overview of these internal and external
information flows.
For most businesses, there are varieties of requirements for information. Senior managers need
information to help with their business planning. Middle management needs more detailed
information to help them monitor and control business activities. Employees with operational
roles need information to help them carry out their duties.
As a result, businesses tend to have several "information systems" operating at the same time.
The main kinds of information systems in business are described briefly below:
A good way to think about an ESS is to imagine the senior management team
in an aircraft cockpit - with the instrument panel showing them the status of all
the key business activities. ESS typically involves lots of data analysis and
Modeling tools such as "what-if" analysis to help strategic decision-making.
Management A management information system ("MIS") is mainly concerned with
Information internal sources of information. MIS usually take data from the transaction
Systems processing systems (see below) and summaries it into a series of management
reports.
Operations Management
Information Information
Systems Systems
Information is different from data. Information is data that have been organized and processed to
provide meaning to a user. Usually, more information and better information translates into
better decisions. There are limits to the amount of information the human mind can effectively
absorb and process. However, when you get more information than you can effectively
assimilate, if the limits are passed, you suffer from information overload. Example: Final exams
week! When you’ve reached the overload point, the quality of decisions declines while the costs
of producing the information increases.
Data Information
Value of information (VI) is the net benefit derived from information. Hence, VI is the benefit
produced by the information minus the cost of producing it.
VI = Benefit - Cost
Costs and benefits of information are often difficult to quantify, but you need to try when you are
making decisions about whether to provide information.
These characteristics of useful information are related to the three dimensions of information;
time, content and form as depicted below.
.
What is the benefit of producing information?
AIS is a set of interrelated subsystems which collect, record, and process data to information
AIS combine the study and practice of accounting with the design, implementation, and
AIS is a computer-based system designed to transform accounting data into information, can
also include transaction processing cycles, the use of information technology, and the
This is a general model because it describes all information systems, regardless of their
technological architecture. The elements of the general model are end users, data sources, data
collection, data processing, database management, information generation, and feedback. The
figure below presents the general model for viewing AIS applications.
Management often requires information that goes beyond the capability of AIS. As organizations
grow in size and complexity, specialized functional areas emerge requiring additional
information for production planning and control, sales forecasting, inventory warehouse
planning, market research, and so on. The management information system (MIS) processes
non-financial transactions that are not normally processed by traditional AIS.
Some management decisions require information that integrates financial and non-financial data.
For example, a purchasing manager, evaluating the performance of suppliers, wants to know the
number and financial value of inventory orders placed with specific vendors during a period of
time. In addition, the manager needs to know the number of deliveries that exceed the normal
lead time, and any inventory stock out conditions that resulted from late deliveries.
Such integrated information, if it could be provided at all, would traditionally come from
separate AIS and MIS applications functioning independently. The AIS application would supply
the cost of purchases data, while the delivery time and stock out data (if available) would come
from an MIS application. The two sets of data would then need to be integrated and reported to
the manager.
To improve operational efficiency and gain competitive advantage in the market place, many
organizations have reengineered their information systems to include both AIS and MIS features.
Given the changes that are occurring in accounting, is there a need to distinguish between AIS
and MIS? The answer to this question is “yes.” Publicly held organizations must provide
financial reports to interested external parties. The management, accountants, and auditors of
public firms have a legal responsibility for the design, operation, control, and audit of AIS
applications that impact the financial statements. Naturally, MIS applications are also important
to the enterprise, otherwise they should not have been implemented. However, the legal and
professional standards that characterize AIS clearly distinguish it from MIS. With the increasing
integration of financial and non-financial systems, organization’s management, systems
professionals, and accountants need a conceptual model that reflects this important distinction.
What is accounting information system?
Being an information system, an accounting information system must have a target system. It
should be obvious that the target system must be business operations in a narrow sense. Other
non-accounting aspects of business operations are covered by information systems such as
Human Resources Information System, Management Information System, Production
Planning/Scheduling System, Strategic Planning System, and so on. The target system for an
accounting system has to do with the aspects of business operations that have to do with
accountability for the assets/liabilities of the enterprise, the determination of the results of
1.4 E-BUSINESS
Types of E-commerce
There are a variety of different types of e-commerce and many different ways to characterize
these types. Five major types of e-commerce discussed in this unit. For most part, we distinguish
different types of e-commerce by the nature of the market relationship- who is selling to whom.
The exceptions are Peer-to-Peer (P2P) and Mobile commerce m-commerce, which are
technology-based distinctions.
Electronic commerce can directly or indirectly affect every step in the value chain. The most
obvious effect is on sales and marketing activities. Companies can create electronic catalogs on
their web sites to totally automate sales order entry. For example, Cisco Systems’ site helps
customers select the right components for their networking needs. Web sites designed to
automate sales and marketing can also improve the efficiency of the operations step of the value
chain. For example, Ford uses its internal data –voice-video communications network to
facilitate communications among 120 designers throughout the world.
Electronic commerce applications can also significantly improve the quality of post-sales-
customer support. For example, setting up a web page ensures that all customers receive
consistent information. Companies like AT & T and Nike use a sequence of menu-driven forms
As far as information system is concerned, the role of accountant is very significant in designing,
using and implementing accounting information system. Accountants must understand the
system development process, as they are involved in it in several ways: as users helping to
As accounting is an information providing activity, accountants can use it after having sufficient
understanding; how the system that provides that information is designed, implemented, and
used, how financial information is reported, and how information is used to make decisions.
1.5.2 ACCOUNTANTS AS THE SYSTEM DESIGNERS
System is a mechanism by which different components are working together in order to achieve
common purpose. To make systems effective it should be well designed. As a result, accountants
are the primarily professionals involved in system design.
1.5.3 ACCOUNTANT AS THE SYSTEM AUDITORS
In order to ensure the effectiveness of system accountant need to evaluate the accuracy and
reliability of information produced by the AIS. Accountants must understand the client’s AIS
adequately to be confident that it is providing complete and accurate information for planning
and compliance work. In private industry and not-for-profit, systems work is considered the most
important activity performed by accountants. In management consulting, the design, selection,
and implementation of accounting systems is a rapid growth area.
Documentation encompasses the narratives, flowcharts, diagrams, and other written material that
explain how the system works. This information covers the; who, what, when, where, why, and
how data entry, processing, storage, information output and system controls. One popular means
of documenting a system is to develop diagrams, flowcharts, tables, and other graphical
representations of information. These are then supplemented by a narrative description of the
system, which is a written step-by-step explanation of system components and interactions. The
two most common tools of system documentation; dataflow diagrams and flowcharts will be
discussed in this part. These tools save the organization both time and money. Depending on the
job function being performed, documentation tools are important on one or more of the
following levels:
Depicting how the system works: Studying and reviewing written descriptions of the inputs,
processing steps, and outputs of the system make the job easier.
Training users: Documentation also includes the user guides, procedure manuals, and other
operating instructions that help people learn how the AIS operate.
Controlling system development and maintenance costs: Good documentation helps system
designers develop object-oriented SW, that is, programs that contain modular, reusable code.
This object-orientation helps programmers avoid writing duplicate programs and facilities
changes when programs must be modified later.
Auditing AISs: Documentation helps auditors determine the strengths and weaknesses of a
system’s controls.
1. Data flow diagram - a graphical description of the source and destination of data that
shows data flow within an organization, the processes performed on the data and how
data are stored.
2. Document flow chart - a graphical description of the flow of documents and information
between departments or areas of responsibility within an organization.
3. System flowchart - a graphical description of the relationship among the input,
processing, and output in an information system.
4. Program flowchart - a graphical description of the sequence of logical operations that a
computer performs as it executes a program.
These tools are used extensively in the system development process. Systems development is a
complex process and these tools are used to create order from chaos and complexity. In addition,
the team members who develop information systems projects often change and these
A data flow diagram (DFD) graphically describes the flow of data within an organization. It is
used to document existing systems, and plan and design new ones. There is no ideal way to
develop a DFD, because different problems call for different methods. Some general guidelines
for developing DFDs are:
6. Group data flows - a data flow consists of one or more pieces of datum. Data elements
that always flow together should be grouped together and shown as one data flow until
they are separated. If the data elements do not always flow together, then they should be
shown as two separate data flows.
A DFD is composed of four basic elements: data sources and destinations, data flows,
transformation processes, and data stores. Each represents in a DFD by a unique symbol.
DataStores
Source/Destination
DataFlow
These four symbols are combined to show how data are processed. For example, in the diagram
below, the input to process C is data flow B, which comes from data source A. The outputs of
process C are data flows D and E. Data flow E is sent to data destination F.
Data Process
source Data flow (B) Data flow (D)
(C)
(A)
Data flow (E)
Data
destination
(F)
A data flow represents the flow of data between processes, data stores and data sources
and destinations. Data that passes between data stores and either a data source or a
A data store is a temporary or permanent repository of data. DFDs do not show the
physical storage medium such as disks, and paper, used to store data. As with other DFD
elements, data store names should be descriptive. Data stores are represented by
horizontal lines, with respective name recorded inside.
A data dictionary contains description of all the elements, stores, and flows in a system.
Data flows and data stores are typically collections of data elements. Typically, a master
copy of the data dictionary is maintained to ensure consistency and accuracy throughout
the development process.
Data flow diagrams are subdivided into successively lower levels in order to provide ever-
increasing amounts of detail because few systems can be diagrammed on one sheet of paper.
Users have differing needs, so a variety of levels can better satisfy these requirements. The
highest-level DFD is referred to as a context diagram. A context diagram provides the reader
with a summary level view of the system. It depicts a data processing system and the external
entities that are the sources and destinations of the system's inputs and outputs. For example, the
following can be considered as the context diagram of payroll processing procedures for a certain
company. It shows that the payroll processing system receives time card data from different
departments and employees' data from HR department. When these data are processed, the
system produces:
Flowcharts
system. It shall be assured that all uses of flowchart conventions are consistent.
20. Drawing the final copy of the flowchart, placing the name of the flowchart, the date, and
Flowchart Symbols
There are various types of symbols used to create flowcharts. Each symbol has a special meaning
that is easily conveyed by its shape. The shape indicates and describes the operation performed
and the input, processing, output, and storage media employed. The symbols are drawn by a
software program or with a flowcharting template. Flowcharting symbols can be divided into the
2. Processing symbols - either show what type of device is used to process data or indicate
3. Storage symbols - represent the device used to store data that the system is not currently
using.
4. Flow and miscellaneous symbols - indicate the flow of data and goods. They also
represent such operations as where flowcharts begin and end, where decisions are made,
Document
Online keying
Display
Input/output; journal/ledger
Magnetic disk
Magnetic tape
Off-page connector
Computer processing
Terminal
Decision
Auxiliary operation
Document Flowcharts
A document flowchart illustrates the flow of documents and information among areas of
responsibility within an organization. They trace a document from its cradle to its grave. They
show where a document originates, its distribution, the purpose for which it is used, its ultimate
disposition, and everything that happens as it flows through the system. A document flowchart is
particularly useful in analyzing the adequacy of control procedures in a system, such as internal
often referred to as internal control flowcharts. The document flowchart can reveal weaknesses
in document flows, or procedures responsible for causing wasteful delays. They also can be
prepared as part of the system design process and should be included in the documentation of an
information system.
Major flowchart symbols are available from EXCEL. To view the Drawing Toolbar of MS EXCEL,
select the following options from the main menu: In EXCEL, “Insert/Toolbar/Drawing” or you can
also click directly on the Drawing icon in the Standard Toolbar. After the Drawing Toolbar appears,
select “Auto shapes/Flowchart”. You can observe approximately 28 symbols.
System flowcharts depict the relationship among the input, processing, and output of AIS. A
system flowchart begins by identifying both the inputs that enter the system and their origins.
The input is followed by the processing portion of the flowchart. The input is followed by
processing portion of the flowchart that is the steps performed on the data. The logic the
computer uses to perform the processing task is shown on a program flowchart. The resulting
new information is the output component, which can be stored for later use, displayed on a
screen, or printed on paper. In many instances, the output from one process is an input to
another. System flowcharts are an important systems analysis, design, and evaluation tool. They
are universally employed in systems work and provide an immediate form of communication
among workers. The system flowchart is an excellent vehicle for describing information flows
and procedures within AIS.
Enter
Start
Input
Reject
No
Approved
Storage Yes
Process Back-
No
Inventory
Yes
Following is another example of a program flowchart for master file updating process.
- DFDs emphasize the flow of data and what is happening in a system, whereas a
flowchart emphasizes the flow of documents or records containing data.
- A DFD represents the logical flow of data, whereas a flowchart represents the
physical flow of data.
- Flowcharts are used primarily to document existing systems. DFDs, in contrast,
are primarily used in the design of new systems and do not concern themselves
with the physical devices used to process, store, and transform data.
What are the basic elements of a data flow diagram and Flow chart?
What are the basic symbols used in data flow diagrams Flow Chart?
3. Facts that are collected, recorded, stored and processed by an information system:
A) Information B) Data
C) Systems D) Mandatory information
4. Information is:
A) Basically the same as data.
B) Raw facts about transactions.
C) Potentially useful facts when processed in a timely manner.
D) Data that has been organized and processed so that it's meaningful.
5. The graphic description of the flow of data within an organization is called a
2.1. INTRODUCTION
This chapter describes how data about business activity is collected processed and transformed
into useful information for management; then, it will introduce the concept of internal controls.
In other words, this chapter provides an overview of how AIS can perform its three basic
functions:
To collect and store data about the organization’s business activities and transactions
efficiently and effectively
To provide information useful for decision making
To provide adequate controls to ensure that data are recorded and processed accurately
It will examine:
- Basic types of business activities in which an organization engages
- Key decisions that must be considered when managing those activities
- Information needed to make those decisions.
2.2 AN OVERVIEW OF BUSINESS PROCESS
Businesses engage in a variety of activities, including: Acquiring capital, Buying buildings and
equipment, Hiring and training employees, Purchasing inventory, Doing advertising and
marketing, Selling goods or services, Collecting payment from customers, Paying employees,
1. The revenue cycle includes the sales and cash receipt events
2. The expenditure cycle includes purchases and cash disbursement events
3. The human resources (payroll) cycle includes events of hiring and paying employees.
4. The production cycle includes the events of transforming raw materials and labor into
finished products
5. The financial cycle includes the events of obtaining funds from investors and creditors
and repaying them.
Note: A transaction is an agreement between two entities to exchange goods or services; or any
other event that can be measured in economic terms by an organization.
• EXAMPLES:
– Sell goods to customers
– Depreciate equipment
The transaction cycle is a process: Begins with capturing data about a transaction and
ends with an information output, such as financial statements.
These various transaction cycles relate to one another and interface with the general
ledger and reporting system, which is used to generate information for both management
and external parties.
In many accounting software packages, the various transaction cycles are implemented
as separate modules because a certain company need not apply all the modules.
The table below shows overview of business process, key decisions and information needs
An effective AIS needs to be able to integrate information of different types and from different
sources.
The trigger of data input is usually the performance of some business activity. Data must be
collected about three facets of each business activity:
1. Data Input
Historically, most businesses used paper source documents to initially collect data about their
business activities and then transferred that data into the computer. Today, however, most data
about business activities are recorded directly through computer data entry screens. Usually the
data entry screen retains the same name as the paper source document it replaced.
Well-designed source documents and data entry screens improve both internal control and
accuracy of capturing data about business activities. Control is improved either by purchasing
pre-numbered source documents or by having the system automatically assign a sequential
number to each new transaction. Accuracy is improved by providing instructions or prompts
about what data to collect, grouping logically related pieces of information close together, using
check-off boxes or pull down menus to present the available options, and using appropriate
shading and boarders to clearly separate data items.
If paper documents are still to be exchanged with customers or suppliers, data input efficiency
and accuracy can be further improved by using turnaround documents, which are records of
company data sent to an external party and then returned to the company system as input.
Turnaround documents are prepared in machine-readable form to facilitate their subsequent
processing as input records.
2. Data Processing
Once data about a business activity has been collected, the next step usually involves updating
previously stored information about the resources affected by that event and the agents who
participated in that activity.
Example, data about a sales transaction results in updating the information about
inventory to reduce the quantity on hand of items sold, as well as the customer’s account
balance. Either this updating can be done periodically or immediately as each transaction
occurs.
Periodic updating of the data stored about resources and agents is referred to as batch
processing.
Immediate updating as each transaction occurs is referred to as on line, real time
processing.
Batch processing is to be used for some applications that occur at fixed time intervals.
Most companies are shifting to OLRT processing because:
1. Online entry is more accurate than batch entry because the system can refuse incomplete
or erroneous entries, and
3. Data Storage
Generally, each type of entity possesses the same set of attributes. The specific data values for
those attributes, however, will differ among entities.
A second function of the AIS is to provide management with information useful for
decision-making.
Whether presented in the form of paper reports or displayed on a computer screen, the
information that AIS provides falls into two main categories:
a. Financial statements and
b. Managerial reports.
Two important methods of accomplishing these objectives are providing adequate documentation
of all business activities and ensuring effective segregation of duties.
Adequate Documentation
Adequate documentation of all business transactions is key to accountability.
Documentation allows management to verify that assigned responsibilities were
completed correctly.
Well-designed documents and records can help organizations quickly identify potential
problems.
Adequate documents and records can also ensure that the organization doesn’t make
commitments it cannot keep.
Adequately written descriptions of task procedures are also important.
Segregation of Duties
– Interfaces with the general ledger and reporting system, which generates
separate modules.
companies.
• However the cycles are implemented, it is critical that the AIS be able to:
Although, AIS can be utilized by using different system, fixed asset sys is one among other.
Here, as an alternative means companies can adopt fixed asset system to establish AIS.
Basically, the information must be organized to meet the needs of internal and external users.
The system must be designed to produce regular periodic reports and to support real-time
inquiries. The basic activities in the GLARS are:
1. Update the general ledger
2. Post adjusting entries
3. Prepare financial statements
4. Produce managerial reports
The first three represent the basic steps in the accounting cycle.
Updating the general ledger consists of posting journal entries from two sources:
Summary journal entries of routine transactions from the accounting subsystems.
Individual journal entries for non-routine transactions from the treasurer
2.5.2 POST ADJUSTING ENTRIES
Adjusting entries originate in the controller’s office at the end of each accounting period
(month, quarter, year, etc.) and after the initial trial balance has been prepared.
The trial balance lists the balances for all of the GL accounts.
If properly recorded, the total of all debit balances equal the total of all credit balances.
5. Error corrections
Error corrections involve correction of errors previously made in the general ledger.
What are the five types of adjusting entries?
- Cash flow budget: Shows anticipated cash inflows and outflows for use in determining
borrowing needs.
often these reports include proprietary information and are for internal use only. They do not
follow GAAP or IFRS. Some of the internal reports that are commonly used are!
Period report about profit and loss account and financial position, statement of cash flow,
changes in working capital, report about cost of production, production trends and utilization of
capacity. Management reports aim at informing managers of different aspects of the business,
in order to help them make better-informed decisions. They collect data from various
departments of the company tracking key performance indicators (KPIs) and present them in an
understandable way.
Learning Objectives
Understand what Data base mean
Explain The data dictionary and DBMS languages
discuss DBMS operations and Relational Data Bases
Explain Data Base Design and The REA Data Model
Explain Entity-relationship diagrams
discuss Developing an REA diagram
Explain Implementing an REA diagram in a relational data base
understand Database systems and the future of accounting
3.1 INRODUCTION
This chapter explains what a database is and how it differs from a file-oriented system. It also
describes the structure of a relational database system. The chapter concludes by discussing the
basic steps involved in designing a database and explaining the double entry accounting system
in a relational database.
To have a clear picture of the power of databases, it is crucial to understand the basic principles
of how data are stored in computer systems. Information about the attributes of an entity, such as
suppliers name and address, are stored in the fields. All the fields containing data about one
entity (e.g. one supplier) form a record. A set of related records, such as all supplier records,
forms a file (e.g. the supplier file). A set of interrelated, centrally coordinated file forms a
database.
What is data base?
A key component of a DBMS is the data dictionary. The data dictionary contains information
about the structure of the database. For each data element stored in the database, such as the
customer number, there is a corresponding record in the data dictionary describing it. The data
dictionary is often one of the first applications of a newly implemented database system.
What are some inputs to the data dictionary?
– Records of any new or deleted data elements
– Changes in names, descriptions, or uses of existing data elements
What are some outputs of the data dictionary?
– Reports useful to programmers, database designers, and users of the information
system
What are some sample reports?
Every DBMS must provide a means of performing the three basic functions of:
1. Creating a database
2. Changing a database
3. Querying a database
1. Creating a database:
A relational database is a database that conforms to the relational model, and refers to a
database's data and schema (the database's structure of how that data is arranged). Common
usage of the term "Relational Database Management System" technically refers to the software
used to create a relational database, but sometimes mistakenly refers to a relational database.
A Relational Database Management System (RDBMS) is a system that manages data using the
relational model. Frequently, the term "RDBMS" is inaccurately used as a generic label for the
relational database concept. Ironically, most RDBMS software packages are not technically
considered "relational" because they do not fully conform to the relational model.
What is a relational database?
1. Planning Sage- involves the initial planning to determine the need for and feasibility of
developing the new system. This includes preliminary judgments about the proposals
technological and economic feasibility.
In the planning stage, accountants both provide some of the information used to
evaluate the feasibility of the proposed project and participate in making that decision.
In the requirements analysis and design stages, accountants participate in identifying
user information needs, developing the logical schemas, designing the data dictionary,
and specifying controls.
During the implementation stage, accountants can also help test the accuracy of the
new database and the application programs that will use that data.
Operation and
Planning
maintenance
Requirements
Data Implementation
modeling analysis
occurs
here
Design Coding
©2003 Prentice Hall Business Publishing, 5-13
Accounting Information Systems, 9/e, Romney/Steinbart
Data modeling is the process of defining a database so that it faithfully represents all aspects
of the organization, including its transactions with the external environment.
Specifically used for AIS database design, the REA data model is conceptual modeling tool that
focuses on the business semantics underlying an organization's value chain activities. The REA
data model provides guidance for database design by identifying what entities should be included
in the AIS database and by prescribing how to structure relationships among the entities in that
database.
Types of Entities
Recently, some researchers proposed a fourth type of entity-locations such as stores, warehouses,
etc. However, they may be considered as resources, or attributes of the event entity.
Resources- are those things that have economic value to the organization. These include cash,
inventories, equipment and machinery, supplies, warehouses, factories, and land.
Events- are the various business activities about which management wants to collect information
for planning or control purposes. The REA data model helps people design databases that
support the management of an organization's value chain activities. Therefore, most of the events
in an REA data model fall into one of the two categories: economic exchanges or commitments.
- Economic exchanges- are the value chain activities that directly affect the quantity
of resources. For example, the sales event decreases the quantity of inventory and
the cash receipts event increases the amount of cash.
- Commitments- represent promises to engage in future economic exchanges. For
example, customer orders are commitments that lead to future sales. Often such
commitments are necessary precursors to the subsequent economic exchanges.
Moreover, management needs to track commitments for planning purposes. For
example, manufacturing firms often use information from customer orders to plan
production.
Agents- are the people and organizations that participate in the events and about whom
information is desired for planning, control, and evaluation purposes. Examples include
employees, customers, vendors etc.
Resource A GET
Inflow Participant Internal Agent
Resource A
Economic
Duality
GIVE
Resource B Outflow Participant Internal Agent
Resource B
The basic REA template consists of a pair of events, one that increases some resource and one
that decreases some resource. The events are drawn as rectangles and the economic duality
relationship between them as a diamond. In drawing REA model, the paper is divided into three
columns-one for each type of entity:
The left column is used for resources, The center column for events, and The right
column for agents.
Readability is further enhanced if the events entities are drawn from top to bottom corresponding
to the sequence in which they occur.
Once the events of interest have been specified, the resources that are affected by those events
need to be identified. For example, the sales event is translated to giving inventory to customers
and the cash receipts event is translated to receiving cash from customers. Hence, the inventory
and cash entities are added in the resource column and the stock flow relationship is drawn
between those entities and the events that affected them. What about A/R? Accounts receivable
is not modeled as a separate entity because it is not an independent object but simply represents a
timing difference between two events: sales and cash receipts. That is, accounts receivable
simply represents sales for which customer payments have not yet been received. Consequently,
if data about both sales and cash collections are already stored in the database, all the
After specifying the resources affected by each event, it is necessary to identify the agents who
participate in those events. There will always be at least one internal agent (an employee) and in
most cases an external agent (the customer or vendor) who participate in each event. For
example, customers and salespersons participate in the sale event and customers and cashiers
participate in the cash collection event. Hence, in the REA diagram, these three agent entities
shall be added: salespersons, customers, and cashiers. Relationships shall be included to indicate
which agent participated in which events. It is important to understand that the agents in the REA
data model represent functions, not specific people. For example, the salesperson and the cashier
are shown as separate entities but the same person may take both roles. The REA data model
requires that each event be linked to at least one resource and at least two agents. This
information needs to be supplemented by interviews with management to identify other possible
relationships of interest. For example, if the organization assigns customers to specific
salespeople to provide customized service, then a direct relationship between the two agent
entities (salesperson and customer) would be added to the diagram.
Participant
Economic
Customer
Duality
Participant
Cash
Cash Stock-flow Participant Cashier
Receipts
This step is analyzing each economic exchange event to determine whether it can be decomposed
into a combination of one or more commitment and exchange events. It is important for
management to get up to date information about various orders to reorder various inventory
items. It is also important to know which orders have been shipped and when. Then, the single
economic exchange event labeled sales may be replaced with a combination of a commitment
event which is labeled customer orders and the economic exchange event that was labeled sales.
The cash receipts economic exchange event will not be decomposed because whether payment is
received immediately or later by mail, what shall be tracked is actual receipts from customers.
Billing as an event is not modeled because it is neither an economic exchange nor a commitment.
Printing an invoice and mailing it to the customer doesn't increase or decrease the amount of any
resource. It is simply an information processing event that merely retrieves information from the
database about previous customer orders and sales events. Organizations build databases to
collect, process, and store information about their value chain activities. Printing documents and
reports or querying the database are just different ways of retrieving information about those
activities for use in making decisions. Such information processing activities do not change the
contents of the database and are not modeled as events in an REA diagram.
This is a step to add information about the nature of relationships between the various entities.
Cardinalities indicate how many instances of one entity can be linked to one specific instance
another entity. For example, cardinalities indicate how many sales transactions can be linked to
each individual customer and, conversely, how many customers can be linked to each individual
sales transaction. In a relational database, each entity is a table and each instance is a row in that
table. Therefore, in relational databases, cardinalities indicate how many rows in one table can
be linked to each row in another table. Cardinalities are represented as pairs of numbers next to
each entity. The first number is the minimum cardinality. It indicates whether a row in this table
Documentation of
Business Practices
Cash Sales-
(1, N) Cash Receipts (0, N)
Sales
Receipts
©2003 Prentice Hall Business Publishing, 5-56
Accounting Information Systems, 9/e, Romney/Steinbart
Documentation of
Business Practices
Cash Sales-
(1, N) Cash Receipts (0, N) Sales
Receipts
©2003 Prentice Hall Business Publishing, 5-57
Accounting Information Systems, 9/e, Romney/Steinbart
Customer
Inventory- (1,N) (1,1) Participant (0,N) Customer
Orders
Orders
(0,N)
(1,1)
(0,1) Participant
(0,N)
Inventory- Leads to
Inventory (0,N) Salesperson
Sales (0,N)
(0,1)
(1,N)
Participant
(1,1)
Sales
Customer
(1,1) Participant (0,N)
Three basic types of relationships between entities are possible depending on the maximum
cardinality associated with each entity.
1. A one to one (1:1) relationship exists when the maximum cardinality for each entity in
that relationship is one.
2. A one to many (1:N) relationship exists when the maximum cardinality of one entity in
that relationship is 1 and the maximum cardinality of the other entity in that relationship
is N
3. Many to many (M:N) relationship exists when a maximum cardinality for both entities
in the relationship is N.
Do not confuse the notation used for minimum and maximum cardinalities (a pair of numbers
separated by a comma) with the notation used to describe the cardinality of a relationship
between two entities (a pair of numbers separated by a colon).
The database designer doesn't arbitrarily choose cardinalities. Instead, cardinalities reflect facts
about the organization being modeled and its business practices. This information is obtained
Almost always, the minimum and maximum cardinalities associated with the event entity in
every agent-event relationship will be both 1.
- The minimum cardinality associated with the event is 1 because there must be some
agent who participates in that event.
- The maximum cardinality is 1 because the organization wants to be able to hold
some specific agent responsible for that event.
There is also a general principle concerning cardinalities associated with the agent entity in the
agent-event relationship. The cardinalities associated with each agent entity in the agent-event
relationship all have zero minimums and N maximums. The maximum cardinality associated
with internal agent entities is almost always N, because organizations expect their employees
will participate in numerous events. It is also usually N for external agents, because
organizations often engage in repeat transactions with the same suppliers and customers. There
are two reasons why the minimum cardinality associated with agent entities in the agent-event
relationship is usually zero:
Organizations want to be able to add information about potential customers and suppliers
even though those agents may not have participated yet in the business transactions
Event entities are analogous to transaction files, whereas agent entities are analogous to
master files. At the end of the fiscal year, the contents of events tables are archived and
the new fiscal year begins with no rows in various event tables. In contrast, information
about agents is permanent in nature and is carried over from one fiscal period to the next.
Therefore, at the beginning of a new fiscal year customers may not be linked to any
current sales.
Cardinality Rules for Resource-Event Relationships
The only exception to this general rule arises if an event potentially can be linked to more than
one resource entity. For example, consider a household appliance repair business. Some services
may not require parts whereas others may include labor plus parts. Thus, the sale event for such
repair business could be linked with inventory entity, or to repair service entity or both types of
resources. Consequently, the minimum cardinality for the sales event would be zero in both of
those relationships. In rare situations, an event might be linked to one of several unique agent
entities. In such cases, the minimum cardinality associated with the event entity again will be 0
instead of the normal 1.However, there is no general principle concerning the maximum
cardinality associated with event entities in resource event relationship. Instead, the maximum
cardinality depends on the nature of the resources affected by that event and by the organizations
policies. For example, customers may by and are encouraged to buy as many as products of a
company. Hence, customer order and sales events can be linked to many rows in inventory table.
Almost any kind of cardinality pair is possible for each event entity in event-event relationships.
The organization's business practices and policies must be understood to decide which possibility
is correct. For example, collections from customers may be at once (1:1) or in installments (1:
Once the REA diagram has been developed, it can be used to design a well structured relational
database. Implementing an REA diagram in a relational database is a three-step process:
1. Create a table for each distinct entity and for each many to many relationships
2. Assign attributes to appropriate tables
3. Use foreign keys to implement one to one and one to many relationships.
A properly designed relational database has a table for each distinct entity and for each many to
many relationships in an REA diagram. Some of the distinct entities include: cash, inventory,
customer orders, sales, cash receipts, employees, and customers. The expected many to many
relationships include customer order-inventory, sales inventory, and sales-cash receipts. It is
good practice to give each table the same name as the entity that it represents. Tables
representing M:N relationships, however, are often titled by hyphenating the names of the two
entities that are linked. For example, Sales-Inventory line table.
During the data modeling process, users and management will have identified facts that they
want to collect. For example, for inventory items the attributes may include item number,
description, cost and selling price.
Assign primary keys- every table in a relational database must have a primary key, consisting
of attributes or a combination of attributes. Companies often create numeric identifiers for
Assign other attributes to appropriate tables- additional attributes besides the primary key are
included in each table to satisfy transaction processing requirements and management's
information needs. Some of the attributes such as the date and amount of each sale are necessary
for complete and accurate transaction processing and the production of financial statements and
managerial reports. Other attributes are stored because they facilitate the effective management
of an organization's resources, events and agents.
Non-key attributes in M:N relationship tables- attributes that help keep the table flat and that
can't be stored in separate tables are listed as attributes in M:N relationship tables. For example,
quantity sold can't be an attribute in the sales table because a single invoice may have several
values. In addition, a single item may be sold in many different sales transactions. Hence, it may
not be an attribute in inventory table. Hence, as it applies to a specific item included in a specific
sales transaction, it belongs in the M:N relationship table that links these two entities.
Price data- may be stored in both the inventory and sales-inventory tables. The inventory
table lists suggested selling price that remains constant. But the sales inventory table
stores actual sales price which varies during the year in relation to promotions.
Cumulative data- includes such information as quantity on hand (in inventory table) and
account balance (in the customer table). Theoretically, it is unnecessary to store such
information separately in the database because the system can readily compute them
when necessary. Explicitly storing cumulative totals and balances, however, may
improve response time to queries.
One to one Relationships- in a relational database, one to one relationships between entities can
be implemented by including the primary key of one entity as a foreign key in the table
representing the other entity. The choice is arbitrary. Careful analysis of the minimum
cardinalities of the relationship may suggest which approach is likely to be more efficient. For
example, in the 1:1 relationship between sales and customer payments,
- the minimum cardinality for the sales event is 0 indicating the existence of credit
sales
- the minimum cardinality for the cash receipt event is 1 indicating that customer
payments only occur after a sale has been made (assuming no advance collections are
made)
In this case including invoice number as foreign key in cash receipts event may be more efficient
because then only that one table would have to be accessed and updated to process data about
each customer payment. When events are sequential, including the primary key of the event that
occurs first as a foreign key in the event that occurs second may improve internal control.
One to many relationships- As with 1:1 relationships, 1:N relationships also can be implemented
in relational databases with foreign keys. To do this, place the primary key of the entity with the
maximum cardinality of N as a foreign key in the entity that has maximum cardinality of 1. For
example, the primary keys of the salesperson and customer tables are included as foreign keys in
the sales table.
A potential exception to this general rule for implementing 1: N relationships may occur if the
relationship includes two sequential event entities, and the event that occurs first is also the one
REA diagrams are especially useful for documenting advanced AIS built using databases,
because the cardinalities in REA diagrams provide information about the organization's business
practices and the nature of its economic exchanges. Correctly interpreting what the cardinalities
in an REA diagram mean requires understanding exactly what the occurrence of each entity
represents. This is usually easy for both agent and event entities. Understanding what each
occurrence of resource entity represents may be difficult. Consider inventory, for example. An
individual occurrence of this entity might represent either a specific physical object or a class of
objects depending on the nature of the inventory. In such cases, examining the attributes
associated with that entity may indicate what it represents. For example, if there is a column
entitled ''quantity on hand'', each row refers to a specific kind of inventory, not an individual
object. In the case of sales-inventory relationship, such column will not exist because items may
be identified by serial number and there could only be one of each item.
Every organization will have its own unique REA diagram at least because business practices
and relationship cardinalities differ across companies. Differences in business practices also
result in differences in entities being modeled. The cardinalities in REA diagram also provide
information about business controls. For instance, each row in the cash entity represents a
specific account. One may be checking account, another payroll account, another money market
investment account etc. Cash-cash receipts relationship being modeled as 1:N reflects a sound
control practice of depositing all cash collections from customers into the company's checking
account.
An entity is anything about which the organization wishes to store data. At your college or
university, one entity would be the student. Consider the following table.
Information about the attributes of an entity (e.g., the student’s ID number and birth date) are
stored in fields. Consider the following table.
fields STUDENTS
Student ID Last Name First Name Phone Number Birth Date
333-33- Simpson Alice 333-3333 10/11/84
3333
111-11- Sanders Ned 444-4444 11/24/86
1111
123-45- Moore Artie 555-5555 04/20/85
6789
A set of all related records forms a file (e.g., the student file). If this university only had three
students and five fields for each student, then the entire file would be depicted below.
A completed REA diagram also serves as a useful guide for querying an AIS database. Elements
such as journals, ledgers and information about receivables as well as payables may seem
missing in a database. Nevertheless, they are present though stored in a different format.
Queries can be used to generate journals and ledgers from a relational database built on
the REA model. The information normally found in a journal is stored in the tables used
to record data about events. For example, a sales journal can be produced by writing a
query that displays the appropriate entries in the sales table for a given period. A query
can be written to display every entry in a sales table, to produce a list of all sales events,
both cash and credit sales. Traditionally, sales journals are used to record all credit sales.
Therefore, the query to produce a credit sales journal would have to include both the
sales and cash receipts tables. The logic on the query would include restricting the output
to display only those sales that are not linked to a corresponding customer payment event
that occurred on the same day as a sale. The information traditionally contained in
ledgers is often stored in a relational database in a combination of resources and events
tables. For example, accounts receivable doesn't appear as a table. Instead, it is derived
An REA diagram can guide the writing of queries to produce other information that
would be included in financial statements. Querying a single table can derive many
financial statement items. For example, summing the amount column of the sales table
would yield sales for the current period.
Preparing managerial reports-
A major advantage of the REA data model is that it integrates nonfinancial and financial
data in the AIS and makes both types of data easily accessible to management. For
example, information such as time of sale, returns and allowances etc can be included as
attributes in the sales table. New attributes such as credit rating could be added easily.
The REA data model can be used to build a database that allows the AIS to change in response to
management's changing information requirements. The REA data model shows that accounting
need not be limited to the traditional double entry model with its journals, ledgers, and chart of
accounts. Instead, the REA data model supports the view that accounting a process or system of
collecting and disseminating information about an organization's business transactions. Although
the mechanics of accounting may change, the need for the results (managerial reports and
financial statements) of accounting remains.
The relational data model represents everything in the database as being stored in the form of
tables. A relation is defined as a set of tuples that all have the same attributes. This is usually
represented by a table, which is data organized in rows and columns. In a relational database, all
of the data stored in a column should be in the same domain (i.e. data type). In the relational
model, the tuples should not have any ordering. This means both that there should be no order to
the tuples, and that the tuples should not impose an order of the attributes. Put differently, neither
the rows nor the columns should have an order to them.
An entity relationship (E-R) diagram is a graphical technique for portraying a database schema.
It is called an ER diagram because it shows the various entities being modeled and the
important relationships among them. In an ER diagram, entities appear as rectangles and
relationships between entities are represented as diamonds. An ER diagram not only depicts the
contents of a database but also graphically models an organization. Thus, the ER diagrams can
be used not only to design databases but also to document and understand existing databases and
to reengineer business processes. An important step in database design is deciding which entities
need to be modeled. The REA data model is useful for making that decision.
Multiple Choice Items: CHOOSE THE BEST ANSWER FROM THE GIVEN
ALTERNATIVES
1. In a relational database, each table is a collection of records and each record is a collection of
A. Fields C. Rows
B. Names D. Formula
2. In an Entity-Relationship diagram Rectangles represents
A. Entity types C. Attribute types
B. Database D. Table
3. serves as the interface between the database and the various application programs.
A. Database system C. Data modeling
B. Database design D. Database Management System
Learning objectives
– Understand Methodologies for systems development
– Explain The systems development life cycle (SDLC)
– Discuss Planning systems development
– Understands Feasibility study
– Discuss the Behavioral aspects of change
– Explain the overall System analysis
– Understands Conceptual system design
– Discuss Systems implementations and conversion
4.1 INTRODUCTION
Because we live in highly competitive and ever changing world organization continually face the
need for new, faster and more reliable ways of obtaining information. To meet this need, an
information system must continually undergo changes, ranging from minor adjustments to major
overhauls. Occasionally, the needed changes are so drastic that the old system is scrapped and
replaced by an entirely new one. Change is so constant and frequent that at any given time most
organizations are involved in some system improvement and change. Companies usually change
their systems for one of the following reasons:
Technological changes: As technology advances and becomes less costly, an organization can
use of the new capabilities or existing ones that were previously too expensive.
Competitive advantage: Increased quality, quantity and speed of information can result in an
improved product or service and may help to lower costs.
Productivity gains: computers automate clerical and repetitive tasks and significantly decrease
the performance time of other tasks.
For a systems development, companies can use different methods. These methods are explained
in the next sections of the module.
Whether systems changes are major or minor, most companies go through a systems
development life cycle. The systems development life cycle (SDLC) is a conceptual model used
in project management that describes the stages involved in an information system development
project, from an initial feasibility study through maintenance of the completed application. It is a
logical process by which systems analysts, software engineers, programmers and end-users build
information systems and computer applications to solve business problems and needs. Systems
development methodology can be used as a synonym for the life cycle. Systems development
methodology is a very formal and precise system development process that defines a set of
activities, methods, best practices, deliverables, and automated tools that system developers and
project managers are to use to develop and maintain information systems and software.
1. The existing system is evaluated - deficiencies are identified. This can be done by
interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined - in particular, the deficiencies in the existing
system must be addressed with specific proposals for improvement.
3. The proposed system is designed - plans are laid out concerning the physical
construction, hardware, operating systems, and programming, communications, and
security issues.
4. The new system is developed - the new components and programs must be obtained and
installed. Users of the system must be trained in its use, and all aspects of performance
must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use - this can be done in various ways. The new system can
phased in, according to application or location, and the old system gradually replaced. In
some cases, it may be more cost-effective to shut down the old system and implement the
new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated.
Maintenance must be kept up rigorously at all times. Users of the system should be kept
up-to-date concerning the latest modifications and procedures.
Systems analysis is the first step in SDLC where in-depth understanding about a system starts. At
this stage, the information needed to purchase or develop a new system is gathered. Since
analysis is too costly (in terms of time, effort, money, etc), it is mostly started after the project is
approved and green light is obtained from the management. When a new or improved system is
needed, a written request for systems development is prepared. The request describes the current
system’s problems, why the change is needed, and the proposed system’s goals and objectives. It
also describes the anticipated benefits and costs.
System analysis is the stage of:
Initial investigation - is conducted to screen projects. At this stage, the following are
essential:
Gaining a clear picture of the problem or need
Determining the project's viability and expected costs and payoffs
Evaluating the project's scope and the nature of the new AIS, and
Recommending whether the development project should be initiated as
proposed, modified or abandoned.
At this stage the exact nature of the problems under review must be determined. If a project is
approved, a proposal to conduct system analysis is prepared. It is assigned a priority and added to
the master plan, and the development team begins the survey of the existing AIS.
Systems survey - at this stage, an extensive study of the current AIS is undertaken. It may
take weeks or months depending on the complexity and the scope of the system. The
objectives of a system survey include:
– Gain a thorough understanding of the company operations, policies, and procedures; data and
information flows; AIS strengths and weaknesses; and available hardware, software, and
personnel.
– Make preliminary assessment of current and future processing needs, and determine the
extent and nature of the changes needed.
– Develop working relationships with users and build support for the AIS
– Collect data that identify user needs, conduct a feasibility analysis and make
recommendations to management.
Feasibility study - a more thorough feasibility analysis is conducted to determine the project's
viability. Especially important is economic feasibility. The feasibility analysis is updated as the
project proceeds and costs and benefits become clearer.
Information needs and systems requirements - once a project is deemed to be feasible, the
company identifies the information needs of the AIS users and documents system requirements.
the strategies for determining requirements include the following:
Ask users what they need; Analyze existing system; Examine existing system
use; & Create a prototype
Systems analysis report - is the conclusion of the system analysis phase. It is used to summarize
and document the analysis activities and serve as a repository of data from which system
designers can draw. A go-no-go decision is generally made three times during system analysis:
1. Impertinence—question everything
2. Impartiality—finds the best organizational solution and don’t try to justify the
importance of your suggestions at any cost.
3. Relaxation of constraints--assume that anything is possible
4. Attention to detail—due consideration should be given to facts (information)
System Design: System design is the evaluation of alternative solutions and the specification
and construction of a detailed computer based solution. It is also called physical design as it
deals with implementation issues. Systems analysis depends more on the logical aspect,
implementation-independent aspects of a system /the requirements. Systems design
concentrates on the physical or implementation-dependent aspects of a system (the systems
technical specifications).
Conceptual Design
Identify and evaluate
design alternatives
Develop design specifications Physical
Design
Deliver conceptual design
requirements
The system analysis phase is related to the conceptual design phase based on the diagram shown below:
Systems
analysis
Prepare
Evaluate Prepare
conceptual
design design
systems
alternatives specifications
design report
©2003 Prentice Hall Business Publishing, 18-10
Accounting Information Systems, 9/e, Romney/Steinbart
Physical design
The above activities will come as a series of steps as shown by the diagram below:
Output Program
design design
Input Controls
design design
©2003 Prentice Hall Business Publishing,
18-16
Accounting Inform ation System s, 9/e, Rom ney/Steinbart
The objective of output design is to determine the characteristics of reports, documents, and
screen displays.
Conceptual Physical
systems design systems design
Physical Systems Design: File and Database Design, Input Design, Procedures Design, and Control
Design
At the end of physical design phase the team prepares a physical systems design report.
This report becomes the basis for management’s decision whether to proceed to the
implementation phase.
Implementation and conversion: Systems implementation is the process of installing hardware and
software and getting the AIS up and running. It includes the following activities.
The relationship of the items in this phase and the conversion process (next phase) will be as shown
below in a series of activities.
Complete
documentation Test system
Conversion
©2003 Prentice Hall Business Publishing, 18-27
Accounting Information Systems, 9/e, Romney/Steinbart
Conversion is the process of changing from the old AIS to the new. Many
elements must be converted: hardware, software, data files and procedures. The
system conversion process is complete when the new AIS has become a routine,
ongoing part of the system.
Conversion approaches
Four conversion approaches are used to change from an old to a new system.
Old system
New sy stem
Parallel
Pilot
1 2 3 1 2 3 1 2 3
old old old old old New old New New
1 2 3
New New New
One activity performed in SDLC is planning system development. In connection with, thus, the
organization must have a long-range plan, each system development project requires a plan and
each phase of each development plan must also be planned. In SDLC two type of system
development plans are needed: individual project plans prepared by project teams and a master
plan developed by the information system steering committee.
The project development plan contains a cost benefit analysis, developmental and operational
requirements, including human resources, hardware, software and financial resource
requirements; and a schedule of the activities required to develop and operate the new
application. The master plan is a long-range planning document that specifies what the system
will consist of, how it will be developed, who will develop it, how needed resources will be
acquired and where the AIS is headed.
The master plan also should provide the status of the project in process, prioritize planned
projects, describe the criterion used for prioritization and provide timetable for development. The
project with the highest priority should be the first to be developed. A planning horizon of
At major decision points shown in SDLC, the steering committee uses the feasibility study
whether to terminate a project, proceed unconditionally or proceed if specific problems are
resolved. Although projects can be terminated at any time, the early go-no-go decisions are
particularly important, as each sub segment SDLC steps require more time & monetary
commitment. Although uncommon systems have been scrapped after implementation because
they did not work or failed to meet an organization needs.
Technical feasibility: Can the planned system be developed and implemented using existing
technology?
Operational feasibility: Does the organization have access to people who can design,
implement and operate the proposed system? Can people use the system and will they use it?
Legal feasibility: Does the system comply with all applicable federal, state laws, administrative
agency regulations, and the company’s contractual obligations?
Scheduling feasibility: Can the system be developed and implemented in the time allotted? If
not it will be modified, postponed or replaced by an alternative selection.
Economic feasibility: Will system benefit justify the time, money and other resources required
to implement it?
What is feasibility study?
The behavioral aspects of change are crucial because the best systems will fail without the
support of the people it serves. Organizations must be sensitive to and consider the feelings and
reactions of persons affected by change.
Why behavioral problems occur?
When something new is introduced there is a natural tendency that people will resist the change.
Resistance to change occurs because of the following factors:
Personal characteristics & background: Generally speaking, the younger and more highly
educated people are more likely to accept the change. Likewise, the more comfortable people are
with technology, the less likely they are to oppose changes in AIS.
Manner in which the change is introduced: The rationale used to sell the system to top
management may not be appropriate for lower level employees. The elimination of boring tasks
and the ability to advance & grow are more important to users than increasing profits and
reduced costs.
Experience with prior changes: Employees who had a bad experience with prior changes are
more reluctant to cooperate when future changes occur.
Top management support: Employees who sense a lack of top management support for change
wonder why they themselves should endorse it.
Communication: Employees are unlikely to support a change unless the reason behind it is
explained.
Bias and natural resistance to change: People with emotional attachment to their duties or co-
workers may not want to change if those elements are affected.
Disruptive nature of change process: Request for information & interviews are distracting and
place additional burden on people. These disturbances can create negative feelings towards the
change that is promoted them to occur.
As organizations grow and change, they may need more or better information. Systems analysis
is the first step. It includes:
a. Initial investigation
Involves gathering the information needed to buy or develop a new system and determining
whether it is a priority.
b. Systems survey
If the system is a priority, survey the existing system to define the nature and scope of the project
and identify the strengths and weaknesses of the system.
c. Feasibility study
Involves an in-depth study of the proposed system to determine whether it’s feasible.
d. Determination of information needs and system requirements:
Involves finding out and documenting what users and management need. This is the most
important aspect of systems analysis.
e. Delivery of systems requirements
Involves preparation of a report summarizing the systems analysis work. This report is submitted
to the information systems steering committee.
What is systems analysis?
------------------------------------------------------------------------------------------------------------
In the conceptual systems design phase, a general framework is developed for implementing user
requirements and solving problems identified in the analysis phase. What are the three steps in
conceptual design?
Conceptual Design
Identify and evaluate
design alternatives
Develop design specifications Physical
Design
Deliver conceptual design
requirements
The system analysis phase is related to the conceptual design phase based on the diagram shown below:
Systems
analysis
Prepare
Evaluate Prepare
conceptual
design design
systems
alternatives specifications
design report
©2003 Prentice Hall Business Publishing, 18-10
Accounting Information Systems, 9/e, Romney/Steinbart
Complete
documentation Test system
Conversion
©2003 Prentice Hall Business Publishing, 18-27
Accounting Information Systems, 9/e, Romney/Steinbart
Learning Objectives
Introduction
The revenue cycle is a recurring set of business activities and related information processing
operations associated with providing goods and services to customers and collecting their cash
payments. The primary external exchange of information is with customers. Management also
has to evaluate the efficiency and effectiveness of revenue cycle processes: The revenue cycle
- Resources used.
2. Shipping
3. Billing
4. Cash collection
Respond to customer inquiries (may be done by customer service or sales order entry).
Respond to customer inquiries (may be done by customer service or sales order entry).
Respond to customer inquiries (may be done by customer service or sales order entry).
What are the four basic business activities which are performed in the revenue cycle?
- The second basic activity in the revenue cycle is filling customer orders and shipping
Manufacturing.
o Selecting best carrier means collecting and monitoring carrier performance data for:
- On-time delivery.
3. Billing
The third revenue cycle activity is Billing customers i.e., - sending invoice to customer.
Invoicing(a document that is issued by a seller to the buyer that indicate the quantity and
cost)
Accurate and timely billing is crucial. Billing is an information processing activity that
repackages and summarizes information from the sales order entry and shipping activities.
4. Cash collection
The final activity in the revenue cycle is collecting cash from customers. The cashier handles
customer remittances and deposits them in the bank. Because cash and checks are highly
the expenditure cycle from other cycles, e.g.: The revenue cycle, production cycle, inventory
control, and various departments provide information about the need to purchase goods and
materials.
Information is provided to the general ledger and reporting function for internal and
The primary objective of the expenditure cycle is to minimize the total cost of acquiring, and
Management also has to evaluate the efficiency and effectiveness of expenditure cycle processes.
Resources affected.
The production cycle involves the transformation of labor and raw material into finished goods.
In this cycle raw materials are purchased and converted to finished goods. Similarly, labor costs
are also incurred in this cycle labor forces in the production processes.
One of the primary functions of GLARS is to collect and organize data from:
The treasurer, who provides entries with respect to non-routine activities such as
1. A 2. B 3. B 4. D 5. B 6. C 7. D
1. B 2. A 3. C 4. D 5. B 6. B
1. A 2. C 3. D 4. B 5. B
1. C 2. D 3. B 4. D 5. C
1. D 2. C 3. A 4. D 5. C