Enhance Item-Specific UOM Conversions Across Interfaces

We have introduced Item Specific UOM Conversions to help you receive and store inventories with one UOM class and fulfill orders or handle the corresponding billings in an another UOM class. This allows you to process purchase orders, inbound shipments, and sales orders with UOMs that belong to a different UOM class than the item’s primary UOM.

Also, you can easily keep a track of inventory in the Primary UOM while enabling customers and external systems to interact with UOMs, that are more relevant for your operations.

A new interface has been introduced to define item-specific UOM conversions between different UOM classes.

POST .../wms/lgfapi/v10/stage/item_specific_uom_conversion/

We have extended support for these conversions across multiple interfaces.

Input Interface:

• Work Order Interfaces and Planned Load Interfaces: Both Work Order Interfaces and Planned Load Interfaces now support processing records with a Unit of Measure (UOM) from a different class. The interfacing logic first attempts to apply item-specific conversion rules; if none are available, it defaults to standard conversions within the same UOM class. If no valid conversion logic exists for the different UOM class, the interface transaction will fail.

• Movement Requests: We support processing records with a Unit of Measure (UOM) from a different class in Movement Request. Also, we have introduced two new columns ordered_uom_qty and ordered_uom. 

New Column In Movement Request

Two New Columns in Movement Request Detail screen

Output Interface:

• OBLPN and Pallet Shipping Info files:

  • New fields in XML, PSV, and JSON formats:

    • ordered_uom

    • ordered_uom_qty

    • ordered_uom_alloc_qty

    • ordered_uom_packed_qty

  • In JSON:

    • curr_qty_in_ordered_uom (Inventory List)

    • ordered_uom_code

    • shipped_qty_in_ordered_uom (Order Detail List)

Steps to Enable

You don't need to do anything to enable this feature.