A barcode can identify a case rather than a single item, but the scanner does not invent the relationship between those packaging levels. The warehouse application must identify which unit was scanned, retrieve the approved conversion for that item and configuration, and show the quantity that will reach inventory before the operator confirms it.
This guide is for warehouse operations, master-data teams, WMS integrators and handheld-terminal buyers. Its scenario is editorial, not an AIDC GO customer deployment or device test. Relevant project entry points are the handheld-terminal category, warehousing and logistics page, Integration Support and Contact. The selected WMS owns product, unit and conversion rules.
Give the scanned identifier and the transaction unit separate fields
The captured value first has to resolve to an item and, where applicable, a packaging configuration. The resulting transaction then needs a quantity and unit. A case-level GTIN can be mapped to a case unit whose master-data relationship is twelve eaches; scanning the GTIN is not itself the arithmetic rule.
GS1's Global Data Model Attribute Implementation Guide, Release 1.0, ratified December 2020, shows separate base, pack, case and pallet hierarchy levels, the contained GTIN and counts at the next lower level. It also distinguishes packaging level from consumer, orderable and shipping indicators. The guide supports a structured hierarchy; it does not tell a particular WMS which inventory unit to post.
Microsoft Dynamics 365 Supply Chain Management provides one software-specific example. Its product identifiers documentation explains that packaging variants can have specific units of measure and that multiple GTINs may be maintained per product and unit. Its unit-of-measure and stocking policies page requires conversions between units in a configured unit sequence and gives 100 Pcs = 1 PL as an example. These behaviors belong to that configured product, not to every handheld or WMS.
Keep packaging identity, conversion and work quantity visible
Record at least four values for a scan: the raw identifier, the packaging unit it resolves to, the effective conversion record and the quantity requested by the work. If a screen only displays 2, the operator cannot tell whether it means two eaches, two cases or two pallets.
| Evidence | Example value | Why it remains separate |
|---|---|---|
| Scanned packaging identifier | CASE-GTIN-B |
Selects a configured item and packaging level; it is not the posted base quantity. |
| Resolved unit | CASE |
States the unit represented by the selected packaging record. |
| Effective conversion | 1 CASE = 12 EACH |
Comes from approved master data for the item, variant and effective configuration. |
| Work quantity | 2 CASE + 6 EACH |
Expresses what the task actually asks the operator to move or confirm. |
| Inventory result | 30 EACH |
Is calculated and posted only after the application validates the preceding values. |
The existing quantity-entry guide explains how item, quantity and unit stay in one transaction. This article addresses the prior question: which packaging unit was identified and which approved relationship converts it.
Follow an editorial each-and-case task
Assume item FILTER-A is stocked in EACH. Master data defines one sealed case as twelve eaches, and the case and each have different teaching identifiers. A replenishment task asks for thirty eaches. The intended physical selection is two sealed cases plus six loose eaches. All values are invented for explanation.
The operator opens the named task and scans the first case identifier. The application resolves FILTER-A / CASE, applies the effective 12 EACH per CASE rule, and shows twelve eaches pending. Scanning a second complete case brings the visible pending quantity to twenty-four eaches. The operator then scans the each-level identifier and enters or accumulates six eaches. Before confirmation, the screen shows both the physical selection—two cases and six eaches—and the base result of thirty eaches.
Now test an error. The operator scans an each-level code but chooses CASE manually. The application should reject the mismatch or require an authorised, visible override; it must not multiply the six loose items by twelve. A readable barcode and valid arithmetic can still produce the wrong inventory when the resolved packaging record and selected unit disagree.
This workflow differs from the pallet-receiving guide. An SSCC identifies a logistics unit and can link to described contents, while a unit conversion defines how a product's approved packaging level relates to another unit. Do not treat every pallet SSCC as a product-level pallet GTIN or derive a conversion merely from an ASN quantity.
Handle broken packs without silent subtraction
Suppose one twelve-each case has been opened and contains only nine usable items. Its printed case identifier still describes the original packaging configuration. The project must define whether the worker scans the individual items, performs an approved break-pack action, records three damaged units, or moves the remainder to a new container state. Silently treating the open case as 0.75 CASE may violate integer-unit, traceability or handling rules.
The application should preserve the observation that an opened package was encountered and the authorised transaction that converted or reclassified it. The hardware only captures the identifier and operator input. The picking-verification guide covers source item and destination-order checks; it does not define case conversion.
Also test a mixed pallet. A logistics pallet can contain multiple products or partial cases, so a single multiplication rule may not describe it. Use the actual content record and transaction instead of assuming one pallet always equals a fixed number of eaches.
Treat a packaging change as master-data change
If a supplier changes a case from twelve eaches to ten, the old conversion must not remain active for the new package. GS1's pack/case quantity rule states that a change in the number of trade items in a case, or cases in a predefined pallet configuration, requires a new GTIN for the affected higher packaging level. Local requirements may be stricter.
The receiving system must therefore know which case identifier and configuration it has scanned. Do not overwrite the old 12 relationship and thereby reinterpret historical transactions. Create or activate the approved new packaging record, preserve its effective boundary, and test both old and new samples during transition. If the barcode resolves to no current conversion, stop for master-data review rather than using the nearest unit name.
Variant-specific conversions are another boundary. Microsoft's unit conversion per product variant page documents a feature in which different product variants can use different pieces-per-box factors. It is a useful warning against applying one master conversion to every variant, not evidence that another WMS behaves the same way.
Close the transaction with observable results
Build acceptance cases for an each, a sealed case, a complete pallet configuration where applicable, a broken case, an outdated package, a wrong unit and a missing conversion. For each case, preserve the raw scan, resolved item and packaging unit, conversion version, work quantity, calculated base quantity, operator decision and backend result.
Verify the normal workflow on the proposed handheld: label position, scan feedback, field focus, unit display, correction controls and the final response. A fast scan engine does not compensate for hidden unit selection. The system should let the operator see and correct the pending physical and base quantities before posting.
Bring sample packaging labels, the item and variant hierarchy, approved conversions, effective dates, break-pack rules, order units, inventory units and exception cases to the project review. Ask the WMS owner to demonstrate the exact conversion and audit behavior. Ask AIDC GO for the model-specific capture and integration materials needed to test that configured flow. The defensible result is not merely a decoded barcode; it is a quantity whose identifier, packaging unit, conversion and transaction record agree.