POS Multi-Restaurant / Multi-Branch Manager

Key Features

New branch model linking `pos.config`, `res.company`, `restaurant.floor`, and `product.pricelist` so each location is a first-class entity, not a cloned config

Per-branch floors and tables scoped to a single branch, preventing cross-location table bookings and split-check errors

Per-branch menu availability: products and POS categories toggled on or off per location without duplicating the master catalog

Per-branch price lists with inheritance from a master list plus location-level overrides for local pricing and taxes

POS session stamping — every `pos.session` and `pos.order` carries its operating branch, enforced at creation

`ir.rule` record rules keyed on branch membership so managers see only their location's sessions, orders, and cash reconciliation

Central menu push: an `ir.actions.server` action propagates products, categories, and prices to selected branches while preserving per-branch overrides

Cross-branch consolidated sales dashboard (pivot/graph plus an OWL component) aggregating revenue, orders, and average ticket across all locations

Stored `@api.depends` compute fields for per-branch and group totals so the dashboard aggregates without slow live queries

Branch-scoped security groups (`res.groups`) for cashier vs branch-manager vs group-operator, with button- and menu-level visibility

QWeb PDF reports for per-branch and consolidated daily and period sales, printable from the back office

Cashier permission controls limiting refunds, discounts, price overrides, and session close by role at the POS UI level

XML-RPC / JSON-RPC endpoints returning branch-scoped figures for HQ BI, franchise portals, or external dashboards

Compatible with single-company (multi-branch) and multi-company (legally separate franchise) topologies, with record rules adjusted to your structure

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Restaurant groups and franchises hit a wall as soon as they open their second location on Odoo. The native Point of Sale app was designed around a single shop per configuration: floors and tables belong to one pos.config, product availability is global, and there is no first-class notion of a "branch" that ties a POS session, its cashiers, its menu, and its pricing together. Operators end up cloning POS configs by hand, duplicating products across price lists, and stitching sales figures together in spreadsheets at month-end. Multi-company setups help with legal isolation but make menu management and consolidated reporting worse, not better, because Odoo core keeps each company's data siloed.

The POS Multi-Restaurant / Multi-Branch Manager is a module we build to close that gap. We introduce a branch model (a new models.Model with _inherit/relational links to pos.config, res.company, product.pricelist, and restaurant.floor) so that each location carries its own floors and tables, its own menu availability, and its own price list, while still rolling up into one reporting layer. On the ORM side we add computed fields (fields.Monetary, @api.depends) for per-branch and consolidated totals, and stored compute fields where the dashboard needs to aggregate quickly. POS sessions are stamped with the operating branch and validated with record rules so a session opened at Branch A can never post orders, read tables, or reconcile cash against Branch B. Menu management is centralized: an admin edits the master catalog and a "push to branches" action (an ir.actions.server / automated action) propagates products, categories, and prices to the selected branches, with per-branch overrides preserved.

Security is done the Odoo-native way rather than bolted on. We ship an ir.model.access.csv for the new models plus ir.rule record rules keyed on branch membership, so a branch manager sees only their location's sessions, orders, and cashiers, while a group operator sees everything. Cashier and manager permissions are modeled as security groups (res.groups) with menu and button-level visibility in the OWL POS UI and back-office XML views. The consolidated sales dashboard is delivered as an Odoo view (list/pivot/graph plus an OWL dashboard component) reading from a read-optimized model, and we provide QWeb PDF reports for per-branch and group-level daily/period sales. Where you already run automation or external systems, the module respects the standard XML-RPC / JSON-RPC API so headquarters tools, BI, or a franchise portal can pull branch-scoped figures without direct database access.

This is a build-to-order engagement, not an instant download. After a short scoping call we confirm exactly which of the capabilities below you need, your Odoo edition (Community or Enterprise), and your target version (17.0, 18.0, or 19.0) — Enterprise unlocks the studio-grade POS restaurant features and advanced reporting we build against, while Community deployments get an equivalent back-office reporting layer. We then develop the module against your version, validate it on a staging copy of your database through UAT, and only promote to production with a rollback plan in hand. Typical delivery is 2-4 weeks from confirmed scope depending on how many branches, the depth of the menu-push logic, and any integrations. You receive the full source, documentation, a training session, and a post-go-live support window.

What you get

Installable module source code for your confirmed Odoo version (17.0, 18.0, or 19.0) and edition, with a clean `__manifest__.py` and dependency list

Installation and configuration on your environment (or handoff instructions for your DevOps), including branch, floor, and price-list setup

Technical documentation: data model, record rules, security groups, menu-push logic, and API endpoints

End-user guide plus a live training session for admins, branch managers, and cashiers

