Last Updated on November 10, 2023 by maximosecrets

Financial processes exist in the tables which end with the characters TRANS and which have attributes for GL debit and credit accounts (GLDEBITACCT and GLCREDITACCT) and a financial period (FINANCIALPERIOD). From a financial point of view, you can split the use of the Inventory Usage application into two distinct areas:

• Issues and Returns – create records in the MATUSETRANS table (Material Use)
• Transfers – create records in the MATRECTRANS table (Material Receipts)

That seems a very black and white distinction but there are shades of grey, for example an issue of an item that is staged will create a MATRECTRANS record because that process step is really transferring the item from the originating bin to the staging bin. There are also financial transactions that create an INVTRANS (Inventory Transactions) record, for example when the item does not exist in the destination storeroom, an INSERTITEM transaction will be written. 

Issue Item and Return Item

When you issue an item, you are charging a work order, location, asset or GL debit account. The GLDEBITACCT field will need to be fully completed if you have “Validate GL Component Combinations” enabled in the Validation Options action of Chart of Accounts application. The GL debit account is typically derived from the GL account on the work order overlaid with the partial GL code for the item’s commodity group, the Inventory Resource Code, which will be found in the Resource Codes dialog of Chart of Accounts application. Sometimes you are issuing items based on just the location or asset and may need to use the GL Account Navigator on the inventory usage line to complete some of the component values.

The reservation for an issue will be derived from a material requisition (MR), sometimes known as a Desktop Requisition, or it may be derived from a work order (WO). The reservations are created when these records are approved. It is likely then that the GL debit account for each line will already have been filled. The request on the MR or WO will be a demand on a storeroom in the same site or across sites but within the same organization. Across organization issues are not allowed you will need to use a transfer. Maximo will allow you to issue to a storeroom, that might be relevant if you were issuing items that the storeroom itself will consume.

All types of item can be issued, including rotating items, kit items, condition enabled items, and lot items. You can also issue tool items, but they must be issued to a person who is responsible for the tools return. There is no GL debit account when issuing a tool item.

Issues have a negative quantity as you are depleting the storeroom balances.

There are two ways to perform a return:

• The Select Items for Return button will look at previous issues in the MATUSETRANS table and use the data from this record. The two MATUSETRANS records will be tied together using the ISSUEID field.
• An inventory usage line of type Return will derive the GL debit account in the same manner as for an issue but doesn’t tie it to an original issue record. This method would be used when there are surplus items where you don’t know the original work order.

Returns have a positive quantity as you are adding to the storeroom balances.

The GL credit account on an issue or return is derived from the item’s inventory control account which is dependent on the issue cost type of the item in the storeroom that is supplying the item to be issued.

• If AVERAGE or STANDARD, then the item’s inventory cost control account is used (INVCOST.CONTROLACC).
• If FIFO, LIFO or ASSET, then the storeroom’s control account is used (LOCATIONS.CONTROLACC)
• A tool item will have a blank GL credit account

The transaction type (ISSUETYPE) field will be set to either ISSUE or RETURN depending on the transaction. The MATUSETRANS record is created when the issue or return is completed.

Transfer Items

The financial processes when you transfer an item are more involved than when you issue or return items. It depends on whether you are transferring within a site, across sites or across organizations, whether you are using an internal PO, and the process steps that take place, a simple completion, or staging and completion, or a shipment and the receiving processes at the destination storeroom using the Shipment Receiving application. Tool items do not process the same as items. You can use transit locationsA physical place where assets exist and where work can be performed. More (Labor and Courier locations) to transfer the items, these are inventory-based locations and will record a balance of an item. The Issue Cost Type also has a bearing on what happens, particularly if the item does not exist at the destination storeroom then it will be defaulted using the sites default which can be found in the OrganizationsA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More application and Inventory Costs action.

While I will cover some financial processes in receiving the items into the destination storeroom using the Shipment Receiving application, I will not cover here what happens if you reject some items or void the receipt. I will leave that to topics covering that application.

In all of this I am assuming that the Inventory Usage application will be used for transferring items outside of the storeroom, you can transfer items from one bin to another, but I am assuming that you would be using the Inventory application for this. Whether we transfer within site, across site or across organizations the debit GL account is derived from the destination storeroom and the credit GL account is derived from the source storeroom. Quantities are positive for transfers. 

Across organization transfers will only work if the two organizations share the same Item Set, i.e. share the same set of Item Master records.

Inventory Usage Line

There is a GL debit account, GL credit account and financial period on the inventory usage line (INVUSELINE) but not on the inventory usage split (INVUSELINESPLIT) table where the quantity required is split between multiple bins or lots or individual rotating assets are identified. However, when the financial processes are written into the MATRECTRANS table the data is merged from these two tables and you end up with one MATRECTRANS record for each split record. For example, if a quantity of 10 was required on an inventory usage line and this was satisfied from two bins, then two MATRECTRANS records would be created. At the destination storeroom that may end up in the same bin but when you look at the MATRECTRANS records from the destination storerooms point you will still see two records.

On the Inventory Usage Line, the GL debit account is derived from the destinations storeroom’s inventory control account for the item and it will be dependent on the item’s Issue Cost Type.

