Multi-Location Retail with Odoo 20 POS

Running one shop on a point of sale is easy. Running five is where most retail software starts to creak: stock counts drift between locations, each store keeps its own price list in a spreadsheet, and head office waits until month-end to find out what actually sold. Odoo has always approached multi-location retail differently — one database, one product catalogue, and a separate point of sale configuration for every register, all drawing on the same inventory and accounting. Odoo 20 keeps that architecture and adds several changes that matter specifically when there is more than one till, more than one stockroom, or more than one store. This article walks through how a multi-location setup is structured, what Odoo 20 changes for chains and multi-store independents, and the decisions to make before you roll it out.

One database, many points of sale

The foundation of multi-location retail in Odoo is that a point of sale is a configuration, not an installation. Each store — and, where needed, each register inside a store — gets its own POS configuration on the same database. Odoo's own getting-started documentation puts it plainly: you can configure each point of sale according to its hardware and location. That per-POS configuration is where the local differences live:

Stock source. Each POS sells from its own inventory location, backed by the store's warehouse, so a sale in one shop decrements that shop's stock — not a pooled company-wide figure.
Payment methods. Payment methods are created centrally, then activated per point of sale. A store that takes a local payment option can offer it without exposing it at every other location.
Pricelists. A POS can have its own available and default pricelists, so regional pricing or a flagship-vs-outlet price difference does not require separate product records.
Hardware. Printers, displays, and other connected devices are attached per POS, matching what is physically on that counter.

What stays shared is just as important: one product catalogue, one customer database, one chart of accounts, and consolidated reporting across every shop. A product created once is sellable everywhere; a customer's loyalty and identity follow them between stores; and head office sees all locations in the same reports instead of merging exports.

Stock: full inventory, or the new simplified mode

Historically, every POS location also meant adopting Odoo's full Inventory app — warehouses, locations, routes, and transfers. That is the right answer for a chain with a distribution centre, inter-store transfers, and reordering rules per location. Odoo 20's Inventory changes support that model well, including suggested minimum and maximum levels on reordering rules, which takes some of the guesswork out of setting per-store replenishment thresholds.

The genuinely new option in 20 is simplified inventory management for POS: the point of sale can now work without installing the Inventory app at all. In this mode a single on-hand quantity is displayed per product and there are no required transfers. For a small second location — a kiosk, a seasonal pop-up, a counter inside another business — that removes most of the setup and training burden. The trade-off is real, though: without the Inventory app you give up the warehouse machinery (multi-step routes, putaway, lot and serial traceability) at that operation. A sensible pattern for mixed estates is full Inventory where stock discipline matters, and simplified mode only where the location is genuinely a till with a shelf behind it.

Two smaller 20 additions help at the shelf edge in every store: cashiers are now notified when they select an expired product on the POS, and products can be snoozed — made temporarily unavailable on the POS or self-ordering menu — which is the clean way to handle a store-specific stock-out or recall without archiving the product for the whole chain.

What Odoo 20 changes at the counter

Multiple printers per point of sale

Printer management is the most directly multi-location item in the Odoo 20 release notes: you can now set up multiple printers linked to your point of sale and select which printer to print on. Odoo describes this as improving the workflow for big structures with several cash drawers — a large store with several tills sharing preparation and receipt printers, or a flagship where the receipt printer depends on which department rang up the sale. Pair this with the existing ability to print one preparation ticket per product, and larger locations get a much more flexible print layout than the old one-POS-one-printer assumption.

Hardware without a box at every till

Odoo 20's browser-based hardware approach (Local Network Access) lets the POS talk directly from the browser to network ePOS printers without an IoT gateway or SSL certificates, on Chromium-based browsers. Across a chain, that changes the per-store hardware bill: a new location whose printing needs are covered by supported network ePOS printers may not need an IoT box at that counter at all, while sites with scales, certain payment terminals, or USB/ESC-POS printers still connect those devices through an IoT system. Standardising on the directly supported printer family across stores is now worth real money, not just convenience.

Multiple currencies in one point of sale

Odoo 20 allows multiple currencies to be supported at checkout in the same point of sale. For most single-country chains this is a non-event; for border-town stores, tourist locations, and airport or duty-free formats it removes a long-standing workaround of splitting tills by currency.

Sessions, cash, and accounting across stores

Each register still works in sessions: open with a cash float, sell, close, and reconcile. What changes in Odoo 20 is what happens at the end. The release notes describe a reworked end-of-session flow in which a global sale is generated to simplify the accounting entries and remove the miscellaneous entries, and payment journal entries are automatically generated at the time specified in the settings, without needing to end the session. Multiplied across five or ten stores closing at different times, that is a meaningful reduction in accounting noise: fewer stray entries per shop, and payment postings that land on schedule even if a store closes its session late.

Control features also tightened up. Employee access levels in POS have been renamed, and a new, highly restrictive “Supervised” access level has been added — useful for trainees and seasonal staff who should sell under oversight but not perform sensitive operations. And when head office or an auditor needs to find a transaction, the Orders overview can now be searched by invoice number or receipt number, which is far faster than filtering by date and store.

Day-to-day merchandising across locations gets a small quality-of-life change too: products can be reorganised in the POS interface by drag and drop, so each store can arrange its grid around its own best sellers rather than a single chain-wide layout.

A rollout checklist for the second store and beyond

Model the estate first. Decide which locations are warehouses in their own right and which are simple selling points; that decides full Inventory versus the new simplified mode per site.
One POS configuration per register, named consistently (store + till), each with its own stock source, payment methods, pricelist, and hardware.
Standardise hardware per store type. Prefer the directly supported network ePOS printers where possible so new sites can use Local Network Access; reserve IoT gateways for scales, terminals, and legacy printers.
Set per-store replenishment. Configure reordering rules per location and review Odoo 20's suggested minimum/maximum levels rather than copying one store's numbers everywhere.
Assign access deliberately. Map managers, cashiers, and trainees to the renamed employee access levels, and default new or seasonal staff to Supervised.
Agree the closing routine. Set the automatic payment-journal timing, confirm who closes sessions at each store, and use the simplified end-of-session accounting as the single version of the truth.
Pilot one store, including an offline drill — Odoo's general offline mode and the POS's ability to keep selling through a temporary outage matter far more at a remote second location than at head office.

Where multi-location setups still go wrong

The failures are rarely about Odoo 20 features. They are structural: two stores accidentally selling from the same stock location, so both counts are fiction; pricelists multiplied per store until nobody knows which price is authoritative; and hardware bought per store without a standard, leaving every site with a different printer and terminal combination to support. Odoo 20 reduces the cost of doing it properly — simplified inventory for small sites, direct browser hardware for standard printers, cleaner session accounting — but the discipline of one catalogue, one location model, and one hardware standard per store type is still yours to enforce.

For a retailer growing from one shop to several, that is the real headline: Odoo 20 does not bolt multi-location on as an afterthought. It treats every store as a first-class point of sale on shared data, and its 20-specific changes — multiple printers, multiple currencies, simplified inventory, supervised access, and tidier closing — are aimed precisely at the friction that appears when the second, fifth, or fifteenth till opens.