A build-to-order Odoo module that forces every POS order to post against the analytic account defined on its POS configuration, so shop, till, and channel-level analytic reporting reconciles automatically. ECOSIRE scopes, builds, installs, and supports it for your database. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
Manifesto do app
Feito em torno do seu fluxo de trabalho
A build-to-order Odoo module that forces every POS order to post against the analytic account defined on its POS configuration, so shop, till, and channel-level analytic reporting reconciles automatically. ECOSIRE scopes, builds, installs, and supports it for your database.
Sem configuração por conta própria — um app funcional criado, instalado e com suporte da ECOSIRE.
Comece com um preço único de desenvolvimento. Definimos o escopo com você no início.
A ECOSIRE cria, configura e instala no seu Odoo.
Você entra no ar em cerca de 2–4 semanas, com um período de suporte pós-lançamento.
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.
Runs several shops or kiosks on Odoo POS and needs profitability and cost reporting per location. Requires every POS journal entry to land on the right analytic account automatically instead of being re-tagged by hand after each session.
Owns the internal Odoo instance and wants a clean, upgrade-safe inheriting module rather than patched core files. Needs it pinned to their release, documented, and handed over as a git repo they can maintain.
Manages POS terminals across legal entities and needs analytic isolation so each company's terminals map only to its own analytic accounts, with record rules enforcing the boundary.
Consumes analytic lines in dashboards and reporting tools and needs POS revenue and cost reliably attributed to the terminal that generated it, accessible via the ORM and JSON-RPC/XML-RPC API.
| Critério | ECOSIRE | Construção personalizada | Concorrente | Odoo nativo |
|---|---|---|---|---|
| Analytic source | POS config account applied automatically at posting | Whatever you build; design burden on you | Fixed behavior, may map by product not terminal | |
| Version fit | Built and pinned to your 17/18/19 + edition | Depends on your team's version knowledge | Generic build; version handling varies | |
| Multi-company isolation | Record rules scoped in the quote | You implement and test the rules | Rarely included out of the box | |
| Upgrade safety | Clean inheriting module, no core edits | Quality depends on developer discipline | Varies; may override broadly | |
| Support model | Post-go-live window + git handover | In-house only | Vendor ticket queue, no source ownership | |
| Testing | UAT on staging + automated hook tests | Whatever you schedule | Depends on vendor QA | |
| Fit to your data | Scoped to your analytic plans and flows | Fully bespoke if you have the time | One-size-fits-all assumptions | |
| Time to value | 2-4 weeks, fixed quote after scoping | Unbounded — hiring/dev cycle | Instant install but integration risk |
No. This is a build-to-order module. ECOSIRE builds it against your exact Odoo version and edition, installs it, and supports it. You are commissioning a productized development engagement, not buying an instant download.
Typical delivery is 2 to 4 weeks from confirmed scope. After the scoping call we agree on version, edition, and any multi-company or fallback requirements, then build, test on staging, and deploy. Complex multi-plan analytic distribution or historical data migration can extend the timeline, which we state up front in the quote.
Pricing starts from $249 as an indicative, single-company base-scope figure. It is not a fixed price — after a short scoping call we confirm requirements and send a fixed quote. Drivers such as multi-company analytic isolation, distribution splits across multiple analytic plans, and migrating historical POS entries increase the quoted scope.
We support Odoo 17.0, 18.0, and 19.0, in both Community and Enterprise. This matters here because the analytic model changed across versions (single `analytic_account_id` versus JSON `analytic_distribution`) and POS-to-accounting posting differs between editions, so we pin the implementation to what your database actually runs.
Every engagement includes a post-go-live support window for defect fixes and configuration help. Because you receive the full git repository and source, your own team can maintain it. Version upgrades (for example moving the module to a newer Odoo release) can be quoted separately as a maintenance engagement.
No. The module operates entirely in the backend accounting-posting logic. Payments, receipts, and session close behave exactly as before — the only difference is that posted journal and analytic lines now carry the analytic account defined on the POS configuration.
Yes. We hook the session-close journal entries for non-invoiced orders and the per-order invoice lines for invoiced orders, so the terminal's analytic account is applied consistently across both paths. We confirm both flows during UAT on staging.
A build-to-order Odoo module that forces every POS order to post against the analytic account defined on its POS configuration, so shop, till, and channel-level analytic reporting reconciles automatically. ECOSIRE scopes, builds, installs, and supports it for your database.