Maximo Secrets

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

Financial Processes in Inventory (4 of 8)

This is the fourth in a series of pages that examine the financial processes in the applications of the Inventory module. They demonstrate, using examples and screenshots, how the debit and credit GL account fields are derived. A summary is provided at the end of each page.

This series will include:

  1. Storerooms/Locations control accounts, GL defaulting in Item Master
  2. GL defaulting in Inventory – Adjustments
  3. GL defaulting in Inventory – Issues and Returns
  4. GL defaulting in Inventory – Transfers
  5. GL defaulting in Inventory – Kitting
  6. GL defaulting in Issues and Transfers
  7. GL defaulting in Inventory Usage and Shipment Receiving
  8. GL defaulting in Stocked Tools

This page will examine:

Transfer Current Item

From the Inventory application you can transfer an item to another storeroom with or without using an internal PO. You can also transfer an item to a labor or courier location which are also inventory type locations that can hold balances of an item. You cannot use the Transfer Current Item action with a rotating item, you will receive the message “BMXAA1825E – Use the Inventory Usage application to transfer a rotating item.”

We’ll start with a straightforward transfer of a non-rotating item to another storeroom without an internal PO.

We are transferring a quantity of 1 of Item 4-LO80, a lock washer from the CENTRAL storeroom to the GARAGE storeroom in the same site, BEDFORD. Item 4-LO80 has an AVERAGE Issue Cost Type in both storerooms.

The Transfer Current Item action creates a transaction type of TRANSFER and is written to the object/table MATRECTRANS. It will be found in the Receipts & Transfers tab of View Inventory Transactions.

If the item is capitalized, the item’s Capital GL Account is used for the GL Credit Account on the MATRECTRANS record. This is the GL account in the Inventory Cost field (INVCOST.CONTROLACCOUNT).

If the item being transferred has an issue cost type of FIFO or LIFO then the GL Credit Account will be derived from the item’s GL Control Account (INVENTORY.CONTROLACC), there is no INVCOST record. 

I wanted to prove that that the GL accounts were coming from the Inventory Cost record and so I have changed the GL Control Account on both Inventory (6600-800-SAF) and Inventory Cost (6600-800-200) so that they are different from the control account on the CENTRAL Storeroom (6600-800-800).

Similarly, I have changed the GL Control Account on both Inventory (6620-800-SAF) and Inventory Cost (6620-800-200) so that they are different from the control account on the GARAGE Storeroom (6620-800-800).

When I transfer a quantity of 1 from Central to Garage the GL Debit Account is the Inventory Cost GL Control Account (INVCOST.CONTROLACCOUNT) on GARAGE storeroom, and the GL Credit Account is the Inventory Cost GL Control Account (INVCOST.CONTROLACCOUNT) on CENTRAL storeroom.

I also wanted to perform a similar test but for a LIFO or FIFO Issue Cost Type item. Item 0-7205, a Needle Valve, has a LIFO Issue Cost Type, for LIFO/FIFO Issue Cost Type items there is no Inventory Cost record. The GL Control Account on Inventory (6600-800-200) is different from the control account on the CENTRAL Storeroom (6600-800-800).

The same item 0-7205, a Needle Valve, also has a LIFO Issue Cost Type in the GARAGE storeroom. The GL Control Account on Inventory (6620-800-200) is different from the control account on the GARAGE Storeroom (6620-800-800).

When I transfer a quantity of 1 of a LIFO/FIFO item from Central to Garage the GL Debit Account is the Inventory GL Control Account (INVENTORY.CONTROLACC) on GARAGE storeroom, and the GL Credit Account is the Storeroom’s GL Control Account (LOCATIONS.CONTROLACC) on CENTRAL storeroom. It looks as if it ignores the Inventory Control Account on the credit side of the transfer, the From Storeroom.

In the final set of tests before we look at internal PO transfers I wanted to see what happens with capitalized items, items that do not exist in the destination storeroom, and what happens if the Issue Cost Type is different for the item in the From and To storerooms.

Item 1044, an Electric Cordless Drill, is Capitalized and only exists in the CENTRAL storeroom. The Capital GL Account is held in the Inventory Costs GL Control Account (INVCOST.CONTROLACCOUNT), it is 6200-300-400. It doesn’t yet exist in the GARAGE storeroom.

