Finance teams that run a busy point of sale hit the same wall every close: POS sessions post thousands of order lines to the accounting journals, but Odoo core has no clean way to stamp an analytic account or cost center onto those postings. Out of the box, pos.order and pos.order.line carry no analytic dimension, and the session-close journal entries that Odoo generates from pos.session inherit whatever the income/expense accounts default to — which is usually nothing analytic at all. The result is that shop-floor, branch, department, or campaign profitability has to be rebuilt by hand in spreadsheets, and your account.analytic.line reporting has a blind spot exactly where a large share of transaction volume flows.

We build a module that closes that gap end to end. On the data side we extend pos.config, pos.order, and pos.order.line with analytic fields (typically an analytic_account_id Many2one to account.analytic.account, and for Odoo 17+ optional support for the analytic_distribution JSON widget so a single line can split across multiple plans/cost centers). Defaults cascade the way a controller expects: a cost center configured on the POS config or the salesperson/point-of-sale flows down to the order, and can be overridden per order or per line. The heavy lifting happens where the accounting is actually created — we override the session-close move generation (_create_account_move / the _prepare_...move_line helpers on pos.session, exact hook names vary by 17.0/18.0/19.0) so that every generated account.move.line carries the resolved analytic distribution. Because Odoo posts the analytic entries from the move lines, your account.analytic.line records and Analytic Accounting reports populate automatically, with no manual re-tagging at month end.

The module is engineered to survive your real environment, not a demo. Analytic resolution is centralized in a compute/helper method with @api.depends so it stays correct when orders are edited, refunded, or split; refunds and returns propagate the same analytic account as the original line so credits net cleanly. We respect Community vs Enterprise differences (Enterprise's analytic plans/distribution UX vs Community's simpler analytic account model) and gate the behavior accordingly. Access is governed through ir.model.access.csv plus record rules where multi-company scoping matters, new fields are surfaced in the backend pos.order form and list views (XML/OWL) and on the relevant QWeb accounting reports, and — where you need it — we can push the selector into the POS front-end screen itself so cashiers or supervisors pick a cost center at the register. Everything is exposed over the standard XML-RPC/JSON-RPC API so external BI or consolidation tools can read the analytic dimension programmatically.

Delivery is build-to-order: you request a quotation, we run a short scoping call to pin down your Odoo version, edition, chart-of-accounts and analytic-plan structure, and whether you need front-end capture or back-office only. We then build against a staging copy of your database, run UAT with you, and deploy with a rollback plan. Typical delivery is one working week from confirmed scope. This is not an existing download you install yourself — it is a made-to-order module we develop, install, and support for your specific configuration.

Pricing starts from $999 (indicative, single-company base scope); multi-company deployments, front-end POS capture, multi-plan analytic_distribution splits, and historical data migration of past POS sessions increase the quoted scope. You receive a fixed quote after the scoping call.