Maximo Secrets

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

,

Financial Processes in Inventory (7 of 8)

This is the seventh 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:

Inventory Usage

The Inventory Usage and Shipment Receiving applications were introduced in Maximo 7.5. They replace the Issues and Transfers application, but they also provide additional capability. I will follow a similar set of tests as were performed for Issues and Transfers.

Issue Item

You can issue an item from a storeroom to a work order, location or asset that is in the same site as the storeroom. You can also issue across sites. I found that an issue across organizations that share the same Item Master wouldn’t allow me to save the Inventory Usage record. If you want to do this use a transfer instead. The financial transactions are written to the MATUSETRANS object/table when you change status to COMPLETE, or a synonym.

When you issue an item to a location you can choose a storeroom, this is something you can do in Inventory Usage which you cannot do in the Inventory application, that would be called a transfer. However, I would suggest that you do not do this, as it will default in the storerooms GL account on the debit side (LOCATIONS.GLACCOUNT), and not the storerooms Control Account (LOCATIONS.CONTROLACC). Of course, you may be genuinely issuing items to be consumed by the storeroom, for example, racking, in which case it is OK to issue to a storeroom.

Issue Item Within Site

We’ll start by issuing items from the CENTRAL storeroom in the BEDFORD site.

When I issue an item from the CENTRAL storeroom to a work order that is also in the BEDFORD site, the GL Debit Account uses the work order’s GL account (WORKORDER.GLACCOUNT) merged with the resource code for the item being issued. In this case work order 1338 has a GL account of 6100-200-300 and the item, 4-L080 has a commodity code of MECH which has an Inventory Resource GL Component of ????-???-200. The merger of these two results in the GL Debit Account of 6100-200-200.

The GL Credit Account is the Inventory Cost Control Account (INVCOST.CONTROLACC) as the item has an Issue Cost Type of AVERAGE. The same field would be used for an Issue Cost Type of STANDARD.

If you look carefully, you’ll see that both the GL Debit Account and GL Credit Account fields can be modified on the Issues tab. You may wish to control this in an implementation.

I’ve navigated from the item to the Inventory application so that you can see that Item 4-L080 in the CENTRAL storeroom is of Issue Cost Type AVERAGE and so the GL Credit Account comes from the Inventory Cost Control Account (INVCOST.CONTROLACC) which you can see in the Inventory Costs table window, it is 6600-800-SAF. Notice it is different from the Inventory GL Control Account of 6600-800-200, which is different from the storerooms GL Control Account of 6600-800-800.

If this was a capitalized item, the Capital GL Account is stored in the Inventory Cost Control Account (INVCOST.CONTROLACC) field and so that would be used as the GL Credit Account. The line cost for capitalized items is zero.

Note the quantity for an issue is negative because it is reducing the balance, but it is a positive line cost because we are charging the work order. The issue transaction is written to MATUSETRANS table/object with a transaction type (ISSUETYPE) of ISSUE.

For those of you that have been following some of the other documents involving the Financial Processes in Inventory you’ll know that for an item with an Issue Cost Type of LIFO or FIFO that there is no Inventory Cost (INVCOST) record. Item 0-7205 has an Issue Cost Type of LIFO. The GL Debit Account is as we saw previously, 6100-200-200, created from the merger of the work order’s GL Account and the Inventory Resource GL Component.

For the GL Credit Account of 6600-800-800 I’ve navigated from the item to the Inventory application so that you can see that Item 0-7205 in the CENTRAL storeroom is of Issue Cost Type LIFO. The Inventory GL Control Account is 6600-800-200 and so it can’t have been derived from there.

If we navigate further to the CENTRAL storeroom, we can see that the GL Control Account, 6600-800-800 was used for the GL Credit Account.

Note. This is different to the processing for issuing materials from storerooms in Work Order Tracking and using the Issue Current Item action from the Inventory application where in both cases if the Issue Cost type is LIFO / FIFO then the GL Credit Account comes from the Inventory Control Account (INVENTORY.CONTROLACC) and not from the storeroom’s control account (LOCATIONS.CONTROLACC).

In our third test we are using item 10012 which is a rotating item with an Issue Cost Type of ASSET. We have selected the Rotating Asset 2130, which you can do if the quantity is 1; the Unit Cost and Line Cost is the Inventory Cost of the asset. Note. Only rotating items can have an ASSET Issue Cost Type.

The GL Debit Account is slightly different, 6100-200-SAF, created from the merger of the work order’s GL Account, 6100-200-300 and the Inventory Resource GL Component. This item has a commodity group of SAFETY with an Inventory Resource GL Component of ????-???-SAF, hence why the third segment of the GL is different.

I’ve navigated from the item to the Inventory application so that you can see that Item 10012 in the CENTRAL storeroom is of Issue Cost Type ASSET. There is no Inventory Cost table window and the Asset Cost table window is based on the Asset object/table. The GL credit account of 6600-800-800 is the storeroom’s control account (LOCATIONS.CONTROLACC), the Inventory GL Control Account is 6600-800-200 is not used for any of the issue transactions.

One advantage of Inventory Usage over Issues and Transfers is that you can specify a quantity greater than one for a rotating item, here the quantity is 2.00, the Rotating Asset field is now read-only and blank.

When you set the status of the Inventory Usage record to COMPLETE then the Split Usage Quantity dialog may appear if either one of the issues is for a rotating item or you have selected a quantity of an item that cannot be satisfied from a single bin or lot. In this case our third line of the Inventory Usage document was a rotating item. I have used the Auto-Split button which creates the record in the table window “Select Rotating Assets for 10012” and populates it with the referenced rotating asset 2130. If the quantity had been 2 then two lines would be created when you use the Auto-Split button. You need to adjust to the actual rotating assets that you selected from the bin.

