Maximo Secrets

A site dedicated to Maximo containing over 350 articles, podcast episodes and YouTube videos, updated weekly.

Maximo Manage – Financial

Contents

Organizations

Maximo has a multiple organizations and multiple sites data structure where multiple organizations could share the same item set and company set. Some data exists at the System level, having no organization or site reference, other data exists at the organization level, or like assets, locations, and work orders there are data tables which exist at the site level.

Making the decision about the organization and site structure in Maximo may be very straightforward for some clients, and not for others, however one major factor in the consideration is the business units and legal entities of the Maximo client. Knowing how you would interface with a financial system, even if it is not part of the Maximo implementation project, is a good idea, because if you change your mind about the organization and site definitions after you have a populated database, then you might be looking at a complex process to update this, and worse case you could be looking at exporting out the data and loading into a new database.

Each organization can have two base currencies, but often only Base Currency 1 is used. Base Currency 2, if used, is calculated on financial transactions by applying the exchange rate between currency 1 and currency 2. The second base currency was used by Maximo clients in Europe during the transition to the Euro. Some Maximo clients use currency 2 as the currency of the country where the group company is head quartered.

The Organization has a General Ledger Clearing Account which is used in item transfers that occur between organizations.

In the actions menu under Purchasing Options there is an action called Tax Options which is where you define tax types and tax codes. Maximo is set up to allow 5 tax types, which means in tables like PRLINE or POLINE there are 5 tax code fields and 5 tax amount fields for storing the calculated tax after applying the tax rate associated with the tax code. The tax types equate to which of the tax fields are being calculated. Tax is normally calculated for the first tax type, a TAX1CODE is entered and the TAX1 amount is calculated. The second tax type applies TAX2CODE and calculates the TAX2 amount, but there are options on whether it should include the TAX1 amount before applying the tax rate. There can be up to 27 tax types by making a change in the Database Configuration application, Tax Types – Add/Modify Tax Types.

Currency Codes

The Currency Codes application must be one of the simplest in Maximo, as there is a three-character code, a description, and a field to indicate whether it is an active currency. This table is normally manually synchronised with a financial or ERP system. Currency is an example of a System level object.

Exchange Rates

The Exchange Rates application does not have an insert record because at the top of the screen you are selecting the Organization and, in the table below this, you create the exchange rates. There are two fields Convert From Currency and Convert To Currency. The Convert To Currency should be the currency of your organization, and the Convert From Currency is the currency of your companies, the vendors where the currency is used.

For each exchange rate there will be an active date and an expiry date both of which are mandatory, there is an optional memo field. In the background Maximo will record who entered the exchange rate record and when, also who/when the record was last modified.

Exchange Rates may or may not be interfaced from a financial or ERP system, depending on the expected volume of exchange rates, which is based on the number of currencies and how often the exchange rate is changed. As with currencies the master is normally assumed to be the financial or ERP system.

Chart of Accounts

The Chart of Accounts application stores the General Ledger codes for each GL segment and the valid combination of GL codes. The General Ledger Account can have up to 20 segments.

If GL codes are going to be used in Maximo, then the starting point will be to define the GL Code Structure. If they are not going to be used then it is best to leave the GL structure as it is defined out of the box and not populate either GL codes or GL account combinations, i.e. keep it clean until you do want to use it in the future. Sometimes, the codes and/or code combinations are used for analysis purposes, which is OK if you understand that if you do use the codes to represent GL codes in the future, then you will need to move your data to other fields and clear all the GL fields everywhere across the Maximo system.

The GL Account Configuration action in the Database Configuration application is where you define the GL components, their width and whether alphanumeric or numeric values are used. There can be some optional segments, but they can only exist at the right-hand end segments of the GL account.

The Add/Modify Account Structure action in the Chart of Accounts application is then used to define the GL Account Configuration for an organization. It will default to the same structure as that defined in Database Configuration, but it can be modified with some restrictions at the organization level. What each component means can be modified, but the length can only be smaller, and the type can only be more restrictive. If a segment was defined as Integer type at the system level, then it cannot be ALN at the organization level, but the reverse would be true, at the organization level a segment can become Integer where it is defined as ALN at the system level.

