A saved POS sale does not establish confirmed payment or settled central inventory. When buying offline capability, request three evidence paths for the same event: sale record, payment state and quantity effect after reconnection. “Offline” alone does not define the service boundary.
Name the actual disconnection
A fictional art-supplies store has two tills. One loses service connectivity while another sale or central change occurs elsewhere. A specialist would prepare an authorized synthetic-data scenario, not disconnect a working store or use customer cards. The example defines acceptance questions only.
Specify whether the application service, all internet access, local network or payment device is unavailable. One component may remain connected while another fails. Record device, app version, peripherals and included payment method; one device's result should not represent every branch configuration.
One event with three states
Connect the stages through a traceable reference after reconnection. A local display number may gain a different central reference, so require an explicit link rather than matching item name and amount. This is a proposed acceptance tool, not a completed test record.
| Path | During disconnection | After reconnection |
|---|---|---|
| Sale | Local reference, items, quantities and known price | Central reference or explained waiting state |
| Payment | Cash, manual or card with an explicit state | Confirmation, rejection or follow-up with method-appropriate evidence |
| Inventory | Device information and freshness limits | Central effect and any decision-requiring conflict |
Define expected results separately for each path. Success in the first should not automatically mark the others successful. Repeated button presses also do not establish valid additional sales. Ask how pending events appear and how staff distinguish them from completed ones.
Temporary resilience is not every function
Odoo19 introduces a browser-based POS designed to retain functionality during temporary outages. That introduction does not establish every peripheral, payment method or function works offline. Request evidence for the included device and function, with exclusions visible.
Shopify distinguishes manual payment methods from later order and inventory synchronization and cautions against device shutdown or logout with unsynced orders. Its Always-on authorization still requires an eligible device reaching the payment processor online; the name does not mean authorization with no connection whatsoever.
Its offline card-payment guidance describes Payment pending followed by processing after reconnection, potentially becoming Paid or Card declined. This is conditional product behavior with device and availability limits, not guaranteed card acceptance in every country or collection for every saved sale.
Include a central change in the sample
In the fictional case, the business owner defines policy when device-known quantity differs from central availability after another sale. The supplier identifies implemented behavior and any reconciliation or decision needed. No universal priority rule is invented, and local sale acceptance is not equated with immediate central stock reservation.
Include a known price version, delayed arrival of the event and an exception requiring follow-up. A specialist defines safe steps in a suitable environment and separates simulation from functions requiring approved equipment. Real payment data or actual inventory changes are unnecessary for this purchasing worksheet.
Who owns unresolved events?
Name who reviews financially unconfirmed or centrally unsettled events and what closes them. “It will sync later” needs an explanation of staff-visible states and required follow-up. Handover may accept a defined function while retaining a disclosed exception for separate decision.
Retain reconnection time, event references, all three outcomes and sample boundaries. If a stage cannot be measured, identify it as unproven rather than inferring success from a disappearing error. Preserve the distinction between continued selling, payment settlement and inventory without promising an unagreed recovery time.
The multi-branch POS demonstration plan places this case within wider operations. Bring the three-state worksheet and intended device when discussing POS with Nextwave to define offline support in the implementation proposal.
Offline capability references
The Odoo POS introduction and relevant Shopify offline checkout and offline payment sections were read on 4 November 2026. Prepared with AI assistance and information and translation review, without payment, network disconnection or inventory changes.