Now when I use the OK button the status of the Inventory Usage document is set to COMPLETE and you can track from any of the three items through to the Inventory application and the action View Inventory Transactions to see that the MATUSETRANS record uses the GL debit and credit accounts that were on the corresponding inventory usage line.

The quantities for issues from a storeroom are negative, there is a negative effect on the balances. The Line Cost will be positive for an issue, but in this example of the rotating asset it is showing as zero. The reason for this is a setting in Organizations application, Inventory Options and the Inventory Costs dialog. If you are going to use the ASSET Issue Cost Type, then the Non Capitalized Rotating radio button should be set to Asset Cost rather than Issue Cost.

When it is set to Asset Cost the Unit Cost on the MATUSETRANS records uses the Inventory Cost of the asset issued. Once issued the Inventory Cost on the asset is set to zero.

To summarise, initially records are created in the Inventory Usage Lines (INVUSELINE) table and when you change status to COMPLETE the records are written to MATUSETRANS with a transaction type (ISSUETYPE) of ISSUE. Issues will also have a negative quantity in the MATUSETRANS record.

Issue Item Across Sites

When you issue the same items to a work order from a different site that is part of the same organization then it is only the GL Debit Account that will change, the GL Credit Account stays the same. The MATUSETRANS records are written when you set the Inventory Usage document to COMPLETE.

There is no difference in the deriving of GL debit and credit account codes between issuing items within the same site and issuing items across sites within the same organization.

Issue Item Across Organizations

In the Inventory Usage application, I found that you were allowed to issue an item across organizations that share the same Item Master, but you couldn’t save the record. You cannot issue items across organizations in the Issues and Transfers application.

If the two organizations do not share the same Item Master, you will receive the error message “BMXAA1914E – Cannot transfer or issue items across organizations that do not share the same item master.”

There is no difference in the deriving of GL debit and credit account codes between issuing items within the same site and issuing items across sites, even across organizations. However, I couldn’t save the Inventory Usage record when issuing across organizations. I received the following error message “BMXAA1791E – Not a valid material usage transaction GL account 5000-100-SAF. Either the required components are not filled or the component’s values are not valid.”

All the GL segment values, and the Chart of Account records were active with an active date a year ago. I could also save an actual material record on Work Order Tracking application with this particular GL account in the GL Debit Account of a MATUSETRANS record.

My suspicion is that the wrong error message is being shown and an issue across organizations may not be possible. The IBM Knowledge Center says “Items can be issued to a charging entity that belongs to the same site or across sites within an organization.” – implying that issuing across organizations may not be possible. There is also no reference to issuing across organizations in the Financial Process Reference part of the IBM Knowledge Center.

The issue with not being able to save might be because the same Inventory Usage Line can be used with a usage type of MIXED and in some cases you may be issuing the item and in other cases you might be using the same To Site (TOSITEID) field for a transfer to a storeroom at a site in a different organization.

If you want to issue items across organizations then I recommend starting with a transfer to one of the destination organizations storerooms, and issue from there.

Note. When issuing a rotating item, the location field is mandatory, and it must be set to an operating location and not a storeroom. If you attempt to issue a rotating item to a storeroom you will get an error message similar to “BMXAA1756E – Cannot issue a rotating item 10012 to a storeroom MACHSHOP.”

Issue Tool Items

In the Inventory Usage application, you can choose a Line Type of Item or Tool. For tools the GL Debit Account and GL Credit Account are null, and the fields are read-only. Tools are always capitalized; they have no cost and when they are issued the line cost will be zero. Stocked Tools are meant to be issued and then returned after use and not consumed by a work order, location or asset.

The issue of a tool will still create a MATUSETRANS record with a negative quantity. A return of a tool will be a positive quantity. Tools can be internal or external, rotating or non-rotating, in each of these cases the GL Debit and GL Credit accounts will remain null when you issue or return. When you issue or return a tool the Issued To field is mandatory, you have to issue to a person who is responsible for it, until the tool is returned.

Note. On Work Order Tracking the Actual Tools tab is writing a TOOLTRANS record which also generates a GL Debit Account and GL Credit Account. This is not the same as an Issue of a Tool which creates a MATUSETRANS record.

Return Item

We will now return the items previously issued.

When you return items the From Storeroom is the storeroom you are returning the items to, and the Usage Type is ISSUE or MIXED. You use the Select Items for Return button.

The Usage Type is Return and when using this button, the Returned Against Issue field is checked. When the status is COMPLETE, the Transaction Type (ISSUETYPE) will be RETURN on the MATUSETRANS record and the Issue and Return records will be linked.

The GL Debit Account of 6100-200-200 and the GL Credit Account of 6600-800-800 are the same as it was on the original issue transaction, it is using the GL accounts on the originating MATUSETRANS record. The quantity is positive, and the line cost is negative. Both the GL Debit Account and GL Credit Account fields are read-only after using the Select Items for Return button.

I have verified this for the other items:

The Select Items For Return button also allow you to select items that were issued to another site.

There is an alternative approach to returning items, you can use the New Row button and change the Transaction Type to RETURN and fill-out the fields as you would for an issue. The GL Debit Account and GL Credit Account default as they would do for an ISSUE transaction and they are not derived from the original MATUSETRANS record when you use the New Row button. The ISSUEID field which ties the return to the original issue is not filled-out and the Returned Against Issue field will be unchecked. When you use this method, you can modify the two GL account fields, to be something else.

The preference should be to use the Select Items For Return button when you are returning items previously issued and you know the work order on which they were issued. However, if items are found where the original work order is unknown then use the New Row button and the Return transaction type.

Transfer Items

You can transfer items between storerooms with or without an internal PO. When a transfer occurs, it may go through a shipment process where the transaction is completed in the Shipment Receiving application. An internal PO is most often used for transferring items across organizations that share the same Item Master, this is also the most likely time to use the Shipment Receiving process, although some clients will go through a shipping process for all across-site transfers, and some will also have a shipping process for inter-site transfers. When using a shipping process items marked as Inspection Required will need to go through additional steps in the Shipment Receiving application. A transfer may also use a labor or courier, transit location.

There are a lot of different ways of performing the transfers, whether they are inter-site, across site or across organization. We’ll start by looking at transfers without an internal PO.

Transfer Items within site, without internal PO

We’ll start by transferring the same items we used as part of the issue item examples. The transfer is from CENTRAL to GARAGE storeroom which are both in the BEDFORD site.

We will transfer a quantity of one of item 4-L080 from CENTRAL storeroom to GARAGE storeroom. Item 4-L080 already exists in both storerooms with an AVERAGE Issue Cost Type.

Both the GL Debit Account and GL Credit Account are modifiable on the INVUSELINE object/table. The transaction records are not written to MATRECTRANS yet, we need to wait until we change status of the Inventory Usage record to COMPLETE.

We transferred a quantity of one of item 0-7205 from CENTRAL storeroom to GARAGE storeroom. Item 0-7205 already exists in both storerooms with a LIFO Issue Cost Type.

We transferred a quantity of one of item 10012 from CENTRAL storeroom to GARAGE storeroom. Item 10012 already exists in both storerooms with an ASSET Issue Cost Type.

We transferred a quantity of one of tool item METER from CENTRAL storeroom to GARAGE storeroom. Tool items do not have an Issue Cost Type. The GL Debit Account and the GL Credit Account were both null.

When we change status to COMPLETE the Split Usage Quantity dialog opens, I’ve used the Auto-Split button which adds the row to the Select Rotating Assets for 10012 table window, and then changed the Rotating Asset to 2149 to demonstrate that the Inventory Cost of the asset is used as the unit cost.

I’ve verified in the Inventory application that the first three items were transferred with the same GL accounts by using the View Inventory Transactions action. The records will be found in the Receipts & Transfers tab. MATRECTRANS records are created with a transaction type (ISSUETYPE) of TRANSFER. For the rotating asset with ASSET Issue Cost Type, the transfer maintains the Inventory Cost of 56.00 in the GARAGE storeroom. Similarly, the tool item METER was transferred to the GARAGE storeroom and the balance has been increased, but you need to review this from the Stocked Tools application. Although the tool item is marked as Inspection Required, no inspection is required. The Inspection Required checkbox only has an effect when receiving via the Shipment Receiving application.

The Inventory Usage application has a View Transactions action which is useful. If you were spending a lot of time reviewing the GL aspects of these transactions then you might want to add to the details section the GL Debit Account and GL Credit Account, perhaps also other fields like the Rotating Asset, Financial Period, etc.

Transfer Items across sites, without internal PO

There is no duplicate action in Inventory Usage application, so I have created a new record with the same four items as the test for transferring between storerooms in the same site, but this time we are going from the CENTRAL storeroom in BEDFORD site to ATLANTA storeroom in the FLEET site. BEDFORD and FLEET are both part of the EAGLENA organization, so transfer across sites, same organization.

I made one small change between the two Inventory Usage examples, in this one the item 4-L080 I have marked as Inspection Required.

We will transfer a quantity of one of item 4-L080 from CENTRAL storeroom to ATLANTA storeroom in FLEET site. Item 4-L080 already exists in both storerooms with an AVERAGE Issue Cost Type.

Both the GL Debit Account and GL Credit Account are modifiable. The transaction records are not written to MATRECTRANS yet, we need to wait until we change status of the Inventory Usage record to COMPLETE.

We transferred a quantity of one of item 0-7205 from CENTRAL storeroom to ATLANTA storeroom in FLEET site. Item 0-7205 already exists in both storerooms with a LIFO Issue Cost Type.

We transferred a quantity of one of item 10012 from CENTRAL storeroom to ATLANTA storeroom in FLEET site. Item 10012 already exists in both storerooms with an ASSET Issue Cost Type.

We transferred a quantity of one of tool item METER from CENTRAL storeroom to ATLANTA storeroom in FLEET site. Tool items do not have an Issue Cost Type. The GL Debit Account and the GL Credit Account were both null.

I have changed status to COMPLETE and as before the Split Usage Quantity dialog opened for the rotating asset of item 10012 to be selected. As before I’ve used View Inventory Transactions in Inventory and Stocked Tools to check the GL accounts used on the MATRECTRANS records and also to check the balances have been incremented by one, which they have in all cases.

There was no difference for item 4-L080 which was marked as Inspection Required. This field only takes effect if you are going through the SHIPPED status and will therefore be using the Shipment Receiving application, which is what we will do in the next example.

For the rotating item 10012, asset 2142 was MOVED and in the Assets application you will find two ASSETTRANS records one for the move from CENTRAL – BEDFORD to ATLANTA – FLEET which is shown. There is also a CREATED transaction for the record in the FLEET site. Asset 2142 in BEDFORD site has been set to DECOMMISSIONED status, it was decommissioned at 13:15.

Incidentally, asset 2142 in BEDFORD and FLEET site show the same details when you use View Asset Move History, it is the same asset. The View Asset Status History action will show different records, it is the status change of the asset in the site, it will show DECOMMISSIONED in the BEDFORD site, but in the FLEET site it just shows NOT READY state, the date though is 05/06/20 14:33 which is the date/time when it was originally created, in the BEDFORD site.

