During Live Operations, pulldown menus provide access to functions used for day-to-day operation of the system.
Daily transaction processing follows a three-step procedure:
- Transaction entry;
- Journal printing (necessary for the audit trail);
- Transaction posting (updating permanent files).
Entry of data occurs in groups, or batches, called "Control Groups", which you should review prior to posting them to your master files. These groups are identified by user ID and "control number", which allows each operator to process transactions separately from other operators (see Transaction Control Options for a discussion of various options available for controlling batches). The system performs validation checks on all transactions when they are entered.
After transaction entry, each control group must be printed on a journal before it can be posted. The journals should be reviewed or edited by the operator, or someone else in the department who can verify the entered data. Save the journals; they are an important part of your audit trail.
During journal printing, the system performs validation checks on the transaction data to ensure that it can be posted correctly. Errors and warnings may be printed on the journal and summarized at the end of the journal. A control group that prints with errors will not be allowed to post until the errors are corrected and the journal is reprinted without error. This process ensures that data is verified twice prior to being posted to permanent master files, and gives added assurance that erroneously entered data will not be posted.
Journal printing may also produce a "journal summary" which details the total dollar amount to be posted to each General Ledger account.
Once transactions have been entered and the journal has been printed and verified, the control group is ready to be posted to your permanent master/holding files. This process usually involves adding records to one or more system-maintained detail files, and summarizing the detail for historical records. Each transaction is deleted after it has been posted. Any errors encountered will be printed on an error log.
Modification logs provide an additional degree of audit control by recording who makes changes to master files, and when such changes are made. For example, when records are added to a file, all new field contents are shown; when records are deleted, the key value and all field contents are provided; when changes are made, old field contents and new field contents are shown. In all cases, the user ID of the individual who performed the maintenance is printed, along with the date and time of the change.
In the Live Operations phase of all APPX applications, modification logs are optional. A modification log for a specific file occurs only if a modification log name is present in the file maintenance function for that file in Application Design. Modification log names are initially present but may be removed by an application designer. Modification logs are not applicable in the Initial Setup phase of an application whereas modification logs are always provided in the Recovery Processing phase.