There is always some discussion about the benefits of batch versus interactive updating of the GL and subsidiary ledgers. With batch updating, a user can access the system data at any time of the day – between updating runs – and be assured of consistent information. With interactive updating, the system is as up-to-date as the latest information that has been entered. In our view, there is no right answer. Even those organizations which prefer batch updating want the ease of use of interactive updating when month-end is looming and conversely, those organizations that prefer interactive updating often wish for a means to “freeze things” until a problem is resolved.
All transactions that have financial implications are presented to the system in the form of GL transactions. The format of these transactions is defined by the GL transaction table definition – GL.
An individual application area accepts data in a form of a transaction that is appropriate to that application. For example, the Accounts Payable application accepts invoice transactions in the form defined by the files AP011, AP021, AP031 and AP033. These transactions are batched examined by the user until the decision is made to process them through the GL system.
The steps involved in processing are:
Process the batch of transaction by marking the batch and the transactions available for processing by the GL system. Note that the transactions don't move; a status flag is changed to indicate this change in status.
All the available transactions are processed. In this step, the transaction details are read and GL transactions are generated. As each AP transaction is processed, it is marked so that it cannot be processed again. The GL transactions are placed in a pool of transactions that are available for processing by the GL system.
Depending on the settings of the company master, a GL processing run may be automatically triggered or the GL transactions may be left until the supervisor of the accounting process decides to perform one.
When the GL processing run is performed, the GL transactions that are available are processed by a series of programs that update the GL master, the GL summary tables, and the various tables for each application area.
The flow in the GL updating process is shown below:
The choice of which of these two programs (GLPOST1 or GLPOST2) are called depends on whether the transactions are being posted in Batch or Interactive mode. Whichever is used, calls GLPOST3.
This program deals with each transaction – one at a time – and updates the GL balance table. In addition it sends the transaction to the GL subsidiary ledger table update programs that are required. The program determines which modules are required by looking up each GL entry in the GL Definition Table (GLDEF) and using the flags that are set by the user to indicate the subsystems being used. For example, a transaction that has a debit GL code that is flagged for Job Cost and Contract Management will trigger a call to the routines that process these subsystems. Similarly if the credit GL code is flagged for Accounts Payable, that routine will be called. Note that the individual transaction is passed as a parameter to each of these routines. While less efficient than “batching” all the data, it facilitates interactive updating.
These programs update the subsidiary ledgers and the various summary report files that are deemed necessary for the efficient use of the application. Each application area has a customized routine which is called by the GL Transaction Handler. Each routine deals with a single transaction at a time.