Introduction to Transaction Processing

PAPER

Prepared to meet the task

Accounting Information System courses supervised by Mr. Eko Ganis

BY

Nadia Dayanti (0910233046)

Satrio Mangkunegoro (0910233138 )

UNIVERSITY BRAWIJAYA OF MALANG

FACULTY OF ECONOMICS

INTERNATIONAL ACCOUNTING DEPARTMENT

March 2011

Introduction to Transaction Processing

ABSTRACT

Transaction processing systems have been

available since the 1970s, and nearly all businesses use

them. The advent of the Internet has seen a boom in

transaction processing systems and software. Over the

years, the cost of buying and implementing the

necessary software has dropped so much that most

businesses can apply it profitably. Banking from home,

booking a holiday on the net, shopping and working

from home are all now readily available and less time

consuming. Transaction processing is a computer-based

group of logical operations. In order for transaction

processing to work, all the operations must succeed or

fail as a group. A simple example of transaction

processing is paying a utility bill from your bank

account. The process of paying a bill from your account

consists of debiting your account by say, 100 US

dollars (USD), and crediting your utility provider’s

account. Systems capable of transaction processing

must pass tests for atomicity, consistency, isolation and

durability, otherwise known as the ACID test.

Key word : Transaction, processing, system, account

Introduction to Transaction Processing

INTRODUCTION

Most of the events which occur in a business can be sorted into just a few

groups: acquisition of materials, labor, and capital assets and the subsequent

disbursement of payment; conversion of materials into goods and services using labor

and assets; and sales of goods and/or services and the subsequent receipt of payment.

Understanding what must happen in each of these cycles and what recordkeeping

must be done will greatly enhance your understanding of what must occur within an

accounting system.

The chapter opens with an overview of transaction processing. Although you are

familiar with the terms source documents, journals, and ledgers, you will find the

second part of the chapter enlightening. Because we need ways to represent (and

therefore visualize) accounting systems, this chapter presents some system

documentation techniques. The last section of the chapter introduces the basic ways

in which an information system can use computer technology.

The objectives of this chapter are:

1. To understand the broad objectives of transactions cycles;

2. To recognize the types of transactions processed by each of the three

transactioncycles;

3. To know the basic accounting records used in transaction processing systems;

4. To to understand the relationship between traditional accounting records and

their magnetic equivalents found in computer-based systems;

5. To be familiar with the documentation techniques used for representing

manual and computer-based systems; and

6. To understand the characteristic differences between batch and real-time

processing and the impact of these technologies on transaction processing.

CONTENTS

I. TRANSACTION PROCESSING

Financial transactions are dealt with by the transaction processing system

(TPS) which is organized to handle like transactions in a like manner.

A. Transaction Cycles

Three transaction cycles handle the three basic types of transactions: those

related to the acquisition of materials, labor, and capital assets and the subsequent

disbursement of payment (the expenditure cycle); the conversion of materials into

goods and services using labor and assets (the conversion cycle); and the sale of

goods and/or services and the subsequent receipt of payment (the revenue cycle).

B. The Expenditure C ycle

The start of business activity is reflected in the expenditure cycle S the acq

uisition of the inputs to production: materials, labor, and fixed assets. Since most

business transactions are conducted on a credit basis, your text distinguishes between

the physical part of the transaction and the financial part. T his is an artificial split

and is used for clarity only. Considerably more effort is required when transactions

are not conducted on a cash basis. Four subsystems make up the expenditure cycle:

1. Purchases/accounts payable involves the ordering of materials and recognizing the

related liability;

2. Cash disbursements handles the payment on those liabilities;

3. Payroll handles both tasks for the purchase of labor; and

4. Fixed assets deals with the acquisition, maintenance and disposal of property,

plant, and equipment.

C. The Conversion Cycle

Conversion implies changing the form of something to make it different. The

conversion cycle handles the activities which occur in a business to combine and

convert raw materials to produce a product.

There are two subsystems.

1. Production includes all of the activities related to the physical creation of the

product, including planning, scheduling, and controlling the product.

2. Cost accounting handles the flow of costs through the system, the financial effort.

