Manufacturing Backflush & Auto-Consumption

We build a dedicated module (its own __manifest__.py, declaring mrp and stock as dependencies) that hooks the completion of a mrp.production and, where you want finer control, the mrp.workorder. When the completion is triggered we compute the components to consume from the active BOM against the quantity actually produced, then create and validate the corresponding stock.move / stock.move.line records so the raw-material picking is set done without operator keystrokes. The behavior is driven by configuration you own: a backflush point per BOM or per operation (consume at final MO close, or progressively as each work order finishes), so a multi-step route can backflush sub-assemblies at their operation and the rest at close. All of it is expressed as proper models.Model extensions with @api.depends computes for the variance fields, ir.model.access.csv plus record rules so the config is only editable by manufacturing managers, and OWL/XML views that add the backflush settings to the BOM and Manufacturing Settings without forking core screens.

The rules engine is where the real engineering sits. You choose per product or category how shortages are handled — allow negative stock and reconcile later, block completion until replenished, or short-consume and raise an exception activity — and how lot/serial-tracked components are auto-assigned (FEFO, FIFO, oldest lot, or a specified reservation strategy) so tracked materials get a genuine, traceable lot_id on the consumption line rather than an operator's guess. Every backflush writes a variance flag when the actual consumed quantity differs from the BOM-expected quantity (scrap, over-issue, yield loss), surfaced as a filterable field and, if you want it, a QWeb variance report and an automated action that notifies production control. Because the consumption still flows through standard stock.move records, valuation, traceability, and the reporting you already rely on stay correct — and the same behavior is reachable over XML-RPC / JSON-RPC, so an MES, a scanner app, or a shop-floor terminal can report production done and have Odoo backflush server-side.

This is build-to-order, not an instant download from apps.odoo.com. It starts with a short scoping call to confirm your BOM structure, backflush points, tracking rules, and Community vs Enterprise edition, then ECOSIRE builds the module against your exact Odoo 17.0, 18.0, or 19.0 version. Typical delivery is 2–4 weeks from confirmed scope. You get the installable source, installation and configuration on your environment, UAT on a staging copy of your database with a rollback plan, and a post-go-live support window — no fabricated benchmarks, just a module engineered to your line and handed over with its git repository.