Finance teams that run multiple points of sale in Odoo hit the same wall the moment they try to report profitability per shop, per till, or per sales channel. Out of the box, POS order lines and their journal entries inherit analytic distribution from the product or the income account default — not from the POS terminal that actually rang the sale. That means a downtown shop and an airport kiosk selling the same SKU land on the same analytic account, and your account.analytic.line records can no longer tell you which location earned the margin. The usual workaround — manual analytic re-tagging after each session close, or per-product analytic rules that ignore where the sale happened — is slow, error-prone, and collapses under real transaction volume.

POS Analytic Config closes that gap by making the analytic account a first-class property of the POS configuration itself. We extend pos.config (and, where your version requires it, pos.session) with an analytic account / analytic distribution field, then hook the order-to-accounting bridge so that when a session is posted, every generated account.move.line and the resulting account.analytic.line carry the analytic account defined on the originating terminal. The implementation is a clean inheriting module: a small models.Model extension with the new analytic_account_id (or analytic_distribution) field, a compute/@api.depends override or a targeted super-call on the POS accounting-entry preparation method (_prepare_line, _create_account_move / _prepare_invoice_line, depending on 17.0/18.0/19.0), plus XML views that surface the field on the POS configuration form under Accounting. Security is wired through ir.model.access.csv and, where multi-company isolation matters, record rules so a company only sees and sets its own terminals' analytic accounts. Nothing in the payment or receipt flow is touched — the cashier experience is unchanged; the intelligence lives entirely in the backend posting logic.

Because this is version-sensitive core-accounting territory, we build against your exact Odoo edition and release. The analytic model changed materially across recent versions (single analytic_account_id gave way to JSON analytic_distribution on move lines), and Community vs Enterprise differ in how POS sessions post to accounting, so we pin the __manifest__.py dependencies and the override strategy to what your database actually runs (17.0, 18.0, or 19.0). We validate the posting on staging with real session data, confirm the analytic lines reconcile against your existing analytic plans, and hand over automated tests where the accounting hooks warrant them. Optional extensions we frequently scope in the same engagement include fallback logic (config account first, then product default), analytic distribution splits across plans, and exposing the terminal's analytic account through the XML-RPC/JSON-RPC API for downstream BI.

This is a made-to-order engagement, not an off-the-shelf download. After a short scoping call we confirm your version, edition, chart-of-analytic setup, and any multi-company rules, then quote a fixed price and build it. Typical delivery is 2 to 4 weeks from confirmed scope, and you receive the installable source, documentation, UAT on staging, and a post-go-live support window. Pricing starts from $249 (indicative, single-company base scope); multi-company analytic isolation, analytic distribution splits across multiple plans, and migration of historical POS entries to the new analytic mapping increase the quoted scope.