Transfer Items across sites, via a transit location

Clients who have been using Maximo for a long time may still be using transit locations to move stock between sites, this test will show how that is done in the Inventory Usage application, and what to expect from the GL accounts.

Locations of type LABOR or COURIER are transit locations, these are inventory type locations capable of holding balances like a storeroom. So, you may transfer out from the source storeroom to a LABOR location, in this case CONNELLY, and then later transfer into the destination storeroom.

When I transfer the item (10112) from CENTRAL-BEDFORD storeroom to CONNELLY-BEDFORD transit location:

When you transfer an item to a transit location for the first time:

You then use another Inventory Usage document to transfer the item (10112) from the labor (transit) location CONNELLY-BEDFORD into the destination storeroom ATLANTA in FLEET site.

If the item didn’t previously exist in the ATLANTA storeroom it would be created and there would be an INSERTITEM transaction in INVTRANS for the ATLANTA storeroom in FLEET site. A TRANSFER transaction is created in MATRECTRANS when the Inventory Usage record is changed to a status of COMPLETE.

After the status of the Inventory Usage document has been changed to COMPLETE then a TRANSFER transaction will be found in the Receipts & Transfers tab showing the MATRECTRANS record created with the From Location/Site as CONNELLY/BEDFORD, and the To Location/Site as ATLANTA/FLEET. The balance has been incremented by one in the ATLANTA storeroom and reduced by one in the CONNELLY transit location.

Transfer Items across organizations, without internal PO

It wasn’t possible with the old Issues and Transfers application to move items across organizations without using an Internal PO. In this test we will move items from CENTRAL storeroom in BEDFORD/EAGLENA to the WOKING storeroom in WOKING site and EAGLEUK organization.

I am using the same four items that we transferred to another storeroom (GARAGE) in BEDFORD site and then across sites to the FLEET site and the ATLANTA storeroom.  I have marked all four items as Inspection Required.

We will transfer a quantity of one of item 4-L080 from CENTRAL storeroom to WOKING storeroom in WOKING site. Item 4-L080 already exists in both storerooms with an AVERAGE Issue Cost Type.

We transferred a quantity of one of item 0-7205 from CENTRAL storeroom to WOKING storeroom in WOKING site. Item 0-7205 already exists in both storerooms with a LIFO Issue Cost Type.

We transferred a quantity of one of item 10012 from CENTRAL storeroom to WOKING storeroom in WOKING site. Item 10012 already exists in both storerooms with an ASSET Issue Cost Type.

We transferred a quantity of one of tool item METER from CENTRAL storeroom to WOKING storeroom in WOKING site. Tool items do not have an Issue Cost Type. The GL Debit Account and the GL Credit Account were both null.

Both the GL Debit Account and GL Credit Account are modifiable. The transaction records are not written to MATRECTRANS yet, we need to wait until we change status of the Inventory Usage record.

You cannot move straight to COMPLETE status as you will receive two error messages (same dialog)

We will change status to SHIPPED by going via STAGED status, you can go direct to SHIPPED status.

As we change status to STAGED the Split Usage Quantity dialog will open to select the rotating asset for rotating item 10012.

After we change status to STAGED a record is written to MATRECTRANS with a transaction type of STAGETRANSFER. This example is for the rotating item 10012. The From Location and the To Location are both CENTRAL/BEDFORD and the GL Debit and GL Credit Account are the same and set to the GL Credit Account on the corresponding Inventory Usage Line (INVUSELINE.GLCREDITACCT).

At staged status the Quantity Staged field in the Inventory application will be incremented by the quantity being transferred.

As we change status to SHIPPED the Create Shipment dialog opens to allow you to fill in details about the shipment. As we are transferring across organizations with two different base currencies (USD and GBP) we may need to make sure there is an active exchange rate, otherwise the following error messages will be received in the same dialog:

In other tests I performed, for rotating items, you may also get the following error messages in the same dialog:

Using View Inventory Transactions in Inventory on the CENTRAL storeroom we get a different GL Debit Account. This is item 4-L080 with an AVERAGE Issue Cost Type. The transaction type is SHIPTRANSFER in MATRECTRANS table/object.

The Organization clearing account is used for the other two items 0-7205 and 10012, but for the tool item it remains blank.

If you look at the same items but from the WOKING storeroom you would see the same records in View Inventory Transactions dialog in Inventory and Stocked Tools applications, but only once the item exists in the destination storeroom.

In the Inventory application looking at the items in the CENTRAL storeroom at shipped status the Total Quantity Shipped field will be incremented by the quantity being transferred, the Quantity Staged will be reduced by this quantity.

From the Inventory application looking at the WOKING storeroom there is no visibility on the items that have been shipped, a pity, but should be pretty easy to rectify with a bit of configuration – the data is held in the SHIPMENTLINE object/table.

Transfer Items across organizations, without internal PO – Shipment Receiving

You receive the items that have been shipped using the Shipment Receiving application. You will find the shipment records under the site of the receiving storeroom, in this case WOKING.

You use the button Select Shipped Items to select the shipment lines, in this case I have used the Select All check box.

When you press OK you may receive the following error messages in the same dialog:

When items are transferred between storerooms using a shipment and the Inspection Required field has been checked on the Inventory Usage line, then the item will not be fully received immediately, it will go into a WINSP – Waiting Inspection state. The item is received into the holding location for the site, you will see this in the To Storeroom column. The Holding Location is defined in the Locations application with a type of HOLDING, there can only be one Holding Location per site. You would normally add a GL Account for the Holding Location.

