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.

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 one working week from confirmed scope, and every engagement includes documentation, a training session, and a post-go-live support window.