D. The Revenue Cycle

Businesses exchange their goods and services with customers through the

revenue cycle. This may involve both cash sales and credit sales. As with the

expenditure cycle, physical and financial parts of the transaction must be recognized.

There are two fundamental subsystems.

1. Sales order processing involves order preparation, credit granting, shipping,

billing, and recording.

2. Cash receipts takes cash receipts all the way to the bank.

II. ACCOUNTING RECORD

A. Manual Systems

Manual accounting systems are paper based. All of the information entered

and organized in the system is written manually. We call the standard bookkeeping

system a double-entry system because of the way it works.

This part of the chapter presents good discussion and examples of these paper

records. For some of you this may be a review. If not, study it carefully.

1. Documents are paper forms used to collect information. There are several basic

types of documents.

a. Source documents capture the information needed by the system

b. Product documents are produced by the system

c. Turnaround documents start life as product documents and later turn around and

become source documents to another part of the same system. (Recall the part of your

credit card statement that you return with your payment.)

2. Journals are called “books of original entry” because a journal is the first place

that information is entered into the accounting system. T he term comes from the

Latin word for day. A journal is sometimes called a “day-book” to emphasize the fact

that it is a chronological list of events. All significant information about an economic

event, or transaction, appears together in one of the journals. There are several types.

a. Special journals are created to handle like transactions that occur in large numbers.

Work is reduced by entries taking only one line with columns for the normal accounts

used. Many organizations have sales, purchases, cash receipts, and cash

disbursements journals.

b. Registers are a subgroup of special journals that serve as logs of activities such as

payroll or receiving.

c. A general journal is used to initially record transactions for which there is no

special journal. These are typically nonrecurring or infrequent transactions.

As its name implies, it is general. Any number of accounts can be listed, one to a

line.

3. Ledgers serve as the filing/sorting mechanism of the system. Extracting

information from the journals would be very time consuming and probably very

inaccurate. The pieces of information in the parts of a journal entry are sorted, or

posted, to a second place that collects information about specific accounts. These

filing systems are the ledgers.

By using the ledger accounts to collect this information, a balance of an

account can be obtained without going through the entire journal. There are two basic

types of ledgers.

a. The general ledger collects information about the basic types of

accounts.

b. Subsidiary ledgers collect information about individual accounts of a similar type.

Each credit customer has an account in the accounts receivable subsidiary

ledger. The total of all customer accounts appears in the general

ledger in a control account. The control account and the subsidiary ledger must be

reconciled regularly.

This serves to double-check both the control account and the subledger.

B. The Audit Trail

The accounting records described previously provide an audit trail for tracing

transactions from source documents to the financial statements. Of the many

purposes of the audit trail, most important to accountants is the year-end audit. While

the study of financial auditing falls outside the scope of this text, the following

thumbnail sketch of the audit process will demonstrate the importance of the audit

trail.

The external auditor periodically evaluates the financial statements of publicly

held business organizations on behalf of its stockholders and other interested parties.

The 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 accounts receivable (AR) as

published in its annual financial statements. The auditor can trace the AR figure on

the balance sheet to the general ledger AR control account. This balance can then be

reconciled with the total for the AR 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. Following 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 that customers agree with the recorded balance.

Information contained in source documents and subsidiary accounts enables the

auditor to identify and locate customers chosen for confirmation. 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.

Because financial information

is communicated to interested parties

outside the organization, it is

important that such parties trust the

information that is reported. One

thing that creates confidence in

financial reports, especially annual

financial statements, is the opinion of

an independent, unbiased

professional that the statements are,

indeed, a fair presentation of the performance and financial state of the firm. In order

to arrive at a judgment, an “audit” is conducted–an extensive examination of the

accounting system and the inform ation in it–to yield an audit opinion. This audit

opinion is not conferred casually. A great deal of work is done examining the

financial system. The ability to trace an item on a financial statement all the way back

to the original entry in a jo urnal and further, to the source document, is referred to as

the audit trail. This is assisted in manual systems by the information recorded in the

“Post. Ref.” columns of journals and registers. The existence of an audit trail in an

automated system should not be assumed. It must be designed into the