The holding location is also used for rotating item transfers across sites, irrespective of the setting of the Inspection Required field. The holding location is still used and the receipt status of the MATRECTRANS record is changed to WASSET – Waiting for Serialization.

After pressing OK the shipment lines are transferred to the Shipment Receipts table window which is based on the MATRECTRANS object. Notice that all the items are at WINSP – Waiting Inspection status, this is because we had marked all four lines in the Inventory Usage document as Inspection Required. The To Storeroom, in this case RECEIVING, is the location of type HOLDING for the WOKING site, it will be found in the Locations application and not in the Storerooms application. It is commonly referred to as the sites “holding location”. Notice also the Transaction Type is SHIPRECEIPT.

You won’t find the SHIPRECEIPT transaction in View Inventory Transactions when looking at the items in the WOKING storeroom in the Inventory application, the item still doesn’t exist in the WOKING storeroom. However, the Quantity in Holding Location field will be incremented by the number of each item that was on the shipment record.

You need to look at the item in the CENTRAL storeroom to see the MATRECTRANS record. This is for item 4-L080.

The destination sites’ holding location’s GL Account is used whenever the Inspection Required field is checked on the Inventory Usage line, this was the case for all four items including the tool item. The Organizations clearing account is used as the GL Credit Account for the other two items 0-7205 and 10012, but for the tool item it remains blank.

Note. If Inspection Required is left unchecked on the Inventory Usage line, then the GL Debit Account will be dependent on the Issue Cost Type defined in the destination storeroom:

Using the Change Inspection Status action only shows the non-rotating items. I’ve selected all items.

When you press the OK button three additional MATRECTRANS records will be created with transaction type TRANSFER from the RECEIVING storeroom to the WOKING storeroom.

You will not see this transaction from the source storeroom’s item when using View Inventory Transactions in Inventory or Stocked Tools applications, only when reviewing the item records in the destination storeroom. In the Inventory application for the source storeroom item, you only see the MATRECTRANS records up to and including the SHIPRECEIPT transaction type.

In the Inventory application reviewing the item 4-L080 in the WOKING storeroom, the destination storeroom, using the View Inventory Transactions action, the Transaction Type (ISSUETYPE) in MATRECTRANS table/object is TRANSFER.

For item 0-7205 with an Issue Cost Type of LIFO.

For the tool item METER there is no Issue Cost Type

For the rotating item 10012 we use the Change Inspection Status for Rotating Items in the Shipment Receiving application. We will accept the rotating asset 2146 and the status of this MATRECTRANS row is changed to WASSET – Waiting to be Serialized.

There is no new MATRECTRANS record at this time, the transfer is not yet complete.

For the rotating item 10012 we use the Receive Rotating Items action. The GL Account field is empty. This should be the default GL Account for the asset in the Woking site, but the GL Account Navigator shows the EAGLENA GL segments and chart of account, so I would leave this field empty and adjust the asset’s GL Account after the transfer is complete.

If you press OK, you might receive the error message “BMXAA0131E – GL Credit Account is not a valid GL account.” This is because the GL Credit Account will be the Organization’s Clearing Account for the source storeroom. The validation though is against the destination organization’s chart of account records, which means that you need to add the source GL clearing account into the destination’s chart of account records, and vice versa, if you want to transfer back in the opposite direction.

If the two organization’s GL structure is different, then I think this will create an issue.

The final MATRECTRANS record has a transaction type (ISSUETYPE) of TRANSFER.

In additional tests I have performed the use of the organization’s clearing account for the source storeroom occurs whenever you are using the Shipment process, whether it is:

Transfer Items that are capitalized

This part of the document is to illustrate some points to note around Capitalized Items and an Issue Cost Type of Standard.

I’ve created a new item 1045 – Ride-on Mower 22 inch in the Item Master application and used the action Add Items to Storeroom to add it to the CENTRAL storeroom in BEDFORD site. I then used the action Change Capitalized Status and added a Capital GL Account of 6200-300-400. Item 1045 is now Capitalized. Note. If you capitalized the item before adding it to a storeroom the Capital GL Account is not stored anywhere, it is only held on an Inventory record. The Change Capitalized Status dialog is based on a non-persistent object. If you created the new item and marked it as Capitalized, then you do not get to access to the Capital GL Account field.

In the Inventory application for item 1045 and the CENTRAL storeroom, the Capital GL Account is added to both the Inventory Costs table window (INVCOST.CONTROLACC) as well as to the Inventory table (INVENTORY.CONTROLACC), but I have subsequently changed this to be 6600-800-200. The CENTRAL storeroom’s control account is 6600-800-800. So, all three control accounts are now different.

I have now changed status for item 1045 to ACTIVE in the Item Master application and rolled this down to Inventory Storerooms. In the Inventory application I have added a balance of 5 to bin B2 for item 1045.

I will be transferring to the CENTRAL storeroom in the NASHUA site. In Organizations application, Inventory Options and action Inventory Costs, NASHUA site is defined so that new items are set up with a STANDARD Issue Cost Type. As I have just created a new item it does not yet exist in the CENTRAL storeroom at NASHUA site.

I’ve just created an Inventory Usage document with type TRANSFER on CENTRAL storeroom in BEDFORD site and have added item 1045 with From Bin of B2 and with the To Site of NASHUA and the To Storeroom of CENTRAL.

If you go to save and receive the error message “BMXAA8227E – The storeroom or bin that you have selected does not contain item 1045” then check your balances and the bin that you are transferring from, in my case I had initially forgotten to select B2 in the From Bin of the source storeroom.

I have now changed status on the Inventory Usage document to COMPLETE, it is at this point when the MATRECTRANS record is written.

