...
Base SKU or primary SKU can be SKU A. The subsequent UOMs for the base SKU A can be A5(which is a pack of 5 items), box of 20 (which is a box of 20 items).
Master Data setup and definitions
Masters will come from ERP or CSV upload.
...
Constraints
There will be no restriction of mapping items to bin or in bin put-away. A single bin can have multiple UOM items. Ie. The same bin can have eaches as well and cartons as well. The system will not restrict this. If it's required then OPS will have to manage this.
Inventory exposure via API to Outer world will always be in eaches quantity.
Orders will come via API OR CSV will always be in eaches qty.
| Note |
|---|
|
Master Data setup and definitions
Master data definition process:
Article masters definition will have two parts:
Each
UOM definition
SKU-related attributes like weight, dimensions, image URL, category, style, size,
...
colour, etc will be separate for eaches and UOM SKUs.
Eaches and different UOMs can have different SKU barcodes or the same SKU barcodes
In the UOM definition, only single SKU definitions will be supported
...
that is pack of 10 A, and not Pack of 5 A and 5 B
...
This is how the UOM definition will be uploaded into the system. :
Name | Barcode | Client sku | Qty of constituents | Consists of what ? | Representative Qty of each | Client Sku Id | Min threshold |
Pack of 5 | A5 | A5 | 5 | A | 5 | A | 10 |
Pack of 6 | A | A6 | 6 | A | 6 | A | 10 |
Carton of 30 | A | A30 | 5 | A6 | 30 | A | 1 |
Notes :
...
...
“Pack of 5” of A is made up of 5 pieces of A.
...
“Carton of 30” of A is made up of 5 pieces of “Pack of 6”
...
The carton of 30 is made up of 5 qty of A6, hence the carton of 30 can only be defined with or after the definition of A6.
...
Min threshold Inventory level will be used by OPS to determine when a bulk break operation is required.
...
Min threshold will be a field to capture min qty of UOM, below which we need to replenish the UOM.
...
Min threshold will be captured through sku attributes.
...
Consists of how many pieces mean the next UOM in which the current UOM can be broken down
The system will expose an API to create and fetch definitions for each client SKU.
For perishable SKUs, batches will be created during gate entry.
Orders and Inventory
Inward Flow
At the time of GRN, Operations will scan the barcode, if multiple UOMs have the same barcode operator will be shown a popup to input what they are inwardingin-warding. If the barcode is unique then directly it will get selected.
Item id will be pasted on handling units (as per UOM) . Ex - If for example if a carton is being inwardedin-warded, stickers will be pasted only on the carton.
There will be no restriction of mapping items to bin or in bin putawayput-away. A single bin can have multiple UOM items. Ie. The same bin can have eaches as well and cartons as well. The system will not restrict this. If If it's required then OPS will have to manage this.
In our view, OPS should create physically different zones for the storage of cartons and eaches. GRN will happen in cartons so all GRNed Bins can directly go to carton storage zones.
Later replenishment teams can break those cartons into each and bring that inventory to each zone.
At the time of gate entry we will allow for the operator to define the external batch and expiry for the eaches UOM SKU.
At the time of GRN the defined expiry and batch details will be available for the warehouse operator to select for the larger UOM that they would be inwardingin-warding. The same details of expiry and batch will then get associated with all the items that are part of the UOM being inwardedin-warded.
Inventory management
The system will have all the inventory in eacheaches, and all UOM sizes. Inventory reports will be available for OPS to see. Inventory Inventory updates will be on eaches only to the marketplaces and to all external sources.
Outward Flow
Inventory exposure is in eaches, .
Orders will come in eaches.
Listings will be created for eaches only.
Once the order is received in the system, the system will run an allocation logic to determine how many cartons, packs , or each have to get shipped from WMS.
For perishable SKUs, orders will either come with a batch id or have a min expiry value.
...
Client sku id
...
Barcode
...
GSKU
...
Batch Id
...
A1
...
ABC_1234
...
G1
...
123
...
A1
...
ABC_1234
...
G1
...
124
...
A1
...
ABC_1234
...
G1
...
125
...
A5
...
ABC_1
...
G2
...
123
...
A5
...
ABC_1
...
G2
...
124
...
A5
...
ABC_1
...
G2
...
125
...
A30
...
ABC_123
...
G3
...
123
...
A30
...
ABC_123
...
G3
...
124
...
A30
...
ABC_123
...
G3
...
125
A1 has 3 batches, G1-123, G1-124, and G1-125. Similarly, A5 and A30 also have 3 batches.
Now inventory allocation will happen as follow
...
GKSU
...
Batch Id
...
Allocated Qty
...
G3
...
123
...
1
...
G3
...
124
...
1
...
G3
...
125
...
1
...
.
...
Bulk break
When required, one will be able to break larger UOM into smaller UOM.
Every unit of smaller UOM will be stickered at this step.
If there is an external item Id, one will have to scan them at the time of the bulk break
Its operationally more hygenic hygienic and clear to do bulk break activity separately from outward order processing
...
In master, we are capturing the Min threshold value against every global skuSKU. WMS will have a screen which will show what all skus SKUs are going below the min_threshold and what all skus SKUs bulk break is required to fulfill fulfil the orders. This screen will highlight SKU, where current inventory - is [unallocated-qty < min threshold] for an global skuSKU.
Create task
Operator will release a bulk break task against any skuSKU. This means telling system that they want to carry ou a bulk break activity for X qty of SKU A30. SKU A30 breaks into 5 of A6. This is similar to a picklist.
Bulk break pick
WMS will have a screen to show Bulk break pick pending. Represents where all bulk brak break activity is to be carried out.
WMs WMS will have a screen where operator will go and scan the location to get guided picking for Items to be picked up for bulk breaking. similar to picking. system will show SKU, batch etc. Operator will scan item ids . and move to next location. No need to auto aisle suggestion here. Items will move to a X state which represents, picked-for-bulk-break. These items can now either be marked lost or take to next screen for bulk break processing.
Bulk Break desk
WMS will have a screen for Bulk break desk. Operator will scan the item id from the previous step.
At this point items ids which are getting printed are only Item temps. System will apply checks etc then enable :
Print all stickersbutton to Print all item id stickers for the contents of the original item. For example, 1 item of A30, as per definition breaks into 5 items of A6, System will auto print 5 Item id stickers of A6.Print 1 stickerbutton to print only 1 sticker of constituent item. It is possible that say 2 stickers got wasted as printer was not working, operator will print them individually.
System will show that paste stickers, and scan 5 items. Operator will have to scan all required items, then press confirm bulk break button. System will validate that only 5 items are scanned.
At confirm, these items will become NEW. and Original Item Id will move some end state representing bulk break. Operator will have to scan all items to a bin Operator will putaway the bin and then put-away to make the items as LIVE. System will also capture the mapping that Item Id XYZ got bulk break into 6 z1,z2,z3,z4,z5 etc.
Returns
B2C Returns will be
...
received on
...
eaches only.
...
If say A10 was shipped, then operator will have to open the A10, print 10 stickers of A, and then process 10 items of A
Return expectations will also come on eaches.
B2B returns will be same as inwards.
...
\uD83E\uDD14 Assumptions
Eaches and different UOMs will have different SKU barcodes or the same SKU barcodes
In the UOM definition, only single SKU definitions will be required. I.e Pack of 10 A, and not Pack of 5 A and 5 B
There will be no restriction of mapping items to bin or in bin putaway. A single bin can have multiple UOM items. Ie. The same bin can have eaches as well and cartons as well. The system will not restrict this. If it's required then OPS will have to manage this.
Inventory exposure via API to Outer world will always be in eaches qty
Orders will come via API OR CSV will always be in eaches qty
Listings will be created for eaches only
Notes
Constraints on batch details wont be a problem as unique is on gsku, externalBatch, partnerId. So UOM can have same batch replicated as that of eaches batch
VIrtual SKU Definition will always be on Each level of child’s SKUs
Virtual Combo SKU inventory exposure will always calculate the Virtual Combo SKU inventory on only eaches of child SKU.
During customer cancellation reverse order of UOM will be followed.
During seller cancellation, deallocation [need to think more] how sub order items will be created, fulfilment items should be.