How Sync Works
Understand what data moves between your Desktop POS devices and the Backoffice, when it moves, and what happens when a device goes offline.
What Syncs
Data flows in different directions depending on where it originates:
Data type | Direction | Description |
|---|---|---|
Catalog | Pull (Backoffice → Device) | Products, categories, prices, and tax labels pushed from the Backoffice to each device |
Stock | Push (Device → Backoffice) | Stock movements — sales, adjustments, and stock takes — sent from devices to the Backoffice |
Sales / Invoices | Push (Device → Backoffice) | Every fiscal invoice created on a device is uploaded to the Backoffice |
Shifts | Push (Device → Backoffice) | Shift opens, cash movements, and shift closes are sent on completion |
Cashiers | Pull (Backoffice → Device) | Cashier accounts and PINs managed in the Backoffice are delivered to devices |
Customers | Bi-directional | Customers created or edited in the Backoffice or on a device are merged at sync |
Suppliers | Pull (Backoffice → Device) | Supplier records managed centrally are delivered to devices |
Audit | Push (Device → Backoffice) | Device-side audit events (logins, voids, overrides) are uploaded to the org-wide audit log |
Backups | Push (Device → Backoffice) | Encrypted device database snapshots are uploaded after each shift close |
Delta Sync
Each sync cycle is incremental rather than a full data transfer:
The device sends the timestamp of its last successful sync to the Backoffice.
The Backoffice returns only the records that changed since that timestamp.
The device applies the changes and confirms receipt.
The Backoffice anchors the next sync to the confirmed timestamp.
This keeps each sync fast and network-efficient, even for large catalogs or high-volume sites.
Intervals
Sync runs on a scheduled interval in the background:
The default interval is approximately 30 minutes.
Each sync cycle uploads any pending pushes and fetches any available pulls.
You can trigger an immediate sync at any time from the device under Settings → Sync → Reconnect, or from the Backoffice under Devices → Force resync.
Tip: After making a large catalog update in the Backoffice, use Force resync on the affected devices to deliver the changes immediately rather than waiting for the next scheduled cycle.
Reliability
The sync engine is designed to handle unreliable connections without data loss:
Idempotency — every upload includes a unique transaction ID. The Backoffice ignores duplicate uploads, so retrying a failed sync never creates duplicate records.
Batched uploads — large sets of invoices or stock movements are broken into batches. If a batch fails, only that batch is retried on the next cycle.
Offline Behavior
Desktop POS is offline-first. When a device cannot reach the Backoffice:
The POS continues to sell, fiscalize, print, and shift-close normally using its local database and local SDC.
All sales, stock movements, and audit events are queued locally.
On the next successful connection, the device uploads everything it accumulated offline in the order it occurred.
Note: Offline periods do not cause data loss. When the Backoffice is unreachable, data accumulates on the device and is pushed in full on reconnection. The only limitation is that catalog updates from the Backoffice will not reach the device until it reconnects.