system.

C. Computer-Based Systems

In this part of the chapter you are introduced to some basic file types used in a

computer-based system. These types refer to the nature of the information in the file,

not to the physical form the file takes. Study the different types. Their meanings may

become clearer as you study the material.

1. master file, which contains account data (e.g., the general ledger)

2. transaction file, which contains data on transactions which will update the master

file (e.g., a sales journal)

3. reference file, (a price list)

4. archive file, the record of past transactions (e.g., prior payroll period).

represents the relationship between the magnetic files in an audit trail. Use the

narrative to improve your understand ing of the way in which information can be

traced.

III. DOCUMENTATION TECHNIQUE

Any individuals who need to know how a system functions can be helped to

visualize the operation, by what are called documentation techniques. Your book

describes five of these. We will have a lot of immediate use for the first three, less for

the latter two, although they are used extensively in business. Often, your accounting

courses do not give students a good feel for the movement of data in the system.

A. Data Flow Diagrams

a sample of a data flow diagram (DFD) created using the symbols . This type

of diagram is very simple. Only four symbols are used. Only the flow of data is

shown, not the movement of paper, not the organizational unit(s) involved, and not

how the data is processed. DFDs are very good as a starting point for understanding

inform ation movement. They will provide an overview of the procedures that occur

in each of the subsystems of the transaction cycles to be discussed in later chap ters.

B. Entity-Relationship Diagrams

