Development of Accounting Information System: Enterprise, Database and Interface Modules!
A number of accounting software packages are available offering a variety of features. They cost much less than what customized accounting software would cost. However, these software packages offer only the structure for accounting information systems. At the most, they reduce the programming effort for accounting information systems.
The development of accounting information systems is much more than the software for ledger posting and report formation. It also involves establishing procedures for capturing data and distribution, as well as analysis of
accounting information.
The development of an accounting information system is explained with special reference to the requirements of a medium to large sized business enterprise. However, these steps would be common to most other information systems in a business enterprise.
1. Enterprise Module:
The enterprise module of information system development involves
identification of basic entities and their interrelationships, identification of basic activities and regrouping these activities into sub systems. Then, the priorities are decided on the basis of cost-benefit analysis for the enterprise.
Identifying Entities:
elementary entities. Kerner5 points out six basic entities in a business
enterprise.
They are customers, products, vendors, personnel, facilities and money. In an accounting information system, there are three basic entities, namely,
transactions, account and processing period. The interrelationships between these entities can be expressed using the E-R diagrams as shown Fig. 8.2.
The transactions shall be of different kinds, such as receipts, payments, sales, purchase, acquisition of assets or repayment of liabilities, etc. and each of them can be called a lower level entity. Similarly, accounts can be of different kinds, such as assets, liabilities, revenue and expense.
The entities are identified in the light of and with a view to defining the scope and focus of the information system. For example, if the information system is being viewed as a strategic information system, the broad entities shall be identified in the light of the strategic thrusts that the enterprise plans to give to its activities with the help of the information system.
These thrusts could be cost minimisation, customer service, product
differentiation and strategic alliances. The basic entities in such a case would be customers, channels, competing enterprises, products, etc.
Activity Analysis:
Another important aspect of enterprise module is identification of activities associated with the entities. These activities are broadly identified in the form of relationships in the E-R diagrams. However, details are obtained with the help of activity analysis. The existing organisation structure is an important source of information regarding the broad activities undertaken by the enterprise.
But, in order to develop information systems that are independent of the current organisation structure, it is essential to base the activity analysis on the basic entities already identified above. The next level of activity analysis involves identification of the life-cycle activities. In the case of ‘transactions’ being one of the basic entities in an accounting information system, there are four broad life-cycle activities, namely:
1. Purchasing life cycle
3. Revenue life cycle
4. Investments life cycle
Similarly, the processing period has two basic life cycle activities, namely:
a. Planning and control life cycle
b. Internal and external reporting life cycle
These life cycle activities are on-going activities and are performed
continuously. Each of these activities may be sequentially related to some other activities. The third level of activity analysis involves splitting of the life-cycle activities into functions.
For example, each type of transaction must be initiated and recognised; then the data regarding the transaction must be captured, coded for future clas-sification, classified, summarised and reported. These functions are to be performed differently for different types of transactions. The process of defining the functions focuses only on those activities that create, update or use information in the database of the enterprise.
At this level of activity analysis, the activities are self contained, have clearly defined starting and ending events or nodes and an identifiable person or a group of persons responsible for performing the function.
For example, the function of classification of captured data may be performed in purchasing and marketing life cycles. Such activity analysis helps in
identifying opportunities to improve the existing design by:
1. eliminating the redundant functions
2. combining the duplicated functions
3. simplifying and improving the processing methods
The redundancy can be identified by careful analysis of the activities. The activities that are likely to offer opportunities for improving the processing include activities:
a. That are performed elsewhere as well
b. That can be combined with other activities
c. That can be handled by some other person as well
d. That can be performed at some other stage of the life cycle that do not add any value to the product or service of the information system.
A word of caution here is that not all redundancies are bad. In fact, some redundancy or duplication may be intentionally allowed to creep into the system. This may be done in order to improve performance and reliability of the system.
For example, some of the duplication may be necessary for ensuring
reliability. The risk of unexpected implications and low returns from proposed new method or procedure are other factors that deserve attention before changes are proposed in the information system.
Grouping Activities into Sub Systems:
After the activities are defined using the top-down approach adopted above, they are regrouped to form sub systems. An important decision to be taken at this stage relates to the basis of grouping. There may not exist one single objective criterion for deciding which sub system an activity belongs to.
The present organisation structure can provide one of the bases for grouping of activities. But, the present organisation structure may undergo changes and the usefulness of the information system may be lost.
To group the activities into sub system, we take help from the organisation theory.One of the essential features of any good organisation structure is that it aims at facilitating coordination of activities.
An effective system of communication is essential requisite for better
coordination. It is essential, therefore, to group activities in such a way so that communication is facilitated within the group and the need for inter-group communication is minimised.
Similar structure charts can be prepared for other clusters of activities and, finally, these sub systems are integrated with each other providing the building blocks for an accounting information system.
The sub systems so identified by clustering of activities are serious
contenders for being entities in the organisation structure. The advantage with the clustering method for grouping of activities is that the grouping is based on functions and resources, and not on geographical regions.
Such a clustering on the basis of functions ensures homogeneity among the members of the group of people associated with each of the sub systems. Impact of information system organisation on organisation structure is not un-common.
Often, introduction of information systems has been accompanied by changes in the organisation structures because of the fact that new information
It is, therefore, all the more important that information system designers work in active association with the organisation development people while grouping of activities into clusters and sub system is being done. This ensures not only that the new structure is more pragmatic but also more acceptable to people. In such cases, the transition from old system to new one is less painful and less expensive.
Setting priorities:
Once the sub systems have been identified and integrated as a whole, the priorities need to be determined among the various sub systems and features in each system. The information system would require commitment of financial resources.
In addition, there may be implicit costs of the new system in terms of
necessary changes in the process of operations. It is, therefore, essential to weigh the pros and cons of each sub system and sub- subsystem before they are designed and implemented.
Each sub system is evaluated on the basis of well-defined evaluation criteria defined in terms of the critical success factors (CSF). These factors have already been identified in Section 8.2.
The other method is, brainstorming, wherein the relevant people in the
organisation get together to identify the factors that deserve consideration in determining priorities. Free flow of ideas is encouraged at the first stage.
The underlying principle, here, is that no idea is silly or irrelevant at this stage. During the second stage, the process of elimination begins and after
Once the list of factors is finalised, relative weights are assigned and a criterion’s function is defined to evaluate each component of the proposed accounting information system.
2. Database Module:
Accounting information system processes large volume of data. Managing the data is, thus, one of the major considerations in the process of its
development. There are two basic approaches to data design, namely:
a. The traditional, application oriented approach, and
b. The database approach.
Traditional approach:
The traditional approach to data design is application oriented in the sense that for each application a separate set of data files is generated as per its requirements. In other words, the data files are dedicated to a given
application and are in a way ‘owned’ by the application.
For example, an account receivables application shall have the customer master data file, a sales transaction file and a receipt from customers’ transactions file. These data files are used only for the accounts receivable application.
The fundamental problem with the traditional approach is that the application programs are dependent on the data files they use and manipulate. As a consequence, any change in the data file (in terms of addition or deletion of data item) necessitates changes in all the programs using the data file.
This data dependency discourages changes in data files leading to inflexibility. In the absence of any tool for performing routine type data management ac-tivities on the data, such facilities are to be included in the programs using the data file. This complicates the program. Another problem relates to meeting the ad hoc query.
For unexpected kind of query, special programs need to be written. Such special programs take time to develop and have only one time use and thus, are expensive. There is a lot of duplication in recording of data items.
The data redundancy results in inefficient use of storage media. It also affects the quality of data as updating of a given data item may not take place in all the files where that data item is stored.
Database approach:
The modern approach to data design is database approach. This approach is based on the assumptions that several applications require data sets that have a lot in common. It is, therefore, better to have a common repository of data that meets the data requirements of each application in the information system.
The common repository is called the database and is managed by a
management system called Database Management System (DBMS). The DBMS is software specially designed to manage the data in databases according to the requests from application programs, as well as from those coming directly from users. The conceptual design of database environment is shown with the help of Fig. 8.5.
The database approach takes care of the problems of the applications
not bother about the location of the data in database. A data dictionary is maintained and data can be called using the words specified in the data dictionary.
The database approach also reduces the size and complexity of the
application programs as the routine kind of data processing operations such as sorting is done by the DBMS. The DBMS is also used for serving the needs of ad hoc query. The DBMS uses Structured Query Language (SQL) as the language for communication between the user and the database.
The language is very simple and quite close to English. This ensures that the user can get information from database as and when required. The amount of training required by managers for making ad hoc queries is minimal and few hours of training can provide the elementary skills for using the language. Perhaps, the most important advantage of database approach is the reduction in the redundancy in databases.
There are many models that are commonly used in design of databases. However, the modern approach is to follow the E-R Model of data base
design. This approach is top-down approach and the E-R charts drawn earlier in the Enterprise Module become the starting point.
For each entity and relationship, attributes are identified and documented in the Extended E-R diagrams (EER diagrams). In an accounting information system, the EER may be drawn for each entity (transaction and accounts) and the relationship (effect) for the transaction accounts is shown in the E-R
These attributes become the data items (fields) in a record in the data file for each entity (in this case sales transaction file). Similarly, for other entities and relationships such Extended E-R (EER) diagrams are drawn.
Once these attributes are identified, it is likely that some of the attributes shall be common in different EER charts. To avoid duplication of such common attributes, normalisation of data is undertaken.
3. Interface Module:
In other words, the module is concerned with defining the interface between the user and machine. The importance of the interface module has increased due to increased communication between user and information systems.
Both the data entry and data query have become interactive. In many cases, input forms are eliminated from the process and the data entry takes place directly. The changing requirements of data query render many report forms too rigid. Interactive report screens provide greater flexibility in data query and permit user defined report formats for viewing and printing.
Input screens:
The input screens are defined in the light of natural process of the business activity. Therefore, they depend primarily on the forms that are used to record manually the data when they are first received by the enterprise. These forms, in an accounting information system, may include invoice, purchase order, sales order, expense voucher, etc.
Thus, in the interface module, forms are also reviewed; redesigned and input screens are defined in the light of forms used by the enterprise. In an
accounting information system, one needs to be more careful regarding screen design.
A minor improvement in input screen that saves data entry may result in substantial savings because the number of times the data entry screen is used is very large. The following factors may be kept in mind while designing input screen:
The input screen format must match with input forms. Sometimes, it pays to adopt the same format that is used by the input form. To the extent possible, even the colour of the background of screen may be matched with the colour of the input form.
(b) Interactive:
The input screen should be interactive. It should point out errors in data entry right at the time of entry and permit corrections. Each data item must have some data validation condition and any violation of such data validation condition should be automatically highlighted at the time of data entry.
For example, a data entry screen for entry of invoice must point out mistake in entry of date if the date is invalid. The date may be invalid because it is
outside the accounting period or the month entered is greater than twelve.
(c) Consistency:
The input screens should be consistent in defining terms and location for certain common types of data items. It helps in reducing the training time as it improves familiarity; for example, date of transaction may always be placed on the right hand corner of each of the transaction document.
(d) Simplicity:
One of the basic features of a good input screen is the simplicity. Too many highlighted sections, blinking of values or attributes, or putting too many boxes and underlining only add to complexity and confusion. Sometimes, beeps are used to point out data entry errors. There should be judicious use of such beeps and generally, these should be avoided.
The input screen should be amenable to modifications. It should permit users to make modifications in terms of addition or deletion and relocation of data item. The procedure for modification should be simple. These days, the Screen Generators available from various software manufactures offer the features such as drag and fix/drop any data item from the screen by using ordinary pointing device like mouse.
(f) Custom made:
The screens must be custom made for each category of user. This would reduce unduly long starting and entry procedures.
Report screens:
The reports may be prepared for further analysis by some other computer program or by the user himself. The data directed for processing by computer programs, such as spreadsheets, statistical packages, word processors, are kept in data files.
It is better to put them in standard data format so that they can be accessed easily. The reports meant for users are normally kept in the form of text, tables, and graphs. Efforts should be made to ensure that the reports are made out and communicated timely, accurately, clearly and at a low cost.
Dialogue screens:
The dialogue screens are the ones that are used for identifying and
performing the tasks in the information system. They define what can be done with the help of the information system, how to navigate from one
These screens should be simple and unambiguous. The simplicity can be introduced by providing Graphic User Interface (GUI) and having limited number of menu items in one screen. The procedure for navigation from one menu to the other should be simple, in right sequence and easy to follow. It should also point out mistake in exercising options and be prompt for
correcting procedure.
CASE tools for screen design:
A variety of CASE tools are available for designing forms, screens and
reports.These tools have the advantage of offering designing environment that is flexible and simple to understand even for a new user.
Since these tools have screen prototyping facilities, it is possible to have greater involvement of users in the process of screen designing. Of course, such tools permit quick changes and improve productivity of programmers by generating codes for final implementation. This results in reduced
development time.
Once the forms, input/output screens and dialog screens are ready, they should be tested and modified accordingly. The forms and screens designed using the CASE tools can be easily modified. Therefore, efforts must be made to improve the acceptability of the system by proper testing and modification of forms and screens.
4. Applications Module:
In other words, the application module is primarily concerned with the
processes involved in converting the input data into values that shall form part of the reports as defined in the interface module. It may be noted that only those processes are to be defined that
(a) Change the values in the databases, or
(b) That are not parts of the database but are required in the reports defined in the interface module.
The values that already exist in the database can be accessed using DBMS query language as per the requirement of users without development of
programs for this purpose. Thus, the task of application module is reduced by the work already performed in the database design and screen design.
Data flow diagram:
The role of the manager in this module is basically identifying the basic processing procedure. The detailed algorithms are generally defined and documented by information system professional, of course, with active help from the manager.
The tool used for expressing the processes to be performed for converting the input data into output is the Data Flow Diagram (DFD). It describes the flow of data. It defines what must be done and ignores how it is to be done or how it was being done earlier. This approach permits changes in the system and weaknesses of the existing system can be removed following this approach.
DFD symbols:
(i) Terminator:
Terminator is an external source of data flow or external sink of data. It is an external entity or object such as customer, vendor, shareholders, etc. Since the terminators are external entities, the communication between the termina-tors is excluded from the system. The terminator is symbolised by a rectangle (generally, shadowed) and the label is placed in the rectangle.
(ii) Data flow:
Data flow carries a series of data items regarding the event that is initiated by the terminator. It is symbolised with an arrow in DFD and the direction of the flow is indicated by the direction of the arrow. The arrows are, generally, labelled unless they are directed to or from data files. As pointed out earlier, data flows between two terminators are not included in DFD and thus, data cannot flow directly between two terminators.
(iii) Process:
Process transforms the incoming data for redirection to data store or
terminator. It is symbolised by a rectangle with rounded corners or a circle. It is labelled with a verb, of course.
(iv) Data store:
It may be noted that some supplementary symbols and minor variations in symbols representing various components of DFD are also in use. The above symbols are the ones most commonly used and are as per the graphic
convention suggested by Gane and Sarson.
Many a time, a manager finds drawing of DFD very difficult and frustrating experience. Each time one draws a DFD, one finds to have ignored one or the other aspect of the data flow. Fortunately, the CASE tools available have facilities for creating and modifying DFDs. However, beginners are advised to follow the following steps to overcome this problem:
(a) Identify all input data flows and output data flows separately along with terminators, putting input data flows on left side and output data flow on right.
(b) Label the terminators using data flow noun or adjective names.
(c) Identify processes forward from input data flows and backward from output data flows till they meet in the middle.
(d) Label the processes using verb names.
involvement at this stage is very useful not only in reducing the effort on the part of manager but also in improving the DFD.
Testing of DFD:
It is suggested that the DFD must be thoroughly tested before it is finalised. The following are some of the common errors in DFD design:
a. The terminator label may be the name of a person or an enterprise instead of class. For example, a terminator may be labelled as M/s. B. R. Ltd. instead of sole vendor. Another mistake could be that the carrier is put as terminator instead of the external entity directly associated with the data flow.
b. Data may flow directly from one terminator to another terminator.
c. No data flow may be indicated to or from a process.
d. Data flow is indicated from terminator to a data store (file) or from a file to terminator, or between two files without processing.
e. The processes are labelled as objects, such as invoice or a noun such as booking clerk.
After the DFDs are drawn for each sub system, future processing details may be chalked out and described in structured English (psedo-codes). These psedo-codes are later used for coding the applications. The manager’s role in this process is limited only to helping the information systems professional in identifying and understanding the algorithms involved in the processing.
This module is primarily concerned with testing of the system, training the users and installation of the system.
Testing the System:
The testing of various modules is done at various stages of development process. The golden rule to be kept in mind while testing is that the testing should be done with a view to identifying the ways in which the system is likely to fail. It should not be with the objective of proving that the system will work as per the design specification. Testing of system is the process of seeking answers to two basic questions:
1. Whether the information system serves the information needs of the enterprise? The process that seeks answer to this question is termed by information system professionals as system validation process.
2. Does the information system function correctly? The process of verification seeks answer to this question.
As the nature and degree of seriousness of errors are different at different stages of system development, different tests are administered at different modules and at the system as a whole.
Unit test:
The tests used at module level may be called unit tests. These tests are performed to detect errors in interfaces, databases, arithmetic operations and control logic. They are performed by running a module of the information system on test data specially designed for testing whether the system:
b. Accepts out of valid range data (e.g. accepts date with month greater than 12);
c. Causes incorrect jumping from a procedure to another procedure.
System test:
As the unit tests are conducted in isolation, it is essential that the integration tests should be conducted to check whether or not these units work correctly as a group. Due to diversities of nature of errors different testing strategies are to be followed to check validity and verify the system. Fertucksuggests three strategies for testing the information system:
(a) Clear box testing:
In this strategy, tests are designed to establish whether the procedures followed for processing match the requirements of the application. This may be achieved with the help of review by fellow information system professionals who were not directly associated at the development stage.
Alternatively, structured walkthrough method may be used. In this method, a group of persons reviews the procedures, first having a look at error-prone parts and identifies corrections that need to be made. Then, the group
members assess the output that the system will offer for a given type of input and test whether the output of the system is correct or not.
(b) Black box testing:
value for quantity ordered or a fractional value for a variable that can take only whole value.
(c) Ticking box testing:
This strategy assumes that it is never possible to deliver a totally error-free information system. Thus, after all testing and modifications, it is necessary to estimate the number of errors still remaining in the system. To estimate this number, a few errors may be deliberately introduced in the system. Then the tests are again conducted to detect errors.
The proportion of introduced errors detected is taken as an estimate of proportion of real errors detected during the earlier tests. Thus, if 90% of the introduced errors were detected during the ticking box testing while a total of 450 errors were detected originally during the clear box testing and black box testing, it means that 50 real errors continue to remain undetected in the system.
Installation:
Installation is a process of replacing the old system with a new system. Broadly, there are four approaches to installation. The ‘cold’ installation is done when the old system is immediately discontinued and is replaced by a new system.
this approach has not been found acceptable. The alternative approaches include:
(a) Pilot installation:
A system may be installed for use only by a select representative user group that tests the system by actually using it. Other users continue to use old system. When the problems in the system are taken care of, other users also start using the system. This approach also is not very popular for accounting information systems because the entire accounting database must be updated before it can be used by users.
The user’s information requirements cross the boundaries of department and divisions in the organisation chart. However, this approach may be used for complete accounting entities such as branch, regional office, etc. Thus, an accounting information system may be used by selected branches. Once they are found to be error free, they may be used by other branches as well.
(b) Phase-in installation:
Under this approach, the installation takes place in stages. These stages are independent components of the information system. So, the revenue life cycle of an accounting information system may be first installed and other life cycles may follow one after the other. This approach helps in focusing on a selected part of the system. It helps in improving the acceptability of the system among users because it enables the user to cope up with change easily.
(c) Parallel installation:
This method is most popular for accounting information system because this is the safest of all other methods. The only difficulty, here, is the cost of
parallel run and the tendency to extend the period of parallel run by those who resist change.
Post Implementation Review:
