Overview
When Logiwa IO converts a higher pack type (such as a Case or Pallet) into UOM (unit of measure) units, it doesn't just relabel the stock. It removes the higher pack type stock, creates unit-level stock, copies the tracking data across, and writes a transaction record. This article explains what is kept, how to find conversions afterwards, and what isn't supported.
Where conversion can happen
Where | How it's triggered | Owning article |
Replenishment (Pick & Put, Direct Put) | Automatically, when the job type has Allow Higher Pack Type Conversion to UOM on | |
Mobile Transfer Product and product directed putaway (Bulk and One-by-One) | The operator turns on Enable Converting to Units | |
Web Inventory by Location → Transfer Product | The user sets Convert Pack Type to UOM to Yes | |
Open API transfer product | The request includes breakHigherPackTypeToUom: true |
What Logiwa IO keeps
These attributes are copied from the original stock to the new units, when the product and client track them:
Attribute | Kept? |
Lot / batch number | ✅ Yes |
Expiry date | ✅ Yes (required for expiry-tracked products) |
Production date | ✅ Yes |
Receiving date | ✅ Yes |
Purchase order (PO) number | ✅ Yes |
LP | ✅ In replenishment LP flows the LP stays the same |
Damage reason | ❌ No. Damaged stock can't be converted in transfers |
Serial numbers | ❌ No (see limitations) |
Example: 2 cases of SKU-300, lot L-88, expiry 2027-06-30, PO-1450, are converted. The 24 resulting units carry lot L-88, expiry 2027-06-30 and PO-1450.
Rules that apply everywhere
Higher pack types only. Units can't be converted further.
Whole packs only. In transfers you enter whole packs. In replenishment, if the quantity actually picked isn't a whole number of packs (for example after picking more or less than the task), conversion is skipped and the task finishes in the higher pack type.
UOM ratio required. Without a ratio for the pack type, conversion is blocked.
One step. Conversion and the move are a single transaction. If any part fails, everything is rolled back.
Transfers only: the stock must be in Stock status (not allocated, picked, packed, sorted or loaded) and have no damage reason; you can't convert and mark as damaged in the same transfer; and on the web or API, all selected stock must be the same product and pack type.
Example: A Static job replenishes PICK-05, whose capacity is in Cases. Conversion is skipped and cases arrive as cases. If PICK-05's capacity were in Units, the cases would be converted.
Transaction history
No new transaction type is created. Logiwa IO reuses the existing types, and a conversion is visible because From Pack Type and To Pack Type differ.
Field | Replenishment (pick phase) | Transfer or putaway |
Transaction type | Replenishment | Inventory Movement |
From Pack Type | Case (or other higher pack type) | Case (or other higher pack type) |
To Pack Type | Unit (UOM pack type) | Unit (UOM pack type) |
Lineage | Lot, expiry, production date, PO, receiving date | Same |
In Pick & Put, two transactions are written: the pick (Case → Unit, the conversion) and the put (Unit → Unit). When both pack types are the same, no conversion happened.
Replenishment task fields
Field | What it shows |
Initial Task Qty | The quantity when the task was created. It never changes, so it keeps the original even after conversion, Allow Exceed Task Quantity or Update Task Quantity If Less Picked change Task QTY |
To Pack Type | Changes to the UOM pack type when conversion happens |
Task QTY | Pick & Put put task: updated to the unit quantity. Direct Put: stays at the case quantity |
Pack Type Conversion Applied | Yes/No column on the replenishment Task Details screen, also in its Excel export |
Example (Pick & Put): Initial Task Qty 34 (6-packs). After the pick, the put task shows To Pack Type = Unit and Task QTY = 204. Example (Direct Put): Task QTY stays 24 (6-packs), Task UOM Qty stays 144, and To Pack Type changes to Unit.
Known limitations
Limitation | Detail |
Serial numbers not carried | Units created by conversion don't carry serial numbers. Planned for a future release |
Mixed-SKU LPs (replenishment) | LPs holding more than one SKU can't be converted. This is permanent |
Whole LP and location transfers | Applies to transfers only: conversion isn't available when Transfer LP, Transfer Location or Directed LP Putaway moves a whole LP or location. In replenishment, LP tasks do convert the LP's contents |
Partial packs | Not supported anywhere |
Putaway suggestions | The first suggestion is based on the original pack type. Directed putaway: Suggest Another gives a unit-based suggestion. Pick & Put: in the put phase, Suggest Another Location can give a unit-based suggestion if the job type has Allow Suggest Another on. Direct Put: always based on the original pack type, because conversion and placement happen in one step |
Pick & Put cancelled after pick | Stock on the cart stays as units; it isn't converted back |
Common questions
Why do some replenishment tasks show From Pack Type = Case and To Pack Type = Case? No conversion happened: the job type setting was off, the Static rule skipped it, or the picked quantity wasn't a whole number of packs.
How do I find replenishment tasks that converted? Check To Pack Type: if it's the UOM pack type while Pack Type is a case, conversion happened. Comparing Initial Task Qty with Task QTY only works for Pick & Put put tasks, because Direct Put keeps Task QTY in cases.
Is traceability back to the purchase order kept? Yes. PO number, receiving date, lot and expiry stay on the units.