M cenaly.ru
🚀 Getting Started

📴 No Internet or Cloud

What keeps working when the connection drops: the POS keeps ringing up and printing, orders and receipts queue up and sync back without duplicates

Documentation

If the internet goes down or the cloud is unreachable

Connections break: the provider, the router, a thunderstorm, an outage at the operator. The venue does not close because of it — guests are standing at the counter. Below is exactly what keeps working, what does not, and what the shift should do.

Tell two failures apart, because they behave differently:

What happened The POS in the venue A guest from the street
The internet is down in the venue Works offline: rings up, prints, builds a queue The storefront opens (it is served from a CDN) and the order reaches the cloud — but in the venue you will only see it after the connection is back
The cloud is unreachable Exactly the same: the POS does not tell one from the other — for it this is "the write did not go through" The storefront may open from cache, but placing an order and paying will not work

The POS deliberately does not try to guess the cause: any network error means "work locally, write to the queue".

What keeps working#

The POS (web). This is not just a cached page but a real write queue on the device:

  • an order is rung up and goes into the order queue (it lives on the POS for 24 hours);
  • receipts and the cash shift get their own operation queue (opening a shift, pay-ins and pay-outs, a receipt, a refund, closing a shift). Every operation carries a client-side idempotency key, so syncing never duplicates anything;
  • a shift opened offline gets a temporary number and keeps working: the gate "no payment without an open shift" applies offline too, computed from the local cache;
  • the menu, prices, tables and reference data are read from the browser's local cache — they got there while the connection was alive;
  • reloading the page does not throw you to the login screen: the POS opens in a "degraded session" from a local snapshot and reconnects itself once the network is back.

Printing. The receipt, the kitchen ticket and the label are printed by the bridge installed on the same computer: the POS talks to it over the machine's local address — no internet needed.

The fiscal receipt. If the fiscal printer is connected to the same computer, the receipt is issued through the bridge over that same local channel: the fiscal drive accumulates documents and the fiscal data operator catches up once the connection appears. For 54-FZ this is a normal mode, not a violation.

The login screen. As long as the browser holds a recent session (the window is 7 days), the cashier signs in and works; sending the accumulated data will still require real authorization once the connection is back.

What does not work without a connection#

  • The kitchen display (KDS). Tickets reach it through the cloud; without the internet new orders will not get to the kitchen — they will travel there once the connection is back. Meanwhile the kitchen works from printed tickets, if you have kitchen printing set up, or from spoken orders.
  • The bank terminal. Card payment requires authorization at the bank — it will not go through offline. Take cash.
  • Online payment by the guest (card on the storefront, paying the bill at the table, paying at the kiosk) — it needs access to the payment provider.
  • A second POS and the server's tablet. Devices do not sync with each other over the local network: each keeps its own queue and syncs it itself. We deliberately do not build a shared local contour ("LAN mode") — the product owner's decision is to cover the autonomy of one POS with printing.
  • The X report. The interim snapshot is computed on the server from sales — offline the POS will honestly refuse. You can close the shift; the Z report will be produced when the connection is back.
  • Admin sections that compute on the server — Orders, Finance, Statistics, Inventory, Staff. They read the cloud, and offline they show at best the last thing they managed to read.
  • The expo screen, the queue display, the kiosk — cloud surfaces as well.

What staff should do#

  1. Keep ringing up. As soon as the connection drops, an amber "offline" banner and an "N not sent" chip appear in the POS. This is a normal mode: the order is taken, the receipt is printed, the money is collected.
  2. Print the guest's receipt as usual. Printing is local — the paper comes out.
  3. Stay on the same device and the same browser. The queue lives on this computer: you cannot move to a second tablet and "sync it from there".
  4. Do not clear the browser cache, do not sign out, do not open the POS in private mode — that erases unsent orders and receipts.
  5. You may reload the page. The queue survives a reload and a browser restart.
  6. Do not ring up the same order twice "just in case": the system protects against duplicates on sync, but two different orders will honestly be counted as two.
  7. Do not accept cards — the terminal cannot authorize offline. Take cash, or issue an invoice if the guest prefers to pay later.
  8. A red "N not delivered" banner means some records did not go through even after the connection returned (they expired or the server refused). That is a reason to call the manager, not to hide the banner.

What happens when the connection returns#

