Features of the AERIS/400 General Ledger include:
All transactions are validated during input and by the Edit List to ensure they are complete and apply only to valid accounts. Only error-free, balanced batches for which a Batch Register was printed can be posted.Transactions, including batches received from other applications can be modified at any time prior to posting. Correcting transactions can be posted to any active period.
The General Ledger system can be simple to operate and very effective. However, some thought is required in order to use the features of the system effectively. This section provides a guideline for successful use of the basic functions of the system.
All manual entry of transactions is done through this one function. Transactions may come into the General Ledger from other systems. These are accepted as batches which must be balanced and listed before posting. They can also be edited before posting. The general procedure to enter transactions to the General Ledger is:
The General Ledger system has been generalized to incorporate multi-level management reporting. This is done by defining the corporate structure in a series of codes prefixed to the specific cost account code. In effect each unit of the organization has its own chart of accounts for detail reporting. By establishing a consistent set of account numbers from which each unit selects only the accounts relevant to itself, it becomes very easy to assemble consolidated reports. When higher levels of corporate management want a consolidated report, it is a relatively simple matter to redo the basic report at the appropriate level ignoring all lower levels of breakdown.
The fully unique Account Number is composed of eight elements. The Account Code was designed for a multi-level reporting structure. Up to five corporate reporting levels can be used with the basic Control Account code. Provision is also made for two levels of sub-account code. Only the desired reporting levels need to be used. Operationally, the units of the Account Code are identified as follows:
Level | Field | Length | Notes |
---|---|---|---|
1 | Company | 2 | |
2 | Group | 2 | |
3 | Division | 2 | |
4 | Location, Department | 3 | |
5 | Branch, Territory | 3 | The lowest level of management responsibility. |
6 | Control Account | 4 | The conventional breakdown for accounting allocations. |
7 | Detail | 3 | A finer division of allocations than is normally reported on the balance sheet or income statement. |
8 | Sub-Detail | 3 |
The input of the account number conventionally provides a default consisting of the last account number entered. An initial default is provided as a Company parameter. The cursor is usually positioned at the first element after the designated paging element, however the two are defined independently.
An organization need only use as many sub-units as are useful to it. For example, a small company may only use Territory and Account. In this case, the Page Break in the company parameters is set to 5, the Territory, and the Position Cursor is set to 6, the Account. As a result, a page break occurs on Territory. The full Account Number appears on inputs, however most of it can be ignored because the cursor is positioned at Account which is usually the only element to be changed.
Each element of the Account Number is associated with a Code Table identified by the element numbers, e.g. Department is associated with Code Table 4. By completing the tables, meaningful names will appear with each report total line. This adds considerably to the clarity of reports - particularly consolidated reports.
In the General Ledger (Application code G) the Table Ids 1 through 8 are reserved for the elements of the Account Number. The Table Header, Table Id = * and Code = element number, must be in place for subheadings and totals to appear on reports and the element to be edited when an account is added. If the Cross Reference is "NO" the subheadings and totals will not print but the element will still be edited. The subheading and totals for one element value is suppressed by setting the Cross Reference for that value to "NO".
When the code table for an element is in place, the value for that element must be one of the defined values when the Account Number is added. If a value of an element is retired after an Account Number is created it does not affect the validity of the Account Number.
Accounts are classified as assets, liabilities, incomes, or expenses. The account type does not affect the debit/credit relationship for amounts. Incomes and liabilities require a clearing account which is used only in the year-end processing.
A monthly budget is maintained independent of the Account Master. The budget is updated through a separate update. The maximum budget per month for an account is $10 million.
A generalized financial statement function is incorporated into the General Ledger system to provide ad hoc reports in a familiar accounting format. It provides extended flexibility in combining account information so that most financial reports for the organization can be produced on the computer. It can also be used to compensate for inconsistent account numbering in management reporting.
Financial statement generation is a two phase process. The first phase is to define the composition of lines to appear on the report. Once a set of lines have been defined they are stored and can be recalled at any time. The second phase is to set up and produce the actual report. The reports are of a semi-fixed format. During setup a predefined set of lines is identified as the base for the report. The contents of many report formats are either current month, or year-to-date and each line shows the corresponding totals for this year, last year, and budget. Once the report is set up it is printed immediately. The setup is not stored, so it must be redone each time the report is to be printed. The line of the report must be constructed in detail. A line is of one of several types:
A detail line may be printed on the report, or may only exist to define part of the contents of the subsequent total line. The sequence of detail lines need not bear any relation to the Chart of Accounts.
Detail lines define account ranges -- if a new account is added in a range defined for a detail line, it will automatically be included the next time the report is run. When a new account is added to the Chart of Accounts, every report that it will affect is in effect updated immediately.
Extra work is required only when the new account is not part of any defined range on a report, or it is not reported in the range that includes it now. In this case the existing single line would have to be replaced by two or more lines -- one for the range below the new account and one for the range above the new account.
Every accounting activity is represented in the General Ledger system by a detail transaction. Each transaction is in effect a one-sided assignment of funds. To assure that the overall General Ledger remains in balance, batches must be zero balanced before they can be posted to the General Ledger. For audit trial purposes, the system requires at least one Batch Register be printed after the last entry or change is made and the batch is in balance, and before the batch can be posted.
Each batch is assigned to an accounting period. All transactions in the batch are posted to that period independent of their effective date. Effective date reporting is available through queries to the detail Transaction History.
A batch can be assigned to any defined accounting period. Normally only 12 periods are used per year, however the database design does not contain any such restriction.
You can manage which periods are open and when through the use of the Period Status. The periods are created with the Status of Inactive, "I". When a period is to be used for input the Status is set to Active, "A", using the Open a Period function. Journal Entry will check for a valid status, and check transaction dates for reasonability. Releases from subledgers will also check for a valid status and a reasonable end date. When you are done with a period and want to restrict input to it, set the Status to Not Open, "N", using the Close a Period function.
Month-end, or period close, can be an arbitrary event in the General Ledger system. This happens when all the periods are changed to a Status of Active, "A". The accountant then decides when a period is complete and no more data is to be posted to it. At this time final Trial Balance and Detail of Account reports should be printed for the period. If adjustments are made to the period at a later date the final reports for the period should be reprinted.
Some organizations, like Louisiana Pacific Canada, have functions that are usually done at the end of each period. These appear on the Monthend Processing menu which is customized for the company.
Evans does their day-to-day accounting using the standard AERIS style of account codes. Their reporting to Louisiana Pacific is in another format of account referred to as the Lawson format. This is supported by having two parallel General Ledgers. Once a period is declared as completed the detail transactions are copied to the parallel AERIS-Lawson General Ledger translating the account numbers in the process. Normally a simple audit report is all that is needed before sending the data on to Louisiana Pacific. To do this we use the Month end Process in the AERIS-Lawson General Ledger to Create a Monthly Summary for Louisiana Pacific. This function creates a file, GL2LPXFR, containing one entry for each account for the selected period. It also produces a printed copy of these transactions. The last page of this report contains control totals for the transfer. When the control totals are received by Louisiana Pacific, they will transfer the file to their computer from the Evans Golden computer.
Do not Create another Monthly Summary until this one has been successfully received by Louisiana Pacific.
This is a transfer of summary totals by account for a selected period from the General Ledger to a transfer file that can be accessed from PC-based spreadsheets. With EXCEL as it is set up for Evans, this file can be imported directly to a cell in a spreadsheet. It appears as a database file on the network.
Ideally, the General Ledger for the old year should be fully closed before the new year begins and the subledgers are in lock-step with the General Ledger. Only one fiscal year is open at any time and the Status of Last Year is always Completed. At the end of the fiscal year you just Close the Old Year. In this case you never Open a New Year.
In reality the books for the old year are often revised for several months after reporting for the new year must begin. To minimize adjustments in this period the General Ledger system opens the new year separately from the close of the old year. When the new year is opened the following actions are taken:
Year End adjusting transactions are assembled in batches in the same manner as regular transactions. Adjustments to the old year are normally posted to the closing period. Be careful to assign the adjustment batches to the correct year because the default is the current year. Reporting in the new year is not aware of these final adjustments to the old year during the closing time. When the old year is finally closed the following actions are taken:
If adjustments occurred during the closing, all period closing reports already produced for the new year should be reprinted. This approach eliminates the need for any adjustments to be made in the new year to account for closing activities in the old year.
A separate set of reports are available for analyzing the old year. These include:
In this case some subledgers open for the new year before others and before the General Ledger is ready to open for the new year. The early subledgers need the Accounting Periods for the new year defined before the General Ledger is opened for the new year. In this case use the Update for Accounting Periods on the Yearend menu to create the accounting periods for the new year before the General Ledger for the new year is opened. These Accounting Periods will then be used when you Open the New Year later.
In order to provide the high level of reporting flexibility, all transactions are retained in detail for at least two years. All transactions are entered through a single batch assembly mechanism, whether they are entered manually or accepted from a subledger. The user assigns batch numbers using the AERIS Batch Control utilities. Each transaction is assigned a transaction number within the batch at the time it is entered into the system. The batch and transaction numbers become part of each transaction record. They are listed with each transaction on the Detail of Account providing a direct link back to the Batch Register and thus to the original document.
The batch counter goes to 9999 before restarting at zero. Each batch is associated with a reporting period when the first transaction is entered.
Commitment processing is a future feature for the General Ledger system. The commitment subsystem is used to track significant orders that will not appear as expenses through the normal channels, e.g. Account Payable, for a prolonged period. This situation often occurs when ordering large custom-made equipment. The delivery can take months, however the commitment to pay for the expense was made when the order was placed. These outstanding cost items must be factored into management planning long before the expense is recorded for accounting purposes.
The commitments are recorded in a separate unit of the database in much the same way that detail accounting transactions are recorded. A commitment is viewed as a document representing one or a series of related commitments. A series could be a purchase that involves progress payments. Each item of the commitment can be assigned to a particular G/L Account for the year and period in which it is expected to occur.
For reporting purposes a commitment is ignored if it is in a period preceding the reporting period or if it has been marked as fulfilled. If the effective date of the commitment is after the end of the reporting period it is also not shown. In the case of full-year reports only commitments after the year-end will be shown. On a detail report the commitments are shown in a separate group following the posted and unposted transactions.
Most volume reporting is done by subledger applications. The subledger records activities at a much more detail level than is usually done in the General Ledger. They also present the information in formats that are more specific to the working needs of the user. This does not altogether preclude the value of reporting volumes with General Ledger transactions. In fact, in some limited situations it is more convenient to monitor a situation entirely within the General Ledger. For example, a company with only a few bulk suppliers can do all their Payable reporting including volumes purchased within the General Ledger rather than processing half a dozen invoices per month through a Payable system.
General Ledger reporting is primarily concerned with dollar accounting so most of the standard reports do not show volumes at all. Those standard reports that do show volumes are of unique formats. For generality the volume reports process non-volume as well as volume accounts. The input mechanism provides the option for volume entry depending on the account type. Volume accounts prompt for the volume on journal entries showing the units of measure to be used. Transactions accepted from subledger can also carry volumes.
Volumes are recorded with each journal entry. At year-end the volumes are bundled differently for assets and liabilities than for incomes and expenses. Assets and liabilities accounts have opening balance records for the new year on which the running total of volumes is recorded. Incomes and expenses are rolled into a clearing account and as such do not have opening balance records. This means volumes on these accounts can only be analyzed on a year-to-date basis. The volumes are not rolled into the clearing account because the volume on each account can represent an entirely different measure from other accounts. As such a roll up into the clearing account would be a mixture of 'apples' and 'oranges'.
This section contains descriptions of the functions that are used regularly in the course of General Ledger processing.
A Batch Register is necessary before transactions can be modified in order to know transaction numbers.
The remaining data is then displayed.
Once a change has been made, a new Batch Register must be printed before the batch can be posted. A change to the amount or a deletion could also throw the batch out of balance.
The Batch Register can be printed at any time. It must be printed at least once after the last change is made and the batch is in balance and before the batch can be posted. The Batch Register is submitted to run immediately, outside the job queue.
The alternative to entering batches manually is to have the sub-ledger applications generate them for you. The applications from which batches can be accepted are on a separate menu.
The general approach is to accept a batch of transactions in a standard format from a designated file for each application. The filename and sometimes the library are defined in the Company Definition. There are two variations on how the transactions are brought into the General Ledger. In the first case, all the transactions in the file are copied directly into a single batch in Assembly. As such they are all assigned to one period. In the second case, the file may contain transactions assigned by the subledger to more than one period. The file is appended to a hold area in the General Ledger. Then the Accept moves only the transactions in the hold area assigned to the selected period into the batch in Assembly. This approach makes it so one General Ledger batch can contain the transactions from several Releases from one or more subledgers.
A batch can not be posted until:
Use the Batch Inquiry to confirm that Batch is ready to be posted. The first step in the post is to back up the data base. This can be bypassed under some circumstances. The attendant risk is that more than one batch would have to be re-entered if a problem is encountered during or after posting.
Batch Inquiry displays the present status of a batch in assembly. It shows the batch number, the period number and end date, the number of entries in the batch, the next transaction number, the current balance, and if the batch is in balance.
The transactions in a batch are displayed, similar to the Batch Register. It shows the transaction numbers and account names as well as the basic data.
When a batch has been entered incorrectly it can sometimes be easier to get rid of it and start again. This function removes all records from the batch area, then resets the controls to indicate that the batch is empty. Entry will now begin with batch set up again, although the batch number remains unchanged.
All reports can be produced separately by selecting them from one of the report menus. Some reports are also an integral part of other system functions like month-end processing. The reports listed below are available to all users. Some installations may have additional custom reports.
To produce a report of detail transactions by G/L account. The report also shows beginning and ending balances for the period selected.
To obtain a printout of the Chart of Accounts. Select a range of accounts to print. If the starting Account Number is blank all accounts are printed.
To print a list of accounts with associated balances for this year, last year and budget.
The set up to print the Comparative Trial Balance is identical to that of the Trial Balance. The reports differ in what columns are presented. The Comparative Trial Balance presents both current period and year-to-date total sets. Each total set includes one column for each of budget, actuals, and actuals last year. The amounts are signed rather than appearing in different columns as on the Trial Balance.
The set up to print a Subsidiary Ledger is identical to that of the Detail of Accounts. It should be noted that only accounts that contain non-blank entries in the lowest selected account level within the ranges of accounts to be reported will actually appear on the report.
To obtain a printout of the definition and titles for the financial statements. Select a valid report code or use F1 to print the definitions for all financial statements.
To obtain a printout of all the General Ledger Codes Tables.
To obtain a printout of the Budget by Accounts.
After the final regular period has been completed, backup the General Ledger data base to a separate set of diskettes outside the regular cycle. These are to be set aside for archives.
When subledgers are on a very different timetable from the General Ledger it can be necessary to define the accounting periods even before we are ready to open the new year. Use this update to create the periods for the coming year immediately. These periods will then be used when the new year is opened.
Simply select this option when the last period of the old year is completed and you are ready to begin the new year. After the procedure is completed, a Trial Balance is recommended to confirm the opening balances. The period ending dates should also be reviewed.
After closing adjustments have been completed, select this option to confirm the opening balances for this year and to close the old year. If there have been a significant number of closing adjustments, a new backup should be done for the archives. After the procedure is completed, a Trial Balance is recommended to confirm the opening balances. The close does nothing if the status of the previous year is not open.
Occasionally extraordinary adjustments must be made after a year has been closed. You must reopen the old year to enter these adjustments. If the previous year is marked as closed the status of the previous year is set to open and the current year is not changed. If the previous year is open the current year is set to the previous year and the status of the previous year is set to closed. After the adjustments are posted you must close the old year again to include the adjustments in the opening balances for the current year.
To review the detail transactions for a particular G/L account.
These functions are planned for implementation in the future.
Select this option to update Commitments when its required. The key to update the line is line number and account number. The updating fields are Description, Amount, Date, Supplier ID. Answer 'yes' when the updated information is correct.
This option will place a closing date at the Selected Record. It has the same key as mentioned above.
Produces a Report base on Account Range.
Produces a Report by Prompt Screen base on G/L number range.
Based on Prompt screen data it purges the commitment file
This section contains descriptions of the functions that are used infrequently in the course of General Ledger processing. Some of the functions appear only on the Management Functions menu and are not available to the general user.
The General Ledger system is a self-supporting system contained in program libraries, usually named GL and UT. The standard entry point to the system is a procedure called SETUP in GL. The corporate database consists of a corporate library, e.g. CO01, and two working libraries, e.g. CO01GL and CO01UT.
The system comes with a model database. This can be adjusted or cloned to become the production database. Once the system is installed, the user takes the following steps to prepare for operation:
The General Ledger is now ready to enter transactions.
To change the an account number in the Chart of Accounts. This function also moves all posted transactions from the old account number to the new accounts number.
To consolidate two accounts from the Chart of Accounts. The Transaction from the two accounts are merged and renumbered in the consolidated account. If by chance identical transactions exist after the source transaction is renumbered, they are merged into one by adding the amounts.
To increment all budget amounts by a specific percentage. Individual accounts may be further adjusted using account UPDATE.
To inquire as to the of details of any G/L account number.
Used for the definition of various codes used in system which are handled through a common code table mechanism.
This update is used to update any or all of the code table definitions.
This function provides the user with a tool to define the content and the general appearance of his financial reports. Each report is assigned a report code, which is the key to printing the report in the financial reporting program. If you have a series of financial reports which are always generated at the same time (e.g. current period, year-to-date, budget) they can be defined as one report. This will assure that all reports are generated and eliminate the task of selecting each report individually.
Types of Lines:
A common requirement in financial reporting is to print the sum of accounts having all entries of the account number common except for one entry. All valid values for this one entry would be included in the total. For example, we want the total revenue for all departments where the revenue is reported as an account within the department.
In setting up the line definition in the financial statement, the range selection contains special entries. All the entries that remain the same are filled in as usual. e.g. the Control Account for revenue is 5001. The entry for the department contains an left-justified asterisk only. This tells the report generator to look to the corresponding Code Table (e.g. 4 for department) for the list of valid values to use. Each value found in the table is substituted individually into the entry. The completed range is then used to perform the accumulation. Then the process is repeated for the next value in the table until all values of the substitution entry (department) have been processed. Only then is the line completion processing done.
More than one entry can use this substitution in the same selection.
All reports can be produced separately by selecting them from one of the report menus. Some reports are also an integral part of other system functions like month-end processing. The reports listed below are available to all users. Some installations may have additional custom reports.
To produce a report of detail transactions by G/L account. The report also shows beginning and ending balances for the period selected.
To obtain a printout of the Chart of Accounts. Select a range of accounts to print. If the starting Account Number is blank all accounts are printed.
To print a list of accounts with associated balances for this year, last year and budget.
The set up to print the Comparative Trial Balance is identical to that of the Trial Balance. The reports differ in what columns are presented. The Comparative Trial Balance presents both current period and year-to-date total sets. Each total set includes one column for each of budget, actuals, and actuals last year. The amounts are signed rather than appearing in different columns as on the Trial Balance.
The set up to print a Subsidiary Ledger is identical to that of the Detail of Accounts. It should be noted that only accounts that contain non-blank entries in the lowest selected account level within the ranges of accounts to be reported will actually appear on the report.
Application Start Up assume that the AERIS Corporate environment is already in place.
To use application startup:
GEN0001 Program Libraries
GEN0002 Data Base Libraries
GEN0011 Application Name
GEN0020 Backup Procedure
GEN0023 Backup Device Type
GEN1200 Menu For Accepting Journaals From Subledgers
In the normal course of operation, the functions used are described under Regular and Maintenance Functions. There are other functions that need to be performed from time to time but only under controlled circumstances. i.e. by a System Manager.
These have been assembled on a special menu called MANAGE. This menu is not linked into the standard menu set as a security measure. The functions are implemented on the principle that if the user can initiate them (i.e. has access to the MANAGE menu), so no further access control is necessary.
The flexibility of the General Ledger is implemented at two levels - system configuration, and system parameters. The system parameters are controlled by the user manager through this update.
This function defines the periods for a year. The system automatically assumes that there is 12 periods, but this number may be changed to more or less according to the company's needs.
Selection Screen
Data Entry Screen
These are general code tables used by the General Ledger. These include tables to define what codes can be used in the prts of the Account Number.
When disk space is short and a particular G/L is rarely used, or for security reasons, we may want to have that G/L stored off the computer. To do this, the standard backup function is used. The System Manager can then remove the database from the disk. Note that this removes the entire General Ledger database so that it is no longer accessible for account code editing in subledgers. To accommodate this editing, there is a function provided to reload only the Chart of Accounts. The reloading of the database is integrated into the startup when the General Ledger is selected. If the Chart of Accounts is loaded, it raises an error condition that can be overridden.
There are three units of the data base that would be merged:
The merge is implemented to combine a second General Ledger that has no duplicating account codes. Each unit is merged separately. The Chart of Accounts merge adds the second Chart of Accounts record for record.
The merge of the Transaction History (which can be detailed or in summary format) has two special features. First, in doing the merge only one transaction is created in the receiving General Ledger for each active account in a period in the source General Ledger. Second, the range of periods to merge can be defined at run time. This way we can do a recreating merge, or just bring in the latest period.
The Financial Statement merge is not frequently used because the reports from the detail level are not often reused at the combined level. Care must be taken that report names are not duplicated or the results can be quite confused.
This manual contains the entire documentation for this system. It defines this system as it is known at the present time.
The System Manual documents the functions in the recent standard release of the system. Older Releases may not contain all the functions described.
A E Rose Information Service Ltd.
400 - 10123 99 Street NW
Edmonton, Alberta
T5J 3H1
Phone: (780) 424-5844
Fax: (780) 421-4060