- Byte Legions
- Odoo Technical
Where POS Data Actually Lives Before It Reaches Your Database
Most teams treat Odoo Point of Sale like any other backend module: orders come in, records get written, life goes on. That mental model breaks the moment the shop Wi-Fi drops during a Saturday rush. Odoo POS is built as an offline capable frontend application, which means a real transaction can exist as a fully paid, receipt printed, customer walked out order while living nowhere except a browser tab. Getting odoo pos offline sync data protection right starts with accepting that uncomfortable fact.
The POS client loads product, pricelist, tax, and partner data into the browser at session start, then keeps writing orders locally as they are created. Depending on the version you run, that local persistence sits in browser storage keyed to the POS config, with newer releases moving toward a structured data service and IndexedDB backed storage instead of the older flat local storage approach. Either way, the storage lives on one device, in one browser profile, under one user. It is not replicated, it is not backed up by your server, and it is invisible to every reporting tool you own until a successful sync happens. That gap is exactly where a strong odoo pos offline sync data protection strategy earns its keep.
The Browser Side Queue: IndexedDB, Local Storage, and Session State
Three separate things sit in the browser during a live session, and they fail differently:
- Loaded master data: products, taxes, partners, pricelists. Cheap to lose because it reloads from the server.
- Draft or in progress orders: carts that have not been paid yet. Annoying to lose but rarely a financial event.
- Paid, unsynced orders: validated tickets with payment lines attached, waiting for the network. Losing one of these means real money that never became a real record.
Only the third category deserves paranoia. Everything you build should be optimized around never losing a paid, unsynced order.
What Survives a Refresh, a Crash, or a Cleared Cache
A page refresh is usually survivable because the queue is written to persistent browser storage rather than memory. A browser crash is normally survivable for the same reason. What is not survivable: a cashier clearing site data, an IT policy that wipes browser storage at logout, an incognito or private window session, a device reimaged overnight, or a “helpful” support person who tells staff to clear cache to fix a slow POS. Every one of those is a routine, well intentioned action that silently destroys revenue records. Write it into your standard operating procedure that browser data is never cleared while a session is open.
Why Server Level Safety Nets Do Not Cover Unsynced POS Orders
Here is the trap. Teams invest in nightly database dumps, filestore snapshots, replication, and tested restore procedures, then assume POS is covered. It is not. A database level safeguard can only protect data that reached the database. An order sitting in a cashier’s browser queue at 4pm was never in any dump taken at midnight, because it was never in Postgres at all.
That does not make server side protection optional, it just means the two layers solve different problems and both are mandatory. Once orders sync, they become normal records subject to the same corruption, deletion, and disaster risks as everything else, so a disciplined recovery posture still matters.
If you want the server side half of the picture, our breakdown of backup, data security, and recovery practices in Odoo 19 covers the database layer in depth. Treat this article as the client side counterpart to it.
Building a Resilient Offline Sync Layer
Order Queue Design, Retry Backoff, and Failure Visibility
Default behaviour retries sync when connectivity returns, but the default user experience is thin: a small indicator changes state, and that is roughly it. In a busy store, nobody is watching a small indicator.
Three improvements deliver most of the value:
Make failure loud, not subtle. Extend the POS UI so that any queue depth above zero for more than a defined window produces a blocking or semi blocking notification with an order count, not a color change.
Use exponential backoff, not a tight loop. Hammering an unreachable server every second drains battery on tablets and floods logs. Back off progressively, then reset on first success.
Log failures with context. Capture the failure reason, order reference, session id, and timestamp. “Sync failed” is useless in a post incident review. “Sync failed, HTTP 500, tax record missing, order Shop/0042” is actionable.
Preventing Duplicate Orders on Reconnection
Duplicates are the most common bug introduced by well meaning sync customizations. The pattern is predictable: the client sends an order, the server writes it successfully, the response is lost to a dropped connection, the client assumes failure and resends. You now have two records of one sale, inflated revenue, and inventory that moved twice.
Odoo guards against this by checking whether an order with the same POS reference already exists before creating a new one. Any custom sync path you write must preserve that guard rather than bypass it.
Idempotency Keys and Unique Order Reference Handling
The client generated order reference is your idempotency key. It is created in the browser before the network is ever involved, which is precisely what makes it reliable. A simplified server side guard looks like this:
from odoo import api, models
class PosOrder(models.Model):
_inherit = 'pos.order'
@api.model
def _order_fields_guarded(self, ui_order):
reference = ui_order.get('name')
existing = self.search([('pos_reference', '=', reference)], limit=1)
if existing:
# Already persisted on a previous attempt, return the existing id
return existing.id
return FalseWire that check into whichever sync entry point your version exposes, historically create_from_ui and more recently sync_from_ui, so a replayed payload resolves to the record that already exists instead of creating a twin. Pair it with a database level constraint on the reference field per session so that a race condition between two devices cannot slip through:
_sql_constraints = [
('pos_reference_session_uniq',
'unique(pos_reference, session_id)',
'A POS order with this reference already exists in the session.')
]Validate this constraint against your existing data before deploying, since legacy records may violate it.
Hardening POS Data Protection at the Session Level
Access Rights, Session Closing Controls, and Audit Trails
Offline capability changes the security calculus. A device holding unsynced revenue data is a device holding financial records outside your access control perimeter. Practical hardening steps:
- Restrict POS users to the minimum group required, and never let shop floor accounts hold broader accounting rights.
- Enforce device level screen locks and disable browser storage clearing through policy where you manage the hardware.
- Block session closing while unsynced orders remain, and make the error message explicit about how many orders are pending rather than generic.
- Log who closed each session, from which device, with which order count, so discrepancies can be traced later.
- Treat customer data loaded into the POS client as in scope for privacy compliance, because partner records genuinely sit in browser storage during a session.
Payment Terminals, IoT Box, and the Offline Blind Spot
This is where expectations and reality diverge most sharply. Cash sales work offline. Card payments through an integrated terminal generally do not, because the terminal itself needs to reach the acquirer. An IoT Box on the local network may keep printers and scanners alive while the internet is down, but it cannot authorize a card transaction.
Decide the store policy before an outage rather than during one. The realistic options are cash only during downtime, a standalone terminal with manual reconciliation afterwards, or halting sales entirely. Whichever you choose, document the reconciliation procedure, because manually processed payments recorded in POS after the fact are a frequent source of end of day mismatches.
A Practical Monitoring Playbook for POS Teams
Detection beats recovery every time. A minimal monitoring setup should:
- Run a scheduled action that flags POS sessions left open beyond a threshold, since a stuck session often signals unsynced orders on a device.
- Compare expected order counts against synced counts per session and alert on drift.
- Alert on any session closing attempt that was blocked by pending orders, because that event means data is currently at risk on a specific device.
- Track sync latency, not just success and failure. Rising latency is an early warning before outright breakage.
- Review POS error logs weekly rather than only after an incident.
If your store network is unreliable or your POS has been customized beyond the standard flow, an architecture review usually surfaces the exact failure points faster than trial and error. Book a consultation and we can walk through your sync layer, queue behaviour, and recovery procedures together.
Conclusion
Protecting POS data in Odoo is a two layer problem. The server layer handles everything already written to the database, and the client layer handles the window between a sale happening and that sale becoming a record. Most organizations invest heavily in the first layer and almost nothing in the second, which is why lost tickets, duplicate orders, and mismatched closings keep appearing in retail deployments. Fix the queue visibility, enforce idempotency on the sync path, lock down session closing, define your card payment policy for outages, and monitor for drift. Those five moves eliminate the overwhelming majority of POS data incidents before they reach your accounting team.
Frequently Asked Questions
If my Odoo database is backed up nightly, are my POS orders safe?
Only the ones that already synced. Orders sitting in a cashier’s browser queue were never in the database when the dump was taken, so a restore cannot bring them back. Client side queue protection is a separate requirement.
Can Odoo POS process card payments while offline?
Generally no, because integrated terminals need to reach the payment acquirer. Cash sales continue to work. Define a documented downtime policy covering cash only operation or standalone terminal use with later reconciliation.
What causes duplicate POS orders after a connection drop?
A successful server write whose response never reached the client, causing the client to resend. Preserving the reference based existence check on the sync method, and backing it with a uniqueness constraint, prevents the duplicate from being created.
Why does Odoo refuse to close a POS session sometimes?
Because unsynced orders are still pending. This is protective behaviour, not a bug. Restore connectivity on the original device and allow the queue to flush before closing, and never clear browser data to make the message disappear.
How do I recover an order stuck in a device's local queue?
Bring the same device, same browser profile, and same user back online so the queue can flush naturally. The data is device specific, so it cannot be recovered from another terminal or from the server. If the browser storage was cleared, the order is unrecoverable and must be re entered manually from the printed receipt.
Comments are closed