Working without a connection on Android

Friday, 8:40 pm. The router restarts and the Wi‑Fi is gone for four minutes. Sara is at T7 with an Android tablet: two guests, three dishes, and they want to pay cash before their film starts.

1. 1Sara opens T7 and adds the dishes as usual. The screen’s header shows an Offline pill with a number — the changes saved on the tablet and not sent yet. Nothing spins and nothing is refused.
2. 2She presses Fire. The round shows under Waiting to send — “fired 8:41 pm · 2 min · sends by itself”. The kitchen gets it the moment the tablet reaches the main terminal, printed once.
3. 3She takes the cash and settles the check. Where the check number goes it says New: numbers come from the main terminal, so the check gets its number (like #0042) once it arrives.
4. 4The Wi‑Fi comes back. Within seconds every change reaches the main terminal and the kitchen ticket prints; the pill says Connected for a moment, then goes away. Each change is applied once, however many times the tablet tried to send it.

• Opening tables, takeaway and delivery orders; adding dishes, changing quantities, notes, voids, discounts, comps and fees.
• Fire — the round waits on the tablet under Waiting to send and prints once it reaches the main terminal. A void of a line already sent says Void prints when connected.
• Each Send shows on the check what happened to it: Waiting to send, then printed — or Didn’t print with the station, once the print queue gives up on a printer (about 2 minutes). Reprint needs a connection.
• Taking cash, or recording a card paid on a separate card machine — tips and change included. A payment from a customer’s Balance (their house account) needs a connection.
• Moving a check, or some of its items, to another table, and merging two checks.
• Seating a booking from the floor and adding a party to the waitlist.
• Locking, and signing in with a PIN — for anyone who has signed in on this device before while it was connected.
• Closing the app or restarting the tablet: it opens where it was, and everything waiting still sends.

Some places show the main terminal’s own records rather than the tablet’s copy. They open on the tablet while it is connected; while it is offline they say Needs the main terminal — in the ≡ menu and when you tap them: the Cash drawer (opening and closing a shift, cash in and out, the X and Z reports), Members, the Kitchenscreen, and refunds. Offline, Payment history still lists today’s checks of this tablet, and Reservations shows today’s bookings from its copy.

A brand-new device needs a connection once: after pairing, Preparing this tablet(Preparing this phone) downloads the branch. If it can’t finish, it keeps what it has and says why — press Try again on the restaurant’s Wi‑Fi.

While everything is fine there is no pill at all. When something needs your attention, a pill appears in the screen’s header (a round button on a phone):

• Offline — nothing it may send to answers: no main terminal and no internet (or no main terminal, on a device set to use only that). The tablet keeps working; the number is how many changes wait on it.
• Through the cloud — the tablet can’t reach the main terminal on this Wi‑Fi (it is on mobile data, say), so its changes go through the cloud, which passes them on to the main terminal.
• Sending — connected, but changes have been waiting more than 10 seconds.
• Not taken — the main terminal refused something (below).
• Connected — shows for a moment when a problem clears, then the pill goes away.

Tap the pill for the details: the route — this tablet, the main terminal, the cloud — with what answers; each change still waiting, like “T7 · Fire · 3 items · Sara · 2 min”; the last update and the connection setting. Try now sends at once. On a check, a chip like 2 waiting in the ticket’s head counts that check’s changes that haven’t arrived yet.

Now and then the main terminal can’t take a change made offline — a discount above the staffer’s limit, a dish taken off the menu in the meantime, a check cancelled on another till. The tablet never drops it silently: a list called Changes to look at opens by itself, once, with what happened to each change, who made it and when, and a button to open the check. Done clears it. Each person sees their own changes there (a manager sees everyone’s), and the list never opens over the lock screen.

A change whose staff member the main terminal can’t check yet — they signed in on this tablet while it was offline — waits on the tablet as Not taken — sign in to send, and goes as soon as that person signs in with a connection.

The same list tells you about sales the main terminal took but decided about, because something changed while the tablet was offline:

• Sold at the old price — the price changed while the tablet was offline (even for a few seconds); the guest is charged what the tablet showed, which is what they were told.
• Charged at the menu price — the tablet showed a price the main terminal can’t confirm it ever held, so today’s menu price was charged.
• Under-paid or Over-paid by an amount — prices or tax changed while the tablet was offline; the check closes at what the guest paid.
• Over-paid by an amount on a check that was already paid — this tablet took a payment offline while another tablet or till had already taken it. Both payments are kept and the check stays closed: give the guest the amount back, or keep it and tell the manager. The main terminal’s Devices counts it as paid twice.
• Sold out — check with the guest — the dish sold out while the tablet was offline; it was still sent to the kitchen.
• Paid elsewhere — dishes added to a check that was paid on another till meanwhile go to a new check on the same table, marked Late items beside its number; Open new check takes you there.

• Both add dishes to the same check while apart: both are kept — every line has its own ID.
• Both change the same line: the main terminal applies the changes in the order they reach it, so the last one to arrive stays.
• Both open the same free table while apart: both checks are kept — nothing is lost. The table’s card says 2 checks; tap it and the table’s sheet offers Merge, which folds the newer check into the oldest — the oldest keeps its number. Merge works offline too. Or open either check and bill them separately.
• One moves a check onto a table another just seated: both checks stay on that table — a move never merges by itself — and Changes to look at says Moved onto a seated table, with Merge one tap away.

The main terminal comes first. A tablet that can’t reach it over the Wi‑Fi but has internet sends its changes through the cloud, which keeps them for the main terminal; the main terminal picks them up within seconds, as long as it has internet.

If the main terminal has been gone for 10 minutes, the cloud takes over. Tablets show a band — Main terminal offline: “Working through the cloud. New checks get C numbers until it’s back.” The cloud then applies the changes itself, new checks get numbers that start with C (like #C007), and kitchen tickets print through the Menulisa Bridge as long as the Bridge’s computer is on. When the main terminal is back, it takes over again by itself — nothing is applied twice. A device set to Main terminalnever uses the cloud: its changes wait for the main terminal (see Choose how a tablet connects).

• A device that is fully offline is on its own: the kitchen and the other devices don’t see its orders until it reaches the main terminal or the cloud. The pill says so.
• Too many wrong PINs rest the keypad for a while — “Too many attempts — try again in 28s” — even after a restart.
• Dish photos may not show while offline; names, options and prices always do.
• The POS inside the app updates itself, only when the device is idle — locked, or on the floor with nothing waiting to send. The lock screen then says Updated to POS and the version, until the next sign-in.
• App 1.2.0 needs the main terminal on version 1.1.31 or later: an older main terminal can’t take its changes, so they wait on the device until the main terminal is updated.
• The app keeps a short log of its connection — Wi‑Fi drops, which server it used, crashes. It holds no guest, order or payment details, and staff appear only as an internal ID. It is sent to Menulisa support only when support asks for it, or by itself after a crash, and kept for 7 days.