AMS Advantage Financial is delivered with a fully functional chart of accounts model already in place that you can use as is or can modify in accordance to the requirements of your site. Later in this guide are details of the delivered model, such as the keys for each dimension, and examples of how it might be used. The following information is given for each dimension:
All parts of the hierarchy
Maximum delivered lengths for each element and rollup
Additional key fields for each element and rollup
As a rule, the application always edits any chart of account code entered against the reference page where codes are established. These edits are done with all existing key field information from that current page. Those dimensions keyed by Fiscal Year are always edited with the Fiscal Year of the Accounting line, Budgeting line, or other type of record. When no Fiscal Year is present, validation can use a Budget Fiscal Year, if present, as the Fiscal Year. When there is no Budget Fiscal Year present or that year is 9999, the application uses the current Fiscal Year (default Fiscal Year on Calendar Date for the Application Date).
There are a few places within the application where code validation is not performed on the page where the code is entered. These pages are not where codes are defined but ones used by documents or batch programs. In such cases, the documents and batch programs do not use the values entered that are not valid.
Users with the proper security may need to delete Chart of Account codes, sub codes or rollups that are not needed. When the delete action is selected on a COA page defined to check usage (all are as delivered) the system will determine if usage should be checked. The Deletion Prevention parameter on the Application Parameters (APPCTRL) page controls usage verification. A setting of either of the following will trigger the usage verification logic.
1 = Usage verification but deletion not allowed
2 = Usage verification and deletion allowed
The most common scenario starts with a user making the first attempt to delete a COA code. The system with either setting on APPCTRL above will create and submit the COA Usage Verification batch job in the background. The job researches whether or not a COA code has been used by a budget or accounting document that is currently in Pending on the Posting Line Catalog or has gone to Final or Historical Final in the past so that an update was made to the Budget, Accounting, or Cost Accounting Journals.
The user must wait until the system has finished the usage verification. If not, the message about needing to do verification issued upon the first deletion attempt will be issued again. After the system has finished the verification and the user makes another deletion attempt:
If the COA code has not been used, and the COA Deletion Prevention parameter is set to 2, then the COA code is deleted.
If the COA code has been used, and the COA Deletion Prevention parameter is set to 2, then the COA code is deleted and a warning error is issued indicating that the code was deleted, although it was used.
If the COA code has not been used and the COA Deletion Prevention parameter is set to 1, then a message is received indicating that the COA code has not been used, but deletion is not allowed. A system administrator must be notified to temporarily change the setting of the COA Deletion Prevention parameter to 2 so that the code can be deleted; remembering to change the parameter back to 1 after the COA code has been deleted.
If the COA code has been used and the COA Deletion Prevention parameter is set to 1, then a message is received indicating that the COA code has been used, but deletion is not allowed. A system administrator must be notified to temporarily change the setting of the COA Deletion Prevention parameter to 2 so that the code can be deleted; remembering to change the parameter back to 1 after the COA code has been deleted.
In the case that a COA has been used, it is the responsibility of the user that is attempting the deletion to ensure all necessary steps have been taken for the deletion. That will include deletion of records on pages that also store that code (e.g. deleting a BSA requires all records on the Valid Fund and BSA Combination).
If the APPCTRL record is set to 3 - Usage verification disabled so deletion is allowed – then a user with security to delete a COA code can do so and the system will not verify usage.
AMS Advantage Financial classifies your accounts into several categories, allowing different aspects of your financial information. These aspects are:
AMS Advantage Financial uses codes in the account code structure to establish hierarchies. These hierarchies can represent a tree-type relationship among a series of codes, separate independent measures, or a mix of the two. A common example of a measure with a mixture of hierarchical rollups and independent measures would be how automobiles are classified.
A vehicle registration number (VIN) would be the lowest level. Then above that there are categorizations for make, model, color, county registered in, and manufacturer. While make, model, and manufacturer are hierarchical, color and county registered in are not. Thus color and county registered in are independent measures of a VIN.
Most hierarchies in AMS Advantage Financial are optional and do not affect processing. Most do not have a built-in hierarchical structure, but one which a site constructs by populating rollup pages with values that are related to one another. AMS Advantage Financial uses hierarchies to make reports and certain online queries such as journals and ledgers more meaningful in how they are organized and how they summarize data in varying degrees.
The decision whether to implement the various hierarchies, and to what extent depends on your use of reports and certain online queries such as journals and ledgers. The number of levels to implement in each hierarchy is dependent upon online and offline reporting needs. Customization of the names of hierarchy pages and fields is often desired to have terms that are meaningful to those who frequently use them. Most chart of accounts elements (except organizational ones) can use the hierarchical elements of class, category, group, and type. Some elements, such as Fund, Object, Revenue, Balance Sheet Account, and Activity, also have rollups that can be used for Comprehensive Annual Financial Reporting (CAFR). These CAFR rollups are optional, and any of the other four - class, category, group, or type - can be used for CAFR reporting.
AMS Advantage Financial is delivered with more than 60 rollups defined for chart of accounts elements. Some of these have no additional keys for uniqueness, while some are keyed by fiscal year and others by department. You can define rollups so they are required for an element using the Advantage Design Studio.
Regardless of whether a user enters a chart of account code directly on a transaction or it is brought in from an inference, AMS Advantage Financial obtains all rollups associated with the code from the appropriate reference page. The code and all rollups are then stored on the accounting line, posting line and journal records for historical purposes. Those rollups can even be stored on ledger records if desired to facilitate reporting and querying based on 'historical' rollup values when 'current' rollup values are not required.
The following sections discuss the elements of the model with their functions and features.