Skip to main content

POS Live Data Sync

Purpose​

POS Live Data Sync updates master data used by already-open Point of Sale terminals. Managers choose separate policies for products, pricing/taxes and customers: apply changes automatically, notify staff for review, or synchronize manually. A status control shows pending changes, offline state and problems requiring review.

The module records changes and terminal progress so missed notifications can be caught up later. It updates only the records permitted by the active POS configuration and user. It does not make every database product or customer available at every terminal.

Before you start​

Install corvus_pos_live_data_sync for the exact Odoo major version. The reviewed 19.0 package depends on Point of Sale, POS Employees and Bus (point_of_sale, pos_hr, bus). There is no external service or Python-package dependency in its manifest. These native dependencies do not require Enterprise; the package is intended for Community and Enterprise with the required addons and hosting that permits server modules.

This guide is based on source review, primarily for 19.0. No runtime sync exercise was performed in this review. Use a test database to establish the effect of your policies before enabling them for a busy store.

Access and roles​

A Point of Sale User operates sync controls through an open, authorized session and active cashier identity. Employee-based POS configurations check that the cashier is assigned to that POS.

A Point of Sale Administrator/Manager configures sync, publishes product/customer records, previews events and opens audit, client-health and error menus. Managers can pause or resume a client, request recovery and export reports. Reprice Draft also requires manager authorization even if the button is visible to another cashier.

Setup and menu​

  1. Open a POS configuration and find Live Data Sync. The controls also appear in POS settings when a configuration is selected. Enable Live Master Data Sync.
  2. Choose the product, pricing and customer sync modes independently. Auto Apply permits automatic application; Notify & Review and Manual Sync defer changes until an explicit sync request. Defaults are automatic products/pricing and review for customers.
  3. Choose the inactive-product policy: Warn, Block, Review Removal, or Manager Override.
  4. Set delivery limits. Batch size must be 10–500, debounce 100–10,000 milliseconds and retention 1–365 days. Defaults are 100 records, 750 milliseconds and 30 days.
  5. Use Preview Changes to open pending events for that configuration. Open the POS under the intended cashier account so the terminal can register its sync client.

Workflow​

  1. Make an authorized backend change to a product, price-related record or customer that belongs in the POS data scope. Product and customer forms also provide the manager-only Publish to Open POS action.
  2. On the open terminal, inspect the Live Master Data status control. Automatic changes are fetched and saved locally before the terminal acknowledges them. Deferred changes remain pending or require review.
  3. Use Sync Now for an explicit catch-up. Check the resulting status and the products/customers available for a new cart. Structural changes may require review or recovery rather than an immediate in-place update.
  4. Review existing drafts separately. A master-data update preserves captured draft prices, discounts and tax relations. If the current draft should use its current pricelist, an authorized manager chooses Reprice Draft, then checks the resulting amounts.
  5. If an existing draft contains an archived or unavailable product, follow the configured policy. Warn displays a warning when paying; Block stops payment. Review Removal removes the affected lines and returns control for review before payment. Manager Override requires an authorized manager before proceeding.
  6. For terminal health, managers open Configuration → Live Sync Clients. Inspect status, last contact, pending work and application results. Use Pause, Resume, or Require Recovery Snapshot according to the issue.
  7. Open Reporting → Live Sync Audit or Live Sync Errors to inspect the event and error records. Errors have manager Retry and Resolve actions. Use Live Sync Health & Audit to select configurations and date range, then choose Print PDF or Export CSV.

Practice scenario​

In an authorized test database, open a fictional “Harbor Counter” POS with product updates automatic and pricing set to review. Add a “Travel Mug” to a draft, then change its backend sales price. Inspect the terminal status and choose Sync Now. The expected behavior is refreshed master data while the existing draft retains its captured values. Ask an authorized manager to use Reprice Draft and inspect the draft afterward. This is a source-derived practice case, not an executed result.

Troubleshooting and limitations​

Sync is disabled or unauthorized: check the POS enablement, open-session state, allowed company and active cashier identity. Employee assignment and manager rights are checked on the server.

Pending or Review Required persists: inspect the configured data-class modes and use Sync Now when the store is ready to apply changes. Do not assume a bus notification means the data has already been applied.

Offline: synchronization waits for connectivity. Reconnection sends native pending POS orders and queued writes before master-data catch-up. Preserve browser storage while those transactions remain unverified.

Reload Required or a retention gap: the retained event history may no longer cover the terminal, or a structural change needs recovery. The source includes a recovery-snapshot path and manager control. Check pending native transactions and the recorded error before refreshing the POS.

A changed record is absent: check POS eligibility, configured domains and user access. This is scoped master-data delivery, not cross-database replication or stock-reservation management. It does not silently reprice all open carts or modify paid historical orders.

Catalogue-qualified versions are 15.0, 16.0, 18.0, 19.0 and 20.0. Odoo 15.0 also needs base_sparse_field. The 15.0–16.0 packages use older POS controls and configuration layouts; 20.0 uses the newer Odoo access-definition format. Selected dependency, setup, security and UI differences were inspected, while the full source workflow here is 19.0. No 17.0 availability or all-version runtime result is established by this guide.