A made-to-order Odoo module that surfaces live payment status, paid/due amounts, and linked transactions directly on the sale order — no digging through the accounting back office. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
App manifest
Built around your workflow
A made-to-order Odoo module that surfaces live payment status, paid/due amounts, and linked transactions directly on the sale order — no digging through the accounting back office. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your Odoo.
You go live in about 2–4 weeks, with a post-launch support window.
Sales reps and order-desk teams lose time every day answering one question: "has this order actually been paid?" In native Odoo the answer lives one or two clicks away — you open the sale order, jump to the related invoice, then to the payments, and reconcile in your head across down payments, partial settlements, and credit notes. The sale.order form exposes an invoice_status field ("to invoice", "invoiced", "nothing to invoice"), but that describes invoicing progress, not money received. There is no core field on the order that tells you at a glance that a customer paid 60% up front and still owes the balance. That gap is where goods get released against unpaid orders and where finance and sales end up maintaining two different versions of the truth.
We build a made-to-order module that pulls the payment picture back onto the sale order where the people who need it actually work. Technically it adds computed, stored fields to sale.order — for example payment_state (a Selection mirroring the standard not_paid / partial / in_payment / paid / reversed values), amount_paid, amount_residual (due), and a payment_percentage — driven by @api.depends compute methods that walk the order's invoice_ids, their own payment_state, and the reconciled account.payment / account.move.line records. Because the fields are stored, they are filterable and groupable in list views, usable in search domains, and available to reports and the XML-RPC/JSON-RPC API. Recomputation is triggered cleanly off invoice and payment changes so the status stays accurate without a manual refresh.
On the UI side we extend the sale order form (XML view inheritance, or an OWL widget where a richer visual is wanted) to show a colour-coded status badge in the header, a paid-versus-due summary, and an embedded list of the linked payments with date, journal, method, and amount. The order list view gets an optional payment_state column and a set of filters ("Fully Paid", "Partially Paid", "Unpaid") plus a group-by so a rep can slice their pipeline by cash position in one click. Access is governed by ir.model.access.csv and, where you need reps to see only their own teams' figures, record rules — so the payment data respects the same visibility model as the rest of your Odoo. Optional add-ons we scope on request include a QWeb payment-status stamp on the order/quotation PDF, an automated action or server action that flags orders unpaid past a threshold, and a colour decoration on the kanban card.
Because this is built to order, nothing ships until we agree the scope. After a short scoping call we confirm exactly which fields, filters, views, and any automation or reporting you need, then hand back an installable module targeting your specific Odoo edition and version (Community or Enterprise, 17.0 / 18.0 / 19.0), tested on a staging copy of your database before it touches production. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company payment consolidation, deeper multi-currency handling, extra automation or reporting, and integration with non-standard payment/reconciliation flows increase the quoted scope.
Needs to see cash position across the pipeline without asking finance. Wants list filters and a group-by on payment state so the team can prioritise fulfilment and follow-ups by who has actually paid.
Owns the payment truth and wants sales looking at the same numbers. Values that the fields compute from real reconciled `account.payment` records rather than a manually maintained flag, keeping AR and sales aligned.
Responsible for the instance and its upgrades. Wants a clean, version-pinned module with documented fields, proper `ir.model.access.csv` security, and a git handover — not a black-box customisation that breaks on the next migration.
Releases goods and schedules delivery. Needs an unambiguous unpaid/partially-paid signal on the order itself to avoid shipping against orders that are not yet settled.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Fit to your workflow | Built to your confirmed scope, fields and filters match how your team works | Fully bespoke but you specify and manage everything | Generic feature set, take it as shipped | |
| Payment status on the sale order | Stored `payment_state` + paid/due badge directly on the order | Possible, depends on your developer's design | Usually a basic status field | |
| Accuracy source | Computes from reconciled `account.payment` / move lines via `@api.depends` | However it is coded and maintained | Often a lighter compute, varies by vendor | |
| Version & edition targeting | Pinned and tested for your 17/18/19, Community or Enterprise | Whatever you build for | Depends on the listing's supported versions | |
| Security model | `ir.model.access.csv` + optional record rules for team-scoped visibility | Only if you build it in | Baseline access rules, rarely team-scoped | |
| Delivery time | 2–4 weeks from confirmed scope | Weeks to months depending on hiring and specs | Instant install, but generic | |
| Support & handover | Support window, docs, training, full git repo handover | Depends on your team's retention | Vendor support tickets, no source ownership | |
| Cost model | Indicative from $249, fixed quote after scoping | Developer time, often the most expensive | Low per-listing licence fee |
No. This is a build-to-order productized service. We build the module to your confirmed scope and target it precisely to your Odoo edition and version, then install and support it. There is no instant download — the value is that it fits your data model, security rules, and workflow rather than being a generic drop-in.
Typical delivery is 2–4 weeks from confirmed scope. After the scoping call we agree the fields, views, filters, and any automation or reporting, then build and test on a staging copy of your database before go-live. Tight, single-company base scopes land at the shorter end; multi-company or heavier automation extends it.
Pricing starts from $249 as an indicative from-price for a single-company base scope. We confirm requirements on a short scoping call and then send a fixed written quote — no surprises. Drivers such as multi-company consolidation, deeper multi-currency handling, extra automation, custom reporting, or unusual payment/reconciliation flows increase the quoted scope.
We build for Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. The module is pinned to your specific version in its `__manifest__.py` and tested against that target. If you run a customised or hosted instance (Odoo.sh, on-prem, or a partner host), we account for that during scoping.
Every engagement includes a defined post-go-live support window for fixes and questions. Because you receive the full git repository and technical docs, your own team can maintain it too. When you upgrade Odoo to a new major version, we can quote a migration pass to re-target and re-test the module against the new release.
Yes. The status fields are computed with `@api.depends` off the order's invoices and their reconciled payments, and recomputation is triggered when those records change — so a partial payment, a new down payment, or a credit note updates the sale order's paid/due figures without any manual refresh.
Both are optional add-ons we scope on request. We can extend the QWeb quotation/order report to stamp payment status and paid/due totals, and add an automated action or server action to flag or notify on orders left unpaid past a threshold you define. These affect the quoted scope but are common requests.
A made-to-order Odoo module that surfaces live payment status, paid/due amounts, and linked transactions directly on the sale order — no digging through the accounting back office. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19.