When I transfer a quantity of 1 of a capitalized item from Central to Garage the GL Debit Account is the Inventory Cost GL Control Account (INVCOST.CONTROLACOUNT) in the destination storeroom. New items are defined to be created with an AVERAGE Issue Cost Type. As the item is being created in the Garage storeroom, it’s Inventory Cost GL Control Account will be set to the Storeroom’s GL Control Account (LOCATIONS.CONTROLACC) which is 6620-800-800. The GL Credit Account is the inventory cost GL Control Account in the CENTRAL (From) storeroom (INVCOST.CONTROLACCOUNT) which was set to the GL Capital Account, 6200-300-400.

There is a secondary INVTRANS transaction of INSERTITEM because the item is being added to the Garage storeroom for the first time. The Debit GL Account and Credit GL Account of the inventory transaction is the same and equal to the storeroom’s control account (LOCATIONS.CONTROLACC), GARAGE in this case, GL account 6620-800-800.

I’ve now changed the Issue Cost Type for the item in the GARAGE (To) storeroom to FIFO, there is now no Inventory Cost record (INVCOST).

When I transfer a quantity of 1 of a capitalized item with AVERAGE Issue Cost Type to a storeroom where the Issue Cost Type is FIFO or LIFO then the GL Debit Account is the Inventory GL Control Account (INVENTORY.CONTROLACC) on GARAGE storeroom, there is no Inventory Cost record for this item in the GARAGE storeroom. The GL Credit Account is the Inventory Cost GL Control Account (INVCOST.CONTROLACCOUNT) on CENTRAL storeroom, this GL account is the GL Capital Account.

Transfer to a Labor or Courier Location

Labor and Courier locations are storeroom type locations, previously known as transit locations, which are capable of storing balances of an item. The idea is you transfer-in to a labor or courier location and then transfer-out to another storeroom. 

For a location of type LABOR the GL Control Account (LOCATIONS.CONTROLACC) is the inventory control account, which is normally hidden, but I am displaying it. CONNELLY has a GL Control Account of 6690-890-300.

In the case of a transfer to a Labor Inventory Location (To Storeroom), it may appear on first sight that there is a difference on the GL Debit Account because the GL account looks to be derived from the Location’s GL Control Account. But if you go and change the Location’s GL Control Account, it doesn’t make any difference when you transfer the same item. This is because it is actually coming from the inventory cost GL control account (INVCOST.CONTROLACCOUNT) which was defaulted from the Labor Location’s GL Control Account. It is behaving the same as if the labor location was a storeroom, which it is really.

In the case of a transfer to a Courier Inventory Location, DHL in this case, it works the same as for a transfer to a regular storeroom. When you perform this test the first time, it may also appear as if it is being derived from the courier location’s GL control account, but this is because they both have the same account value. It is actually being derived from the inventory cost GL control account (INVCOST.CONTROLACCOUNT) if the issue cost type is AVERAGE or STANDARD, and INVENTORY.CONTROLACC if the issue cost type is LIFO or FIFO.

Transfer using an Internal PO

We can also transfer items via an internal PO. An internal PO will allow rotating items to be transferred from one storeroom to another. The use of internal POs was more common a few years back especially for transferring between sites or across organizations. There is a setting in Organizations – Inventory Options – Transfer Options for defining whether a PO is required. With the introduction of the Inventory Usage application in Maximo 7.5, the need for an internal PO has mainly disappeared and with it also the use of the Issues and Transfers application which was used to transfer-in an item that was part of an internal PO. I’ll be covering the GL financial processes of transfers using both Inventory Usage and Issues and Transfers applications later in this series.

The GL control accounts for:

We will be transferring from Central to Garage. To use an Internal PO the check box “Use in PR/PO?” must be set (LOCATIONS.USEINPOPR) in the Storerooms application, this is for the storeroom referenced on the PO header, the from storeroom, CENTRAL in this case. 

We have created a PO, and marked it as Internal in the Vendor section, adding the CENTRAL storeroom as the storeroom from which items will be sourced.

A PO Line has been created for item 4-L080 with the charge being made to the GARAGE storeroom. I’ve added the GL Credit Account field to the screen so that you can see both sides of the financial transaction. The GARAGE storeroom will be debited and the CENTRAL storeroom will be credited.

To prove that both debit and credit side are using the inventory cost GL control account.

I have changed the item in CENTRAL so that its Inventory and Inventory Cost GL control accounts are different from that in the storeroom, 6600-800-SAF is the value for the Inventory Cost Control Account.

I have also changed the item in GARAGE so that its Inventory and Inventory Cost GL control accounts are different from that in the storeroom, 6620-800-SAF is the value for the Inventory Cost Control Account.

