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.
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.
An ERP system can create a UOM definition by mapping the UOM Client SKU with the child client SKU and Child UOM quantity.
UOM Client SkuId - UOM client SKU Id.
child Client SkuId - the next clientSkuId that the UOM can be broken into.
child UOM Qty - the quantity of the nextBreakableSkuId that the UOM can be broken into
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
{
"uomSkuDefinitions": [
{
"childClientSkuId": "98745678932",
"childUomQty": 24,
"uomClientSkuId": "98654342567"
}
]
}
Parameter Name | Data Type | Description | Mandatory |
| Object [ ] | SKU definitions of the product | yes |
| String | It represents the UOM Client SKU ID, a unique identifier for a specific UOM product. | yes |
| String | It represents a unique identifier for the next SKU that the UOM can be broken into. | yes |
| Integer | It represents the number of child products that a Main/ UOM product can be broken into. | yes |
Response
EmptyBody
HttpStatus : 200
Validations/ Constraints
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.
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.