Connect Duro PLM to Odoo with AI
Duro plus Odoo is the scrappy hardware stack: real PLM for engineering, an open-source ERP/MRP for everything else. Its structural weakness is the double BOM. Duro holds the engineering BOM — the design truth. Odoo needs its own manufacturing BOM to drive manufacturing orders and procurement. Two BOMs for one product means every ECO must land in both places, and the day one lands in only one, your buyer is procuring against a design that no longer exists.
bomrail gives you a standing answer to "are the BOMs in agreement?" — as a question any team member can ask an AI agent, rather than an export-and-VLOOKUP exercise. Through one hosted MCP endpoint, the agent walks the Duro BOM at the released revision and the Odoo mBOM behind your active manufacturing orders, and reports the diff: missing lines, quantity disagreements, superseded part numbers still being consumed.
Beyond the BOM check, the pairing answers day-to-day questions that neither system can alone: whether an Odoo purchase order references a part an open Duro ECO is about to change, or what the paid cost of a Duro assembly is according to Odoo vendor bills. All reads, no writes, every call logged.
What becomes answerable
bomrail exposes both systems as read-only MCP tools. These are the joins an agent can make on demand:
eBOM vs. mBOM
Duro engineering BOM diffed line-by-line against the Odoo manufacturing BOM, at explicit revisions.
ECO propagation
Released Duro ECOs checked against Odoo: has the mBOM been updated, and do open POs reference old revisions?
Procurement exposure
Odoo purchase order lines mapped to Duro parts under active change — flagged before parts arrive, not after.
As-designed cost
Duro BOM lines priced from Odoo vendor bills, giving a paid-cost roll-up per assembly revision.
Example: the Friday BOM-drift check
A three-person ops team makes it a ritual: every Friday, someone asks the agent to compare the Duro BOM for the shipping product against the Odoo mBOM feeding next week’s manufacturing orders. Most weeks the answer is "in agreement." One week it is not: ECO-77 swapped a torque sensor last Tuesday, the Duro BOM shows the new part, and Odoo still lists the old one — with a manufacturing order scheduled Monday and 30 old sensors on the shelf.
The team decides what to do (use up old stock under deviation, or update the mBOM and hold the build) — bomrail does not decide for them, and does not touch either system. What it changed is when they found out: Friday afternoon instead of during Monday’s kitting, when the discrepancy would have cost a build slot.
Frequently asked questions
We self-host Odoo. Can bomrail reach it?
Yes — the Odoo connector targets both Odoo cloud and self-hosted instances via the standard external API with a read-only user. For self-hosted instances behind a VPN, the self-hosted bomrail deployment runs inside your network alongside it.
Odoo has a PLM module. Why keep Duro at all?
Teams that chose Duro usually did so for revision control and change workflows that Odoo’s PLM module does not match. bomrail is agnostic on that choice — it assumes you run both systems on purpose and makes the seam between them queryable.
Can the agent update the Odoo mBOM when it finds drift?
Not silently, ever. Read-only is the default across bomrail. mBOM updates are the kind of scoped write action the Growth plan can enable, and each execution requires a human to approve that specific change.
Which Odoo versions and modules are covered?
The connector is being built against Odoo 17+ covering Manufacturing (mBOMs, manufacturing orders), Purchase, Inventory, and Accounting (vendor bills). Odoo is in the design-partner tier — the waitlist form is where module priorities get decided.