Odoo Bidirectional Connector

Groups rarely run one ERP. They run the one corporate finance chose and the one a subsidiary already had, and the second one is very often Odoo. A manufacturing arm keeps Odoo because the shop floor knows it. An acquired distributor keeps Odoo because ripping it out was never in the deal. A regional office keeps Odoo because its local accountant will not work in anything else. Meanwhile corporate consolidates in Dynamics 365 Finance and Supply Chain Management, and somebody spends two days a month exporting spreadsheets to make the two agree.

The direction of travel is not always the same, either. Some organisations are moving data from Dynamics into Odoo at the subsidiary level. Others are pulling Odoo entities up into F&O. Plenty need both at once, permanently. A one-way import script cannot serve any of those cases for long, because the moment a user edits a customer address on the wrong side, the two systems begin to drift and nobody can say which record is right.

This connector is built to keep both systems correct at the same time, with a defined answer to the question of who wins.

What ECOSIRE builds

The connector is an X++ extension model deployed into your F&O environment through your normal LCS or self-service pipeline. There is no overlayering: integration logic sits in its own model using Chain of Command, event handlers, new tables and new forms. On the Odoo side, communication uses the documented external API over XML-RPC or JSON-RPC with a dedicated integration user, so no modification to your Odoo installation is required beyond permissions and, where you want push-style events, a small outbound configuration.

Entity and legal entity mapping

Before any record moves, the connector needs to know how your two structures line up. A mapping form pairs each F&O legal entity with an Odoo company, and each Odoo journal, warehouse, product category and tax with its F&O counterpart. This is configuration held in F&O tables, exportable as a Data management framework package so the same mapping promotes from sandbox to production without being retyped.

Two-way master data synchronisation

Customers, vendors, contacts, products and product variants sync in the direction you configure per entity type, or in both directions with a defined field-level ownership model. That ownership model is the important part: for each field you declare which system is authoritative. Corporate might own credit limit and payment terms in F&O while the subsidiary owns delivery address and contact phone in Odoo. Records carry a stable cross-reference so a record created on either side is never duplicated on the other.

Transaction synchronisation

Sales orders, purchase orders, customer invoices, vendor bills, payments and inventory movements flow according to the scope you agree. On the F&O side the connector writes through data entities and standard posting logic — SalesTable and SalesLine for orders, CustInvoiceJour for issued invoices, LedgerJournalTable and LedgerJournalTrans where a journal posting is the right shape — so number sequences, posting profiles and ledger dimensions behave exactly as they would for a manual entry. Inventory movement sync respects item model groups and dimension groups rather than forcing quantities into on-hand tables.

Change detection and conflict handling

Outbound changes from F&O are detected through business events and change-tracked data entities, so the connector reacts to a real modification rather than polling every record every hour. Inbound changes from Odoo are pulled on a watermark using write date, with an idempotency key so a repeated delivery cannot create a duplicate. When both sides changed the same field since the last successful sync, the connector applies your configured rule — authoritative side wins, latest write wins, or hold for human decision — and every held conflict lands in a review queue with both values side by side.

Batch execution and operational visibility

All sync jobs run under the batch framework as SysOperation services, with configurable recurrence per entity type so high-volume order sync can run every few minutes while the chart of accounts syncs nightly. A message log form records every payload, its direction, its correlation identifier, its outcome and the number of attempts. Failures retry with backoff and then park in a dead-letter list that an administrator can inspect, correct and replay without touching the database. Where you want the operational surface in Power Platform instead, the connector can raise business events that a Power Automate flow consumes for alerting.

Multi-currency, tax and dimension handling

Currency conversion uses F&O exchange rate types rather than a hard-coded rate. Tax mapping translates Odoo tax records to F&O tax groups and item tax groups so posted tax lands where your finance team expects it. Financial dimension defaulting is configurable per entity mapping, which is usually what makes the difference between a consolidation that reports correctly and one that needs a month-end reclassification journal.

Who it is for

This suits groups running F&O at corporate with one or more Odoo installations at subsidiaries, organisations partway through a phased consolidation where both systems must stay live for a year or more, and businesses that use Odoo for a specific function — manufacturing, field service, point of sale — while finance and supply chain sit in F&O. It also serves the reverse case, where a group standardising on Odoo needs an ongoing feed out of an existing Dynamics installation during and after the transition.

It is not a migration tool. If your goal is to move off one platform entirely and switch it off, a one-time conversion is the right shape and we build that separately.

How delivery works

Scoping call. We map your entity structure, list the object types that must sync and in which direction, agree field-level ownership for the contested ones, and establish your Odoo version, hosting and API access. We ask which system finance treats as the book of record.

Fixed quote. You receive a written scope naming every synchronised object, the direction, the conflict rule and the sync frequency, with a fixed price and a delivery window. We do not start until you accept.

Build. ECOSIRE develops the model against your F&O platform and application version, with an Odoo instance matching your version for integration testing. Code is committed to an Azure DevOps repository.

Install in test. We deliver a deployable package to your sandbox, install it, configure the mappings with your team, and run a controlled two-way test using your real data shapes — including deliberate conflict cases so you can see the rules behave as agreed.

Production. After sign-off the package promotes through your pipeline to production. We supervise the first live sync cycles and the initial backfill.

Support window. A defect-fix window follows go-live, covering the delivered scope against the F&O and Odoo versions it was built for.

Lead time is typically two to four weeks from accepted quote to installation in your test environment, depending on how many object types and directions are in scope.

Honest limits

Nothing here is pre-built. There is no download, no trial version, no shelf copy — the connector is written for your entity mapping, your field ownership rules and your Odoo version, and it does not exist until we build it. Two-way sync also has a hard requirement we will not work around: for every field, somebody has to decide who owns it. If that decision is deferred, the connector will hold conflicts for review rather than guess, and the review queue will grow. We will push for those decisions during scoping because they determine whether the integration is trusted six months later.