A build-to-order Odoo module that deducts raw ingredients from inventory on every dish sold via recipe BOMs, and reports true food cost, margin, and yield per menu item. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, or 19.0. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $299.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo module that deducts raw ingredients from inventory on every dish sold via recipe BOMs, and reports true food cost, margin, and yield per menu item. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, or 19.0.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
Restaurants and central kitchens bleed margin at the point where a plated dish meets the stock ledger. In standard Odoo POS, a menu item is sold as a single finished product, so a burger leaves inventory as "1 burger" — the bun, patty, cheese, and sauce it consumed are never decremented. Odoo's Manufacturing (mrp) app can hold a Bill of Materials, but it is built for production orders on a factory floor, not for silently exploding a recipe on every pos.order.line at the counter. The result is that food-cost reporting is guesswork, ingredient stock drifts from reality within days, and reorder decisions are made on gut feel instead of consumption.
Recipe Bill of Materials per menu item, with ingredient product, quantity, and unit of measure (`uom.uom`) per line
Automatic `stock.move` generation on POS order validation, consuming ingredients from the configured kitchen/warehouse location
Combo and set-menu explosion — component dishes each contribute their own recipe lines to the deduction
Modifier and variant ingredient mapping (extra cheese, large size) as incremental recipe lines, not flat surcharges
Computed food cost and gross margin per dish via `@api.depends` on recipe lines and ingredient `standard_price`
Theoretical-vs-actual consumption reporting to surface waste, over-portioning, and shrinkage
ECOSIRE builds a POS-native recipe engine that closes this gap. We add a recipe Bill of Materials to each menu item — modeled either on Odoo's existing mrp.bom structure or a purpose-built restaurant.recipe model depending on your Enterprise/Community edition and appetite for MRP dependencies. Each recipe line maps an ingredient product, a quantity, and a unit of measure (uom.uom), so 200 g of beef and 30 ml of sauce are recorded against the dish. When a POS order is validated, an extended flow hooks the order confirmation (via pos.order._process_order / stock move creation) to generate stock.move records that consume the ingredients from the kitchen location — real inventory movements, not a cosmetic counter. Combos and modifiers are handled explicitly: a "large" size or an "extra cheese" modifier carries its own incremental ingredient lines, so the deduction reflects what was actually made. Cost per dish is a computed field (@api.depends on recipe lines and the ingredients' standard_price) so gross margin per menu item is live, not a monthly spreadsheet.
On top of the deduction core we build the reporting and control layer operators actually run the business on: food-cost percentage and margin per dish, theoretical-vs-actual consumption, and yield reporting for prep items (e.g. one 5 kg tray of dough yields 40 bases). Low-ingredient and reorder alerts run as Odoo automated actions / scheduled ir.cron jobs against your reorder rules, notifying the kitchen manager before a key ingredient hits zero mid-service. QWeb PDF reports give you a printable food-cost sheet and a daily consumption summary, and every model ships with ir.model.access.csv entries plus record rules so line cooks, shift managers, and finance see only what their role permits. Where you already run integrations, the module's models are exposed over Odoo's XML-RPC / JSON-RPC API so a central-kitchen system or external BI tool can read consumption and cost data.
Because this is a build-to-order product, nothing ships as a blind download. We start with a short scoping call to confirm your edition (Community vs Enterprise — Enterprise unlocks tighter MRP and accounting hooks), your Odoo version (17.0, 18.0, or 19.0), your location/warehouse layout, and how your menu, combos, and modifiers are structured. From that confirmed scope we build the module, deliver it against a staging copy of your database for UAT, and only then install to production with a rollback plan. Typical delivery is 2-4 weeks from confirmed scope, and every engagement includes documentation, a training session, and a post-go-live support window.
Runs one or several outlets and needs true food-cost percentage per dish and reliable ingredient stock, instead of reconciling POS sales against inventory by hand each month.
Produces prep items in bulk and distributes to outlets; needs yield tracking, sub-recipe explosion, and multi-location deduction so stock reflects real consumption across sites.
Owns margin and purchasing budgets; wants live gross margin per menu item, theoretical-vs-actual variance, and role-scoped reports to catch over-portioning and shrinkage.
Maintains the Odoo instance and needs a clean, version-matched module with documented models, `ir.model.access.csv` security, and XML-RPC/JSON-RPC access for existing BI tools.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 POS Restaurant Recipe & Ingredient Stock (BOM) 模块 ZIP。
将 ZIP 解压到服务器上的 Odoo 自定义插件文件夹中(或通过“应用程序”>“从 Odoo.sh / runbot 上的文件安装”上传)。
激活开发者模式,打开应用程序,单击更新应用程序列表,搜索 POS Restaurant Recipe & Ingredient Stock (BOM),然后按安装。
打开新菜单,粘贴您的 ECOSIRE 许可证密钥,连接任何外部凭据(Shopify、Amazon、Stripe 等),然后保存。
运行内置连接测试,同步前 10 条记录,并安排定期 cron。如果出现任何问题,请联系支持人员。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| Ingredient deduction per dish | Recipe BOM explodes to real `stock.move` on every POS sale | Possible but you design and maintain the whole flow | Often deducts only finished product, or a rigid recipe model | |
| Food cost & margin per dish | Live computed field on ingredient `standard_price` with QWeb report | Depends on your team's costing implementation | Basic cost field, limited variance reporting | |
| Combos & modifiers | Explicit explosion and incremental modifier ingredient lines | Must be specified and coded case by case | Frequently unsupported or flat-surcharge only | |
| Yield / sub-recipes | Prep-batch yield and nested sub-recipes for central kitchens | Buildable with significant design effort | Rarely offered | |
| Reorder alerts | `ir.cron` + automated actions against reorder points | Wire up your own scheduled jobs | Sometimes present, often generic | |
| Version & edition fit | Built for your exact 17.0/18.0/19.0, Community or Enterprise | Whatever you build it against | May lag Odoo versions or force Enterprise | |
| Support & handover | Post-go-live window + full git repo + docs + training | In-house; support is your own burden | Vendor ticket queue, variable SLAs | |
| Time to value | 2-4 weeks build-to-order, UAT on staging first | Weeks to months depending on team capacity | Instant install but generic fit + integration work |
This is a build-to-order module, so it is built for your confirmed scope rather than downloaded. Typical delivery is 2-4 weeks from the point where scope is confirmed on the scoping call — your Odoo version and edition, menu/combo/modifier structure, and warehouse layout. Larger menus or multi-location central-kitchen setups sit at the upper end of that range.
Every engagement includes a post-go-live support window for defect fixes and configuration adjustments. Because the module is version-specific, moving to a newer Odoo release (for example 18.0 to 19.0) is handled as a scoped migration — we adapt the models, views, and POS hooks to the new version. You receive the full git repository, so your own team can also maintain it.
Both. We confirm your edition on the scoping call. Enterprise gives us tighter hooks into MRP and accounting for costing, but the recipe deduction and food-cost core runs on Community too — where needed we implement a purpose-built recipe model instead of depending on the `mrp` app.
No. The ingredient explosion and `stock.move` creation run on order validation on the server side, not in the cashier's checkout keystrokes, and we build with batched moves plus negative-stock and UoM-rounding safeguards so high-volume service is not blocked by stock logic.
Combos explode into their component dishes, each carrying its own recipe, and modifiers (extra cheese, large size) are mapped as incremental ingredient lines. So an 'extra cheese' order deducts the additional cheese, and a combo deducts every ingredient of every component — the deduction reflects what the kitchen actually made.
Yes. Consumption, cost, and recipe models are exposed over Odoo's standard XML-RPC / JSON-RPC API, so an external dashboard, procurement system, or central-kitchen platform can read live consumption and food-cost data without direct database access.
You get the complete, documented source code and a git repository with full history and a tagged release, alongside technical documentation of the data model and stock flow. There is no lock-in — your team can extend or maintain the module independently.
A build-to-order Odoo module that deducts raw ingredients from inventory on every dish sold via recipe BOMs, and reports true food cost, margin, and yield per menu item. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, or 19.0.