The GL Component Maintenance action is then used to enter the codes and descriptions for each GL segment for the organization. A new code is set active by default. The same code value can exist in multiple segments. The length of the value entered can be shorter than the width of the segment, for example, if segment 1 is defined as ALN 4 then a value of 123 is acceptable.

If you are going to validate the GL code combinations these are then entered, or data loaded. There is the GLACCOUNT field, up to 20 segment fields and the account description. New records are also active by default, and the active date defaults to date/time now. These chart of account records can be made inactive, or a date set when they will expire. As you enter the GL code combinations its description is generated based on the descriptions of each GL segment value you enter, with the plus sign used as a separator.

The Validation Options action is where you decide whether to leave the GL validation as active or use the Deactivate GL Validations field. The field Validate GL Component Combinations is used when you have populated the CHARTOFACCOUNTS table with the valid code combinations. If this is not set, then validation is verifying that the value entered for a segment is active, but all permutations of the values are considered valid. When clients have several segments to their GL account, and several code values for each segment, then you can quickly get into the millions of code combinations, and it becomes impractical to validate the code combinations. Think of a purchase order with 10 PO lines, there are going to be 20 validations of the GL account fields, one each for the debit and credit side. Validation will take time even with an index if you have many code combinations. 

Financial Periods is another action in the Chart of Accounts application. The financial periods are normally monthly but may be 4-weekly with 13 periods in a year, or they may be a repeating pattern of 4-4-5 weeks with 12 periods in the year. You define a code for each period and the From and To dates which must be contiguous with no gaps. The To Date of one period is the From Date of the following period. You can also validate financial periods.

The Accounting Close Date must be after the To Date and is the last date and time in which a financial transaction can be posted to the financial period. This field is normally set up at the same time as entering the From and To dates. 

The Actual Close Date is the date and time when the financial period was closed. Maximo records who closed the financial period, this is normally a member of the finance team, it there is no interface. 

Maximo does not display the financial period, but it is populated automatically using various fields across Maximo. Maximo Secrets has an article with a table showing which date fields are used.

I said earlier not to use the GL Accounts unless you were going to populate it with data that would be found in your financial system, the same also applies to financial periods, leave it to be used later with an integration to a financial system. There is also little point populating financial periods unless you were going to validate financial periods, and to be used effectively you need to define the Accounting Close Date, and regularly add an Actual Close Date.

If you are not setting up GL Accounts, you will still need one as a Site requires a Holding Account, a location with a type of HOLDING. The convention is to name this location RECEIVING. A holding account is used during the receiving process after the receipt has started but before it is completed the GL account of the holding location is used. 

GL Defaulting

If you have defined GL segments and GL code combinations, then you will want to make sure that wherever possible the GL debit and GL credit accounts are defaulted on each of the financial transactions of Maximo. There is a GL Account Navigator, a special dialog which helps a user enter a valid GL account code, or to enter a value that may be missing and causing an error when a financial transaction is posted. For example, on purchase order approval all PO lines must have a valid GL debit and GL credit account. Ideally, you set up GL defaulting or custom code so that a user does not need to use the GL Account Navigator. In this way, you get consistency in your finance system, even if you need to tweak the defaulting or scripts to get it right.

If you were wondering about the difference between debit and credit, the debit account is the account that will be charged, the credit account is the beneficiary account of the financial amount. For example, if you issue a $100 item from inventory to a work order, the work order’s GL Account is the debit account and the storeroom control account is the credit account.

Maximo’s General Ledger Financial Transactions are those tables containing the letters TRANS at the right-hand end.

In Purchasing:

In Inventory:

In Work Management:

In Asset Management:

In each of these tables you’ll find attributes GLDEBITACCT and GLCREDITACCT. The attribute FINANCIALPERIOD exists on all tables except ASSETTRANS. The attribute FINCNTRLID which is the unique field of a Cost Management record also exists in most of these tables but not on ASSETTRANS, INVTRANS and INVOICETRANS.

Maximo has GL defaulting on both the debit and credit side of these financial transactions, and you’ll find GL fields across many Maximo tables. A partial GL account is one where not all segments have a value, where they do not have a value, you’ll see the GL account has a series of question marks the width of the GL segment, e.g.????. A full GL account is one where there are no question marks.

