Page 103 - Accounting Information Systems

74 PART I Overview of Accounting Information Systems

file records that are unique to a transaction such as customer accounts and individual inventory records
can be updated in real time without causing operational delays.
Updating the records in the general ledger is a different matter. All general ledger accounts previously
listed need to be updated by every sales transaction. If the processing of John Smith’s transaction begins
before that of Mary Jones, then she must wait until all six records have been updated before her transac-
tion can proceed. However, the 20- or 30-second delay brought about by this conflict will probably not
inconvenience Mary Jones. This problem becomes manifest as transaction volumes increase. A 20-second
delay in each of 500 customer transactions would create operational inefficiency on a chaotic level.
Each of the 500 customers must wait until the person ahead of him or her in the queue has completed
processing their transaction. The last person in the queue will experience a delay of 500 20 seconds ¼
3
2= 4 hours.

REAL-TIME PROCESSING
Real-time systems process the entire transaction as it occurs. For example, a sales order processed by the
system in Figure 2-32 can be captured, filled, and shipped the same day. Such a system has many poten-
tial benefits, including improved productivity, reduced inventory, increased inventory turnover, decreased
lags in customer billing, and enhanced customer satisfaction. Because transaction information is transmit-
ted electronically, physical source documents can be eliminated or greatly reduced.
Real-time processing is well suited to systems that process lower transaction volumes and those that do
not share common records. These systems make extensive use of local area network and wide area net-
work technology. Terminals at distributed sites throughout the organization are used for receiving, process-
ing, and sending information about current transactions. These must be linked in a network arrangement
so users can communicate. The operational characteristics of networks are examined in Chapter 12.

Data Coding Schemes

Within the context of transaction processing, data coding involves creating simple numeric or alpha-
betic codes to represent complex economic phenomena that facilitate efficient data processing. In
Figure 2-28, for example, we saw how the secondary keys of transaction file records are linked to the
primary keys of master file records. The secondary and primary keys in the example are instances
of data coding. In this section we explore several data coding schemes and examples of their applica-
tion in AIS. To emphasize the importance of data codes, we first consider a hypothetical system that
does not use them.

A SYSTEM WITHOUT CODES
Firms process large volumes of transactions that are similar in their basic attributes. For instance, a firm’s
AR file may contain accounts for several different customers with the same name and similar addresses.
To process transactions accurately against the correct accounts, the firm must be able to distinguish one
John Smith from another. This task becomes particularly difficult as the number of similar attributes and
items in the class increase.
Consider the most elemental item that a machine shop wholesaler firm might carry in its inventory—a
machine nut. Assume that the total inventory of nuts has only three distinguishing attributes: size, mate-
rial, and thread type. As a result, this entire class of inventory must be distinguished on the basis of these
three features, as follows:

1. The size attribute ranges from = 4 inch to 1 = 4 inches in diameter in increments of = 64 of an inch, giving
1
1
3
96 nut sizes.
2. For each size subclass, four materials are available: brass, copper, mild steel, and case-hardened
steel.
3. Each of these size and material subclasses come in three different threads: fine, standard, and coarse.