Overview
When Logiwa IO converts a higher pack type (such as a Case or Pallet) to individual units (UOM), it does more than change a label. The system creates new unit-level inventory records, transfers all applicable tracking data from the original stock, and writes a permanent transaction record. This article explains what is preserved, what appears in your audit trail, and what is not supported in the current release.
What Logiwa IO Preserves at Conversion
All of the following attributes are automatically carried from the source inventory to the resulting unit records, provided the relevant tracking setting is enabled for the product and client:
Attribute | Preserved at conversion |
Lot / batch number | ✅ Yes |
Expiry date | ✅ Yes (required for expiry-tracked products) |
Production date | ✅ Yes |
Receiving date | ✅ Yes |
Purchase Order (PO) number | ✅ Yes |
Damage reason | ❌ No — damage reasons are not propagated to unit records |
Serial numbers | ❌ No — see Limitations below |
Conversion Rules — Applies to All Contexts
These rules apply whether conversion occurs during replenishment, a mobile transfer, or from the web:
Higher pack types only: Only Case, Pallet, Box, or other configured higher pack types can be converted. UOM inventory cannot be converted.
Whole packs only: The quantity must be a whole multiple of the product's UOM ratio. Partial pack conversion is not supported. If the quantity is not a whole multiple, conversion does not execute — the task or transfer completes with the higher pack type as-is.
UOM ratio required: If the product's UOM ratio is not configured, conversion is blocked.
Atomic operation: Conversion and the associated inventory movement execute as a single transaction. If any step fails, the entire operation is reversed automatically — there are no partial conversions.
Transaction History
Every conversion event is recorded in your Transaction History. Logiwa IO reuses the existing replenishment or inventory movement transaction type — no new transaction type is created. The conversion event is identified by the From Pack Type and To Pack Type fields:
Field | Replenishment (pick phase) | Transfer |
Transaction Type | Replenishment | Inventory Movement |
From Pack Type | Case (or higher pack type) | Case (or higher pack type) |
To Pack Type | Unit (or UOM pack type) | Unit (or UOM pack type) |
Lineage fields | Lot, expiry, PO, receiving date, associate, timestamp | Lot, expiry, PO, receiving date, user, timestamp |
When From Pack Type ≠ To Pack Type, the transaction marks a conversion event. When both are the same, no conversion occurred.
Initial Task Qty (Replenishment only): A new Initial Task Qty column is available in the replenishment task details table. This field is set at task creation and is immutable — it always shows the original higher pack type quantity as generated, even after conversion updates the task quantity to reflect UOM units. This allows you to compare the pre-conversion and post-conversion states in a single task record.
Known Limitations
Limitation | Detail |
Serial numbers not propagated | For products with serial number tracking enabled, unit records created by conversion will not carry individual serial numbers. This will be addressed in a future release. |
Mixed-SKU LPs (replenishment) | Conversion is not supported for LPs containing more than one SKU. This is a permanent exclusion. |
LP transfers and location transfers | Conversion is not available when transferring an entire License Plate or an entire location. |
Partial pack conversion | Not supported in any workflow. Quantities must be whole multiples of the UOM ratio. |
Putaway location suggestions | During directed putaway (transfers) and in Direct Put replenishment flows, the location suggestion is always based on the original higher pack type. The system cannot generate a UOM-based suggestion. This is a permanent characteristic. |
Pick & Put job cancellation after pick | If a Pick & Put replenishment job is cancelled after pick completion (when conversion has already executed), cart inventory remains as UOM units. It is not automatically reverted. |
Common Questions & Edge Cases
Why does the transaction history show From Pack Type = Case and To Pack Type = Case on some replenishment tasks?
This means conversion was suppressed for that task or the job type toggle was not enabled. No conversion event is recorded when both pack types match.
Can I see which tasks triggered conversion in the replenishment task table?
Yes. Compare the Initial Task Qty column (original case quantity) against Task QTY (post-conversion UOM quantity). If they differ, conversion occurred. If they are equal, conversion was suppressed or did not apply. For pick and put operations, compare quantities and pack types between pick and put tasks seperately. In pick tasks, task qty is based on the case pack type and put tasks will reflect the unit qty.
What happens to inventory traceability from the original Purchase Order?
PO number, receiving date, and LP traceability are all preserved on the resulting unit records. The inventory lineage from receipt through to pick face is maintained end-to-end.
Related Articles