• If AVERAGE or STANDARD, then the item’s inventory cost control account is used (INVCOST.CONTROLACC).
• If FIFO, LIFO, then the item’s inventory control account is used (INVENTORY.CONTROLACC).
• If ASSET, or the item does not yet exist at the destination storeroom, then the storeroom’s control account is used (LOCATIONS.CONTROLACC).
• A tool item will have a blank GL debit account.
• If an internal PO is being used, then the PO lines GL debit account is used.

On the credit side it is similar, but not quite the same, the GL credit account is derived from the source storeroom’s inventory control account for the item.

• If AVERAGE or STANDARD, then the item’s inventory cost control account is used (INVCOST.CONTROLACC).
• If FIFO, LIFO or ASSET, then the storeroom’s control account is used (LOCATIONS.CONTROLACC).
• A tool item will have a blank GL credit account.
• The GL credit account on the internal PO is not used, why would the destination site that issued the internal PO know the GL account to be credited?

When you capitalize an item, which you do in the Item Master application and it effects all inventory records for that item, then you can use a Capital GL Account. The only place this is stored is on the inventory cost (INVCOST) table which is only used when the Issue Cost Type is STANDARD or AVERAGE. When you transfer a capitalized item to a storeroom for the first time, even if the default issue cost type for the site is STANDARD or AVERAGE the storeroom’s control account is used, the Capital GL Account is not transferred.

Change Status to STAGED or COMPLETE

With the inventory usage record prepared you may change status to STAGED or COMPLETE or STAGED then COMPLETE. Staging is moving the quantity of an item from one bin to another, the staging bin, and so will create a MATRECTRANS record. This also occurs if the Usage Type on the inventory usage line is set to ISSUE.

When change status to STAGED, a MATRECTRANS record is created with a transaction type (ISSUETYPE) of STAGETRANSFER. The GL Debit Account (GLDEBITACCT) and GL Credit Account (GLCREDITACCT) are copied from the same fields on the corresponding inventory usage line.

When change status to COMPLETE, a MATRECTRANS record is created with a transaction type (ISSUETYPE) of TRANSFER. The GL Debit Account (GLDEBITACCT) and GL Credit Account (GLCREDITACCT) are copied from the same fields on the corresponding inventory usage line.

As a reminder there may be multiple MATRECTRANS records if the inventory usage line was split across multiple bins or the required quantity of a rotating item was greater than one.

There can be other financial transactions as you COMPLETE:

• If you are transferring the item to a storeroom where the item does not currently exist, you will see a record in the INVTRANS table which is used for inventory adjustments. It will have a transaction type of INSERTITEM. This is very common when using a Labor or Courier location as they store the balances of the item and consequently will need to create the items in their storeroom as part of the transfer.
• If you are moving a rotating asset from a storeroom in one site to another site, then you will see a record in the ASSETTRANS table of transaction type MOVED. If the asset had not previously existed in the destination storeroom then there would be a second ASSETTRANS record with a transaction type of CREATED.
• If you are transferring an item where the Issue Cost Type is STANDARD in the destination storeroom, then there may be a difference between the received cost and the standard cost in which case you will receive an INVTRANS transaction of type STDRECADJ (standard receipt adjustment) in the destination storeroom. The GL Debit Account is the storeroom’s control account and the GL Credit Account is the Receipt Variance Account both of which will be found in the Storerooms application for the destination storeroom. This does not occur if you are inserting the item in the destination storeroom, as the standard cost in this case would be zero, it has not yet been set. 
• If you happened to perform a physical count of the item in the source storeroom’s bin before you picked your required quantity, then there will be an INVTRANS transaction of type PCOUNTADJ (Physical Count Adjustment) in the source storeroom. The GL Debit Account and the GL Credit Account are the same and are derived from the Shrinkage Account dependent on the Issue Cost Type:
  • If STANDARD or AVERAGE, then the item’s inventory cost shrinkage account is used (INVCOST.SHRINKAGEACC)
  • If FIFO, LIFO or ASSET, then the storeroom’s shrinkage account is used (LOCATIONS.SHRINKAGEACC)

If you are transferring a rotating asset across sites then a new asset record will be created in the destination site, unless it had previously existed there. The asset in the source storeroom is DECOMMISSIONED. The two asset records are linked as they will have the same ASSETID field. If the asset was being depreciated, then the depreciation records continue on the asset in the destination site. The asset number in the destination site will default to the same ASSETNUM in the source site unless that value is already taken in which case you will need to provide a new asset number.

Change Status to SHIPPED

With the inventory usage record prepared you may change status direct to SHIPPED or STAGED then SHIPPED. You may have to use the shipping process dependent on the Transfer Options action in the Organizations application. The options are that shipping is required for across organizations, across sites, or for all transfers. The setting is an organization level setting and it is presumed to apply to the organization of the From Storeroom as that is where the validation occurs. The default is that across organization transfers require a shipment. I think it probable that an internal PO is also required for across organization transfers, the defaults for when internal POs are required is in the same Transfer Options action.

