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 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 100 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 also drawing on — cannot be decided by one terminal in the dark.

​
Sell through an outage

1

Notice the bar

An amber chip appears in the header: Offline · stock as of 14:32. When everything is healthy the bar shows nothing at all, so if you can see it, there is something to know.
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 panel 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. Open the Sync status sheet from the bar to watch: Sync now forces a drain if you would rather not wait. Rejected sales lists anything that needs review with its provisional number, when it was taken and what went wrong, and Last error: shows the most recent failure.

​
Three outcomes, and why you cannot be double-charged

Every sale carries its own key from the moment you complete it, and that key travels with it through every retry.
The sale gets a real number immediately and the toast reads Sale completed successfully!
The sale 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.
This is the case that used to create duplicates: the sale reached the server, the reply did not reach 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, and what “Need review” means

  • 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 — a bad payload, a product it does not recognise — 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 perfectly well and shows up on Inventory › Reconciliation to be squared off later.
If the session has expired, the queue parks rather than failing: a red Sign in to sync chip appears and the sheet says “Your session expired. Sign in again to sync {n} saved sale(s).” Sign in and the drain resumes. Nobody is ever 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. The cache also goes stale after about fifteen minutes online, and is replaced wholesale rather than patched. Read the label and trust it: a figure presented as “as of 14:32” is exactly that, and 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. On the desktop app, a terminal that has never been primed shows an offline page headed Can’t reach ClinikEHR: “This terminal needs to connect once to finish setting up. Check the network and try again — after the first successful load, the POS keeps working even when the connection drops.” Select Retry once the network is back. Any sales already saved on that machine are safe — the page says so. See The desktop app and Working offline.

​
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.

​
If something goes wrong

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 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 Walk-in with their name and phone number in the optional boxes, and reconcile it afterwards.
Redemption needs a connection. The reward is not lost — it stays available for the customer’s next visit.
Provisional slips carry no barcode by design. After the sale syncs, find it on the Sales page and reprint the confirmed receipt.
Queued sales live on the terminal that took them until they sync. They appear everywhere once the queue drains.
Synced entries are tidied up after about a week. They are on the server, in Sales History — the local queue is a waiting room, not a record.