In the Inventory application and for item 1045 in CENTRAL-NASHUA storeroom we can use the View Inventory Transactions action and Receipts & Transfers tab to see the MATRECTRANS record with transaction type (ISSUETYPE) of TRANSFER. The GL Debit and Credit Accounts are the same as we saw on the Inventory Usage document.

Maximo will automatically add the record to the destination storeroom if it does not exist there. On the Adjustments tab you can see that Maximo has created the INVTRANS record with a transaction type of INSERTITEM. The GL Debit and Credit Accounts are the storerooms control account (LOCATIONS.CONTROLACC) for CENTRAL storeroom at NASHUA site.

While the new item has been created in the CENTRAL storeroom in NASHUA site, and it is a capitalized item, you can see that the Inventory Costs Control Account has not used the Capital GL Account. You need to change this manually and for you to do this you need to add it into the Inventory screen and enable it for editing. Note, the INVCOST object has a non-persistent CONTROLACCOUNT field, you cannot use this to modify the table you need to use the persistent CONTROLACC field.

Note. If you are using LIFO or FIFO as the default Issue Cost Type for the Site, then there will be no Inventory Cost record and the Inventory Control Account is used instead (INVENTORY.CONTROLACC). The Inventory Cost table window and its underlying table is only used for items with an Issue Cost Type of STANDARD or AVERAGE.

The main point in this section is that if you aim to use a Capital GL Account and you transfer items to other storerooms then you probably need a way of viewing and modifying the Inventory and Inventory Cost control accounts. Note also that capitalized items have a zero standard cost and average cost.

I have now gone back to the Item Master application and changed the capitalized status to non-capitalized. Ignore the Capital GL Account, as there is no central location to store this value it can only come from an inventory or inventory cost record – but which one? 6600-800-200 happens to be the Inventory control account (INVENTORY.CONTROLACC) in CENTRAL storeroom of BEDFORD site. After pressing OK it is now non-capitalized in all storerooms that reference item 1045. The Inventory (INVENTORY.CONTROLACC) and Inventory Cost Control Accounts (INVCOST.CONTROLACC) will be reset to the Storerooms Control Account (LOCATIONS.CONTROLACC).

While at all storerooms in my test the item is set with an Issue Cost Type of STANDARD it will still have a zero standard and average cost in these storerooms. When you move from Capitalized to Non-Capitalized you need to remember to reset the standard or average cost if that is the way you value your items.

In the Inventory application for item 1045 in the CENTRAL storeroom and BEDFORD site I have used the Inventory Adjustments – Standard Cost action to reset the standard cost to $2,200. I have repeated this process for the item in CENTRAL storeroom of NASHUA site, but in this case, I have set the standard cost to $2,000.

I have created another Inventory Usage record to transfer item 1045 from CENTRAL storeroom in BEDFORD site to CENTRAL storeroom in NASHUA site and set the Inventory Usage record to COMPLETE. The balance is incremented, and you can see in the Inventory Costs that the Last Receipt Cost was $2,200.00.

The IBM Knowledge Center suggests that a receipt price adjustment record will be created in INVTRANS with a transaction type of STDRECADJ. As you can see, no INVTRANS record was created, the last one is the adjustment to the standard cost which set it to $2,000. If the unit cost of the receipt is different from the standard cost then a receipt cost adjustment transaction should be made in the receiving storeroom, if the item has an Issue Cost Type of STANDARD. This looks to me like an omission in the code, you may have a different name for it.

I have transferred another one of item 1045 by using the Issues and Transfers application and the Transfer Out tab. You can see that the Current Balance is now 3.00 and the Average Cost in the Inventory Costs table window has changed.

The Issues and Transfers application is producing an INVTRANS record of transaction type STDRECADJ – Standard Receipt Adjustment.

A similar record should be produced when you are using the Inventory Usage application. Note. When you transfer an item into a storeroom for the first time you do not get a Standard Receipt Adjustment record.

Transfer Items with an Internal PO

In the Organizations application under Inventory Options there is an action called Transfer Options which determines when a Shipment record and when an Internal PO are needed. The default is that a shipment record is required when transferring across organizations and no Internal PO is required to transfer items.

As you can see, I have changed this so that Shipments are needed to transfer items across sites and that an Internal PO is needed only when transferring across organizations. However, I am going to show an Internal PO being used when transferring item 1045 across storerooms of the same site, and different sites and different organizations.

This time I am going to transfer from CENTRAL storeroom in BEDFORD to:

In all three sites I have set the Issue Cost to default to Standard Costs when creating new items. This is the Inventory Costs setting in Organizations application.

Transfer Items with an Internal PO, same Site

I have created an Internal PO sourcing from the CENTRAL storeroom in the BEDFORD site.

On the PO Lines tab, I added item 1045 with a Charge To the storeroom GARAGE.

Initially, I thought the GL Debit Account was the destination storerooms Control Account (LOCATIONS.CONTROLACC), the destination storeroom is GARAGE-BEDFORD. However, we are inserting into the GARAGE storeroom for the first time and the default Issue Type is set to STANDARD. The Inventory Cost Control Account is being used, however the value of the Inventory and the Inventory Cost Control Accounts are set the same as that in the Storeroom’s Control Account when the item has just been inserted.

I’ve approved PO 1143. As a reminder the item doesn’t yet exist in the GARAGE storeroom.

In the Inventory Usage application, we have created a new record on the CENTRAL storeroom of type TRANSFER. Then we have used the button Select Reserved Items. The Internal PO against the CENTRAL storeroom has created a reservation.