When the item is added to a PO line with a charge to the GARAGE storeroom you can see the GL Debit Account, 6620-800-SAF, is the destination storeroom’s (GARAGE) inventory cost GL control account and the GL Credit Account, 6600-800-SAF, is the source storeroom’s (CENTRAL) inventory cost GL control account.

In the case of item 0-7205 which is marked with an Issue Cost Type of LIFO in both CENTRAL and GARAGE storerooms, when the item is added to a PO line the internal PO defaults a GL debit account from the Inventory GL control account (INVENTORY.CONTROLACC) of the item in the destination storeroom, GARAGE, but it uses the storeroom’s GL control account (LOCATIONS.CONTROLACC) for the source storeroom, CENTRAL, on the credit side of the PO line transaction.

This is exactly as it is for non-rotating items when using the Inventory application action – Transfer Current Item.

I ran a similar test but for a rotating item. Item P-896 has an issue cost type of FIFO and is Active in both CENTRAL and GARAGE storerooms. On the Debit GL Account, it has defaulted to the Inventory GL Control Account, 6620-800-200 (INVENTORY.CONTROLACC). On the Credit GL Account there is no default. I was surprised by this, possibly an issue in Maximo 7.6.1.1 where I was performing the tests. I expected it to be the same as for a non-rotating item, and default to the Storeroom’s GL Control Account 6600-800-800 as it did for item 0-7205.

Item PUMP100 which is a rotating item and marked with an Issue Cost Type of AVERAGE in both CENTRAL and GARAGE storerooms, defaulted on both the debit and credit side of the PO line transaction.

The Internal PO (1135) with the four items has now been approved and we will later follow what happens when we receive the items. This will be in part 6 of this series, as we can only receive Internal POs using the Issues and Transfers application. We used to be able to do this also via the Receiving application but in out of the box Maximo there is an application restriction of “internal=NO” (MAXAPPS.RESTRICTIONS). That is, of course very easy to remove with a bit of SQL.

Summary – Inventory – Transfers (MATRECTRANS)

The GL account codes when you transfer an item using the Inventory application and when you transfer items using an Internal PO are almost identical and are defaulted on both the debit (blue) and credit side (mauve). The financial transactions are written to the MATRECTRANS object/table with a transaction type (ISSUETYPE) of TRANSFER. The debit side are GL accounts coming from the destination (To) storeroom, and the credit side are GL accounts coming from the source (From) storeroom.

When we refer to a storeroom or inventory, the financial processes seem to work equally with a labor or courier location, which are also capable of storing balances and may be viewed within the Inventory application.

You cannot transfer rotating items using the Inventory application’s action Transfer Current Item, but you can when you use an internal PO.

On the debit side (GLDEBITACCT):

On the credit side (GLCREDITACCT):

On the Inventory application the control and other GL accounts are normally hidden, but if displayed they can be modified. Note. On the Inventory Cost table window, they are not saved to the database when you use the save button. In this article I have been making the change by another method, so that I could make sure the financial processes were using INVCOST values.

3 responses to “Financial Processes in Inventory (4 of 8)”

  1. Long Cao avatar
    Long Cao

    Hi Andrew,

    I have a little question regarding “Transfer Current Items” option.
    If you specify a HOLDING location in the “To Storeroom” field, that transaction will be recorded in MATRECTRANS table, but no balance deduction will be actually made.

    Am I missing any process in between? Like creating a Transfer out from that HOLDING to another storeroom (which is impossible in Issue and Transfer app)?
    Or is it a flaw in Maximo (7.6.1.2).

    Regards,

    Reply
    1. maximosecrets avatar
      maximosecrets

      The HOLDING location in a site is often called RECEIVING. It is used to register that an item has been received but it is still in inspection or if a rotating item, waiting to be serialised. When you complete the inspection/serialization process Maximo will automatically transfer out from the holding location to the final destination. There is nothing that you need to do to use this. Your To Storeroom should be the final destination storeroom – CENTRAL-BEDFORD to CENTRAL-NASHUA, so CENTRAL-NASHUA in this case. The HOLDING location is not a storeroom.

      Reply
      1. Long Cao avatar
        Long Cao

        Great Andrew, highly appreciate your response.

        My question comes from a mistake by client (he has a RECEPTION storeroom and a RECEIPT holding location), which caused incorrect balance in the Inventory Balance report (because of such record in MATRECTRANS).

        Anyway I just made a few edit to make sure HOLDING location will not show up in “Transfer Current Item” TOSTORELOC field.

        Best regards,

Leave a Reply

%d bloggers like this: