Odoo POS Architecture – How the Point of Sale Works

Point of Sale: Why It's Offline-First

The Odoo POS is architecturally different from the rest of Odoo: it's a JavaScript (OWL) app that loads its data up front and runs in the browser, so a cashier can keep ringing up sales even if the network drops. Orders sync back to the server when the connection returns.

Why this design: a checkout line can't freeze because the WiFi hiccuped, and it must feel instant — so the POS avoids a server round-trip on every scan or key press. Everything needed to complete a sale is preloaded and processed client-side.

What it means for developers: extending the POS is mostly front-end work — OWL components and JS models, not Python views. When you add a field the POS needs, you must tell it to load that field (via the POS's loaded-models config) or it won't be in the browser's cached data. And because computation happens locally, business logic like custom pricing often has to be implemented in JS on the POS side, not only in Python — a common surprise for backend-focused Odoo devs. Orders reconcile server-side after the fact.

Two-Layer Architecture

Odoo POS has a clear separation between two layers:

When a cashier opens a POS session, the browser loads all necessary data from the server in one batch. After that, the POS works with local JavaScript objects. The server is only contacted for specific operations: real-time card payments, loyalty program lookups, and closing the session.

pos.config – Shop Configuration

pos.config is the static configuration of a POS shop. One business can have multiple configs (e.g., one for each register or each shop location). Key fields:

• name — display name ("Cash Register 1")
• payment_method_ids — accepted payment methods (cash, card, etc.)
• pricelist_id — default pricelist for this POS
• product_configurator_ids — which product categories to show
• module_account — whether to generate invoices at checkout

Custom modules that add settings to the POS extend pos.config with new fields.

pos.session – An Active Session

pos.session represents one working session on one pos.config. A session has states:

Closing a session posts all session payments as bank/cash journal entries and marks all session orders as done. The session's statement_ids link to accounting journal items.

Data Loading at Session Open

When the POS loads, it calls /pos/ui which returns a JSON payload containing everything the frontend needs. The _get_pos_ui_data() method (on pos.config) controls what is loaded:

# What gets sent to the browser at session open (simplified):
{
    'pos.session':     [session data],
    'pos.config':      [config data],
    'product.product': [all products visible in POS],
    'res.partner':     [all customers],
    'account.tax':     [all taxes],
    'pos.payment.method': [payment methods],
    'pos.category':    [product categories],
    # ... more models
}

To add your custom model's data to this payload, override _get_pos_ui_data() in your Python extension of pos.config.

Order Lifecycle

A POS order goes through these stages:

1. New order — created as a JavaScript object in the browser
2. Lines added — product lines with qty, price, tax computed locally
3. Payment — payment lines added; total validated
4. Order finalized — sent to server via /pos/create_from_ui
5. Server creates records — pos.order + pos.order.line + account.payment

If the internet connection drops after step 3, the order is stored locally (IndexedDB) and synced when connectivity is restored.

RPC Communication

The POS frontend calls the server using JSON-RPC. Key endpoints:

From JavaScript, use this.env.services.orm.call(model, method, args) to call Python model methods from the POS frontend.

Interview Questions

• How is the Odoo POS architected?
• Why can POS work offline?
• Where do POS orders live before syncing?
• What frontend technology does POS use?
• How does POS sync with the backend?

Related Topics