Generally, a partial GL account is added to a location and/or asset and/or preventive maintenance record and this defaults on to a work order when the work order references the asset or location. If a segment has a value coming from all three places, then the PM takes priority over the asset that takes priority over the location.

The work order’s GL Account is then used during issues and returns with any missing segment values being provided by the Resource Codes defined from an action on the Chart of Accounts application, these are codes defined at the commodity group level. The same dialog provides codes for internal and external labor transactions (LABTRANS) and tool transactions (TOOLTRANS).

During purchasing the PO lines will default their GL Debit Account from the work order, location, asset, or storeroom for stock purchases and there are various GL defaulting depending on who and what is being charged, however, this is the most likely place where not all financial transactions will have a complete GL account and it is where either additional rules will be needed through scripts or where the requester will need to provide a value using the GL account navigator.

The credit side accounts are mainly defaulted from full GL accounts defined in the Storerooms and Companies applications, but also in the Chart of Accounts application through the actions Organization Default Accounts, Company-Related Accounts, and External Labor Control Accounts.

There used to be a Finance Manager Guide, which you can still find in PDF format. Nowadays it is in IBM documentation and called Financial Processes Reference. Maximo Secrets also has several guides, search for “Financial Processes” they exist for work orders and inventory, but not (yet) for purchasing.

There is an action Update Database which is performed for the organization of your default insert site, it is used to overwrite GL accounts on records when you change some of the control accounts. For example, you change the storeroom control account, this is written onto inventory records in tables like INVENTORY and INVCOST, but the fields are not visible. This action can help update those fields.

Cost Management

The Cost Management application is used for managing project costs, particularly where there is a project ledger in a finance system, for example Oracle. It contains a set of records that allow a work breakdown structure to be created although in many cases this might be two levels, project, and task. Each record is defined at the site level and the SITEID will be filled using the user’s default insert site if there is no interface from a finance system. The project identifier must be unique within an organization. 

The Project record does not have many fields but can be extended.  The main fields are an identifier (FINCNTRLID), description, type which is often set-up with an ALN Domain, for example CAPEX, OPEX, a value, start date and end date. If there are project budget or cost codes then the Budget and Budget Line fields are used, but these fields do not have any validation. The Tasks table window has the same fields. There is a Parent Project field which allows for more than two levels.

The unique attribute for a project or task, FINCNTRLID, exists on many of the financial transaction records in Maximo as we saw earlier, you will see the attribute FINCNTRLID where you typically will find the GLDEBITACCT attribute. However, the field is hidden, and you will need to unhide it where you need to refer to it, particularly in the Work Order Tracking application. If you are using it, then it is worth unhiding the fields on all the financial transaction records where it would normally be set read-only, and providing a little hover-over dialog so that you can identify its meaning.

You usually associate a work order with a particular project and task record and its FINCNTRLID will be copied though to all the financial transactions records that flow from the work order, in the same way that the GL account is copied to the GLDEBITACCT on financial transactions, however, in the case of the Cost Management identifier it is not modified by Maximo. 

Budget Monitoring

The Budget Monitoring application is a great addition to Maximo, it should not be ignored if your reaction is “budgets, that’s handled by finance”. It is relatively new, introduced in 2017 but there had been other budgeting applications sold by IBM services prior to this.

A budget record can be based on one of several focal points, single or multiple GL segments is normal, but it might be the complete GL account (Chart of Accounts), location, asset, or another basis. The focal points are used to gather cost information from the financial transactions across Maximo. It isn’t provided out of the box, but in a Maximo Secrets article I showed how to configure the Budget Monitoring application to retrieve costs from financial transaction records based on the Cost Management field FINCNTRLID, if you were using the data from a project ledger. This illustrates the power of the Budget Monitoring application, it is configurable.

A budget can have multiple budget lines based on different values for your focal point. The action Generate Budget Lines does this for you. The enterable fields on each budget line are the budgeted amounts for internal and external labor, direct or shared material, service, and tool. There are also internal and external labor hours. There are 24 Budget Rules that need to be defined, but there is an Auto-Configuration button for this. Each budget rule determines how to calculate a budget attribute on the budget lines. You’ll need to set the budget to Approved status before you can use the Update Budget Lines action to updated estimates, commitments, and actuals.