When you have change status to SHIPPED, a MATRECTRANS record is created with a transaction type (ISSUETYPE) of SHIPTRANSFER. The GL Debit Account (GLDEBITACCT) is the source organization’s clearing account (ORGANIZATION.CLEARINGACCT). The GL Credit Account (GLCREDITACCT) is copied from the same field on the corresponding inventory usage line.

All transfers via SHIPPED status use the source organizations clearing account, whether within site, across site or across organization. The final financial transaction made in the Shipment Receiving application will debit the destination storeroom’s control account dependent on the Issue Cost Type in the destination storeroom. The source organizations clearing account will be credited in one of the financial transactions taking place within the Shipment Receiving application. The internal PO line GL Debit Account is not used when you ship the item to the destination storeroom. The Organizations Clearing Account will be found on the main tab of the Organizations application.

As a reminder there may be multiple MATRECTRANS records if the inventory usage line was split across multiple bins or the required quantity of a rotating item was greater than one.

Shipment Receiving

The Shipment Receiving application is based on the SHIPMENT table but the Shipment Receipts table window is based on MATRECTRANS. The same Shipment Line attribute can exist multiple times in this table window because there can be multiple financial transactions against the same shipment line. For example, I receive a quantity of 10 and reject 2 that will create two MATRECTRANS records. In the following text I am only considering what happens when I receive the quantity sent, and not what happens if I return or void the receipt transaction, I’ll leave that for a discussion on Shipment Receiving application.

What happens in the Shipment Receiving application from a financial transaction point depends on whether the inventory usage line had indicated Inspection Required, a checkbox.

• If Inspection Required = 0 and not a rotating asset, then the MATRECTRANS status is moved to COMP (complete).
• If Inspection Required = 0 and a rotating asset and the asset had previously existed in the destination storeroom, then status is moved to COMP (complete).
• If Inspection Required = 0 and a rotating asset and the asset had previously not existed in the destination storeroom, then status is moved to WASSET (waiting to be serialized).
• If Inspection Required = 1, then the MATRECTRANS status is moved to WINSP (waiting for inspection). After inspection then the MATRECTRANS status will move to WASSET (waiting to be serialized) if it is a rotating asset, and it does not exist in the destination storeroom, otherwise the status is moved to COMP (complete).

If the asset number exists in the destination storeroom but it is not the same asset, then you will receive an error message similar to “BMXAA7771E – The asset CROSS_SITE exists at the BEDFORD site. Enter a new asset number for the BEDFORD site.” You will need to enter a value in the New Asset Number attribute.

In the Shipment Receiving application when you use the Select Shipped Items button a MATRECTRANS record is created for each shipment line with a transaction type (ISSUETYPE) of SHIPRECEIPT. The destination storeroom will be:

• The Holding Location for the destination site if the status is WINSP or WASSET. One Holding Location should be defined for each site. This is defined in the Locations application with type HOLDING. Often it is called RECEIVING or HOLDING.
  • The GL Debit Account is the holding location’s GL account (LOCATIONS.GLACCOUNT)
  • The GL Credit Account is the source organization’s clearing account (ORGANIZATION.CLEARINGACCT)
• The destination storeroom if the status is set to COMP.
  • The GL Debit Account that is used is dependent on the Issue Cost Type of the item in the destination storeroom:
    • If AVERAGE or STANDARD, then the item’s inventory cost control account is used (INVCOST.CONTROLACC).
    • If FIFO, LIFO, then the item’s inventory control account is used (INVENTORY.CONTROLACC).
    • If ASSET, or the item does not yet exist at the destination storeroom, then the storeroom’s control account is used (LOCATIONS.CONTROLACC).
    • If a tool item, then the Storerooms Tool Control Account is used (LOCATIONS.TOOLCONTROLACC)
  • The GL Credit Account is the source organization’s clearing account (ORGANIZATION.CLEARINGACCT)

If in Shipment Receiving application when you have completed the inspection or asset serialization another MATRECTRANS record is created for each shipment line that requires inspection or serialization. This has a transaction type (ISSUETYPE) of TRANSFER and the destination storeroom will now be set, it will no longer be the holding location.

• The GL Debit Account that is used is dependent on the Issue Cost Type of the item in the destination storeroom:
  • If AVERAGE or STANDARD, then the item’s inventory cost control account is used (INVCOST.CONTROLACC).
  • If FIFO, LIFO, then the item’s inventory control account is used (INVENTORY.CONTROLACC).
  • If ASSET, or the item does not yet exist at the destination storeroom, then the storeroom’s control account is used (LOCATIONS.CONTROLACC).
  • If a tool item, then the Storerooms Tool Control Account is used (LOCATIONS.TOOLCONTROLACC)
• The GL Credit Account is the holding location’s GL account (LOCATIONS.GLACCOUNT)

There is a complication with a cross-organization transfer that had not been resolved in Maximo 7.6.1.1, hopefully it will be in the next release. Each organization can have a different GL structure. When you are receiving into the destination storeroom there is a reference on the GL credit account to the source organization’s clearing account. That account does not generally exist in the destination organization’s chart of account records, I added it and the transfer could then proceed. But what would happen if the source organization’s GL structure did not neatly fit the destination organization’s GL structure?