Introduction To Transaction Processing
Introduction To Transaction Processing
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 )
ABSTRACT
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
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).
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.
There are a number of differences between real-time and batch processing. These
are outlined below:
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:
The following concepts and techniques are important to keep in mind when designing
an effective database:
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
http://en.wikipedia.org/wiki/Transaction_processing_system
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