A warehouse scanner must survive a lost connection
For Inventory managers and supply-chain heads · Plan implementation
TL;DR — what you’ll learn
- Give a physical movement one persistent event ID across all transmission attempts.
- Show saved, pending, accepted and rejected states in language operators understand.
- Decide which actions can proceed with stale data and which require a live check.
- Rehearse connection loss, device restart and conflicting picks using the actual scanners.
A picker scans a transfer, loses Wi-Fi and presses submit again. Both attempts arrive when the device reconnects. Without a shared event identity, the ERP can record two transfers while the warehouse moved one pallet. The difficult part of offline scanning is agreement about what happened.
How can offline warehouse scanning avoid duplicate or invalid inventory movements?
Give every captured movement a persistent ID, show whether it has been accepted by the server and define which actions may proceed offline. Replaying a saved event should return its existing result rather than create another stock movement.
- 01Scan the eventItem, lot, location and quantity
- 02Save locallyStable event identity and pending status
- 03Validate on reconnectMapping, state and duplicatesCan this event be posted safely?YesConfirm the postingNoKeep it in an owned exception queue with its original evidence.
- 04Confirm the postingReturn the destination reference
Illustrative information flow. The article explains the evidence, exceptions and responsible decisions. Diagram: NextEdge Labs.
Captured and posted are different states
Use clear states such as saved on device, awaiting sync, accepted and needs review. Do not display a success tick that means only 'stored locally' if operators understand it as 'posted to stock'. Preserve the original event time alongside the server acceptance time.
The device should retain the same transaction ID across retries. The receiving service checks that ID before changing stock and returns the earlier outcome for a duplicate. A new ID belongs to a genuinely new event, not another attempt to transmit the same one.
Some information becomes unsafe to trust when it is old
A cached quantity or lot status may have changed on another device. Decide which offline actions are observations, which are provisional requests and which require a live check. For example, a quality release decision should not be inferred from a cached 'released' label after the central record has been restricted.
GS1 EPCIS describes event information exchange across applications. That gives useful vocabulary for identifying events, but it does not settle your conflict rules. Document who resolves competing reservations, unexpected units and movements against a newly held lot.
Source: GS1 · Event information exchange model. Reference details
The most awkward failure happens after acceptance
Suppose the server accepts a transfer but the acknowledgement never reaches the scanner. The device cannot tell whether the request failed or the response was lost. Retrying is reasonable; creating another movement is not. Store the event ID before transmission and use that same ID on every retry. The server needs a durable record of the accepted result so it can return it again.
Also check that a reused ID carries the same intended movement. If the device changes quantity but sends the original ID, the service should flag the mismatch rather than silently treat it as the earlier request. Corrections should be explicit new events linked to the original, with the appropriate approval. This gives operations a readable history and makes technical recovery auditable.
Two scanners can each believe the last stock is available
Imagine an illustrative ten cases cached on two devices. Each operator captures a pick of eight cases while disconnected. Sixteen cases of requests now compete for ten cases of stock. A replay mechanism can prevent duplicate messages, but it cannot make both requests valid. The server must apply the agreed reservation or conflict policy and return a clear outcome to each device.
If the physical picks already occurred, the exception requires an operational reconciliation. The interface should show which request was accepted, which remains unresolved and what stock is believed to have moved. A generic sync failed banner is inadequate. Avoid letting a device repeatedly retry a business-rule rejection as though it were a temporary network error.
Plan for shared devices and unfinished work
A shift change or app restart should not lose pending events. Store the operator associated with each captured movement and show outstanding work during handover. Define what happens when a device is lost or replaced before it synchronises. The business may need a supervised recovery process using its physical records, rather than a promise that every offline event can always be recovered.
Limit the information stored locally to what the workflow requires and apply the organisation's device access and retention controls. Separate an expired login from lost transaction data: staff may need to sign in again before transmission, while the pending event remains available for an authorised recovery. Test this on the actual device configuration, not only in a browser simulator.
Ask for acceptance evidence, not a connectivity claim
The handover should include a short set of recorded failure tests: response lost after acceptance, app restart with pending work, conflicting picks, changed lot status and a rejected unit conversion. For each, compare the device queue, integration record and ERP ledger. A supplier claiming offline support should be able to explain those outcomes in operational terms and identify who maintains the recovery process after launch.
Test the failures on a real device
A pilot should disconnect after capture, during transmission and immediately after server acceptance. Restart the app, resend an event and submit two competing picks. The stock ledger must remain explainable, with rejected or provisional work visible to the operator.
Begin with a limited workflow such as internal transfers, the scanners already in use and one ERP endpoint. Measure duplicate prevention, unresolved sync age and recovery effort. An offline application is ready when a shift supervisor can reconcile its queue after an outage; a successful demonstration on strong office Wi-Fi does not establish that.
Summary
Offline scanning is a transaction-recovery design, not just a screen that works without Wi-Fi. The device and server need to agree about event identity, acceptance and conflicts. A supervisor should be able to reconcile the queue after an outage without guessing which stock movements were posted.
What to do next
- Map the current scanner states to what has actually been recorded in the ERP.
- Define permitted offline actions and the owner of each conflict type.
- Disconnect during a submission and verify that replay returns one accepted movement.
Scope this automation around your operation
Tell us your current systems, transaction volume and the exception you need to resolve. We can discuss a bounded first release, its review controls and how to measure the result.
Sources and further reading
Sources checked 15 October 2026. The worked examples and software evaluation suggestions are NextEdge Labs’ editorial analysis.
- EPCIS StandardGS1 · Release 2.0, ratified June 2022
Event information exchange across applications. An implementation still needs agreed identifiers, responsibilities and validation.
Visual credits
AI-generated illustration created for NextEdge Labs; it does not depict a client facility. Workflow diagram by NextEdge Labs. Icons from Lucide (ISC licence).
