A build-to-order Odoo customer-portal extension that lets your customers select and pay several open invoices in a single bulk checkout. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0. 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
Auf Ihren Workflow zugeschnitten
A build-to-order Odoo customer-portal extension that lets your customers select and pay several open invoices in a single bulk checkout. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.
Keine Selbsteinrichtung — eine funktionierende App, die von ECOSIRE erstellt, installiert und betreut wird.
Starten Sie mit einem einmaligen Entwicklungspreis. Den Umfang legen wir beim Kickoff gemeinsam fest.
ECOSIRE erstellt, konfiguriert und installiert sie auf Ihrem Odoo.
Sie gehen in etwa 2–4 Wochen live, mit einem Support-Zeitraum nach dem Launch.
Every finance team running Odoo eventually hits the same friction: a customer with ten open invoices has to open the portal, click into each invoice separately, and run ten individual online payments. That means ten payment-provider transaction fees, ten account.payment records to reconcile, ten confirmation emails, and a frustrated customer who abandons half the payments midway. Out of the box the Odoo portal is built around the single-invoice view (/my/invoices/<id>) — the payment and account_payment flows key each transaction to one account.move, so there is no native "select several invoices and pay the combined balance at once" experience on the website. Teams work around it with manual bank transfers and spreadsheet chasing, which is exactly the reconciliation drag Odoo was supposed to eliminate.
This is what we build for you. Website Multi Invoice Payment is a portal extension that adds a bulk-selection layer over the customer's list of posted, unpaid account.move records. We inherit the portal account controller (PortalAccount / http.Controller) so the logged-in customer sees checkboxes plus a live "selected total" that we compute from amount_residual, scoped by move_type in ('out_invoice','out_refund') and payment_state in ('not_paid','partial') and filtered by the portal record rules so a partner only ever sees their own documents. A single "Pay selected" action assembles the chosen invoices into one payment intent and hands it to Odoo's standard payment engine, so the money moves through whichever acquirers you already have configured (payment.provider) with no bespoke gateway code. On success we generate the payment, post it, and let Odoo's reconciliation match it against each selected account.move — optionally splitting a single received amount across invoices oldest-first when a partial-allocation policy is requested.
Technically, the module ships as a proper addon: a __manifest__.py declaring dependencies on account, account_payment, payment, portal, and website; new/extended models with @api.depends compute fields for the running selection total and eligible-invoice domain; QWeb templates that extend the existing portal invoice list rather than replacing it (so your theme and any other portal customizations survive); and ir.model.access.csv plus record rules that keep the multi-select strictly inside the requesting partner's commercial entity. We wire the confirmation and receipt into the standard mail templates, expose the bulk-pay result over the JSON-RPC/XML-RPC layer for any headless or app integration you run, and cover both Community (manual/wire acquirers) and Enterprise (full electronic-payment acquirers, follow-up automation) so the feature behaves correctly on your edition. Everything is delivered against your pinned series — 17.0, 18.0, or 19.0 — with the controller and template inheritance adjusted for the API differences between them.
Because this is build-to-order, nothing is pre-listed for instant download: after a short scoping call we confirm the exact selection rules, allocation policy, and acquirer set, then build, test on a staging clone of your database, and install to production. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company deployments, additional payment acquirers or currencies, partial-allocation logic, and localization or e-invoice reconciliation requirements increase the quoted scope — you receive a fixed quote after the scoping call, never a surprise invoice.
Runs accounts receivable in Odoo and is tired of chasing customers who pay invoices one at a time or not at all. Needs bulk portal payment to lift collection rates and cut reconciliation labor.
Issues many recurring or project invoices to the same partners. Wants customers to clear several outstanding balances in one checkout instead of abandoning a tedious per-invoice flow.
Owns the internal Odoo instance and its portal theme. Needs a clean, inheritance-based addon that won't clash with existing customizations and ships with docs, security rules, and a rollback plan.
Manages a customer portal where clients self-serve. Wants a smoother 'pay everything I owe' experience to reduce support tickets and speed up cash collection.
| Kriterium | ECOSIRE | Benutzerdefinierter Build | Konkurrent | Odoo Native |
|---|---|---|---|---|
| Bulk-pay multiple invoices at once | Built as a first-class portal feature, tailored to your rules | Possible but you design and maintain it from scratch | May offer a generic multi-select with fixed behavior | |
| Fit to your workflow (allocation, currencies, acquirers) | Scoped to your exact policy and edition before build | Fully custom but dependent on in-house Odoo expertise | Fixed feature set; you adapt to its assumptions | |
| Theme and customization safety | QWeb inheritance, extends not replaces; verified in UAT | Depends entirely on developer discipline | Varies; some replace templates and cause clashes | |
| Odoo 17/18/19 and Community vs Enterprise | Version-pinned build for your exact series and edition | You port and test across versions yourself | Often lags new releases or targets one series | |
| Security and multi-company scoping | `ir.model.access.csv` + record rules per your entity model | You must design and audit access controls | Generic rules; may not match your company structure | |
| Delivery and installation | Built, tested on staging, installed with rollback plan | Your team plans, builds, and deploys it | Self-install; support depends on the vendor | |
| Support and ownership | Post-go-live support window + full git repo handover | Self-supported unless you retain a developer | Vendor-dependent support and license terms | |
| Total cost of ownership | Fixed quote from $249 indicative; predictable scope | Unpredictable dev + maintenance cost over time | Low sticker price but rigid; adaptation costs add up |
No. This is a build-to-order module. ECOSIRE scopes your exact requirements, then builds, tests on staging, and installs it. There is no instant download — you receive source code and a working install tailored to your Odoo series and acquirers.
Typical delivery is 2–4 weeks from confirmed scope. After the scoping call we lock the selection rules, allocation policy, and acquirer set, then build, run UAT on a staging clone of your database, and install to production. Complex multi-company or localization scopes can extend the timeline, which we state in the quote.
Pricing starts from $249 (indicative, single-company base scope). The exact figure depends on drivers like multi-company setup, extra payment acquirers or currencies, partial-allocation logic, and localization needs. You get a fixed, written quote after a short scoping call — never a surprise invoice.
Every build includes a post-go-live support window for defect fixes and configuration questions, plus a git repository handover so your team owns the code. We can also quote a longer maintenance arrangement or a version upgrade (for example moving the module from 18.0 to 19.0) as a separate scope.
Yes. The module reuses your configured `payment.provider` acquirers and hands the combined payment to Odoo's native `payment` engine, so it works with whatever gateways or manual/wire methods you already run. We don't build a bespoke gateway; we build the bulk-selection and reconciliation layer on top of the standard flow.
Both. On Community it works with manual and wire acquirers; on Enterprise it additionally covers the full electronic-payment acquirers and follow-up automation. We target your specific edition and series (17.0, 18.0, or 19.0) and adjust controller and template inheritance accordingly.
No. We extend the existing portal invoice templates via QWeb inheritance rather than replacing them, and add security via `ir.model.access.csv` and record rules. Existing website theme and portal customizations remain intact, and we verify this during UAT on your staging clone.
A build-to-order Odoo customer-portal extension that lets your customers select and pay several open invoices in a single bulk checkout. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.