Odoo Point of Sale implementation

Every Odoo Point of Sale session produces postings in two places at once: stock moves in Inventory and journal entries in Accounting. Understanding the order in which those postings happen is the fastest way to find configuration errors before they reach the ledger. When a session opens, the cashier's opening balance is recorded against the session, and the point of sale is tied to the warehouse, company and journals that will receive its activity. Nothing reaches the general ledger yet, but every choice made at that point, from the picking type to the cash journal, determines where later entries will land. As sales are rung up, the point of sale creates orders that move stock out of the configured stock location and generate sales lines. Whether those moves are valued, and at what cost, depends on the valuation method and the product category settings for each product. Taxes on each line are resolved through the product's tax mapping and any fiscal position in force. Payments taken during the session are assigned to payment methods, and each payment method points to a journal. Cash payments usually hit a cash journal that is tied to the session, while card or other electronic payments may route to a bank or clearing journal. The accounts on these journals, and the outstanding accounts behind them, decide how the receipts appear in the books. When the session closes, the posted orders are aggregated into journal entries and the difference between the expected cash and the counted cash is recorded as a cash difference. Odoo's close step is the point where account mapping problems usually surface, because a missing income account on a product category, an unexpected tax account or a payment method pointing at the wrong journal will show up only when the totals are reconciled. Ask your implementation lead to confirm which journal, income account and stock valuation account each product category and payment method will use, and write that mapping down before the pilot. The most reliable control is a full open-to-close test against Accounting in a test database that mirrors production configuration. Run a session with cash, card and split payments, returns, a discount, a product with a different tax rate and at least one cash difference. Then check the stock valuation report, the sales and payment journals, the bank or clearing balances and the session close reconciliation line by line. Repeat the test after any change to journals, payment methods, categories or fiscal positions, since each one changes the postings. Finally, plan for the exceptions that real shops produce: refunds posted in a later session, orders paid partly in cash and partly by card, and sessions closed late or after a configuration change. Confirm with your accounting team how they want these handled in the ledger, and confirm with the Odoo documentation for your version how each case is posted, since behavior around session closing and valuation has changed across releases.

Hardware and offline behavior decide whether a point of sale rollout works on the first trading day, so verify both before purchasing a single device. Every store will run a mix of receipt printers, cash drawers, barcode scanners, kitchen printers, payment terminals and sometimes scales, tablets or other IoT devices. Odoo Point of Sale can only drive what your environment connects to it reliably, and the supported device list, connection methods and network requirements must be confirmed in Odoo's current POS documentation and with each device vendor. Do not rely on a general statement that a printer or terminal is compatible.

Start with a compatibility test in your own network, not in a demo room. Receipt printers and kitchen printers need a tested path from the POS terminal, whether that is USB, network or a bridge device, and the test should print a real receipt, a kitchen ticket and a reprint from the same till. Cash drawers are usually triggered through the printer, so the drawer test depends on the printer model and cabling. Barcode scanners should be tested with your real product barcodes, including weighed or variable-length items, because a scanner that reads a demo label correctly can still misread packaging in production.

Payment terminals need the most scrutiny. Confirm whether your acquirer and terminal model have a documented integration with Odoo, whether it is a direct integration or a manual card entry flow, and who certifies and supports that connection. Ask the terminal vendor and payment provider which PCI DSS responsibilities sit with your organization and which sit with them, and record the answer. Test declined, timed-out and refunded transactions, not only successful sales, and confirm how a payment that completes on the terminal but fails to return to Odoo is reconciled.

Offline operation is a design decision, not a fallback you configure later. Decide which transactions the till must complete without a connection, such as cash sales, card sales through a terminal that authorizes offline, or restaurant orders sent to kitchen printers on the local network. Then decide what syncs later: sessions, orders, payments, stock movements and customer records, and in what order. Document what a store does during an outage and how it recovers, including who closes the session, how duplicate orders are prevented, and how cash counts are reconciled against Accounting. Confirm each of these behaviors with Odoo's documentation for your version and by testing a cut network connection in a pilot store.

Put these checks on the pre-purchase list with named owners: the store manager for printer and drawer tests, the payments lead for terminal certification and PCI scope, and the platform team for network segmentation and offline recovery. A pilot store running a full trading day with the network disconnected for a defined period will expose more problems than any test plan. Ask any implementation partner for the written test scripts and the results from the pilot, and make a device that fails a test a blocking item rather than a go-live risk.

Before the first Point of Sale session, the database needs five groups of master data in a state the cashiers can trust: the product catalog with variants, price lists, taxes and fiscal positions, customers, and users with access rights. Payment methods belong on the same checklist, because each session needs a payment method linked to a journal before it can close. Treat these as one dataset that is reviewed together, not as separate uploads. A price list that points at the wrong tax, or a variant that carries a different barcode from the one printed on the shelf, shows up at the till as a rejected sale, not as a clean report. Start with the catalog. Decide which items are sold at the counter, which are components or services, and which carry variants such as size or flavor. Variant attributes should be agreed with the merchandising team before import, since changing them after sales have posted means reworking product references. Check barcodes, units of measure and internal references for duplicates. For a restaurant, confirm which products are routed to which kitchen or bar printer, because that routing is part of the product setup and is tested during the first session, not after it.

Prices and taxes are the most common source of disputes after go-live. Build price lists for each channel or shop that needs them, and confirm which list is the default for each Point of Sale configuration. Taxes depend on the fiscal localization installed for your country and on the chart of accounts, so ask your accountant to sign off the tax rates, tax-included or tax-excluded display, and any fiscal position that changes tax for a customer group, such as a tax-exempt organization. Confirm the exact fiscal localization package and whether a given tax behavior is supported in your Odoo version before you rely on it. Do not assume a rule from another country or version applies. Customers and users need the same care. Import only the customers you need at the counter, with the fields your receipts and invoices require, and remove or merge duplicates first. For users, map each cashier and manager to a role that limits discounts, refunds, price changes and session closing. Access rights decide who can override a price at the till, so write down the approval rule before the list is loaded. If your organization signs users in through an external directory, confirm which sign-in method your edition and version support rather than assuming it.

Test data is where a Point of Sale project most often causes harm. A test database built by copying production must be duplicated and neutralized before anyone runs a session on it. Odoo documents database duplication with neutralization for test copies, and neutralization is what keeps scheduled actions, outgoing mail and integrations from acting on live customers or payment providers. Confirm with your implementation lead exactly which items the neutralization step disables in your version, and then verify it on the copy: outgoing mail should go nowhere real, and payment terminals and payment provider settings should point to test accounts or be disabled. Record the check result before the first test session. The migration source changes how this data gets loaded. Moving from another POS system, from a spreadsheet, or from an older Odoo database each requires a different method, and the import tools available depend on your version and edition. Confirm with the vendor documentation which import and export tools apply to your exact version, and test each load on a copy with a reconciliation of counts, totals and tax amounts against the source. Do not run the full load into production until those totals match. Plan for a second full load rehearsal if the first one exposes a mapping problem.