The field keeps working when the signal does not

Queuing work offline is the easy half. The half that decides whether a day’s takings balance is what the app does when a sync partly fails.

The van is where software goes to fail

A salesperson in a vehicle has patchy signal, a full day of stops and no patience for a spinner. Any system that needs the network to record a sale will lose sales.

Queue it, then reconcile it

The van and mobile apps write what you do into a local queue and sync when a signal returns. That part is ordinary. The part that matters is what happens when a sync does not work.

A sale that fails to sync is shown to you

The failure this class of app usually ships is silent: the request returns 200, some entries inside it failed, and the queue is cleared anyway. The day’s takings are then short by an amount nobody can name. Here, a per-entry failure parks that entry and surfaces it with a Retry — it is never dropped, and the count of what did not go through is shown rather than folded away.

Two real cases this had to get right

• The route closed while the van was offline. The invoice was created and could not be confirmed. It is parked as needing attention and is confirm-only from then on — it is never re-created, which would duplicate it.
• The order was taken in the office while the rep was driving. It is recorded, and it is NOT reported as on its way. Those are different facts and the board shows them differently.

Printing without a server

Receipts print from the device over Bluetooth, in Arabic, as an image when the printer cannot set Arabic itself. If no printer is paired the receipt is shown on screen — and the app says which of the two happened rather than reporting success either way.