Teams that manufacture food, beverages, cosmetics, or any batch-produced good live and die by their recipes — the precise quantities, sub-recipes, process steps, and allergen data that turn raw materials into a finished product. Odoo's native Manufacturing gives you a bill of materials and routing, but a BoM is a flat parent-child structure: it has no concept of a formulation percentage, a per-batch yield loss, a graduated scaling factor, a versioned "approved" recipe with an effective date, or the process instructions and quality parameters a production floor actually needs. Prep teams end up keeping the real recipe in a spreadsheet and re-keying it into an mrp.bom, which is exactly where cost drift, allergen errors, and out-of-date formulations creep in.

Recipe Manager is a build-to-order Odoo application we design and build to sit on top of that native foundation and give you a proper recipe layer. At its core is a dedicated recipe model (a new models.Model, e.g. recipe.recipe) with ingredient lines that carry either an absolute quantity or a percentage of batch, a state field for the draft → approved → archived lifecycle, and version tracking so a superseded formulation is retained for traceability rather than overwritten. Ingredient costs, batch cost, and cost-per-unit-of-yield are computed fields (@api.depends on the line quantities, the linked product.product standard or average cost, and the declared yield) so a change to a raw-material price re-rolls the recipe cost automatically. Because recipes reference real product.product records and units of measure, they scale cleanly: a scaling wizard recomputes every line for a target batch size and rounds to the UoM's precision. Where you want the recipe to actually drive production, we generate or synchronise the corresponding mrp.bom and routing so the shop floor keeps using standard Odoo manufacturing orders — no parallel system.

Technically it is delivered as a normal Odoo addon with its own __manifest__.py, declaring dependencies on mrp (and stock/quality where in scope). Access is governed by ir.model.access.csv for the recipe-author, reviewer, and read-only roles, with ir.rule record rules to keep recipes scoped per company in a multi-company database. The UI is built with standard XML views (list, form, kanban by state) plus OWL components where an interactive scaling or costing panel adds value, and printable QWeb reports produce a clean recipe/spec sheet and a batch production sheet for the floor. Automated actions (or base.automation rules) can flag recipes whose linked ingredient cost has moved beyond a threshold or whose approval has expired, and everything is reachable over the standard XML-RPC/JSON-RPC API so an external PLM, e-commerce catalogue, or nutrition/labelling system can read and write recipe data. We build against your exact edition — Community or Enterprise — and target Odoo 17.0, 18.0, or 19.0; Enterprise-only hooks (such as Quality or Studio-adjacent features) are only used when your database actually has them.

Because this is a build-to-order product, nothing is auto-downloaded. It starts with a scoping call to confirm your recipe structure, whether percentages or absolute quantities lead, how yield and by-products are handled, which fields must flow into the BoM, and your reporting and integration needs. From confirmed scope, typical delivery is one working week: we develop on a branch, hand over on a staging database for UAT, then install into production with a rollback plan and a training session. Pricing starts from $999 (indicative, single-company base scope); multi-company record rules, deep sub-recipe/BoM synchronisation, nutrition/allergen and labelling logic, external-system integrations, and migrating a large existing recipe library into the new models increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise.