Maximo supports the referencing of General Ledger (GL) codes throughout Maximo in order to be able to provide integration with a finance system. This document will focus on the GL configuration aspects of Maximo.

Database Configuration – GL Account Configuration

The Database Configuration application has an action – GL Account Configuration where you define the structure of the GL account. The GL Account can have up to 20 components. Each component can accept integer values or alphanumeric values (ALN). You define the component width and whether the component is required or optional. Optional components can only exist at the end of the GL account, after the last required component.

The standard GL structure in Maximo has four components of which the first three will be required and the fourth component is optional. The database fields which are defined with a Maximo type of GL will in this case be defined with a width of 23. This will accommodate the length of each component, plus a delimiter between each component.

If your first implementation of Maximo will not include an integration to a finance system, it is still worth configuring the GL account to set the width of the field. The GL account field exists in many tables and configuring the field later with a populated database may take a while.

Chart of Accounts – Add/Modify Account Structures

Maximo supports the capability to create an integration to multiple finance systems by allowing the GL structure to be defined at the OrganizationA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More level. The Add/Modify Account Structure action in the Chart of Accounts application looks similar to the GL Account Configuration dialog but here we are defining the GL account structure for a particular Organization. The structure defaults from how it was set in Database Configuration.

There are some restrictions on how the GL Account is configured at the organization level. The length of a component cannot be longer than the length of the same component defined at the System level in the Database Configuration application. The type field cannot be made alphanumeric at the organization level if it were defined as an Integer at the system level, but if a component was defined as ALN at the System level it can be defined as an Integer at the organization level. 

You can change the GL component description, so the first component for one organization could be completely different from another. If you intend to integrate with different finance systems from the same Maximo system, then make each component an ALN and make it required when you configure it initially in Database Configuration.

Chart of Accounts – GL Component Maintenance

With the structure defined at the Organization level we can create the set of values and descriptions for each of the GL components.

The GL Component Maintenance action is used for creating a set of valid component values and their descriptions. You click on the row in the Components table window to enter the values for that component. As new records are entered, they are set to be active, at some later stage when component values or whole GL accounts are retired you can set them to be inactive. The value entered does not need to be the same length as the length defined for the segment. For example, a value of 123 would be acceptable for a Cost Center defined as Integer with a length of 4.

The component values are set at the organization level, and it will be a bit tedious entering these values manually if you have several organizations with the same set of GL components and accounts. Hence, it will be normal to data load these values initially and then to have them interfaced from your finance system. 

It is the duplication of Organization level data that should be one of the considerations when deciding on how many organizations and sites you have in your Maximo system. Remember organizations are for data sharing, and sites are for data separation in Maximo.

You will not be able to delete a GL component unless it is first made inactive, and you will not be able to delete it if it is used in a default account somewhere in Maximo. Unless you have just created the GL component, only consider making it inactive rather than trying to delete it.

Chart of Accounts – Creating GL Accounts

With the values created for each component you can now enter the valid component code combinations, referred to as the Chart of Accounts (COA).

The chart of accounts is also created at the organization level and each COA record will default to active state. As you enter a new row you are using the GL Account Navigator, the same dialog that will be used by Maximo users in other applications to fill-in component values which are missing after defaulting rules have been applied.

When creating a new GL account, the GL Account Navigator will start in the first component, which is titled segment, and will provide the list of active values and descriptions for this component – Cost Center, in the diagram above. After you choose the value for the first component, the value will be transferred to the GL Account field and the GL Account Navigator will now show the component values and descriptions for the second component – Activity. A user would proceed through selecting the values for each required component and when they are finished, pressing OK will close the dialog and transfer the value to the GL Account field. The description of the GL Account will be made up from the descriptions of each component value with a plus sign between. You can modify the description if you wish, but it will be easier to allow the default to be used.

The status of the new GL Account will be set to Active with an active date set to today and time now. There is an expiry date which if set in the past will make the GL account inactive, or if the expiration date is in the future, or is cleared, will make the GL account active. There is no standard escalation that will automatically set a GL account to become inactive at the expiry date, but this can be easily created.

Chart of Accounts – Validation Options

Some Maximo clients do not use GL accounts, others will want all financial transactions and financial periods to be validated because they are interfacing with a finance system. This is set up using the Validation Options action in the Chart of Accounts application. Validation options are set for each organization.

The default setting for an organization is to validate GL Component Combinations and Financial Periods. 

• The Deactivate GL Validations checkbox will be used by those clients who do not set up GL component or GL account codes. See picture later of what this looks like when this is enabled.
• The Validate GL Component Combinations will be enabled and checked when the Deactivate GL Validations is unchecked. The GL Account used on a financial transaction will need to exist as an active combination of component codes as defined in the GL Accounts table window. If this field is unchecked, then each component must be an active component, but the combination of component codes need not exist in the GL Accounts table window (*see below).
• When the Validate Financial Periods is enabled Maximo will check that each financial transaction falls within a valid open financial period.
• The Use current date as a transaction date if Financial Period is Closed check box provides the option to change the transaction date to time now if when posting the financial transactions and validating the financial period it is found to be closed. The new transaction date will find the financial period that is currently open.
• The Require Valid GL Account for All Transactions check box is used to make sure that valid GL accounts exist for both the debit and credit side on all financial transactions. With this field checked Maximo is ensuring that the debit GL account and the credit GL account have a value and are not null. However, a partial GL account, for example 6000-200-???, is still a valid GL account. To enforce a check that the valid GL account is fully specified then the attribute class file in Database Configuration can be changed from psdi.app.financial.FldPartialGLAccount to psdi.app.financial.FldFullGLAccount.

 * Sometimes the number of GL components and the number of values in each component is such that the number of valid GL component code combinations is so high that it is impractical for performance reasons to have validation of the GL code combination. If you consider a Purchase Order with 10 lines then there are 20 validation requests against the CHARTOFACCOUNTS table, one each for the debit side and the credit side, and if this table has a high data volume, then approval may take a while.

If there is going to be a high number of records in the table CHARTOFACCOUNTS then look to see how you can reduce the volume by removing a segment that may contain many values. For example, removing a project code from the General Ledger and using the Cost Management application instead can sometimes make the records in CHARTOFACCOUNTS more static, less likely to change over a financial year. This might make the interfaces to a finance system more complex, but it could allow validation to take place where before it were not possible using standard validation rules due to performance. In the past I have seen a proposed GL structure and set of segment values that when combined would have required more than a billion code combinations, which is not practical for performance reasons.

When the Deactive GL Validations is checked the only option available is the “Use current date as a transaction date if Finanical Period is Closed?”.