After selecting the reservation, the Inventory Usage line is created. You can see Reservation 1881 was an APHARD reservation for PO 1143 and PO line 1. The GL debit and credit accounts appear to have been pulled through from the PO Line (POLINE) fields GLDEBITACCT and GLCREDITACCT, but the values could be modified here, we won’t.

I need to select the From Bin (B2) where item 1045 exists, then I can save and change status to COMPLETE.

Item 1045 has been added to the GARAGE storeroom, the Issue Cost Type has been defaulted to STANDARD, and the balance is now 1.00. The Inventory Costs and Inventory Control Accounts are set the same as the GARAGE storerooms control account 6620-800-800. As it is a new item the Standard and Average Cost is set the same as the Unit Cost on the MATRECTRANS record which is entered into the Last Receipt Cost field on the Inventory Costs table window.

The MATRECTRANS record of transaction type TRANSFER appear to have the same GL debit and credit accounts as the PO Line. There is also the INVTRANS record with transaction type INSERTITEM.

Transfer Items with an Internal PO, across sites same organization

We are now going to use an Internal PO to transfer to NASHUA site and GARAGE storeroom. I am changing my default insert site to NASHUA and creating the internal PO as we did before.

On the PO Lines tab, I added item 1045 with a Charge To the storeroom GARAGE.

This is a test to ensure that the values are derived from the internal PO, so I have changed the PO Line GLDEBITACCT to 6620-800-200 and GLCREDITACCT to 6600-800-200. I’ve now approved PO 1144. As a reminder the item already exists in the GARAGE storeroom with a standard cost of $1800.00.

I’ve changed my default insert site back to BEDFORD. In Inventory Usage application I’ve created a new record of type TRANSFER on CENTRAL storeroom and used the button Select Reserved Items to select the reservation 1882 for Internal PO 1144 and line 1.

I have done several other tests to check when the PO line GL Debit Account is used and in all of these tests the PO line GL Credit Account is never used in the Inventory Usage or Shipment Receiving applications. It may appear to be used, but then the same value is being derived on both PO line and Inventory Usage line. It is only when you change the PO line Credit Account you realise it isn’t used.

When we go to change status to COMPLETE, we get the following error messages in the same dialog:

This is because we had specified in the Transfer Options of Organizations application that a shipment was required for transfers between sites.

When change status to SHIPPED which you can do without going through the STAGED status the Create Shipment dialog opens.

A MATRECTRANS record is created with transaction type of SHIPTRANSFER which is visible from both storerooms because it already exists in the GARAGE storeroom in NASHUA site. If the item had not existed in the destination storeroom then we would only be able to see the transaction from the source storeroom.

In the Shipment Receiving application for NASHUA site we can find shipment 1011 and use the button Select Shipped Items to select item 1045 associated with internal PO 1144 and line 1. This creates a MATRECTRANS record of type SHIPRECEIPT. There is no inspection required and so the status is set to COMP, complete.

As this is the only item on the Inventory Usage record 1047 its Receipts field will now be marked COMPLETE. Similarly, the Receipts field on the PO header is set to COMPLETE and the Receipts Complete on the PO Line is checked.

Back in the Inventory application for item 1045 in the GARAGE storeroom of NASHUA site we use the View Inventory Transactions action to see the MATRECTRANS record of transaction type (ISSUETYPE) of SHIPRECEIPT.

In the Adjustments tab we have an INVTRANS record of transaction type STDRECADJ – Standard Receipt Adjustment.

A Receipt Adjustment is being created when going across storerooms, but perhaps not when you are inserting the item in the storeroom for the first time.

Transfer Items with an Internal PO, across sites different organization

In the final test we will transfer the item from CENTRAL storeroom in BEDFORD site and EAGLENA organization across organizations to WOKING storeroom, WOKING site in EAGLEUK organization. We will do this twice to see if the Receipt Adjustment only occurs when the item already exists in the destination site.

I am changing my default insert site to WOKING and creating the internal PO as we have done before.

On the PO Lines tab, I added item 1045 with a Charge To the storeroom WOKING.

You might say that the Storeroom’s Control Account is being used, because the item doesn’t yet exist in the WOKING storeroom, and you would be right. I’ve chosen to say that it is the Inventory Cost Control Account that is being used, because if it did exist in the WOKING storeroom, that is the account that would be used. On insert of the item in the WOKING storeroom the value of the Inventory and the Inventory Cost Control Accounts are set the same as that in the Storeroom’s Control Account. I think it makes things easier to not have to distinguish between whether the item exists or not in the storeroom, when the control account that is used is already dependent on the Issue Cost Type of the item. Certainly, it made the diagrams easier to understand when I adopted this approach.

I’ve approved PO 1004. As a reminder the item doesn’t yet exist in the WOKING storeroom.

I’ve changed my default insert site back to BEDFORD. In Inventory Usage application I’ve created a new record of type TRANSFER on CENTRAL storeroom and used the button Select Reserved Items to select the reservation 1883 for Internal PO 1004 and line 1.

When we go to change status to COMPLETE, we get the following error messages in the same dialog:

When changing status to SHIPPED the Create Shipment dialog opened. The Inventory Usage document is now at SHIPPED status.

A MATRECTRANS record is created with transaction type of SHIPTRANSFER which is only visible for the item in the source (CENTRAL) storeroom, it doesn’t yet exist at the destination storeroom, WOKING.

In the Shipment Receiving application for WOKING site we can find shipment 1012 and use the button Select Shipped Items to select item 1045 associated with internal PO 1004 and line 1. We are only receiving a quantity of 1 of the two ordered.

Unfortunately, I received error message “BMXAA3240E – The receipt cannot be created for the selected row 1. Null” and I couldn’t find the reason for this.

