A made-to-order Odoo module that automatically applies a discount when a customer pays with a nominated method — cash, bank transfer, wallet or card — across Sales, POS and invoicing. ECOSIRE scopes, builds, installs and supports it on 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.
App-Manifest
Auf Ihren Workflow zugeschnitten
A made-to-order Odoo module that automatically applies a discount when a customer pays with a nominated method — cash, bank transfer, wallet or card — across Sales, POS and invoicing. ECOSIRE scopes, builds, installs and supports it on your database.
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.
Many finance teams want to steer customers toward cheaper-to-process payment methods — offering a small cash or bank-transfer discount to dodge card interchange fees, or a wallet-specific promotion to hit a partner target. Out of the box, Odoo has no concept of a discount conditioned on how the customer pays. Discounts live on pricelists, coupon programs or manual sale-order lines, all of which are decided long before the payment step. The result is manual line edits, spreadsheets of "if they pay cash, knock off 2%," and reconciliation headaches when the recorded discount and the actual tender disagree. Native account.payment and pos.payment carry no pricing logic, and pricelist rules key off product, quantity and partner — never payment.method.line or pos.payment.method.
We build a dedicated module that closes this gap. At its core is a configurable payment.method.discount model (models.Model) that maps each payment method — a Sales/Accounting account.payment.method.line or a pos.payment.method — to a discount rule: fixed amount or percentage, optional minimum order value, product/category eligibility, active date window and per-company scope. Fields are computed with @api.depends so the eligible discount recalculates whenever the payment selection, order amount or partner changes, and @api.constrains guards against nonsensical setups (negative percentages, overlapping windows, discounts exceeding the order total). Access is locked down with ir.model.access.csv plus record rules that respect company_id for multi-company databases, so a subsidiary's payment-discount table never leaks into another company.
On the Point of Sale side, the discount is evaluated the moment a payment line is added: an OWL PaymentScreen extension recalculates the order total live so the cashier and customer both see the corrected figure before tender, and the applied rule is written back as a distinct discount line (never a silent price edit) for a clean audit trail. In Sales and Accounting, the module hooks payment registration and the confirmation flow so that selecting a bank-transfer or cash method proposes the mapped discount, records it against the invoice or sale order, and keeps the journal entry balanced. Everything surfaces in a QWeb report and a filterable list/pivot view so finance can see exactly how much margin each method costs, and an optional automated action can flag orders where the tendered method did not match the discount that was granted.
Because this is built to order, we start from your real payment-method configuration and workflow rather than a generic template. After a short scoping call we confirm the exact rule matrix, POS-versus-back-office behavior, rounding and tax treatment, then build against your target release — we support Odoo 17.0, 18.0 and 19.0, and account for Community-versus-Enterprise differences (Enterprise ships extra POS payment terminals and accounting flows the rules must respect). Typical delivery is 2–4 weeks from confirmed scope, on a staging database first. Pricing starts from $249 (indicative, single-company base scope); multi-company rule tables, POS-terminal integrations, complex tax/rounding localization, and migration of historical discount data increase the quoted scope. You get a fixed quote after the scoping call — no surprise line items.
Wants to cut card-processing fees by nudging customers to cash or bank transfer, and needs every granted discount recorded cleanly against the invoice so margin reporting and reconciliation stay accurate.
Runs one or more Point of Sale outlets and needs the payment-method discount to appear live on the cashier screen before tender, with a clear audit line rather than manual price overrides.
Maintains the database and wants a properly-scoped, access-controlled module they can configure from Settings, that respects multi-company boundaries and survives version upgrades.
Sells through POS and online and needs eligible payment-method discounts exposed over the XML-RPC/JSON-RPC API so the storefront and back office show consistent pricing.
| Kriterium | ECOSIRE | Benutzerdefinierter Build | Konkurrent | Odoo Native |
|---|---|---|---|---|
| Discount tied to payment method | Native concept — rules map each method to its own discount | Achievable but you design and build the model yourself | Sometimes offered, but fixed to the vendor's assumptions | |
| Live POS recalculation | OWL PaymentScreen extension updates total on tender selection | Requires bespoke POS JS/OWL work to get right | Varies; may only apply in back office, not live at POS | |
| Fit to your workflow | Built from your real payment matrix and rounding/tax rules | Fully bespoke, but full cost and risk on you | Generic; you adapt your process to the module | |
| Multi-company scoping | Per-`company_id` rules with record rules and ACLs | Only if you build and test it | Inconsistent; often single-company assumptions | |
| Audit trail | Discount posted as a distinct line, not a silent price edit | Depends on your implementation discipline | Varies by vendor | |
| Odoo version support | 17.0 / 18.0 / 19.0, Community and Enterprise, per branch | Whatever you build and maintain | Often lags new major releases | |
| Support & ownership | Post-go-live window plus full git repo handover | You own all maintenance | Vendor-dependent; source often obfuscated | |
| Time to value | 2–4 weeks from confirmed scope on staging first | Longer — design, build, test from scratch | Fast to install but slow to fit reality |
No. This is a build-to-order module. ECOSIRE scopes, builds, installs and supports it specifically for your database and workflow — it is a productized service, not an off-the-shelf download. You request a quotation and we build your version.
Typical delivery is 2–4 weeks from confirmed scope. After the scoping call we build against your target Odoo release, deliver to a staging database for UAT, then move to production. Larger rule matrices, POS-terminal integrations or data migration can extend that timeline, which we confirm before you commit.
Pricing starts from $249 as an indicative single-company base scope. The exact figure depends on your rule complexity, multi-company needs, tax/rounding localization and any historical-data migration. You get a fixed written quote after a short scoping call — no open-ended hourly billing.
We support Odoo 17.0, 18.0 and 19.0, on both Community and Enterprise. Enterprise ships additional POS payment terminals and accounting flows; we account for those differences and build the rules to respect whichever edition you run.
Every build includes a post-go-live support window for defect fixes and configuration questions. Beyond that we offer optional support and version-upgrade retainers, and you receive the full git repository so any Odoo partner can maintain it. Upgrades to a newer Odoo major version are scoped separately.
Yes. In POS the discount recalculates live via an OWL screen extension the moment a payment line is added. In Sales and Accounting it is proposed and recorded at payment registration and kept consistent with the journal entry. You choose which channels are in scope.
Yes. The rule model is scoped by `company_id` with record rules, and access is controlled through `ir.model.access.csv`, so each company's payment-discount table and the users who can edit it stay isolated.
A made-to-order Odoo module that automatically applies a discount when a customer pays with a nominated method — cash, bank transfer, wallet or card — across Sales, POS and invoicing. ECOSIRE scopes, builds, installs and supports it on your database.