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.

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

• 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.