A readable product barcode is only the first input to a recall or quality-hold task. The warehouse still has to determine whether the physical item falls inside the controlled scope, prevent affected stock from moving, and preserve who made the decision under which list version. A product match without the required lot or serial match can isolate too much stock—or release the item that matters.
This guide is for warehouse operations, quality teams, recall coordinators, WMS integrators and handheld-terminal buyers. Its examples are editorial, not customer deployments, compliance advice or device tests. Commercial starting points are the handheld-terminal category, warehousing and logistics, Integration Support and Contact. The authorised quality process—not the scanner—owns the recall scope and disposition.
Freeze the scope before scanning stock
Give the task a controlled reference: notice or case ID, approved version, issue time, issuing role, effective sites and the identifiers that define inclusion. A later revision may add or remove lots, so an offline list needs a visible version and freshness rule. If the application cannot prove that the local list is still authorised, it should stop for a refresh or supervisor decision rather than silently treat an old list as current.
GS1's Global Traceability Standard, Release 2.0.0, ratified August 2017, distinguishes class-level identification from batch/lot-level and instance-level identification. It explains that a GTIN alone distinguishes the product class, while GTIN plus lot distinguishes one production group and GTIN plus serial can identify one instance. That is why a product-only match is insufficient when the controlled scope names a lot or serial.
The standard supports identification and traceability design; it does not define a regulator's obligations or a specific warehouse application's approval workflow. Record those project rules separately.
Keep captured, looked-up and entered values separate
First preserve the raw decoded value. Then identify which fields were actually encoded, which values came from master data or a recall list, and which were entered by an operator. A linear retail barcode may contain only a product identifier. A GS1-128, GS1 DataMatrix or GS1 QR symbol may carry additional attributes when they are encoded and correctly parsed. The handheld cannot reconstruct a missing lot from the product number alone.
The GS1 parsing guide covers Application Identifier and delimiter handling. For a recall check, the important extension is provenance: do not display a looked-up lot as if the scanner read it from the label.
| Evidence field | Example | What it proves—and does not prove |
|---|---|---|
| Raw scan | ITEM=042;LOT=L2407B |
Preserves the teaching input; it does not prove that the item is in scope. |
| Parsed product | 042 |
Identifies the compared product under the project's mapping rule. |
| Parsed lot | L2407B |
Supplies the lot only if that field was truly encoded and parsed. |
| Scope reference | HOLD-27 / revision 3 |
Identifies the list used for the decision; it does not move inventory. |
| Match result | item and lot matched |
Supports the decision branch; it does not prove physical isolation. |
| Isolation result | Q-02 / blocked / accepted |
Records physical location, inventory state and backend acknowledgement separately. |
Walk through a two-lot editorial example
Assume quality notice HOLD-27, revision 3, covers product 042, lot L2407B, at warehouse WH-A. Lot L2407C of the same product is outside the listed range. These identifiers and all results are constructed for explanation.
The operator opens the named task and scans a case. The application retains the raw data, resolves product 042, reads lot L2407B, and compares both fields with revision 3. It displays match: isolate, asks the operator to confirm the source location and quantity, and directs the case to quarantine location Q-02. Completion requires three independently observable results: the case is physically placed in the controlled area, the relevant inventory quantity receives the approved blocking status, and the backend accepts a disposition-pending record tied to HOLD-27.
The next case scans as product 042, lot L2407C. A product-only rule would wrongly isolate it. The complete comparison displays product match, lot outside scope and keeps it out of the recall action unless another quality rule applies. The event can still be logged as checked against revision 3.
Now remove the lot from the label. The item matches but the decisive field is unavailable. The application should route it to lot unresolved—perhaps for a readable secondary label, packaging record, authorised lookup or manual review. It must not copy the lot from the previously scanned case or infer the nearest lot from storage position.
Separate isolation from system blocking
Moving a case behind a quarantine line does not automatically stop allocation in the WMS. Conversely, changing an inventory status does not prove that the case reached the controlled physical area. Design the workflow so the operator can see which result remains open.
Microsoft Dynamics 365 Supply Chain Management provides a bounded software example. Its current inventory blocking documentation describes manual blocking, quality-order blocking and inventory-status blocking. Its quarantine orders page describes transfers to a quarantine warehouse and distinct order states. Those mechanisms belong to that configured product; they are not features supplied by an arbitrary barcode terminal.
The existing returns guide covers inspection and routing of returned goods. A recall check starts from a controlled affected-population definition, which can apply to otherwise saleable stock already in the warehouse.
Give every unresolved condition a safe branch
A practical task needs more than match and not match.
– Unreadable label: retain the task and location, then use the approved secondary identification or manual-review route. Do not type a convenient lot without a source. – Item found, lot missing: mark the decision unresolved and prevent release under a lot-specific task until the required evidence is obtained. – Scope list expired or superseded: stop the comparison, preserve scans already captured and load the authorised revision before continuing. – Unknown product mapping: retain the raw value and route to master-data review; do not strip digits or force it to the closest item. – Duplicate scan: show the existing case or container event and require the project's deliberate recount or reversal action instead of producing a second isolation quantity. – Offline completion: keep the physical hold visible, queue the inventory-state transaction with an idempotent operation identity, and verify the server result after reconnection.
The offline transaction guide explains why an attempted submission, an accepted transaction and a retried transaction are different states. A recall workflow should reuse that pattern without treating an offline queue as completed backend blocking.
Preserve the disposition decision after the hold
Isolation is usually an interim state. Release, return, rework, destruction or another outcome must reference the authorised decision, affected identity, quantity and actual operation. Scanning the same label later should reveal the current case state rather than silently create a new case.
The component traceability guide explains forward and reverse links for manufacturing use. Here, the record must answer a different question: what stock was checked against which scope, what was isolated, and what authorised disposition followed?
Keep corrections auditable. If a lot was entered incorrectly, retain the original observation, corrected value, reason, actor and time. Do not overwrite the record and then present the corrected value as if it had been scanned initially.
Accept the complete workflow, not just decode speed
Prepare samples for an affected lot, an unaffected lot of the same product, an unreadable label, missing lot data, a duplicate scan, an expired offline list and a failed backend update. Verify raw characters in a neutral receiving field before evaluating application parsing. Then test scope selection, decision display, physical instructions, inventory blocking, retry identity, supervisor actions and the final backend record.
The FEFO guide selects usable stock under allocation rules; it does not define recall scope. The scanner may capture the same item and lot fields, but the business decision is different.
Bring the authorised scope format, sample labels, product/lot master data, location model, inventory-status rules, offline policy, disposition approvals and audit requirements to the project review. Ask AIDC GO for model-specific capture and integration material needed to test the proposed flow. The defensible outcome is a chain of evidence—scope, physical identity, isolation, system state and disposition—not a green scan indicator.