Keep warehouse work recoverable during scanner or network outages

Two scanners lose their connection after both display ten available units. Each operator receives a request to pick six. If both devices treat the cached balance as fresh authority, the requested work exceeds the stock and the central system may learn about the conflict only after dispatch.

Warehouse offline operations need a bounded continuity model. Continue only work that the operation can control with known ownership and quantity limits. Keep uncertain or conflicting work held, and define how the warehouse will reconcile it before normal allocation resumes.

Choose the permitted work before the outage

List the decisions that require a current shared view: allocating stock, releasing holds, changing reservations, approving substitutes or advancing an order into dispatch. An offline device should not acquire those permissions simply because its network connection failed.

Some sites may permit completion of work already assigned exclusively to a worker or physical area. Others may need to stop picking and continue only observation or administrative recording. The approved continuity procedure, stock characteristics and deployed WMS determine the boundary.

Microsoft documents configured warehouse work and location directives. Those controls provide context for assigned work, but they do not prove that a given scanner application supports safe offline execution. Control warehouse work by using location directives Demonstrate the actual configuration and failure behavior rather than relying on a generic “mobile capable” claim.

Name the shift supervisor who can stop or authorise the permitted fallback. Define how staff learn that the outage is active and which release actions are suspended.

Give disconnected work an exclusive scope

Consider this illustrative controlled work package. Ten usable units are physically in a designated location. Before connectivity is lost, the WMS assigns six to worker A and four to worker B, with distinct work IDs and reservations.

The resulting physical bridge is ten starting units, nine picked units and one unit on hold. The damaged unit has not been shipped or silently written off. Its disposition belongs to the authorised warehouse process.

If B's device instead presents a new six-unit request from a stale cache, that request exceeds B's assigned four-unit scope. It must stop for resolution. The example does not assume that twelve units were physically picked from ten; it identifies the conflicting instruction before execution.

Exclusive digital assignment must match the physical process. If another worker can take the same stock under a paper order, the apparent reservation boundary is ineffective. Use the site's approved segregation and supervision controls.

Record observations without inventing final system state

An offline event should identify the work package, device, operator, item, quantity, source and destination, event time and local sequence. Preserve the original time zone and record when the central system later receives it.

Use stable event IDs so a reconnect does not create new identities for the same observation. An operator correction should link to the earlier event, with a reason, instead of deleting the record and pretending it never occurred.

GS1 EPCIS supports structured visibility-event exchange. The local continuity design still needs to define which observations represent a completed movement and which require central validation or supervisor review. GS1 — EPCIS and CBV artefacts

The scanner can say “recorded locally” without saying “accepted by WMS.” Make those states visible to the worker. A completed physical pick with an unconfirmed system update is an exception to reconcile, not permission to pick again.

Recover a lost acknowledgement carefully

Suppose A's six-unit pick reaches the WMS when connectivity briefly returns, but the acknowledgement is lost. The device resends the same event ID. The destination must recognise the prior outcome or allow a supported lookup before another stock movement is applied.

A unique outbound message alone is insufficient if the receiving process applies the movement twice. AWS's transactional outbox guidance discusses duplicate delivery and the need for idempotent consumers; the same delivery distinction matters during controlled replay. AWS Prescriptive Guidance — Transactional outbox pattern

For B, the three-unit pick and one-unit damage observation need separate outcomes. A failed hold update should remain visible even if the pick succeeded. A batch-level success label must not hide partial acceptance.

Reconcile at the business-event level rather than counting transmissions. In this fixture, repeated delivery of A's event still represents one six-unit pick, not twelve picked units.

Resolve conflicts against physical evidence

On reconnection, compare approved work, recorded events, current WMS reservations and physical custody. A central order may have been cancelled or a stock hold may have arisen while the device was disconnected.

Do not apply a “last writer wins” rule to physical inventory. A later timestamp cannot prove which instruction was authorised or which movement actually occurred. Route the conflict to a supervisor with the relevant tote, location and event records.

Keep goods affected by unresolved identity, quantity or status conflicts out of subsequent release under the approved procedure. An audit log should show the observation, the conflict and the authorised correction.

If device time is inaccurate, retain that uncertainty and use local sequence and other evidence carefully. Do not reorder events solely by unsynchronised clocks and call the result a reliable movement history.

Compare continuity options against the actual risk

A paper fallback may be practical for a small controlled area if forms are numbered, work is exclusive and later entry is reconciled. Native offline functionality may reduce re-entry when its reservation and replay rules are demonstrated. A custom extension needs a justified scope and tested recovery.

Evaluate the same outage fixture for each option: two devices, a stale request, a damaged unit, a lost acknowledgement and an order cancelled while offline. Test the supervisor's stop action as well as the normal completion path.

Measure unreconciled quantities, duplicate applications, work accepted outside its authorised scope and time to establish a trusted stock position. Continuing more work during the outage is not a success if recovery cannot explain where the stock went.

Resume from a known stock position

The recovery owner should sign off the completed, held and unresolved work before normal release restarts in the affected area. Preserve pending events and record which ones were entered manually, so automated replay does not repeat them.

For a continuity assessment, choose one zone and one work type. Use the real scanner and WMS behavior with authorised test data, then compare it with the site's approved fallback.

Next actions

1. Define permitted offline work and the decisions that require a current central state.
2. Assign exclusive work identities and quantity limits before allowing disconnected execution.
3. Test stale instructions, partial results and lost acknowledgements through controlled replay.
4. Reconcile physical stock and system outcomes, then obtain the responsible owner's approval to resume normal release.