When your service is down, and when the till is offline
Part 4 of 5 · 9. The extension points, and how to ask for a new one
Back: Asking for a new extension point, or for more from oneNext: Technical notes
Every extension point states both before it ships. For the extension points:
| Extension point | Your service is down or slow | The till is offline |
|---|---|---|
| Remote till key | The cashier reads that your app could not finish; nothing is added; the sale goes on. No retry. | The key is dimmed. |
| Event feed | Nothing is lost: you pull, so your events wait until you are back. | An offline sale's events appear when the till syncs, possibly hours later. |
| Save rules | No service is called. | A write inside an offline sync is never refused, only flagged for review. A manager's approval given offline is not counted by a count_per_day rule. |
| Desk action | The user reads "… did not answer in time. Check the record before you try again." It never claims nothing changed: your service may have written before it went quiet. | Desk is online by nature. |
| Document check | The answer you declared applies: allow the submit and flag it (the default), refuse it (did not answer, so this document can't be submitted yet), or ask the user whether to submit anyway. The document waits for you, at most 10 seconds for all of one submit's checks. | None: back-office documents are submitted on the server. A sale the till made offline never reaches you. |
| Partner page | A page that does not load in 10 seconds shows "… isn't answering." Nothing is added to the sale. | The key is dimmed. |
| Fiscal reader | The sale waits as pending and its receipt is held until the service answers or the back office does. | A sale made offline waits as pending, like any other, once the till syncs it. |
| Check before payment | The answer you declared applies: allow the sale and flag it (the default), refuse it, or ask the cashier whether to go on. | You are not called. The till applies each check's declared answer; the sale, when it syncs, is flagged and never refused. A need that must hold offline declares refuse, or runs as a module (the Wasm kit). |
| Pricing | No service is called: the module runs inside the retailer's iVendNext. A module that traps, runs out of steps or answers something refused takes nothing off the line. | The same module runs on the till from its offline copy. A customer the till does not know reads as no customer group, so a rule keyed on the group takes nothing off there. |
| Wallet | The till says the wallet did not answer, and the cashier takes another payment. A payment left without an answer is settled later by asking your service about its reference. | The wallet is not offered. |
| Capture on an event | The answer you declared applies: let the item or customer on and flag it (the default), or refuse. On customer_select, refuse takes the customer off the sale. On qty_change, refuse puts the last allowed quantity back. A notice is never a down answer. |
You are not called. The till applies the declared answer: a scanned item your filter names is let on or refused by it, and a customer is taken on the till or stopped by it. A customer added offline and synced with the sale is created and flagged, never refused. On customer_select, a sale paid offline with a customer you were not asked about books when it syncs and is flagged. On qty_change, the declared answer applies: allow and flag keeps the new quantity, marked on the line and flagged when the sale is paid online or syncs; refuse puts the last allowed quantity back. |
| Scan source | No service is called: the source is a table in the retailer's iVendNext, and one that cannot be read is skipped. | A unit's code reads Not found: the cashier scans the item barcode and picks the batch. A GS1 pack code is read offline. |
| Field rules | No service is called. | Hide, relabel and require work, and a shown field rides the till's offline data. The basket's totals keep the till's own provisional words offline, and a line's list price is the till's own price basis. A customer added offline without a required field is created when the sale syncs, and flagged. |
| Label layout | No service is called. | The cashier reads "Labels need a connection." |
| Fulfil at sale | The sale stands and the receipt waits: Try again, or Print without it (the receipt says the code is on its way; a reprint once it is issued prints it). The retailer's server asks again 1 and 5 minutes later; after three failed tries the line is flagged. A refund of that line is refused until its code is cancelled, so none is given while your service is down. | The item cannot be sold offline ("⟨label⟩ needs a connection to sell this item."). A sale drained with one anyway is never refused: you are asked after it syncs, and the line is flagged. |
| Payer | No down answer to choose: a service that does not answer in its time to answer (3 seconds unless raised, at most 5), errs or answers wrongly means no cover, and the cashier reads "⟨label⟩ cannot be reached: the customer can pay it all, or hold the sale." Your share is never booked on a guess. | Never offline: the Payer tile is not offered, a sale with a payer is never queued, and its return is online only. |
| Open check | No service is called: your app calls the retailer's iVendNext. When it does not answer, send the same request again with the same key: a write that landed answers with its first answer and is never written twice. |
Nothing here works offline. A sale for a check that a till queued offline is never booked: the till's offline review shows it, and it is paid on the check. Your app never sees that flag. |
| Station ticket | No service is called: your screen calls the retailer's iVendNext. A move sent again with the same step answers already, so a retry is safe. While the live connection is down, read the board every few seconds: every read is the whole board. |
Your screen needs the internet. The store's tills print their tickets on their own; those tickets never reach the board, even after the till reconnects. |
| Register books | No service is called. | A sale made offline writes its lines when it drains, numbered then and dated when the till captured it, marked Entered late; a drained sale is never refused, only flagged. |
| List mark | No service is called. | Desk is online by nature; the till draws no Desk list. |
| Print template readers | No service is called. | The till's own screen receipt never calls a reader; a print from the server needs the server. |
| Receipt | No service is called. | WhatsApp is not offered offline: the receipt offers email and SMS, as before. |
Back: Asking for a new extension point, or for more from oneNext: Technical notes