Inbound | POST | /master/uom-sku

Summary

This API is used to create a UOM SKU definition.

Description

The UOM (Unit of Measure) definition describes the relationship between different units of measure for items, such as eaches, boxes, cases, and pallets. It involves defining the primary UOM, and subsequent UOMs for the base SKU data setup.

<aside> ℹ️ Terminology

Eaches SKU: denotes the base SKU. UOMs for this product will be formed from this base SKU. For example, a munch is the eaches SKU, and a box of much is a UOM.
BulkBreak: The process of breaking the UOM SKU into the next breakable SKU. This can be done to replenish child SKUs to ensure picking optimization or to fulfill a pending order with the child SKU. </aside>

An ERP system can create a UOM definition by mapping the UOM Client SKU with the child client SKU and Child UOM quantity.

uomClientSkuId → UOM client SKU Id.
childClientSkuId → the next clientSkuId that the UOM can be broken into.
childUomQty → the quantity of the nextBreakableSkuId that the UOM can be broken into

<aside> ℹ️ After definition of UOM SKUs, GRN can be done for UOM SKUs by scanning barcodes and selecting the UOM being inwarded. Post GRN, inventory will be exposed in eaches SKU and orders are received on eaches SKU.

For Fulfillment, the order allocation logic is built in such a way that the larger UOMs will be allocated first.

</aside>

Request

{
  "uomSkuDefinitions": [
    {
      "childClientSkuId": "98745678932",
      "childUomQty": 24,
      "uomClientSkuId": "98654342567"
    }
  ]
}

Parameter Name	Data Type	Description	Mandatory
`uomSkuDefinitions`	Object [ ]	SKU definitions of the product	Yes
`uomClientSkuId`	String	It represents the UOM Client SKU ID, a unique identifier for a specific UOM product.	Yes
`childClientSkuId`	String	It represents a unique identifier for the next SKU that the UOM can be broken into.	Yes
`childUomQty`	Integer	It represents the number of child products that a Main/ UOM product can be broken into.	Yes

Response

EmptyBody

HttpStatus : 200

Validations/ Constraints

<aside> ⚠️

A Virtual SKU cannot be marked as UOM and vice-versa.
The maximum allowed value for nextBreakableSkuQty is 200, i.e a maximum 200 units of the next breakable SKU can be present in a UOM unit.
UOM SKUs will not be supported in kitting workflow.
Perishable UOMs cannot be defined with Non-Perishable each SKU and vice-versa. Ie, If each SKU is perishable then UOM should also be perishable.
UOM and NextBreakableSKU cannot be uploaded in single UOM definition creation payload.
Once the UOM definition is uploaded, it cannot be modified again.
Master data should be present in the system for UOM Client SKU with the is_uom flag should be true in master data.
Similarly, article master data/ definition for childClientSkuId should be present in the system.
- If childClientSkuId is a subsequent UOM SKU for the base product, then its definition should be created first separately. In the same payload, the UOM definition for both client SKU and childClientSku cannot be created.
- If childClientSkuId is non-UOM SKU, then article master data should be created first for childClientSku(if not already present in system).
UOM client SKU could not have multiple definitions in the system. </aside>