A build-to-order Odoo module that lets finance teams manually set the currency exchange rate directly on individual sales orders, purchase orders, and invoices — overriding the daily company rate per document when the deal was struck at a negotiated or contractual rate. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 database. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $299.00 USD; request a quote for a scoped proposal.
アプリマニフェスト
あなたのワークフローに合わせて構築
A build-to-order Odoo module that lets finance teams manually set the currency exchange rate directly on individual sales orders, purchase orders, and invoices — overriding the daily company rate per document when the deal was struck at a negotiated or contractual rate. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 database.
自分での設定は不要 — ECOSIRE が構築・インストール・サポートする実働アプリです。
一回限りの構築料金から始めます。キックオフで一緒に範囲を決めます。
ECOSIRE がお客様の Odoo 上で構築・設定・インストールします。
約2〜4週間で稼働し、リリース後のサポート期間が付きます。
Odoo applies a single company-wide exchange rate per currency per date, resolved automatically from res.currency.rate when a foreign-currency document is confirmed. That works until reality diverges from the rate table: a customer was quoted at a fixed contractual rate weeks ago, a purchase was hedged at a rate your bank locked in, or a payment cleared at a rate that differs from the day's official figure. In stock Odoo the finance user has no clean way to say "this specific invoice should convert at 3.75, not today's 3.71" — they end up editing the global rate (which corrupts every other document dated that day), booking manual exchange-difference journal entries, or reconciling the variance after the fact. Every one of those workarounds is error-prone and audit-unfriendly.
We build a focused module that adds a per-document manual_currency_rate field (with a manual_rate_active boolean toggle) to sale.order, purchase.order, and account.move. When the toggle is on, the document's currency conversion uses your entered rate instead of the company rate pulled from res.currency.rate. Technically this means extending the relevant models via models.Model inheritance, overriding the _compute_amount/_compute_tax_totals and currency_rate computations (with correct @api.depends so amounts recompute the moment the rate or currency changes), and propagating the chosen rate through the sale-to-invoice and purchase-to-bill flows so the manually set rate carries onto the generated account.move. The company amount (amount_total_signed, amount_currency vs balance on account.move.line) is derived from your rate, so the general ledger, tax lines, and currency-exchange postings all reflect the number you actually transacted at — not the table default.
The implementation ships with proper access control and an audit trail. Editing the manual rate is gated through ir.model.access.csv and record rules so only the groups you nominate (typically Accounting / Billing Administrator) can override a rate, and every override is visible on the document and captured in the chatter/mail.thread log for auditors. Views are extended cleanly via XML inheritance (xpath into the existing order and invoice forms) so the field appears next to the currency with an on-screen indicator when a manual rate is in effect, and QWeb report templates are optionally adjusted so the applied rate prints on the PDF invoice or order confirmation. The manually set rate is also exposed through the standard XML-RPC/JSON-RPC API, so external systems that create or read these documents can set and audit the rate programmatically. We target Odoo 17.0, 18.0, and 19.0 and account for Community vs Enterprise differences in the accounting layer where they matter.
Because this is a productized service, nothing is downloaded and switched on instantly. After a short scoping call we confirm exactly which documents need the override, which user groups may set it, how it should behave on the sale/purchase-to-invoice handoff, and whether reports and API access are in scope. We then build against a copy of your Odoo version, deliver on a staging database for your UAT, and go live with a rollback plan. Typical delivery is 2-4 weeks from confirmed scope. Pricing starts from $299 (indicative, single-company base scope); multi-company setups, deeper accounting/localization requirements (e.g. specific exchange-difference posting rules), extra documents, and integration or data-migration work increase the quoted scope.
Runs multi-currency AR/AP in Odoo and needs invoices and bills to book at the rate actually agreed or paid, not the daily table rate — without corrupting the global `res.currency.rate` or piling up manual journal corrections.
Owns the Odoo instance and wants a clean, upgrade-safe module (proper model inheritance, access rules, XML view extensions) rather than a fragile in-house patch, plus a git handover they can maintain.
Quotes customers and buys from suppliers at negotiated or contractual FX rates that differ from the market rate, and needs each order and invoice to carry its own locked rate through to the ledger.
Pushes and pulls sales, purchase, and invoice data via XML-RPC/JSON-RPC and needs the manual rate to be a first-class, auditable field they can set and read programmatically.
| 基準 | エコシエール | カスタムビルド | 競合他社 | オドゥー ネイティブ |
|---|---|---|---|---|
| Delivery model | Build-to-order for your exact version; installed and supported by us | Bespoke in-house build from scratch | Instant download, generic implementation | |
| Per-document rate override | Toggle + rate field on SO, PO, and invoice, scoped to your flows | Whatever you have time to build and test | Usually a fixed set of documents, take it or leave it | |
| Global rate safety | Override is isolated per document; `res.currency.rate` untouched | Depends on the developer's care | Varies; often does isolate correctly | |
| Ledger accuracy | Rate drives `account.move.line` balances, tax, and FX postings | Must be engineered and verified by you | Typically covers invoices; edge cases uncertain | |
| Access control & audit | Group-gated via record rules + chatter log of every change | As designed, if you prioritize it | Often minimal or absent | |
| Upgrade safety | Clean model + XML `xpath` inheritance, git handover | Only as clean as the in-house code | You depend on the vendor's upgrade cadence | |
| Support & source | Support window + full git repo handover | You own and staff all maintenance | Vendor support terms, source may be obfuscated | |
| Total cost profile | From $299 indicative; fixed quote after scoping | High developer time and QA cost | Low sticker price, poor fit risk |
This is a build-to-order module, not an instant download. Typical delivery is 2-4 weeks from the moment scope is confirmed on our scoping call. Simple single-company scope lands toward the shorter end; multi-company, extra documents, report changes, or integration work extends it. We agree the timeline in writing before starting.
Pricing starts from $299 as an indicative figure for a single-company base scope. After a short scoping call we confirm exactly which documents, user groups, report changes, and integrations are in scope, then send a fixed written quote. The from-price is a starting point, not a firm quote — the fixed number is set once scope is agreed.
Every build includes a defined post-go-live support window for fixes and questions. Because we hand over the git repository, you can maintain it yourself afterwards, or we can carry it forward under a support arrangement. When you upgrade Odoo (e.g. 18 to 19), we can quote a compatibility pass — the module is written with clean inheritance to make that straightforward.
No. The override is strictly per-document and only takes effect when the manual-rate toggle is switched on. The shared `res.currency.rate` table and every other document that relies on it are left completely untouched. That is the entire point of the module versus the workaround of editing the global rate.
Yes. The rate you set drives the company-currency amounts on the invoice or bill, so `account.move.line` balances, tax lines, and any exchange-difference postings reflect the rate you actually transacted at. It also carries from a sales order or purchase order onto the generated invoice or vendor bill.
We build for Odoo 17.0, 18.0, and 19.0, on either Community or Enterprise. We account for the accounting-layer differences between editions during scoping and target the exact version and edition your database runs.
Yes. The manual rate is a standard model field, so it is readable and writable over Odoo's XML-RPC/JSON-RPC API. Integrations that create sales orders, purchase orders, or invoices can set the rate programmatically, and audits can read the applied rate back out.
A build-to-order Odoo module that lets finance teams manually set the currency exchange rate directly on individual sales orders, purchase orders, and invoices — overriding the daily company rate per document when the deal was struck at a negotiated or contractual rate. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 database.