On a device
The Android till
Who: cashiers, on a tablet or a Sunmi terminal
The Android app is a terminal, not a second Sellify: the same terminal row, the same API, the same server-built receipt. Everything in POS applies. This page is only what is different about a device.
Setting one up
- Install the APK we give you.
- Type the branch's pairing code and name the till.
- Ring us to approve it — see Terminals.
- Sign in. Sign in online at least once; that is what makes offline sign-in possible later.
The app checks for a new version itself. An update is only forced when a build is genuinely unsafe to keep selling on — a shop mid-service is never stopped by an update it could take after closing.
Selling with no internet
The till prices the cart itself from a price bundle the server issued, prints what it quoted, and uploads the sale when the network comes back. The server re-prices it from the ids at that point, exactly as it always does. If the figures disagree the sale is saved at the server's figure and flagged for a manager — never silently absorbed, never silently kept.
| Works offline | Does not |
|---|---|
| Lines, variants, modifiers, deals | Promo codes (their caps are counted on the server) |
| Tax, including the cash/card split | A customer's standing discount |
| Campaigns | Staff meals |
| A manual discount within your cap | A price override |
| A manager's PIN for a discount or an FOC | Reopening a closed day |
| Kitchen tickets | The day close |
| Held orders, today's sales | The negative-stock refusal |
Each refusal is a plain sentence on the screen — never a dead button.
A bundle older than 24 hours refuses the sale. A shop that has been off the network for two days is selling last week's prices.
Selling offline is per till (Setup → Terminals, Sell without internet). Turn it off for a device on the shop's wifi that you would rather stopped than half-worked; leave it on for the one on a 4G dongle.
The outbox
Sales waiting to upload. It drains when the network returns, when the app comes to the front, on a timer, on Sync now, and — the case none of the others cover — through Android's own job queue, so a tablet swiped away at closing time still uploads.
A sale carries the id the device generated, so one timed-out response never charges a customer twice.
A day will not close while a till still has unsynced sales, and the refusal names the tills so a manager knows where to go. A till that is off the network cannot report, so its last figure stands and the day stays open — that is the safe way round on purpose.
A sale for a day that has since closed
Refused, and kept. It waits on the outbox screen for a person: a manager reopens that day and it goes through. Retrying it every sixty seconds helps nobody and dropping it loses a sale that was really made. A backdated sale stays backdated — it is never quietly re-filed onto today.
Signing in offline
A cashier who has signed in on this terminal before may sign in offline for 7 days since
their last online sign-in (pos.offline_login_days). Nobody else — a dead router at 8am
must not close the shop.
Signing in offline does not restart the clock; only an online sign-in does.
Receipts and kitchen tickets
Online, the device prints the bytes the server built. Offline, it builds the same document and prints it. Both are checked against the server automatically, so the two can never drift.
An offline receipt prints a local ref; the real order number arrives at sync and shows on the orders list and on any reprint.
Printing never rolls a sale back. The money is taken whatever the paper does; a printer that is off, out of paper or unpaired says so on the same screen with Try again and Set up a printer beside it.
The device's own printers
Set on the device (role, connection, paper, copies, cut, drawer). The branch's printer rows pre-fill the form, but the device's own binding wins — which tablet is paired to which Bluetooth printer is nobody else's business and is pushed nowhere.
Test print is the server's own test receipt when the network is up, and otherwise a plain test page the device builds — the printer's name, where it is, and a column ruler. A till that has never been online must still be provable before a customer is standing there.
Barcode scanning
Three kinds of scanner, all of which just work:
- A USB or Bluetooth scanner — it types the code and presses Enter
- A Sunmi hardware trigger
- The camera, for a tablet with no scanner at all
A scan reads the same menu the grid is drawn from, so it works with the internet off and can never find something the cashier cannot see.
A barcode on the variant names exactly what was scanned; a barcode on the product names the dish and still asks for the size. Scanning the 500ml never lets the till decide it was the 1.5 litre.
A scan that misses stays quiet unless the code could not have been typed on purpose — telling a cashier that "rice" is not a barcode helps nobody.
A second screen for the customer
Plug one in and it starts by itself. It shows the lines as they are rung, then the total.
While the cashier is ringing, the figure is labelled ITEMS — the goods, before tax. Tax and TOTAL appear only once the sale is priced. A figure called Total that then grows when the tax lands reads as a surprise charge, which is the one thing a customer display exists to prevent.
It never touches the sale. A till with one screen, a panel unplugged mid-order — all ordinary.
Sending us a diagnostic
Settings → Send diagnostics on the device. It uploads the app's own logs and nothing else: no passwords, no PINs, no tokens and no customer details.