Barcode receiving that survives network interruptions

A warehouse operator scans a container and presses Receive. The device loses connectivity before displaying a response. The operator retries, then retries again when the screen still appears stuck. After reconnection, the inventory system shows three receipts for the same container.

The scanner read the barcode correctly. The failure sits between the physical action, the recorded event and the inventory posting. A useful offline design preserves those distinctions and makes uncertainty visible to the operator. It should support the approved contingency process while giving reconciliation staff enough evidence to establish what happened.

Identify the thing being scanned

Start with identifier granularity. An item barcode can identify a product without identifying a particular lot or container. A pallet identifier can identify a group whose contents may later change. The receiving workflow needs to know which object the scanned value represents.

Map the identifiers used by suppliers and internal operations to the records needed at receipt. Include product, batch, container or handling unit, quantity and unit as applicable. If a barcode does not carry a required attribute, establish a controlled way to obtain it rather than pretending the scan supplied everything.

GS1 EPCIS provides a standard for exchanging visibility events between systems. It can inform interoperable event design, but it does not itself prevent duplicate inventory postings. GS1 EPCIS standard.

The duplicate-posting protection belongs in the receiving transaction and its integration contract. A unique container identifier also needs a defined lifecycle: a legitimate later movement of that container must not be mistaken for a retry of the original receipt.

Give the event an identity before sending it

Create a stable receiving-event identifier when the operator confirms the intended action. Preserve that identifier in the local queue and use it for every retry of the same event. Generate a new identifier only for a genuinely new business action.

Include the operator, device, source transaction, scanned object, quantity, unit and relevant event time. Record when the central system received and posted the event separately. A delayed upload should not erase the distinction between observation time and processing time.

The server should retain the event identity with the posting result. When the identical event returns, it should return the recorded outcome rather than execute another movement. This behaviour is often called idempotency: retrying the same authorised operation does not repeat its business effect.

Do not rely only on the device remembering which requests succeeded. Devices can restart, queues can be restored and acknowledgements can be lost. The receiving service must recognise retries across those recovery paths for the defined retention and replay window.

Follow three retries through one receipt

In an illustrative receipt, event R-900 records one 25 kg container against a purchase-order receipt line. The central service accepts the event and posts 25 kg, but the acknowledgement never reaches the handheld.

The device sends R-900 three more times after reconnecting. Each request contains the same material, container, quantity and business references. The service returns the original posting reference each time. The inventory movement remains 25 kg, not 100 kg.

Now change the last retry to 30 kg while retaining R-900. That is no longer an identical retry. The service should reject or quarantine the conflict for the defined resolution path, preserving both payloads and the original outcome. Treating the new quantity as an update would hide a material change inside a recovery operation.

If the operator truly needs to correct the receipt, use the authorised correction workflow with its own record and reference to the original movement.

Show operators what is known

Use distinct interface states such as captured locally, awaiting submission, accepted centrally and needs resolution. Labels should describe the current evidence. A green “received” message is misleading if only a local queue entry exists.

Tell the operator what to do next when the network is unavailable. Can the container enter a designated receiving area? Can it be moved internally? Is another activity prohibited until central confirmation? Those decisions come from the approved operational contingency arrangements.

Avoid making operators repeatedly scan because a queue is invisible. Show pending events and provide a safe way to inspect their details. A retry control should resend the existing event rather than create a new business event with every tap.

Design for real warehouse conditions: gloves, damaged labels, noisy work areas and shared device handovers. A useful screen makes the container and pending action obvious without requiring the operator to interpret technical error codes.

Define the outage boundary explicitly

Offline capture is not permission to perform every online action. A device may hold an old quality status or an outdated material mapping. Decide which actions remain permissible with that information and when the operation must stop or use a different approved procedure.

For example, recording a physical arrival can be different from authorising material use. The inventory-status guide explains why these should remain separate. On reconnection, a previously captured observation may need reconciliation against current information rather than automatic acceptance as a permitted movement.

EU GMP Annex 11 addresses tested continuity arrangements for relevant computerised systems. Determine applicability to the system before using it as a requirement. Annex 11, section 16.

Document the local data needed for the permitted activities, how it is protected and what happens when the device's offline operating limit is reached. A cached login should not silently grant indefinite access after a role changes.

Give reconciliation an accountable owner

The reconciliation queue should distinguish duplicate retries, conflicting payloads, unknown objects, invalid quantities and transactions that no longer fit the source order. Each category needs a clear action and owner.

Do not close every exception by deleting the local event. Some events represent physical activity that must be accounted for. The reviewer needs the original capture, central response, relevant stock state and any correction history.

Reconcile device queues after a restart or replacement. If a device is lost, establish which pending events may be missing and assess the physical stock against the available records. A cloud backup is helpful only if the recovery process demonstrates what it restores and what uncertainty remains.

The integration exception guide covers the wider handling of delayed and conflicting messages. Receiving should use that operating model rather than leaving unresolved events in a developer-only log.

Test physical and digital recovery together

Test loss of connectivity before submission, after central posting and during acknowledgement. Restart the handheld with pending events, resend an identical event, change a payload under an existing identifier and submit a new legitimate movement for the same container.

For every scenario, reconcile physical stock, inventory movements and event outcomes. Verify that the operator sees a meaningful state and that the designated owner can resolve any uncertainty without editing the database directly.

Measure duplicate business postings, unresolved queue age and the time needed to reconcile an outage. Do not evaluate the design only by scan speed. A fast normal path with an unusable recovery path will create expensive manual work when connectivity fails.

NextEdge Labs can help define the transaction contract and build the reconciliation interface around these cases. The cycle-counting guide provides a useful independent check of whether the resulting records match the warehouse.

Summary and next actions

Reliable barcode receiving preserves one physical action as one explainable business event, even when requests and acknowledgements are repeated or delayed. Recovery must be part of the workflow from the start.

• Map each scanned identifier to the object and quantity it actually represents.
• Agree event identities, retry behaviour and conflict handling with the receiving-system owner.
• Define permitted offline activities and show pending versus centrally accepted events clearly.
• Rehearse an outage through physical reconciliation, including a lost acknowledgement and changed retry payload.