The Android till

Menu: the Sellify app on the tablet, not the web panel · 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.

On a counter PC, read this page and then The Windows till — the two apps are one program built two ways, and that page is only the handful of things a PC does differently.

Setting one up

1. Install the APK we give you.
2. Type the branch's pairing code and name the till.
3. Ring us to approve it — see Terminals.
4. 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.

When one is out, a line above the till offers Update now (also under Support → App). With the cart empty, press it: the app downloads the new version, checks the file is exactly the one Sellify published, and opens Android's installer. Press Install — Android always asks for that one tap. The very first time, Android also asks once to allow installs from Sellify: allow it, come back, and press Try again. Nothing needs a browser, and unsent sales stay on the tablet.

Taking money off the bill

Tap the tag beside Pay (on a phone, open the cart and tap Discount). Two things live there, and they are not the same thing:

• A discount — a percent or an amount off the goods. The screen says what your company caps discounts at, so you can see the ceiling rather than find it by being refused.
• Write the whole bill off — an FOC. It takes the total and the tax to nothing, and the reason is required, because that reason is what the owner reads later.

Both are on the cart, not on the payment screen, so the customer is told the figure before they are asked to pay it. Whichever you apply replaces the other and replaces any campaign — one bill carries one discount, always.

When a manager is asked for. Up to your own limit you need nobody. Past it, the till asks for a manager's PIN — and it asks for one before any write-off. An owner or a branch manager signed in at the till is never asked; they are the manager.

This works with the internet down. The PIN is checked against what the device learnt the last time that manager really approved something on it, and the approval goes up with the sale. A manager who has never approved on that till cannot approve on it offline.

Offers on the till

Offers work as they do on the web, with one difference worth knowing: the till shows them on the payment sheet, not beside the cart. That is where every figure on this app comes from, and picking an offer moves them.

When two offers fit the same bill the heading reads Pick an offer and nothing is taken off until you tap one — ask the customer which they want. Each chip shows what that offer is worth on this cart, so the choice is between two figures rather than two names. One offer fitting on its own applies itself and is ticked; there is nothing to do — and if the customer does not want it, tap the ticked chip to take it off. Tap it again to put it back.

This works with the internet down. An offer's rules — its dates, its days, its minimum, its order type — are all in the price bundle, so a dark till reaches the same answer the server would.

Selling at a price you agreed

Sometimes the shelf price is where the conversation starts rather than where it ends — loose goods weighed out, a damaged carton, a wholesale line haggled over.

Tap the pencil on a cart line, type the price, tap Set. The line then shows what you are charging with the shelf price struck through beside it, so nobody has to wonder. Use the shelf price puts it back. Options on the line are still charged on top — a haggled base does not include the extra cheese.

No PIN and no cap: this is the counter's own price, and a shop that decided you may set it has already answered the question a PIN would ask again. What is kept instead is the record — every line remembers what the shelf said and who typed over it, and the owner reads it back on the Price overrides report.

One floor, and it cannot be argued with: below what the item costs is refused, in a sentence naming the item and the figure. A till that sells at a loss because of a typing slip is worse than a till that asks again.

No pencil? Either you were not granted it — the owner gives it out in Admin → Users — or the till has no internet, and then it says so. The cost is counted from your branch's own stock ledger, which another till moves while this one is dark, so the floor cannot be checked and the price cannot be typed.

What else a sale can carry

Under the cart, tap Customer, staff meal, channel… — the bar that reads back whatever is already set. Four things live there, and none of them work without the internet; the sheet says so in one line rather than showing you four controls that do nothing.

• A customer — a name, a phone, and an address for a delivery. A phone with no name is still a customer; 03001234567 and +92 300 1234567 are the same person to us. If they have a discount of their own it simply applies — nothing is asked.
• A staff meal — type the staff code and tap Find. You are told the name and what is left of their allowance this month before you ring anything. Somebody who left, the wrong outlet or no allowance at all is refused in a sentence you can read out. Nothing left is not a refusal: the meal is rung and they pay for all of it, and it still counts as a staff meal on the month's report.
• A channel — Foodpanda, Bykea, our own website. Their order number goes in beside it. The payment screen then shows what the platform keeps and what is coming back, and asks you nothing about cash or card: they collected the money, not you. Not offered on a dine-in order — nobody sits down at a Foodpanda table.
• A delivery area — only for a delivery, and only if your branch keeps areas. It decides the delivery charge, the promise and the minimum order, and the area's own words ("12 km · 45 min") are there for you to read out.

A promo code is on the payment screen instead, beside the offers. Type it and tap Apply. A code that cannot be used is never a dead end — you are told why in one line ("needs an order of at least Rs 2,500") and the sale carries on at full price. Codes need the internet too: their limits are counted from what every other till has already done.

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.

The right-hand column is one rule, not eight: anything the server has to count or look up. A code's limit, an allowance, a customer's terms, an item's cost and a platform's commission are all rows another till changes while yours is dark — a figure worked out here could be wrong by the time the customer has left.

Each refusal is a plain sentence on the screen — never a dead button.

A table parked with no internet is that till's table until the connection comes back. It is badged This till only on the Tables screen, and no other terminal can see or settle it — so send the waiter back to the till that took it. The moment the network returns it goes up on its own and behaves like any other table. If another till parked the same number while both were dark, the second one stays here with the reason on it: that is two bills on one table, and a manager has to sort it out rather than the till guessing.

Another round with no internet. Recall the table, add the items and press Send to kitchen as usual. The kitchen slip prints straight away with only the new items, headed ADDED TO ORDER, and the table stays open.

• On a table this till parked offline, the round is simply added to it.
• On a table that was placed while the internet was on, the round waits on the till and goes up by itself when the connection returns. Recalling that table again meanwhile shows the round's items.
• If another till changed the same table while yours was offline, the round is not sent — sending it would take that till's items off the bill. It waits under Held sales with the reason, and the bill for that table waits with it. A manager chooses: Send anyway (this till's bill replaces the other till's) or Drop (keep the other till's bill; the dropped items were already sent to the kitchen, so add them again on a till if the customer is having them).

A sale rung offline is never refused later for stock. The till cannot check the shelf with no internet, and by the time the sale reaches the server the goods have already gone — so it is accepted even where that takes the item below zero, and a stock count settles it. Your Allow selling below zero stock setting is untouched by this: it still refuses a live sale at the counter, which is the moment it is about.

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.

That clock is measured against the last time this device actually reached Sellify, not against the tablet's own date — so setting the date back does not buy another week.

When the till warns you

A strip across the top of the till says the one thing that matters most, and never more than one at a time:

The same strip is on the sign-in screen, because the shift change is when somebody who can do something about it is usually standing at the counter.

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.

Sales in the side rail lists what this till sold on a business day, one lane per order type. It opens on this shift — the drawer open right now — so one cashier's sales are not mixed with the shift before. The button beside the date picks another shift on that day (it says when each opened and who opened it) or Whole day for every shift together.

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.

Paying a supplier

Suppliers in the side rail, or under the ⋮ menu on a handheld. The van man turns up at the counter and wants money: this is that screen and nothing else.

Every supplier, heaviest debt first, with how long they give you under the name. Tap one and you get what is owed, what is still open — their own invoice number, because that is what he is holding — and a box for what you hand over.

Cash handed over at the counter comes off what the drawer is expected to hold at day close — under a head of its own, never mixed in with expenses. Paying a supplier is not an expense: the cost of those goods went into the books the day they were received.

Who sees it: an owner and a branch manager always. A cashier only where the branch has said the counter may hand money out — the same setting that lets them record what was paid out of the till. Where it does not, the screen is simply not there.

It needs the internet, and that is not a limitation waiting to be lifted: what a supplier is owed is counted from rows another till changes while this one is dark, and money handed over against a stale figure is money handed over twice. On a dark till the screen says so and pays nobody.

What it deliberately does not do: the month's statement, sending goods back, and adjusting an account. A counter does none of those — they are on the admin panel, where the delivery and the record are.

Asking where something is

Help — in the side rail on a tablet or a counter PC, and under the ⋮ menu on a handheld. Type the question the way you would say it — in English, in Roman Urdu or in Urdu script, and you are answered the same way you typed it — and you are told which screen to go to, with the manual chapter it came from named under the answer.

Help and Support are two different errands, which is why they sit apart, each with its own icon. Help answers where is this in Sellify. Support (below) sends us a report when the till is misbehaving.

It needs the internet: the manual lives on the server, and an old copy on the device would send you to the wrong screen, which is worse than saying nothing. On a dark till the box says so and the Ask button is off.

While it works it says which step it is on — Thinking, Looking through the manual, Reading the chapter, Writing the answer — so a wait of a few seconds reads as a screen that is busy rather than one that has stopped.

New chat starts a fresh conversation and keeps the old one; Past questions lists everything you have asked and opens any of them again. The list is yours alone, and with no connection it is not offered at all — it lives on the server like the manual does.

It names the chapter rather than opening it — a counter wants the route, not two thousand words. Read the chapter itself on the admin panel or on sellifypos.com.

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.