Construction and estimating teams live inside BC3 exchange files: a single .bc3 export from a measurement or bill-of-quantities tool carries the entire cost breakdown structure — chapters, sub-chapters, priced work units (partidas), unit-price decompositions, and detailed measurement lines with dimension formulas. When that budget has to become a real Odoo sales order, purchase plan, or project cost baseline, the work today is manual re-keying: someone retypes hundreds of concept codes, prices, and measured quantities into sale.order.line or a BoM, transcription errors slip in, and the moment the estimator issues a revised budget the whole exercise repeats. Odoo core has no notion of the FIEBDC-3 hierarchy or its fixed-format ~V/~C/~D/~M record grammar, so out of the box there is no bridge between the estimating world and the ERP.

We build a made-to-order Odoo module that ingests BC3/FIEBDC-3 files and turns them into structured, native Odoo data. Technically, it adds a parser service that reads the file's declared character set and version header, tokenises each ~-delimited record type, and rebuilds the concept tree from the ~C (concept), ~D (decomposition) and ~M (measurement) relationships — respecting the hierarchical codes, price types, and the decimal/date conventions the format uses. A new set of models (models.Model with proper _parent_name/_parent_store hierarchy for the chapter tree) stores each imported concept, its unit, its unit price with the decomposed cost breakdown, and its measurement lines with the length/width/height/quantity formula fields. compute/@api.depends fields roll measured quantities and decomposed prices up the tree so a chapter total always reconciles to its work units. From that staging tree we map records onto whatever native target your workflow needs — product.product/product.template for the concept catalogue, sale.order/purchase.order lines, or project/analytic cost lines — with a configurable code-to-product matching rule so re-imports update existing concepts instead of duplicating them.

The module ships as a normal Odoo addon: a versioned __manifest__.py, an import wizard built as an OWL/XML view with an upload widget and a mapping-preview step, QWeb reports for the reconstructed budget and measurement sheets, and optional automated actions to notify a reviewer when a new budget version is detected. Access is locked down with ir.model.access.csv plus record rules so imports and the concept catalogue are scoped to the right company and users, and the parser is also exposed over the standard XML-RPC/JSON-RPC API so an upstream estimating pipeline can push a BC3 file in unattended. It targets Odoo 17.0, 18.0 and 19.0 and works on Community; where your target flow depends on Enterprise-only apps (for example advanced accounting or full project financials) we wire to those cleanly and note the dependency up front.

Delivery is build-to-order: we start with a short scoping call to confirm which BC3 versions and source tools you export from, the exact Odoo target records you want populated, and your matching/versioning rules, then we build on a staging instance, run UAT against your real budget files, and hand over installable source, documentation, and a git repository. This is not an instant download — typical delivery is 2-4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company rollout, mapping into additional target documents, deeper measurement-formula handling, and large historical-budget migration increase the quoted scope.