The representation of entities (which can be resources, events, and agents as

introduced in Chapter 1's discussion of the REA model), and the relationships

between them, is very important. the symbol set used in entity

relationship diagrams (ERDs). This figure also serves as a sample ERD for a sales

example. Read this material carefully. Recognize that the numbers at the nds of the

connecting lines indicate the nature of the relationship, one-to-one, one-to-many, or

many-tomany. The examples given in the book are very clear. Study them well. ERDs

will be used extensively later in the bo ok.

C. Flowcharts

The remaining three document types are all forms of flowcharts. Three flowcharts are

presented here: document, system, and program. Document and system flowcharts

have several characteristics in common. They use standard symbols [although each

type has its own set], are divided vertically according to organizational unit [we will

see later that this helps verify separation of duties–a key control technique], and use

special connector symbols to jump between points on a single page and from page to

page. These are used to minimize the mess that can result if flowlines cross each

other.

• As the name implies, document flow charts show the flow of documents, or

paper, through the system or part. In the example, a flowchart of a sales order

processing system is created. One concept that is introduced here is that of batch

processing. When a business has large groups of similar transactions, processing

them in batches is more efficient and more controllable than handling the transactions

individually. Think of how most people do laundry.

• System flowcharts are used to show the relationships between parts of a

system, namely inputs, processes, and outputs. Although typically used for computer-

based systems, they can be used to represent manual systems also. Several of these

represent the storage medium involved. This section walks through the process of

describing symbolically what happens in the sales order department.

• Each program shown in a system flowchart would be supported by a

program flowchart which shows the detail of processing.

IV. COMPUTER-BASED ACCOUNTING SYSTEMS

This last part of Chapter 2 introduces computer-based accounting systems,

beginning with the differences between the two basic types: batch systems and real-

time systems.

Batch processing permits the efficient management of a large volume of

transactions.A batch is a group of similar transactions (such as sales orders) that are

accumulated over time and then processed together. There are two general advantages

to batch processing. First, organizations improve efficiency by grouping together

large numbers of transactions into batches rather than processing each event

separately. Thus a business can achieve an efficient allocation of its processing

resources by employing specialized, cost-effective procedures to deal with these

batches. Batch processing is an economical method of high-volume transaction

processing.

Second, batch processing provides control over the transaction process. The

accuracy of the process can be established by periodically reconciling the batch

against the control figure. For example, assume that the total value of a batch of sales

orders is $100,000. This number can be recorded when the batch is first assembled

and then recalculated at various points during its processing. If an error occurs during

processing (for example, a sales order is lost), then the recalculated batch total will

not equal the original batch total and the problem will be detected.

Both of these advantages have implications for designing batch systems. The

first is that economies are derived from having batches that are as large as possible.

The cost of processing each transaction is reduced when the fixed costs of data

processing are allocated across a large number of transactions.

The second implication is that finding an error in a very large batch may prove

difficult. When a batch is small, error identification is much easier. In designing a

batch system, the accountant should seek a balance between the economic advantage

of large batches and the troubleshooting advantage of small batches. There is no

magic number for the size of a batch. This decision is based on a number of

operational, business, and economic factors. Among these are the volume of

transactions, the competitiveness of the industry, the normal frequency of errors, the

financial implications of an undetected error, and the costs of processing. Depending

on these factors, a system might process small batches (50 to 100 items) several times

a day or an entire day’s activity as a single batch.

A. Differences Between Batch and Real-time Systems

Real-time and batch processing

There are a number of differences between real-time and batch processing. These

are outlined below:

a. Each transaction in real-time processing is unique. It is not part of a

group of transactions, even though those transactions are processed in

the same manner. Transactions in real-time processing are stand-alone

both in the entry to the system and also in the handling of output.

b. Real-time processing requires the master file to be available more

often for updating and reference than batch processing. The database is

not accessible all of the time for batch processing.

c. Real-time processing has fewer errors than batch processing, as

transaction data is validated and entered immediately. With batch

processing, the data is organised and stored before the master file is

updated. Errors can occur during these steps.

d. Infrequent errors may occur in real-time processing; however, they are

often tolerated. It is not practical to shut down the system for

infrequent errors.

e. More computer operators are required in real-time processing, as the

operations are not centralised. It is more difficult to maintain a real-

time processing system than a batch processing system.

f. When decisions must be made between the two types of systems (later

chapters) we will consider two characteristics: response time (a

measure of the lag) and activity ratio (proportion of a file that is

processed each time the file is updated). These will help answer the

efficiency v. effectiveness issue.

B. Alternative Data Processing Approaches

Despite the availability of very modern information systems, many

organizations continue to use older systems. Early legacy systems were mainframe

based, batch oriented using flat-files. Newer legacy systems use databases. More

modern systems are network based and process data in real time. It is important

that accountants have an understanding of older system because they are still in use.

Section B of the chapter appendix provides a great discussion of legacy systems

including data structures and processing modes.

An excellent example is presented on updating master files from transactions

in the sales order system, which

shows sequential record structures for the hypothetical system. The labels (PK)

and (SK). (PK) refers to the primary key for the record–the piece of information that

uniquely identifies a record, e.g., your social security number is used by the

university to uniquely identify your records, not your name or anything else that

might have a duplicate. Try to follow the logic of the processing and not get lost in

the details. Anyone who uses a PC has experienced the loss ofdata when the “save”

command is given for a file that has changed. The new file replaces the old–which is

gone!

C. Batch Processing Using Real-Time Data Collection

One hybrid using the best of both worlds is to capture data in real-time and

process it in batches.This will walk through a sales order system. Follow the narrative

carefully. We will see much more about this and other parts of a system in later

chapters.

D. Real-Time Data Processing

What many people think of when computer processing is mentioned is a

situation in which data is captured live and processed immediately–in realtime.

This section of the chapter introduces the concepts of distributed processing and

network

CHARACTERISTICS OF VALUABLE INFORMATION.

In order for information to be valuable it must have the following characteristics, as

adapted from Ralph M. Stair's book, Principles of Information Systems:

1. Accurate. Accurate information is free from error.

2. Complete. Complete information contains all of the important facts.

3. Economical. Information should be relatively inexpensive to produce.

4. Flexible. Flexible information can be used for a variety of purposes, not just

one.

5. Reliable. Reliable information is dependable information.

6. Relevant. Relevant information is important to the decision-maker.

7. Simple. Information should be simple to find and understand.

8. Timely. Timely information is readily available when needed.

9. Verifiable. Verifiable information can be checked to make sure it is accurate.

Data processing folks like to talk about the "ACID test" when deciding

whether or not a database management system is adequate for handling transactions.

An adequate system has the following properties:

Atomicity

Results of a transaction's execution are either all committed or all rolled back.

All changes take effect, or none do. That means, for Joe User's money transfer, that

both his savings and checking balances are adjusted or neither are. For a Web content

management example, suppose that a user is editing a comment. A Web script tells

the database to "copy the old comment value to an audit table and update the live

table with the new text". If the hard drive fills up after the copy but before the update,

the audit table insertion will be rolled back.

Consistency

The database is transformed from one valid state to another valid state. This

defines a transaction as legal only if it obeys user-defined integrity constraints. Illegal

transactions aren't allowed and, if an integrity constraint can't be satisfied then the

transaction is rolled back. For example, suppose that you define a rule that postings in

a discussion forum table must be tied to a valid user ID. Then you hire Joe Novice to

write some admin pages. Joe writes a delete-user page that doesn't bother to check

whether or not the deletion will result in an orphaned discussion forum posting. The

DBMS will check, though, and abort any transaction that would result in you having a

discussion forum posting by a deleted user.

Isolation

The results of a transaction are invisible to other transactions until the

transaction is complete. For example, if you are running an accounting report at the

same time that Joe is transferring money, the accounting report program will either

see the balances before Joe transferred the money or after, but never the intermediate

state where checking has been credited but savings not yet debited.

Durability

Once committed (completed), the results of a transaction are permanent and

survive future system and media failures. If the airline reservation system computer

gives you seat 22A and crashes a millisecond later, it won't have forgotten that you

are sitting in 22A and also give it to someone else. Furthermore, if a programmer

spills coffee into a disk drive, it will be possible to install a new disk and recover the

transactions up to the coffee spill, showing that you had seat 22A.

Database design and the creation of an entity relationship diagram (also

known as an "ERD" or data model) is an important yet sometimes overlooked part of

the application development lifecycle. An accurate and up-to-date data model can

serve as an important reference tool for DBAs, developers, and other members of a

JAD (joint application development) team. The process of creating a data model helps

the team uncover additional questions to ask of end users. Effective database design

also allows the team to develop applications that perform well from the beginning. By

building quality into the project, the team reduces the overall time it takes to complete

the project, which in turn reduces project development costs. The central theme

behind database design is to "measure twice, cut once".

Effective database designers will keep in mind the principles of normalization

while they design a database. Normalization is a database design approach that seeks

the following four objectives:

1. minimization of data redundancy,

2. minimization of data restructuring,

3. minimization of I/O by reduction of transaction sizes, and

4. enforcement of referential integrity.

The following concepts and techniques are important to keep in mind when designing

an effective database:

1. An entity is a logical collection of things that are relevant to your database.

The physical counterpart of an entity is a database table. Name your entities in

singular form and in ALL CAPS. For example, an entity that contains data

about your company's employees would be named EMPLOYEE.

2. An attribute is a descriptive or quantitative characteristic of an entity. The

physical counterpart of an attribute is a database column (or field). Name your

attributes in singular form with either Initial Capital Letters or in all lower

case. For example, some attribute names for your EMPLOYEE entity might

be: EmployeeId (or employee_id) and BirthDate (or birthdate).

3. A primary key is an attribute (or combination of attributes) that uniquely

identify each instance of an entity. A primary key cannot be null and the value

assigned to a primary key should not change over time. A primary key also

needs to be efficient. For example, a primary key that is associated with an

INTEGER datatype will be more efficient than one that is associated with a

CHAR datatype. Primary keys should also be non-intelligent; that is, their

values should be assigned arbitrarily without any hidden meaning. Sometimes

none of the attributes of an entity are sufficient to meet the criteria of an

effective primary key. In this case the database designer is best served by

creating an "artificial" primary key.

4. A relationship is a logical link between two entities. A relationship represents

a business rule and can be expressed as a verb phrase. Most relationships

between entities are of the "one-to-many" type in which one instance of the

parent entity relates to many instances of the child entity. For example, the

relationship between EMPLOYEE and STORE_LOCATION would be

represented as: one STORE_LOCATION (parent entity) employs many

EMPLOYEEs (child entity).

5. The second type of relationship is the "many-to-many" relationship. In a

"many-to-many" relationship, many instances of one entity relate to many

instances of the other entity. "Many-to-many" relationships need to be

resolved in order to avoid data redundancy. "Many-to-many" relationships

may be resolved by creating an intermediate entity known as a cross-reference

(or XREF) entity. The XREF entity is made up of the primary keys from both

of the two original entities. Both of the two original entities become parent

entities of the XREF entity. Thus, the "many-to-many" relationship becomes

resolved as two "one-to-many" relationships. For example, the "many-to-

many" relationship of (many) EMPLOYEEs are assigned (many) TASKs can

be resolved by creating a new entity named EMPLOYEE_TASK. This

resolves the "many-to-many" relationship by creating two separate "one-to-

many" relationships. The two "one-to-many" relationships are EMPLOYEE

(parent entity) is assigned EMPLOYEE_TASK (child entity) and TASK

(parent entity) is assigned to EMPLOYEE_TASK (child entity).

6. A "foreign key" exists when the primary key of a parent entity exists in a child

entity. A foreign key requires that values must be present in the parent entity

before like values may be inserted in the child entity. The concept of

maintaining foreign keys is known as "referential integrity".

7. Relationships between two entities may be classified as being either

"identifying" or "non-identifying". Identifying relationships exist when the

primary key of the parent entity is included in the primary key of the child

entity. On the other hand, a non-identifying relationship exists when the

primary key of the parent entity is included in the child entity but not as part

of the child entity's primary key. In addition, non-identifying relationships

may be further classified as being either "mandatory" or "non-mandatory". A

mandatory non-identifying relationship exists when the value in the child table

cannot be null. On the other hand, a non-mandatory non-identifying

relationship exists when the value in the child table can be null.

8. Cardinality helps us further understand the nature of the relationship between

the child entity and the parent entity. The cardinality of a relationship may be

determined by asking the following question: "How many instances of the

child entity relate to each instance of the parent entity?". There are four types

of cardinality: (1.) One to zero or more (common cardinality), (2.) One to one

or more (P cardinality), (3.) One to zero or one (Z cardinality), and (4.) One to

exactly N (N cardinality)

Effective database design can help the development team reduce overall

development time and costs. Undertaking the process of database design and creating

a data model helps the team better understand the user's requirements and thus

enables them to build a system that is more reflective of the user's requirements and

business rules.

V. CONCLUSION

Database Systems and the Future of Accounting

o Database systems may affect the fundamental nature of accounting as follows:

Database systems may lead to the abandonment of the double-entry accounting

model.

o The basic rationale for the double-entry model is that the redundancy of

recording the amount of a transaction twice provides a check on the accuracy of

data processing.

o Data redundancy is the antithesis of the database concept.

o If the amounts associated with a transaction are entered into a database system

correctly, then it is necessary to store them only once, not twice. Database

systems also have the potential to significantly alter the nature of external

reporting. For example, a company can make a copy of its financial database

and make it available to external users.

o External users would then be free to manipulate and analyze the raw data in

whatever manner they see fit. The most significant effect of database systems

will be in the way accounting information is used in decision making.

o For example, relational databases provide query languages that are powerful and

easy to use.

o Thus managers can concentrate solely on specifying what information they

want.

o As a result, financial reports can be easily prepared to cover whatever time

periods managers want to examine, not just the time frames accountants

traditionally use. Finally, relational DBMSs provide the capability of integrating

financial and operational data.

o For example, data about customer satisfaction should be stored in the same

database used to store information about current balances and credit limits.

o In this case managers would have access to a case, richer set of data for making

tactical and strategic decisions

Accountants must become knowledgeable about database systems so that they can

participate in designing the accounting information systems of the future.

References

Hall, James., Introduction to Transaction Processing, USA: Accounting Information System, 6e., 2008

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

http://philip.greenspun.com/sql/introduction.html accessed on March 4th 2011

http://www.aisintl.com/case/library/R-Theory_vs_ER/r-theory_vs_er6.html accessed

on March 4th 2011

http://www.referenceforbusiness.com/management/Comp-De/Data-Processing-and-

Data-Management.html#ixzz1FaNegoLu accessed on March 5th 2011