Offline & Connectivity

What happens when a scanner loses signal on the floor, mid-shift — stated exactly as precisely as it’s been verified, no more and no less. If you haven’t already, why offline barcode scanners lose scans covers the general problem every offline-capable scanning tool has to solve; this page describes the mechanism WarehouseQ actually uses.

The mechanism

A scan queued while a device is offline is held in a durable, on-device queue, and each queued entry is tagged with its own identifier that Business Central uses to recognize a scan it has already accepted.

Read that sentence carefully, because the wording is deliberate on both halves. Durable means the queue is written to the device’s own storage, not held only in memory — an app restart or a device reboot doesn’t erase what’s waiting to sync. Tagged with its own identifier means each queued scan carries something that lets Business Central’s own dedup check recognize a resend of the same scan as a resend, rather than as a brand-new transaction to post again.

What this sentence is not is a claim that offline scanning has been formally proven, under every possible failure timing, to replay each scan exactly once. We’d rather describe precisely what the mechanism does — a durable local queue, plus a per-scan identifier the receiving side checks against — than round it up to a stronger guarantee we haven’t independently verified end to end.

What this means in practice

• A worker can keep scanning through a dead zone — receiving, put-away, picks, whatever the shift calls for — without the app blocking them or forcing them to wait for a connection before continuing.
• Everything captured offline sits in a queue on the device itself, not in memory that a crash or an app restart can simply erase.
• When the connection returns, the queue drains, and each entry’s identifier is what lets the receiving side recognize a duplicate delivery attempt rather than treating it as a new transaction to post again.

No separate cloud service in the loop

The mobile experience talks directly to the Business Central environment it’s installed against — there’s no separate hosted backend that scan data passes through on its way to the ledger. That’s a smaller, more auditable path than a design where offline data has to round-trip through a third-party service before it ever reaches Business Central: fewer systems in the loop means fewer places for a scan to go missing, and nothing to explain to an IT team asking where inventory data travels before it lands.

What we don’t claim

We don’t claim, and won’t claim until it’s actually been proven, that offline scanning “cannot post twice” or “replays exactly once” as an absolute guarantee under every possible failure timing — including, specifically, a device crashing mid-reconnect at the exact moment a batch is draining. That’s a stronger statement than the mechanism above has been independently verified to guarantee, and we’d rather under-claim here than have a customer discover a gap between a guarantee and the mechanism the hard way, on their own floor. If that stronger guarantee is ever formally tested and verified, this page will say so plainly — and will say exactly what was tested, not just that testing happened.

Related reading

Why offline barcode scanners lose scans — the general dead-zone problem this mechanism is built to address. Operations covered — every operation this offline queue applies to equally.