Post-go-live support window for bug fixes and questions after production launch

UAT on a staging copy of your database with a documented rollback plan before any production promotion

Git repository handover with full commit history so your team can maintain or extend the module

Menu-push and consolidated-report configuration tuned to your branches, price lists, and reporting cadence

Who this is for

Multi-location restaurant group owner

Runs 3+ outlets on one Odoo instance and needs consolidated daily sales and average-ticket figures across all locations without exporting each POS to a spreadsheet, plus confidence that each site's cash reconciles independently.

Franchise operations manager

Oversees franchised branches that may be separate companies. Needs to push a standardized menu and pricing to every branch centrally, allow local price overrides, and enforce that each franchisee only sees their own sessions, orders, and staff.

Branch / restaurant manager

Manages one location's floors, tables, cashiers, and shift close. Needs a POS scoped strictly to their branch and role-based limits on refunds, discounts, and price overrides so front-of-house staff can't act outside their permissions.

Odoo administrator / IT lead

Owns the Odoo deployment and wants a module built the native way — proper `ir.model.access.csv`, record rules, and OWL/XML views — that upgrades cleanly across 17/18/19 and exposes branch data over the standard XML-RPC/JSON-RPC API.

How POS Multi-Restaurant / Multi-Branch Manager Compares

Criterion	ECOSIRE	Custom Build	Competitor	Odoo Native
Multi-branch data model	First-class branch model linking POS, floors, price lists, and company	Whatever your developer designs, if scoped correctly	Often a thin config clone, no true branch entity	No branch concept; one shop per POS config
Per-branch isolation	Record rules on branch membership for sessions, orders, cash	Possible but must be built and tested from scratch	Usually relies on manual multi-company setup	Only via separate companies, which silos everything
Central menu push	Server action propagating menu and prices with local overrides	Buildable, but propagation and override logic is non-trivial	Rarely included; menus managed per branch	Manual product and price-list duplication
Consolidated reporting	Cross-branch dashboard plus QWeb PDF group reports	Depends on effort spent on aggregation and views	Typically per-shop reports only	Spreadsheet exports stitched by hand
Version and edition fit	Built to your exact 17/18/19 and Community/Enterprise	Tied to whoever built it and their assumptions	Pinned to the versions the vendor chose to support	Core behavior only, same across the board
Support and ownership	Post-go-live window, full source, and git repo handover	Depends entirely on the contractor's retainer	Vendor support queue, no source ownership	Community forums or a paid Odoo partner
Rollout safety	UAT on staging with a documented rollback plan	Only if the contractor insists on staging	Install-and-hope; limited pre-production validation	Not applicable — no custom code to validate

Frequently Asked Questions about POS Multi-Restaurant / Multi-Branch Manager

How long does delivery take?

This is a build-to-order module, so there is no instant download. After a scoping call to confirm your branch count, menu-push depth, Odoo version, and edition, typical delivery is 2-4 weeks from confirmed scope. Larger fleets or deep integrations may extend that, and we give you a firm timeline once scope is locked.

Which Odoo versions and editions do you support?

We build against Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. Enterprise unlocks the advanced POS restaurant and reporting features we build on top of; Community deployments receive an equivalent back-office reporting layer. We confirm your exact version and edition during scoping so the module targets your environment precisely.

How do updates and support work after go-live?

Every engagement includes a post-go-live support window for bug fixes and questions. Because you receive the full source and git repository, your team can maintain and extend the module. For future Odoo version upgrades or new features, we offer follow-on support and migration engagements.

Does this work with a single company or separate companies per branch?

Both. If your branches live in one Odoo company we scope them with a branch model and record rules for isolation and consolidated reporting. If franchisees are legally separate companies, we adapt the record rules and consolidation layer to your multi-company topology so central menu push and group reporting still work across company boundaries.

Can we push one master menu to all branches but keep local prices?

Yes. A central action propagates products, categories, and base prices to the branches you select, while per-branch price lists and availability overrides are preserved. You edit the master catalog once and choose which locations receive each update, and local pricing or menu toggles stay intact.

Can headquarters pull branch data into external BI or a portal?

Yes. The module exposes branch-scoped figures over Odoo's standard XML-RPC and JSON-RPC API, so HQ dashboards, BI tools, or a franchise portal can read consolidated or per-branch sales without touching the database directly. We document the available models and fields as part of handover.

Will this survive an Odoo version upgrade?

We build cleanly against your target version using standard ORM, security, and view patterns rather than fragile hacks, which keeps upgrades tractable. When you move to a newer Odoo version we can deliver a migration of the module as a follow-on engagement, tested on staging before production.