In the Item Master application there are two fields with a lookup to units of measure.

The Order Unit is the unit of measure in which you purchase the item. For example, you may only be able to buy an item in a packet of 25, or you may only be able to buy specialist oil in 50 litre drums.

The Issue Unit is the unit of measure in which you issue the item to a work order or person, it is also the same unit of measure in which you would return unused items. It is the unit of measure that reflects the balance quantities in a storeroom.

In many cases items will have the same unit of measure for the order unit and the issue unit and this will often be set to EACH. It would be good practise to have both fields made mandatory on the Item Master application with a default of EACH and for you to change this if needed.

If the order unit and issue unit were not the same what does this mean?

If I order and receive a case of an item that is destined for a storeroom how will I know how much the balances in the storeroom need to be increased? The answer lies with creating a conversion for how to convert from the order unit to the issue unit.

There is an action Unit of Measure and Conversion with two sub actions:

• Add/Modify Units of Measure is used to add or modify a unit of measure. It is the same dialog box as you will find in the Classifications application.
• Add/Modify Conversions is used to tell Maximo how to convert from a quantity of the order unit to a quantity in the issue unit when receiving an item for a storeroom.

Our example above with an order unit of CASE and an issue unit of EACH was for item 1025, and this is shown as the last row in the diagram above with a conversion factor of 24. Therefore, if I order 5 cases of item 1025, when I receive the item the balances will be incremented by 5 x 24 = 120.

You will notice that when adding a new row, the Item Number in the conversion is optional. Conversions are used in Maximo during the Receiving and Transfer processes in which case there is always an item involved. Therefore, consider making this field mandatory to avoid confusion. For example, a conversion of BOX to EACH with a conversion factor of 250 and no item would lead to issues when I ordered another item with an order unit of BOX, except in this case it was a box of 25. You can get around this by having a unit of measure of BOX25, but then you will soon have BOX5, BOX10 and other units of measure starting with the word BOX and that would unnecessarily add rows to the units of measure lookup. So better, to always use the Item number field on the Add/Modify Conversions dialog.

Using the example, I ordered a quantity of 1 CASE of item 1025 for the CENTRAL storeroom at a cost of 480 USD. I then received the item in the Receiving application. If you then go to Inventory application and use the action View Inventory Transactions you will see that while I received a quantity of 1 from an order perspective, from an inventory perspective I received a quantity of 24, it has performed the conversion. It has also divided the line cost by the received quantity to obtain a unit cost and actual cost of 20 USD per quantity held in the storeroom.

For the Advanced Maximo User

Order Unit for Items on Purchasing Documents

The Order Unit in the header of the Item Master application is a default for the PR or PO line for direct issue items. The reason you should consider making it mandatory in the Item Master application is that when you order the item on a PR or PO the Order Unit field will be mandatory, it will be much easier if it is defaulted on the PR or PO line.

However, when ordering items for a storeroom the order unit is actually derived from either the Inventory record or the Inventory Vendor record.

In the action Add Items to Storeroom from the Item Master application you will see an Order Unit field. You can then find the order unit field by looking on the Reorder Details tab on the Inventory application.

But what will happen if we later change the order unit on the Item Master application?

I’ve done this and have now added the item to the MACHSHOP storeroom and you can see above that the order unit is EACH.

Now I’ll order the same item from both the MACHSHOP storeroom (line 1) and the CENTRAL storeroom (line 2). This is for a new vendor, I haven’t previously purchased the item from them.

As you can see, I have a different order unit on each line. The order unit is actually coming from the Inventory record, as there has been no purchase of this item from the vendor.

To illustrate the next part, I have ordered the item from vendor GMC and on purchase order 1140 above I changed the order unit for line 1 to CASE and approved the PO. You can see this in the Reorder Details tab.

To recap,

• In Item Master the order unit is set to EACH
• In Inventory for MACHSHOP storeroom the item has an order unit of EACH
• But we, have previously purchased the item for this storeroom from BMC when the order unit was CASE.

What happens if we make another purchase for MACHSHOP of this item? Well it depends on who we purchase the item from.

If we purchase from a vendor we have never used before for this item, then the order unit will be defaulted from the Inventory record (EACH).

If, however, we purchase from a vendor we have used before for this item, then the order unit will be defaulted from the Inventory Vendor record (CASE).

Issue Unit and Conversion for Items on Purchasing Documents

The Issue Unit in the Inventory application is a default for a PR or PO when the purchase is being made on behalf of a storeroom, when the storeroom attribute has a value the issue unit will be filled.

The Conversion attribute on the PR or PO line will be filled automatically when the item and storeroom is referenced. If the purchase is a direct issue to a work order the conversion factor will be set to 1, meaning that we could be purchasing a case of 24 for the work order, if the order unit is CASE on the Item Master.

Tools and Service Items

Now we have considered the order unit and issue unit in the Item Master application, how about Tools and Service Items?

• In the Tools application there is an Issue Unit but no Order Unit.
• In the Service Items application there is neither an order unit or an issue unit.

An order unit in the Tools application would make sense because when you order the item on a purchase order line on behalf of a storeroom the order unit will become mandatory, so better that it is defaulted. The issue unit will be defaulted from the issue unit on the storeroom for that tool item.

An order unit in the Service Items application would also make sense because when you order the item on a purchase order line you will probably be entering an order unit. The issue unit makes no sense at all for service items as they are not held in a storeroom.

In both cases for Tools and Service Items the order unit is actually defaulted from the order unit on the Vendors table window for the vendor entered on the purchasing document. If you have not purchased the item from the vendor previously then you will need to enter the order unit on the PR or PO, but thereafter it will be defaulted for you.

