Skip to main content
The till is built to keep selling when the connection is not there. You ring sales up exactly as you always do; they are saved on the terminal and sync themselves the moment the network comes back. Nothing is queued behind a spinner and nobody is asked to write on paper.

​
What you’re looking at

The offline bar sits in the POS header, and when everything is healthy it renders nothing at all — no chip, no button, no badge. That is the empty state, and it is the one you should normally see. If anything is showing, there is something to know: Selecting the status button opens the Sync status sheet, headed “Connected. Queued sales sync automatically.” or “Offline. Sales are saved and will sync when you’re back online.” It carries two counters — Waiting to sync and Need review — a Sync now button, a Rejected sales list showing each provisional number, when it was taken and what went wrong, and Last error: for the most recent failure.

​
What works, and what does not

Capture works offline. Completion does not — and that boundary is deliberate.

Works offline

  • Ringing up and completing a sale on any payment method, including part-payment and credit
  • Barcode scanning and product search, against the cached catalogue — the whole sellable list, not just the tiles on screen
  • Holding and resuming carts
  • Interaction screening against the cached ruleset, including a pharmacist’s acknowledgement
  • Printing the receipt
  • The calculator

Needs a connection

  • Account balance as a tender — “Account balance needs a connection — take cash or card, or wait for the network.”
  • Searching for a registered customer
  • Redeeming a loyalty reward (it stays available for next time)
  • Everything outside the till: dispensing workflow, receiving stock, billing and reports
The reason is the same in every case: capturing what happened at your counter is safe to do alone, but anything that depends on a shared balance — someone else’s wallet, a reward, stock another branch is drawing on — cannot be decided by one terminal in the dark.

​
Sell through an outage

1

Notice the bar

The amber Offline · stock as of 14:32 chip appears in the header. The time is when the terminal last took its copy of the catalogue.
2

Ring the sale up as normal

Scan or search, build the cart, take Cash, Card, Mobile Money, Bank Transfer, Insurance or Other, including part payment on credit. Only Account balance is unavailable.
3

Complete it

The dialog reads Sale Saved Offline — “Saved on this device — it will sync automatically when you’re back online.” — with the chip Provisional — will confirm on sync and a Provisional No. in place of a sale number. The toast reads Sale saved — will sync when back online.
4

Give the customer their slip

The receipt prints with PROVISIONAL — WILL CONFIRM ON SYNC and the provisional number, and no barcode — that number does not exist on the server yet. Quote the provisional number if the customer asks. See Print and reprint receipts.
5

Keep going

The status button counts the sales waiting. There is no limit you need to watch and no point at which you should stop and wait.

​
What happens when the connection returns

Sales sync on their own, one at a time, in the order you took them. You do not have to press anything; Sync now simply forces a drain if you would rather not wait. Every sale carries its own key from the moment you complete it, and that key travels with it through every retry. That is what makes all three outcomes safe:
  • Online — the sale gets a real number immediately and the toast reads Sale completed successfully!
  • Offline — it is stored on the terminal with a provisional number and syncs later. It is a real sale from the moment you complete it; only its number is provisional.
  • The connection died mid-request — the sale reached the server but the reply never got back to the till. Because the retry carries the same key, the server recognises it and reports This sale was already processed instead of recording a second one. The customer is charged once.
Retries are not all equal, and the difference matters:
  • Anything that failed to reach the server is retried automatically, with a growing gap between attempts so a flapping connection is not hammered.
  • A sale the server actively refuses is not retried silently. It goes to Need review and waits for a person, because repeating a refused write forever is how quiet data loss happens.
  • Stock shortfalls are not rejections. A sale that went beyond recorded stock syncs fine and shows up on Inventory › Reconciliation to be squared off later.
  • An expired session parks the queue rather than failing it: “Your session expired. Sign in again to sync {n} saved sale(s).” Sign in and the drain resumes — nobody is asked to store a password to keep syncing.
Unsynced sales live on that terminal and nowhere else. Do not clear the browser’s site data, uninstall the desktop app, or wipe the machine while the status button still shows a pending count — those sales are not recoverable afterwards. Get to Synced first.

​
Stale figures are labelled, always

While you are offline the cached catalogue is treated as stale regardless of its age, and the header says stock as of HH:MM so the number never pretends to be live. Low-stock badges are muted for the same reason. Read the label and trust it: another till may have sold the last box at 14:40.

​
Before the outage: prime the terminal

A device can only work offline if it has loaded the till at least once while online — that is when it takes its copy of the catalogue and the screening rules. Open POS on every counter machine on the day you set it up. See The desktop app.

​
Who can do this

Selling offline is not a separate privilege — it is the same act as selling, on a terminal that happens to have no network. Anyone who can work the till can work it during an outage. Role governs the sidebar: a Cashier reaches POS and Sales only, which is everything an outage needs. Two behaviours surprise people:
  • Enforcement is opt-in, per person. Someone never saved in the permissions sheet is unrestricted, whatever their role bundle. The sheet warns “Saving starts enforcing”.
  • A denied action is recorded; an allowed one is not. A refused reversal leaves a line in the audit trail; the sales you were entitled to take do not.
See Staff permissions.

​
Check it worked

  • During the outage: sales complete, receipts print, and the status button counts what is waiting.
  • After it: the status button reads Synced, Waiting to sync is zero, and every sale appears in Sales History with a real receipt number and an Offline badge showing where it was captured.
  • Sales taken offline count towards the day’s totals and reports exactly like any other.

​
Common issues

Open Sync status and select Sync now. If it stays put, check Last error: and whether the Sign in to sync chip is showing — an expired session parks the whole queue.
Those were refused rather than lost. Open the Rejected sales list, note the provisional number, capture time and error for each, and re-enter the sale if it is still valid. They will not disappear on their own, and they will not retry silently.
Wallet tender needs the live balance, which is why it is disabled offline. Take cash or card, or wait for the network. See Take payment.
Customer search needs a connection. Complete the sale as a walk-in with their name and phone number in the optional boxes, and reconcile it afterwards.
Provisional slips carry no barcode by design. After the sale syncs, find it on the Sales page and reprint the confirmed receipt.
That terminal has never finished its first online load — “This terminal needs to connect once to finish setting up.” — so it has no catalogue to sell from. Select Retry once the network is back. Sales already saved on the machine are unaffected, and the page says so.

​
FAQ

Nothing — they stay on that machine. The queue is written to the terminal’s own storage rather than the browser session, so it survives a refresh, a restart and a power cut. Open POS again on the same machine and the drain picks up where it left off.
Yes. Each sale is stamped with the time you captured it, not the time it synced, so it lands in the right trading day even if the network only returns the next morning. It appears in Sales History with an Offline badge.
Not until they sync. Queued sales live on the terminal that took them, so a second till shows nothing and cannot amend them. Once the queue drains they appear everywhere, like any other sale.
No. Synced entries are tidied off the device after about a week: the local queue is a waiting room, not a record. The sales themselves are in Sales History, permanently.
There is no number to watch and no point at which the till starts refusing. Keep serving — the counter tells you how much is outstanding, it is not a warning.