This is a build-to-order module, not an instant apps.odoo.com download. Typical lead time is one working week from confirmed requirements: we scope your currencies, rates, denominations, and reconciliation rules, build against your Odoo 17/18/19 version, test on a staging copy of your database, then install and train your team. Simple single-branch setups land at the shorter end; multi-branch or heavy accounting integration at the longer end. You get a firm timeline in writing before we start.

Every build includes a post-launch support window for bug fixes and reasonable workflow adjustments (rates, rounding, denominations, report tweaks). Because you own the source in a versioned repository, there is no per-seat licence lock-in. When you later upgrade your Odoo version, or want new capabilities, we quote the migration or enhancement as a scoped piece of work — the module is written to Odoo's standard ORM, security, and OWL patterns specifically so it stays maintainable across 17, 18, and 19.

Both. The module builds on standard POS, res.currency, and accounting concepts present in Community, and we test the same code against Enterprise. Tell us your edition and exact version (17, 18, or 19) and we build and validate against it. If you use ECOSIRE-managed hosting or Odoo.sh, we handle deployment there too.

You control them. Counter rates are managed separately from Odoo's daily bank-feed currency rates, because retail counters usually apply a fixed posted rate through the day rather than a fluctuating market rate. Authorised staff set and update rates in the back office, protected by record rules. If you prefer, we can add a scheduled automated action to refresh rates from a source you nominate, with manual override always available.

Each tender is converted to your base currency at its applied rate, the order total is settled from those converted amounts, and any change due is calculated and handed back in your base currency — shown clearly on screen and on the QWeb receipt. The customer sees what they paid in their currency and what they received as change in yours, with the rate printed, so there is no ambiguity at the counter.

Yes — that's a core reason to build this properly rather than let cashiers improvise. Each foreign tender is stored on the pos.payment / pos.order with its currency and rate, session closing counts are captured per currency against expected denomination totals, and journal entries post with the correct currency so your P&L reflects real FX. The reconciliation report rolls every currency into a single base-currency variance so you can see at a glance whether a drawer balanced.