Transfer Considerations

What if you wanted to keep both whole cases in a storeroom ready for transfer to other storerooms, and issue items individually for local consumption?

The Issue Unit is held at the Inventory level and not at the inventory balances level. There are two choices:

• Create two items with different issue units. This is effectively duplicating the item, however, it better fits an e-commerce scenario where the same physical item is likely to have multiple catalog items.
• Create a separate storeroom for use as a storeroom for eventual transit.

If you have a central physical storeroom this does not mean that you need to have one central Maximo storeroom, you could have multiple Maximo storerooms all physically located at the site of the central one. For example, CENTRAL and CENTRAL01, let’s call that the Central Bulk Storeroom. CENTRAL would have an issue unit of EACH, because we issue items individually, and in CENTRAL01 it would have an issue unit of CASE, for forward transfer to other site storerooms.

If you use an Inventory Usage record of type Transfer then:

• If CENTRAL01 had a quantity of 1 case and you transferred to CENTRAL a quantity of 1 and it currently had a quantity of 2, then CENTRAL01 quantity will be 0 (1 minus 1) and CENTRAL quantity will be 26 (2 + (1 multiplied by the conversion factor of 24)).
• If you then tried transferring back from CENTRAL which has a quantity of 26 to CENTRAL01, with a quantity of 24, the conversion factor will 0.04. When you complete the Inventory Usage document, the CENTRAL quantity will be 2 (26 minus 24), and the CENTRAL01 quantity will be 0.96 (24 multiplied by a conversion factor of 0.04). There is a rounding issue because the conversion field is set to 2 decimal places.

You could increase the attribute INVUSELINE.CONVERSION from 15,2 to 19,6 to reduce the occurrences of rounding issues but I expect you cannot eliminate it without Java custom code.

Therefore, if the quantity received from the vendor is typically converted from an order unit to an issue unit and you transfer the received items to other storerooms as whole cases, or whole drums then I would recommend receiving into a bulk purchase storeroom, CENTRAL01 in our case. That would avoid the occurrences of rounding issues as the conversion would not occur until it was transferred to one of the storerooms from which it is issued to a work order or person.

Work Order and Desktop Requisition Reservations

When you make a reservation from a work order against a storeroom the quantity being issued is in the issue unit of that storeroom. If you are using different issue units for the same item in different storerooms, then it may be wise to expose the issue unit on the work plan materials and actual materials tabs in Work Order Tracking application as otherwise someone might wonder why they are paying a higher unit price on one work order to another for the same item.

The Create Requisitions application, which is part of Desktop Requisitions, has the issue unit exposed and defaults to the issue unit from the chosen storeroom. Similarly, in Inventory Usage application the issue unit is also exposed and is read-only. So, if you expose this field on Work Order Tracking, you should also make it read-only.

Reorder Process

When reordering from a storeroom the order unit that will be used will be the one on the Item Master record and will be EACH in our example.

When reordering from the CENTRAL storeroom where the order unit shows CASE, the order unit is EACH, taken from the Item Master record, however, it has taken into account that the order unit is CASE, and it has used the conversion factor to determine a quantity of 24 to be purchased.

When receiving this purchase order into the CENTRAL storeroom the balance quantity will be increased by 24, as the issue unit is EACH.

If I order from the CENTRAL01 storeroom where the order unit is CASE, and the issue unit is also CASE.

It makes no difference; the order unit has been taken from the Item Master record and the conversion factor applied to create enough quantity for one case.

When receiving this order into the CENTRAL01 storeroom the balance quantity will be increased by 1 because the issue unit is CASE.

Issue Unit on Inventory

The Issue Unit field in the Inventory application allows a user to change the unit of measure. This can be done when the balance is > 0, which potentially means the balance is incorrect, also the average cost of the item may need to be adjusted. This field will be defaulted from the issue unit field on the Item Master application, therefore, you may wish to consider restricting who can change the value in this field.

Org/Site Considerations

While units of measure exist at the SYSTEM level, they have an ORGID and SITEID attributes. If these are used, then you may see multiples of the same unit of measure in the lookups and this will be confusing for users (see below). I would recommend leaving the ORGID and SITEID blank and not filling them as part of data loading. You don’t see these fields exposed in the default dialogs for unit of measure, so I don’t believe they are really intended to be used.

Conversion records are defined at the ITEMSET level which really does suggest that the Item field should be considered mandatory. If you have multiple Item Sets in your Maximo implementation, then consider adding the Item Set to the Add/Modify Conversions dialog box.

Some concluding thoughts

The order unit in Maximo is being derived from the Inventory Vendor record, but if it hasn’t been purchased before, then it will use the order unit from the Inventory record and for direct issue items it will use the order unit from the Item Master application. However, when using the Reorder process, it seems to be using the order unit from the Item Master application. Note, the test was performed on Maximo 7.6.1.

Having the Issue Unit different from one storeroom to another for the same item will work in Maximo but it could be difficult for end users to interpret. For example, the action View Item Availability will show quantities in different units for the different storerooms. Therefore, if you do have a bulk purchase storeroom and different issue units across different storerooms for the same item, you might want to additionally consider hiding the bulk purchase storeroom from the majority of users or changing the dialog to add the issue unit column.

If the issue unit is different from one storeroom to another then be careful about introducing rounding errors. Transferring from one storeroom to another when it is using the conversion factor to multiply the quantity is OK, but when it is being used to divide the quantity then rounding issues can easily occur.

It will be a lot easier all round if the Issue Unit was the same in all storerooms for the item. In which case, the best way to handle this is to ensure that the Issue Unit field on the Item Master is made mandatory and on the same field on Inventory it is made read-only.