Syncing starts on its own — on the "network is back" event, when you return to the tab, and on a timer.

  • The "N not sent" chip goes down and disappears. Orders appear in the Orders section and on the kitchen display, receipts get numbers, stock is written off according to recipe cards.
  • There will be no duplicates. Every order carries a client-side identifier and every POS operation an idempotency key; the server recognizes a repeat and does not apply it twice.
  • The offline shift is replaced by the real one. The temporary shift number is rewritten to the real one in every receipt and movement still waiting in the queue.
  • The Z report is produced for a shift closed offline.
  • Nothing is deleted silently. Records that could not be delivered (a day expired, or the server returned an unrecoverable error) go into a separate "not delivered" list (kept for 7 days, up to 100 records) and are shown in a red banner that can be dismissed manually.

Order is preserved: the queue is sent sequentially, and on temporary server errors it retries with a growing pause.

Limitations#

  • Offline covers the POS and printing — and nothing else. The kitchen display, the bank terminal and syncing between devices over the local network do not work without the internet; a full LAN contour is deliberately not being built.
  • The queue is tied to the device and the browser. It lives in that specific browser's storage: another computer, another browser or private mode will not see it.
  • The queue lives 24 hours for orders and POS operations. More than a day without a connection and records move to the "not delivered" list instead of quietly disappearing.
  • An offline session lives 7 days. After that the POS asks for a normal login, and that is impossible without a network.
  • The X report is unavailable offline — it is computed on the server.
  • Guest-facing surfaces (storefront, kiosk) keep a queue for one hour only — they are meant for a short mobile-network gap on the guest's side, not for working without the internet.
  • The Android POS. Taking an order and issuing a local fiscal receipt work offline, but writing to the receipt registry and the cash shift offline do not yet (planned). The fiscal drive is the source of truth offline there.
  • An end-to-end "pull the cable" run on a live fiscal printer has not been done yet. The POS offline mode is covered by code and automated tests (including an "in-session offline" e2e test), while a check on real hardware by the owner is on the plan — we say this plainly instead of presenting it as done.

Troubleshooting#

The POS asks me to sign in although it used to work. The session is older than seven days, or the browser was cleared. You cannot sign in without a network — restore the connection.

The "N not sent" chip does not go down. Check that the connection really is back (open any website) and keep the POS tab active: syncing runs on the network event, on returning to the tab and on a timer. If the chip stays at the same number, look at the red banner — some records may have moved to "not delivered".

A red "N not delivered" banner appeared. The records were not accepted by the server: the 24-hour limit expired or the answer was unrecoverable (for example, access was revoked). Orders and receipts from that list have to be entered manually — reconcile with the shift's paper receipts.

An order was rung up offline but the kitchen does not have it. That is expected: the ticket will travel to the kitchen display once the connection is back. While there is no network, printed tickets feed the kitchen.

The receipt does not print offline. Then it is not about the internet: check that the bridge on this computer is running and the printer is connected — Cenaly Hardware Bridge. The bridge and the POS talk inside the same machine.

Duplicate orders appeared after the connection returned. Syncing cannot create duplicates — check whether the same order was rung up twice by hand, and cancel the extra one in the Orders section.

FAQ#

Does the POS work without the internet?#

Yes: it rings up orders, prints receipts and fiscalizes them through the bridge on the same computer. Everything that has to reach the cloud accumulates in a queue on the device and is sent automatically.

Will data be lost?#

No. The queue survives a page reload and a browser restart, and whatever could not be delivered lands in a visible "not delivered" list instead of vanishing. The only way to lose it is by hand — by clearing the browser's data.

Can 54-FZ receipts be issued offline?#

Yes, if the fiscal printer is connected to the same computer as the bridge: the fiscal drive accumulates documents and passes them to the fiscal data operator once the connection appears. This is a mode the law provides for.

Why does the kitchen display not work?#

Tickets travel through the cloud. There is no local network between the POS and the kitchen display — a deliberate decision: we cover the autonomy of the POS with printing, not of the whole floor. While there is no network, printed tickets hold the kitchen.

Can a guest open the menu while we have no internet?#

Yes — the storefront is served from a CDN and does not depend on your internet. An order placed by a guest will reach the cloud, but in the venue you will see it only after the connection is back.

What about card payments?#

Take cash: the bank terminal needs authorization at the bank.

How long can the POS hold out without a connection?#

Twenty-four hours for the queue of orders and POS operations, seven days for the session. In practice that means you will work through the shift calmly.