However, using New Row and entering Shipment Line 1 I was able to save the record with a quantity of 1. Note. The PO and PO Line fields are empty and read-only, which is the case when using New Row button. The Select Shipped Items button is the right one to use.

This creates a MATRECTRANS record of type SHIPRECEIPT. There is no inspection required and so the status is set to COMP, complete.

The eagle eyed of you will notice that there wasn’t a very good exchange rate for USD to GBP of 1.333333 as it has resulted in a higher line cost. When I looked, the exchange rate on EAGLEUK between USD and GBP was roughly correct, but on EAGLENA the exchange rate between USD and GBP was not the same. This would obviously create issues in a production environment.

I am changing the Standard Cost of item 1045 in order to see if the Receipt Price Variance transaction will be created in INVTRANS. The Standard Cost is now 2500 GBP. I have also changed the Inventory Cost GL Account of item 1045 in WOKING to 5000-100-SAF to validate that this is being used when we receive the remaining quantity of the item.

In Shipment Receiving application, as you can see, the new Inventory Cost Control Account of 5000-100-SAF has been used.

As this is the last item on the Inventory Usage record 1048 its Receipts field will now be marked COMPLETE. Unfortunately, the Receipts field on the PO header remains as NONE and the Receipts Complete on the PO Line is left unchecked, this is because using the New Row button has not associated the Shipment Receiving line with the PO Line, these fields are left null and they are read-only fields. We should have been using the Select Shipped Items button, but as I remind myself this is a test of GL accounts defaulting.

Back in the Inventory application for item 1045 in WOKING storeroom in View Inventory Transactions and the Adjustments tab we now have the INVTRANS record with transaction type STDRECADJ – Standard Receipt Adjustment.

In subsequent tests on Internal POs with GL accounts that were modified from their defaulted values I found that the PO lines GL Debit Account is used if you complete, or stage and then complete, the inventory usage document. When you use the shipping method the GL debit account on the PO line is not used, instead the final MATRECTRANS transaction is derived from the destination’s inventory or storeroom control accounts depending on the issue cost type in the destination storeroom. The PO lines GL Credit Account is never used, not on the inventory usage line or on any record created on MATRECTRANS.

Summary – Inventory – Inventory Usage

The Inventory Usage and Shipment Receiving applications were introduced in Maximo 7.5, replacing the Issues and Transfers application. There are a lot of processes in these two applications, hence I have split the summary between Issues and Returns, and Transfers. The diagrams show how the debit (blue) and credit side (mauve) GL Accounts are derived. In Shipment Receiving, the Select Items for Return and Select Records to Void buttons have not been covered here, I aim to cover these as part of the Purchasing and Receiving financial processes.

Issues and Returns

Issue Item and Return Item

Issues create a transaction type (ISSUETYPE) of ISSUE in the MATUSETRANS object/table.

The GL account codes when you issue or return an item are similar to what we find in Work Order Tracking or Inventory applications, but they are not exactly the same. I found no use of the Inventory Control Account (INVENTORY.CONTROLACC) when performing issues and returns.

Transfers

Transfer Item

Inventory Usage of type Transfer creates an INVUSELINE record:

Set Inventory Usage of type Transfer to COMPLETE or STAGED then COMPLETE state creates a MATRECTRANS record with transaction type (ISSUETYPE) of STAGETRANSFER or TRANSFER:

When STAGED

When COMPLETE

Set Inventory Usage of type Transfer to SHIPPED state creates a MATRECTRANS record with transaction type (ISSUETYPE) of SHIPTRANSFER:

In Shipment Receiving application if received items are waiting inspection (WINSP), they exist in the Holding Location of the destination site, it creates a MATRECTRANS record with transaction type (ISSUETYPE) of SHIPRECEIPT visible from source storeroom:

In Shipment Receiving application additional MATRECTRANS records are created of transaction type SHIPRECEIPT or TRANSFER. Some items are fully received (Status=COMP) with a transaction type of SHIPRECEIPT. These are items where Inspection Required was left unchecked or rotating items which do not need to be serialized, perhaps because the asset has previously existed in the destination site.

If on the Inventory Usage line Inspection Required was checked and on initial receipt the status moves to WINSP – Waiting for Inspection, or the status moves to WASSET – Waiting for Serialization (which can occur without an inspection), then there will be both a SHIPRECEIPT and a TRANSFER transaction. In this case, the sites Holding Location is used, and its GL Account is referenced.

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.

If Inspection Required was checked or there is a transfer of a rotating asset that requires serialization, then it creates a MATRECTRANS record with transaction type (ISSUETYPE) of SHIPRECEIPT visible from both the source storeroom and the destination storeroom, if the record already exists in this storeroom:

If Inspection Required was checked or there is a transfer of a rotating asset that requires serialization, after completion of the inspection and serialization steps the status is now COMP, then it creates a MATRECTRANS record with transaction type (ISSUETYPE) of TRANSFER visible from the destination storeroom:

If Inspection Required is unchecked and we are not transferring a rotating asset that requires serialization, then after receipt the status is COMP, then it creates a MATRECTRANS record with transaction type (ISSUETYPE) of SHIPRECEIPT visible from both the source storeroom and the destination storeroom:

The first MATRECTRANS record created in the Shipment Receiving application has a GL Credit Account that is the source Organizations Clearing Account. The Organizations Clearing Account is used for all shipments even between two storerooms in the same site.

For transactions that originate against an internal PO its GL Debit Account is not used in the final receipt via a shipment, the destination storeroom or inventory control accounts are used depending on the issue cost type in the destination storeroom.

Leave a Reply

%d bloggers like this: