Introduction To Transaction Processing PDF

CHAPTER Introduction to Transaction Processing hapter | introduced the transaction processing sys- tem (TPS) as an activity consisting of three major ~ subsystems called cycles: the revenue cycle, the a expenditure cycle, and the conversion cycle. Even thou...

CHAPTER Introduction to Transaction Processing hapter | introduced the transaction processing sys- tem (TPS) as an activity consisting of three major ~ subsystems called cycles: the revenue cycle, the a expenditure cycle, and the conversion cycle. Even though M Learning Objectives each cycle performs different specific tasks and supports dif- ferent objectives, they share common characteristics. For After studying this chapter, you should: example, all three TPS cycles capture financial transactions, m@ Understand the broad objectives of. record the effects of transactions in accounting records, and transaction cycles. provide information about transactions to users in support of m Recognize the types of transactions their day-to-day activities. In addition, transaction cycles pro- processed by each of the three duce much of the raw data from which management reports transaction cycles. and financial statements are derived. Because of their finan- cial impact on the firm, transaction cycles command much of Know the basic accounting records the accountant’s professional attention. used in transaction processing The purpose of this chapter is to present some preliminary systems. topics that are common to all three transaction processing Understand the relationship between cycles. In subsequent chapters, we will draw heavily from traditional accounting records and this material as we examine the individual subsystems of _their digital equivalents in computer- each cycle in detail. This chapter is organized into six major based systems. sections. The first is an overview of transaction processing. Be familiar with the documentation This section defines the broad objective of the three transac- techniques used for representing tion cycles and specifies the roles of their individual subsys- manual procedures and the computer tems. The second section describes the relationship among components of systems. accounting records, both traditional and digital, in forming Understand the differences between an audit trail. The third section describes the key features of batch and real-time processing and flat file and database structures used to store accounting data. the impact of these technologies on The fourth section examines several documentation techni- transaction processing. ques used to represent systems including manual procedures and the computer components of system. The fifth section Be familiar with data coding schemes addresses alternative transaction processing approaches. It used in accounting information reviews the fundamental features of batch and real-time tech- systems. nologies and their implication for transaction processing. The final section examines data coding schemes and their role in transaction processing. 33 34 PeAGRS pal Overview of Accounting Information Systems An Overview of Transaction Processing TPS applications process financial transactions. A financial transaction was defined in Chapter | as An economic event that affects the assets and equities of the firm, is reflected in its accounts, and is measured in monetary terms. The most common financial transactions are economic exchanges with external parties. These include the sale of goods or services, the purchase of inventory, the discharge of financial obliga- tions, and the receipt of cash on account from customers. Financial transactions also include cer- tain internal events such as the depreciation of fixed assets; the application of labor, raw materials, and overhead to the production process; and the transfer of inventory from one department to another. Financial transactions are common business events that occur regularly. For instance, thou- sands of transactions of a particular type (sales to customers) may occur daily. To deal efficiently with such volume, business firms group similar types of transactions into transaction cycles. TRANSACTION CYCEES Three transaction cycles process most of the firm’s economic activity: the expenditure cycle, the conversion cycle, and the revenue cycle. These cycles exist in all types of businesses—both profit- seeking and not-for-profit types. For instance, every business (1) incurs expenditures in exchange for resources (expenditure cycle), (2) provides value added through its products or services (con- version cycle), and (3) receives revenue from outside sources (revenue cycle). Figure 2-1 shows the relationship of these cycles and the resource flows between them. FIGURE Tat RELATIONSHIP BETWEEN TRANSACTION CYCLES | Cash Physical Plant Cash Good Finished | Finished Goods Cash Learning” Cengage ©  G@iHVAT ER Tiber 2 Introduction to Transaction Processing 35 The Expenditure Cycle Business activities begin with the acquisition of materials, property, and labor in exchange for cash— the expenditure cycle. Figure 2-1 shows the flow of cash from the organization to the various providers of these resources. Most business-to-business (B2B) expenditure transactions are based on a credit rela- tionship between the trading parties. The actual disbursement of cash takes place at some point after the receipt of the goods or services. Days or even weeks may pass between these two events. Thus, from a systems perspective, this transaction has two parts: a physical component (the acquisition of the goods or services) and a financial component (the cash disbursement to the supplier). A separate subsystem of the cycle processes each component. The primary expenditure cycle subsystems are out- lined next. Because of the extent of this body of material, two chapters are devoted to a detailed examination. Purchases/accounts payable and cash disbursements systems are the topics of Chapter 5. Payroll and fixed asset systems are examined in Chapter 6. Purchases/accounts payable (AP) system. This system recognizes the need to acquire physical inventory (such as raw materials) and places an order with the vendor. When the goods are received, the purchases system records the event by increasing inventory and establishing an account payable to be paid at a later date. Cash disbursements system. When the obligation created in the purchases system becomes due, the cash disbursements system authorizes the payment, disburses the funds to the vendor, and records the transaction by reducing the cash and accounts payable accounts. Payroll system. The payroll system collects labor usage data for each employee, computes the pay- roll, and disburses paychecks to the employees. Conceptually, payroll is a special-case purchases and cash disbursements system. Because of accounting complexities associated with payroll, most firms have a separate system for payroll processing. Fixed asset system. A firm’s fixed asset system processes transactions pertaining to the acquisition, maintenance, and disposal of its fixed assets. These are relatively permanent assets that collectively often represent the organization’s largest financial investment. Examples of fixed assets include land, buildings, furniture, machinery, and motor vehicles. The Conversion Cycle The conversion cycle is comprised of two major subsystems: the production system and the cost accounting system. The production system involves the planning, scheduling, and control of the physical product through the manufacturing process. This includes determining raw material requirements, authorizing the work to be performed and the release of raw materials into produc- tion, and directing the movement of the work-in-process through its various stages of manufactur- ing. The cost accounting system monitors the flow of cost information including labor, overhead and raw materials related to production. Information this system produces is used for inventory valuation, budgeting, cost control, performance reporting, and management decisions, such as make-or-buy decisions. We examine the basic features of these systems in Chapter 7. Manufacturing firms convert raw materials into finished products through formal, physical, and observable conversion cycle operations. The conversion cycle in service and retailing establish- ments, however, may not be formal and observable. Nevertheless, these firms still engage in value added conversion cycle activities that culminate in the development of a salable product or service. These activities include the readying of products and services for market and allocating resources such as depreciation, building amortization, and prepaid expenses to the proper accounting period. Unlike manufacturing firms, merchandising companies do not account for these activities through formal conversion cycle subsystems that track and allocate costs to specific goods. In con- trast, some service organizations such as public accounting firms, law firms, and consulting firms do track specific costs (primarily labor) to client accounts in much the same way as a manufactur- ing cost accounting system would track labor and raw materials to the products they produce. 36 JIN IRI AL Overview of Accounting Information Systems The Revenue Cycle Firms sell their goods and services to customers through the revenue cycle, which involves proces- sing cash sales, credit sales, and the receipt of cash following a credit sale. Revenue cycle transac- tions also have a physical and a financial component, which are processed separately. The primary subsystems of the revenue cycle, which are the topics of Chapter 4, are briefly outlined below. Sales order processing. The majority of business sales are made on credit and involve tasks such as preparing sales orders, granting credit, shipping products (or rendering of a service) to the cus- tomer, billing customers, and recording the transaction in the accounts (accounts receivable, inven- tory, expenses, and sales). Cash receipts. For credit sales, some period of time (days or weeks) passes between the point of sale and the receipt of cash. Cash receipts processing includes collecting cash, depositing cash in the bank, and recording these events in the accounts (accounts receivable and cash). Accounting Records MANUAL SYSTEMS This section describes the purpose of each type of accounting record used in transaction cycles. We begin with traditional records used in manual systems (documents, journals, and ledgers) and then examine their digital counterparts in computer-based systems. Documents Documents serve several purposes in transaction processing. Documents may initiate transaction processing or be the output of a process. They also provide auditors with evidence of economic events. In this section we examine three types of documents: source documents, product docu- ments, and turnaround documents. SOURCE DOCUMENTS. Economic events result in the creation of some documents at the beginning (the source) of the transaction. These are called source documents and are used to cap- ture and formalize transaction data that the transaction cycle uses for processing. Figure 2-2 shows the creation of a source document. The economic event (in this case the sale) causes the sales clerk to prepare a multipart sales order, which is formal evidence that a sale occurred. Copies of this source document enter the sales system and are used to convey information to various functions, such as billing, shipping, and accounts receivable. The information contained in the sales order triggers specific activities in each of these functions. PRODUCT DOCUMENTS. Product documents are the result of transaction processing rather than the triggering mechanism for the process. For example, a payroll check to an employee is a product document of the payroll system. Figure 2-3 extends the example in Figure 2-2 to illustrate that the customer’s bill is a product document of the sales system. We will study many other examples of product documents in later chapters. TURNAROUND DOCUMENTS. Turnaround documents are product documents of one system that become source documents for another system. This is illustrated in Figure 2-4. The customer receives a perforated two-part bill or statement. One portion is the actual bill, and the other por- tion is the remittance advice. Customers remove the remittance advice and return it to the com- pany along with their payment (typically a check). The remittance advice is a turnaround document that contains important information about a customer’s account to help the cash receipts system process the payment. One of the problems designers of cash receipts systems face is matching customer payments to the correct customer accounts. Providing this needed informa- tion as a product of the sales system ensures accuracy when the cash receipts system processes it.  CeEIFAGPE Tie eRe2 Introduction to Transaction Processing 37 FIGURE 9.9 OF517-W alo) Me) Wt YolU) (ol Dlolelel vane Customer’s Source Order Document ENNIS Data Collection Sales Order ® Sales System Cengage © Learning FIGURE pee! A Propuct DocuMENT Source Document eXoS Data oe Collection Sales Order oe Customer Remittance Advice ® Product Document Cengage © Learning Journals A journal is a chronological record of a transaction. At some point in the transaction process, when all relevant facts about the transaction are known, the event is recorded in a journal in chronologi- cal order. Documents are the primary data source for journals. Figure 2-5 shows a sales order being recorded in the sales journal (see the following discussion on special journals). Each transaction requires a separate journal entry, reflecting the accounts affected and the amounts to be debited 38 BeASRet Overview of Accounting Information Systems FIGURE Dank 7a MULNY-V (ol 0) ]oymDlofolU) ia. he Source Document &? Data Cree ood Collection Sales Order gor Oe Customer Remittance Advice Cash FE LE i sce aR RC Receipts ® System Remittance Advice Cengage © Learning FIGURE 9-5 SALEs ORDER RECORDED IN SALES JOURNAL Economic Event Capture Event Record Event 1 Sales. eae ) ® Customer’. Oreer ourna Order Learning Cengage © and credited. There is often a time lag between initiating a transaction and recording it in the accounts. The journal holds a complete record of transactions and thus provides a means for posting to accounts. There are two primary types of journals: special journals and general journals. SPECIAL JOURNALS. Special journals are used to record specific classes of transactions that occur in high volume. Such transactions can be grouped together in a special journal and processed more efficiently than a general journal permits. Figure 2-6 shows a special journal for recording sales transactions.  COHVASP TaBaRy 2 Introduction to Transaction Processing 39 pel Credit Acct.Rec. #102 | |Sales #401 3300 3300 — 65.25 68.25 i Learning” Cengage © As you can see, the sales journal provides a specialized format for recording only sales transac- tions. At the end of the processing period (month, week, or day), a clerk posts the amounts in the columns to the ledger accounts indicated (see the discussion of ledgers in this chapter). For exam- ple, the total sales will be posted to account number 401. Most organizations use several other special journals, including the cash receipts journal, cash disbursements journal, purchases journal, and the payroll journal. REGISTER. The term register is often used to denote certain types of special journals. For example, the payroll journal is often called the payroll register. We also use the term register, however, to denote a log. For example, a receiving register is a log of all receipts of raw materials or merchandise ordered from vendors. Similarly, a shipping register is a log that records all shipments to customers. GENERAL JOURNALS. Firms use the general journal to record nonrecurring, infrequent, and dis- similar transactions. For example, we usually record-periodic depreciation and closing entries in the general journal. Figure 2-7 shows one page from a general journal. Note that the columns are nonspe- cific, allowing any type of transaction to be recorded. The entries are recorded chronologically. As a practical matter, most organizations have replaced their general journal with a journal voucher system. A journal voucher is actually a special source document that contains a single journal entry specifying the general ledger accounts that are affected. Journal vouchers are used to record summaries of routine transactions, nonroutine transactions, adjusting entries, and clos- ing entries. The total of journal vouchers processed is equivalent to the general journal. Subse- quent chapters discuss the use of this technique in transaction processing. Ledgers A ledger is a book of accounts that reflects the financial effects of the firm’s transactions after they are posted from the various journals. While journals show the chronological effect of business activity, ledgers show activity by account type. A ledger indicates the increases, decreases, and current balance of each account. Organizations use this information to prepare financial state- ments, support daily operations, and prepare internal reports. Figure 2-8 shows the flow of finan- cial information from the source documents to the journal and into the ledgers. 40 PAN IR TW It Overview of Accounting Information Systems FIGURE 9.7 GENERAL JOURNAL GENERAL JOURNAL PAGE DESCRIPTION Sept. 1, 2009 Sept. 2, 2009 Learning” Cengage © en Ce Oe 2-8 FLOW OF INFORMATION FROM THE ECONoMic EVENT TO THE GENERAL LEDGER Journal ar Entry as Post G : ales ales enera enh eee al Order oan ae Journal amma Ledger Post 30° yo oS gor Accounts Receivable aN Subsidiary cer" Ledger WOr de Re sce’ \e Learning® Cengage © There are two basic types of ledgers: (1) general ledgers, which contain the firm’s account infor- mation in the form of highly summarized control accounts, and (2) subsidiary ledgers, which con- tain the details of the individual accounts that constitute a particular control account.! 1 Not all accounts in the general ledger have corresponding subsidiary accounts. Accounts such as sales and cash typically have no supporting details in the form of a subsidiary ledger.  CUHEAGR ie BaRaw Introduction to Transaction Processing GENERAL LEDGERS. The general ledger (GL) summarizes the activity for each of the organi- zation’s accounts. The general ledger function updates these records from journal vouchers pre- pared from special journals and other sources located throughout the organization. The general ledger presented in Figure 2-9 shows the beginning balances, the changes, and the ending balances as of a particular date for several different accounts. GENERAL LEDGER 2-9 Cash ACCOUNT NO. /0/ | DATE ITEM ao DEBIT CREDIT aveens pest || CREDIT | Sept. 70 157) Fe 3\O\0 (a I\Z1O10 | i H | /5 s [lt leleebl LETT Welolelol [| | [pax || $1 MISES eee eae Heiek Hin) ex |T TULL UT belslolol [Ee[lslab] [TE LLL | a ee a eae a ae ea a | Accounts, Receivable ACCOUNT NO. 702 | |DATE ITEM ee DEBIT CREDIT sala ua | DEBIT CREDIT | se se deelolol EET efoto EEE oem a ee a aslola| | |[| tlolols| [TL TLL SE area ee ee eee IE eS eee ee ttt eres ECACC | Accounts Payalle ACCOUNT _ NO..207 BALANCE POST. DEBIT CREDIT REE DEBIT | CREDIT Pr 2\0\5\0 |2 Jols|olo -3F ai nt CD7 25 O |7 7\7\0\0 aatite HH 42 PEAGR Sioa) Overview of Accounting Information Systems FIGURE 2-9 GENERAL LEDGER (CONTINUED) Deepa! ACCOUNT NO. 502 POST. BALANCE DATE ITEM CREDIT iis REF. DEBIT TT CREDIT Hitef Learning” Cengage © The general ledger provides a single value for each control account, such as accounts payable, accounts receivable, and inventory. This highly summarized information is sufficient for financial reporting, but it is not useful for supporting daily business operations. For example, for financial reporting purposes, the firm’s total accounts receivable value must be presented as a single figure in the balance sheet. This value is obtained from the accounts receivable control account in the general ledger. To actually collect the cash this account represents, however, the firm must have certain detailed information about customers that this summary figure does not provide. It must know customers’ addresses, which customers owe money, how much each customer owes, when certain customers last made payment, when the next payment is due, and so on. The accounts receivable subsidiary ledger contains these essential details. SUBSIDIARY LEDGERS. Subsidiary ledgers are kept in various accounting departments of the firm, including inventory, accounts payable, payroll, and accounts receivable. This separation provides better control and support of operations. Figure 2-10 illustrates that the total of account balances in a subsidiary ledger should equal the balance in the corresponding general ledger control account. Thus, in addition to providing financial statement information, the gen- eral ledger is a mechanism for verifying the overall accuracy of accounting data that separate accounting departments have processed. Any event incorrectly recorded in a journal or subsidi- ary ledger will cause an out-of-balance condition that should be detected during the general led- ger update. By periodically reconciling summary balances from subsidiary accounts, journals, and control accounts, the completeness and accuracy of transaction processing can be formally assessed. THE AUDIT TRAIL The accounting records described previously provide an audit trail for tracing account balances contained in the financial statements back to source documents and the economic events that cre- ated them. An audit trail is of utmost importance in the conduct of a financial audit. The external auditor’s responsibility involves, in part, the review of selected accounts and transactions to determine their validity, accuracy, and completeness. Let’s assume an auditor wishes to verify the accuracy of a client’s AR balance as published in its annual financial state- ments. The auditor can trace the AR value on the balance sheet to the general ledger AR con- trol account. This balance can then be reconciled with the total for the accounts receivable  @oHPAGR Ty EeRY 2 Introduction to Transaction Processing 43 FIGURE 2-10 RELATIONSHIP BETWEEN THE SUBSIDIARY LEDGER AND THE GENERAL LEDGER e Accounts Receivable Subsidiary Ledger General Ledger Hobbs Johnson Cash XXXX.XX XXXX.XX 9,845,260 Smith XXXX.XX Total AR = Accounts Receivable 14,205,800 ei 14,205,800 Howard XXXX.XX XXXX.XX Inventory 126,389,538 Learning” ©Cengage subsidiary ledger. Rather than examining every transaction that affected the AR account, the auditor will use a sampling technique to examine a representative subset of transactions. Follow- ing this approach, the auditor can select a number of accounts from the AR subsidiary ledger and trace these back to the sales journal. From the sales journal, the auditor can identify the specific source documents that initiated the transactions and pull them from the files to verify their validity and accuracy. The audit of AR often includes a procedure called confirmation. This involves contacting selected customers to determine if the transactions recorded in the accounts actually took place and if customers agree with the recorded balance. Information contained in source documents and subsidiary accounts enables the auditor to identify and locate customers chosen for confirma- tion. The results from reconciling the AR subsidiary ledger with the control account and from confirming customers’ accounts help the auditor form an opinion about the accuracy of accounts receivable as reported on the balance sheet. The auditor performs similar tests on all of the client firm’s major accounts and transactions to arrive at an overall opinion about the fair presentation of the financial statement. The audit trail plays an important role in this process. 44 ReAG Rail Overview of Accounting Information Systems DIGITAL ACCOUNTING RECORDS Modern accounting systems store data in four types of digital computer files: master files, transac- tion files, reference files, and archive files. Figure 2-11 illustrates the relationship between these files in forming an audit trail. MASTER FILE. A master file contains account data. The general ledger and subsidiary ledgers are examples of master files. Data values in master files are updated (changed) by transactions. TRANSACTION FILE. A transaction file is a temporary file of transaction records used to update data in a master file. Sales orders, inventory receipts, and cash receipts are examples of transaction files. The actual file update process is explained later in the chapter. REFERENCE FILE. A reference file stores data that are used as standards for processing trans- actions. For example, the payroll program may refer to a tax table to calculate the proper amount of withholding taxes for payroll transactions. Other reference files include price lists used for FIGURE 2-11 DicitaL ACCOUNTING REcOoRDs IN-A CompuTer-BASED SysTEM | Audit Trail - Balance Source Sheet Document AR XXX Sales Orders 7 if 7 if if rs Transaction / File /] i '@ \ \ Master Files \ A General Ledger N Control Accounts x + Accounts Receivable ae N : Inventory >< \ - Cost of Goods SS Sold \ » + Sales ; | / ——_———— Inventory Subsidiary Learning® Cengage ©  COHEAGE aE Re Introduction to Transaction Processing 45 preparing customer invoices, lists of authorized suppliers, employee rosters, and customer credit files for approving credit sales. The reference file in Figure 2-11 is a credit history file. ARCHIVE FILE. An archive file contains records of past transactions that are retained for future ref- erence and form an important part of the audit trail. Archive files include journals, prior-period payroll information, lists of former employees, records of accounts written off, and prior-period ledgers. The Digital Audit Trail Audit trails among digital records are less observable than those between hard-copy documents, but they still exist. Let’s walk through the system represented in Figure 2-11 to illustrate how digi- tal files provide an audit trail. We begin with the capture of the economic event. In this example, sales are recorded manually on source documents. The next step in this process is to convert the source documents to digital form. This is done in the data-entry stage, where the transactions are edited for correctness and a transaction file of sales orders is produced. Some computer systems do not use physical source documents. Instead, transactions are captured directly on digital media. The next step is to update the various master file subsidiary and GL control accounts that are affected by the transaction. During the update procedure, additional editing of transactions takes place. Some transactions may prove to be in error or invalid for such reasons as incorrect account numbers, insufficient quantities on hand, or customer credit problems. In this example, the system determines the available credit for each customer from the credit file before processing the sale. Any records that are rejected for credit problems are transferred to the error file. The remaining good records are used to update the master files. Only these valid transactions are added to the archive file, which serves as the sales journal. By copying the valid transactions to the journal, the original transaction file is not needed for audit trail purposes. This file can now be erased (scratched) in preparation for the next batch of sales orders. Like the paper audit trail, this digital audit trail allows transaction tracing. Again, an auditor attempting to evaluate the accuracy of the AR figure published in the balance sheet could do so via the following steps, which are identified in Figure 2-11 with the dotted arrows. 1. Compare the accounts receivable balance in the balance sheet with the master file AR control account balance. N Reconcile the AR control figure with the AR subsidiary account total. 3. Select a sample of updated entries made to accounts in the AR subsidiary ledger and trace these to transactions in the sales journal (archive file). 4. From these journal entries, identify specific source documents that can be pulled from their files and verified. If necessary, the auditor can confirm the accuracy and propriety of these source documents by contacting the customers in question. File Structures Digital file structures and storage techniques vary widely among transaction processing systems. This is because each file structure was designed to serve a particular task. Some structures are most effective for processing large portions of a master file. For example, on payday, every employee record in the employee payroll master file needs to be processed, because all (or most) employees get paid. Some file structures are better for directly locating and processing a single record in a large file, without having to search through thousands of other records on the file. For example, selecting a specific customer’s record, in response to a customer query over the phone, from a cus- tomer master file that contains a million records requires a direct access file structure. Unfortu- nately, no single structure works optimally in all applications; therefore, selecting a data management file structure often involves compromise. The appendix to this chapter presents several examples of file structures and discusses their respective advantages and disadvantages. File technologies broadly fall into two classes: (1) flat files and (2) databases. The sections that follow examine the general characteristics of each class and illustrate the evolution of data 46 PAN IR IP Overview of Accounting Information Systems management systems. The flat-file approach is often associated with so-called legacy systems, which are large mainframe systems that were commonplace in the 1960s and 1970s, but still exist today. Most modern system implementations employ database technologies, although flat-file systems are still implemented in special applications. In addition, database technology has been with us since the 1960s, and some legacy systems use early database technologies. Eventually, flat files will proba- bly succumb to databases, but in the meantime, accountants and auditors must deal with both. THE FLAT-FILE MODEL The flat-file model describes an environment in which individual data files are not related to other files. End users in this environment own their data files rather than share them with other users. Thus, stand-alone applications rather than integrated systems perform data processing. When multiple users need the same data for different purposes, they must obtain separate data sets structured to their specific needs. Figure 2-12 illustrates how customer sales data might be pre- sented to three different users in a durable goods retailing organization. The accounting function needs customer sales data organized by account number and structured to show outstanding bal- ances. This is used for customer billing, AR maintenance, and financial statement preparation. Marketing needs customer sales history data organized by demographic keys. Marketing uses this for targeting new product promotions and for selling product upgrades. The product services group needs customer sales data organized by products and structured to show scheduled service dates. Such information is used for making after-sales contacts with customers to schedule preven- tive maintenance and to solicit sales of service agreements. The data redundancy demonstrated in this example contributes to three significant problems in the flat-file environment: data storage, data updating, and currency of information. These and other problems associated with flat files are discussed in the following sections. Data Storage An efficient information system captures and stores data only once and makes this single source available to all users who need it. In the flat-file environment, this is not possible. To meet the pri- vate data needs of users, organizations must incur the costs of both multiple collection and multi- ple storage procedures. Some commonly used data may be duplicated dozens, hundreds, or even thousands of times. Data Updating Organizations have a great deal of data stored in files that require periodic updating to reflect changes. For example, a change to a customer’s name or address must be reflected in the appro- priate master files. When users keep separate files, all changes must be made separately for each user. This adds significantly to the task and the cost of data management. Currency of Information In contrast to the problem of performing multiple updates is the problem of failing to update all the user files affected by a change in status. If update information is not properly disseminated, the change will not be reflected in some users’ data, resulting in decisions based on outdated information. Task-Data Dependency Another problem with the flat-file approach is the user’s inability to obtain additional information as his or her needs change. This problem is called task-data dependency. The user’s information set is constrained by the data that he or she possesses and controls. Users act independently rather than as members of a user community. In such an environment, it is difficult to establish a mech- anism for the formal sharing of data. Therefore, new information needs tend to be satisfied by procuring new data files. This takes time, inhibits performance, adds to data redundancy, and drives data management costs even higher.  GOHEAGE TERE =2 Introduction to Transaction Processing FIGURE pJ He FLAT-Fite MobeEL User — Stand-Alone Application User-Owned Data Sets Customer Data (Current Accounts Receivable) Accounting Billing/Accounts Receivable System Sales Invoices Customer Data (Historic/Demographic Orientation) Product Promotion Marketing System Sales Invoices Customer Data (Historic/Product Service Scheduling Orientation) Product Services j ee ae System ® Product Services Schedule Learning Cengage © Flat Files Limit Data Integration The flat-file approach is a single-view model. Files are structured, formatted, and arranged to suit the specific needs of the owner or primary user of the data. Such structuring, however, may exclude data needed by other users, thus preventing successful integration of data across the orga- nization. For example, because the accounting function is the primary user of accounting data, these data are often captured, formatted, and stored to accommodate financial reporting and gen- erally accepted accounting principles (GAAP). This structure, however, may be useless to the organization’s other (nonaccounting) users of accounting data such as the marketing, finance, pro- duction, and engineering functions. These users are presented with three options: (1) do not use 48 RrAGRei Overview of Accounting Information Systems accounting data to support decisions, (2) manipulate and massage the existing data structure to suit their unique needs, or (3) obtain additional private sets of the data and incur the costs and operational problems associated with data redundancy. In spite of these inherent limitations some organizations still make limited use of flat files in their older legacy systems. THE DATABASE MODEL Organizations have overcome some of the problems associated with flat files by implementing the database model to data management. Figure 2-13 illustrates how this approach centralizes the organization’s data into a common database that is shared by other users. With the organization’s data in a central location, all users have access to the data they need to achieve their respective objectives. Access to the data resource is controlled by a database management system (DBMS). The DBMS is a software system that permits users to access authorized data only. The user’s application program sends requests for data to the DBMS, which validates and authorizes access to the database in accordance with the user’s level of authority. If the user requests data that he or she is not authorized to access, the request is denied. Clearly, the organization’s procedures for assigning user authority is an important control issue for auditors to consider. The most striking difference between the database model and the flat-file model is the pooling of data into a common database that all organizational users share. With access to the full domain of entity data, changes in user information needs can be satisfied without obtaining additional pri- vate data sets. Users are constrained only by the limitations of the data available to the entity and the legitimacy of their need to access it. Through data sharing, the traditional problems associated with flat-file systems described previously can be eliminated. We devote Chapters 9 and 10 to a detailed examination of the relational database model and the process and control issues unique to it. Until then, to simplify discussion in the transaction processing chapters that follow, we make no references to the specific file technology that may be used in the systems presented. The specific file structure employed, whether flat file or databases, is for the most part irrelevant to the process and control issues that are the focus of those chapters. Instead, we will refer to digital data files in generic terms such as AR subsidiary ledger, Accounts Payable Control, or Customer Order file. Similarly, the digital data storage symbols depicted in system flowcharts that follow in this chapter and in subsequent chapters represent generic data files. FIGURE 2.73 | DY-Gy\:¥-\-) = a (o)0)18 Data User A ee Management Shared Database ication Pe, and Control Customer Sales Software Accounting