Working offline

Warehouses have dead zones, and docks have flaky Wi-Fi. The mobile app is built for that: keep scanning with no signal, and let the device settle up with APEX when the connection returns.

What works offline

Receive, issue, and count work fully offline. Each submitted operation is saved to a queue on the device the instant you tap the button — the confirmation, ”… queued — syncs when online,” means exactly that. The queue survives closing the app or restarting the phone; nothing is lost.

Two caveats:

• Photos need signal — the image uploads at capture time, so the Photo operation can’t be queued offline. See Count & photo.
• Open the app while you still have coverage. With no connection at all, a cold launch of the app shows a plain “You’re offline” screen with a Retry button (your queued scans are safe). Once a screen is open, it keeps working as the signal comes and goes.

The header tells you where you stand

Screen: The mobile header — workspace and operator name on the left; on the right an amber ⇅ 3 badge (operations waiting to sync), the connectivity indicator (● Online in green / ○ Offline in red), and the Sync button, which reads Syncing… while a sync runs.

Sync is automatic: the queue flushes the moment the device comes back online, and after each newly queued operation while online. The Sync button just lets you force the same thing — useful before handing the phone over at shift change (the badge at zero means everything landed).

Exactly once — retries can’t double-post

Every queued operation carries a one-time key minted when you tapped the button. APEX remembers each key it has already posted, so if the connection drops mid-sync and the queue re-sends, the second attempt is recognized and ignored — no second receipt, no double issue, no repeated adjustment. Tapping Sync twice is harmless for the same reason. Large backlogs sync in slices automatically; a long offline shift settles up on its own.

When an operation won’t sync

An operation can be rejected when APEX applies it — a mistyped code that matches nothing, a unit that was already issued by someone else, a count delta that would push quantity below zero. A rejected operation is skipped without disturbing the rest of the batch, stays in the queue, and is retried on every sync — which means the ⇅ badge won’t reach zero while a bad operation sits in it.

If your badge is stuck:

1. Open the part on the desktop console and check the movement ledger to see what actually posted. The exactly-once guarantee means work that landed, landed once — the stuck item is the one that never posted.
2. If the movement is genuinely missing, redo it on the phone with the correct codes (or book it from the desktop). The bad queued item keeps failing harmlessly — it will never post.
3. As a last resort, once everything you care about has synced, clearing the browser’s site data for APEX empties the device queue — but it discards all unsynced items, so only do it at a zero-loss moment.