Budgets are defined at the Organization level but there is also a Site field. You do not need to enter budget amounts to be able to understand your year to date actual spend, or the spend in each financial period. You can compare estimates, commitments, and actuals without entering budgets, however, the two percentage fields use the budget values, and they will remain zero if the budget amounts and hours are zero. The budget values need to be entered before you approve the budget.

The three articles in Maximo Secrets on the Budget Monitoring application provide an overview, a detailed explanation of the budget rules and associations, and the third article provides the worked example of creating a new focal point based on the cost management project identifier (FINCNTRLID) and the minimum amount of testing that would be involved to check that it was calculating correctly. 

Budget Monitoring based on assets or locations will create a lot of budget lines, one for each asset or location record if you do not enter a condition. This can be useful to collect costs and hours, but it is likely to be too low level for budgeting. Ideally you would enter budgets at a level higher in the asset or location hierarchy, but estimates, commitments and actuals may not be collected at that level, and you could end-up with a set of zeros. It would be quite a bit of work to modify the budget rules to calculate costs from the asset or location hierarchy, if you are using General Ledger codes it is likely that some of the segment values are already identifying the point where you want to summarise your location and asset costs.

I think it would also be possible to create a set of budget rules to collect the costs to support the two customer-based accounting fields (Charge Account and Cost Center) provided by the Maximo Service Provider add-on.

Asset Depreciation

Asset Depreciation was introduced at the end of 2015 and originated from functionality that was in Maximo for Transportation. Asset Depreciation is the periodic allocation of an asset’s original purchase price over the service life of the asset. It is important because it defines the expectation of an asset’s useful life, allows you to understand an asset’s current value and remaining life, and for assets in storerooms it would allow you to adjust the inventory cost based on current value. Maximo’s asset depreciation will also create financial transactions for the asset’s depreciation amount.

You define the original purchase price or the current value of the asset, the number of periods over which depreciation will last and the residual value of the asset at the end of the term. Depreciation can then be calculated as the per period reduction in value between the date associated with the original price or current value and the end of the term over which depreciation is calculated. There can be an estimated salvage amount at the end of the depreciation term. There are two calculation methods, Straight Line and Double Declining Balance.

Asset Depreciation is important for Maximo clients because knowing the current value of the asset can help in repair or replacement decisions.

An asset can have depreciation based on dates or meter usage and it can support multiple depreciation schedules with a percentage weighting between them. Asset depreciation can also be split across the asset’s children or other assets. When depreciation is active a background Cron Task will create GL transactions for transfer to a finance system.

You can define depreciation on both an Item Master record and on an Asset Template so that the depreciation basis is inherited onto the associated assets. Assets that are received against an item with a depreciation schedule will trigger the creation of the depreciation schedules for new assets. Changes to the depreciation schedules are audited.

Asset depreciation moves with the asset when an asset is moved to a new site, but the GL transactions that have already been created remain. The depreciation schedule of two assets can be swapped.

You’ll find that Maximo Secrets has four articles on asset depreciation including a summary, defining depreciation schedules on Asset Templates and Item Master applications, and managing depreciation schedules. The final article follows what happens during an asset move, asset swap, and when you swap or split depreciation schedules.

Roll Up Asset Costs

Maximo collects actual costs against assets as financial transactions take place. The two fields updated are YTD Cost and Total Cost. There is an action in the Assets application called Zero Asset Costs which can be actioned on multiple assets which will set the Year To Date costs to zero, this is normally run at the start of a new year. It will also zero the Total Cost if you set it to do so. The two fields do not exist on a location.

The Roll Up Maintenance Costs action in the Assets application can also be run against multiple assets, and it rolls the costs up the asset hierarchy. It is a manual task, but a system property can automate this when a work order is closed. Unprocessed maintenance costs must be rolled-up manually if they exist before changing the system property. 

There is an automation script that can be downloaded for a one-time rollup that resolves all existing transactions. The roll up summarises the labor, material, service, and tool costs, and enters the values into YTD Cost and Total Cost fields for the assets referenced on closed work orders.

Leave a Reply

Your email address will not be published. Required fields are marked *