Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...

Info

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.

Request

Code Block
languagejson
{
  "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

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

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

Nuances

  • UOM support in postings, as of now is not there, i.e., we are not sending the UOM definitions along with postings.

  • There is no support for UOM listings, as of today we do not allow listings of UOM. (As complexities are there around inventory exposure of UOM to the marketplace and the same goes for order allocation)

  • UOM SKU definition once provided cannot be updated. UOM support in the update article master/ update definition APIs is not there.