Caterers and central kitchens run on a rhythm that standard Odoo was never shaped for: a wedding for 240 guests, a corporate lunch for 30, and a funeral reception for 80 can all land in the same week, each with its own menu, per-head price, dietary constraints, and a hard delivery time that cannot slip. In vanilla Odoo you can raise a sale.order and even build kitted products with the MRP mrp.bom, but there is no first-class notion of an event with a headcount that drives both pricing and ingredient demand. Teams end up managing menus in spreadsheets, re-keying headcounts into manufacturing orders by hand, and discovering at 5am that they are short 6kg of chicken because nobody exploded the BOM across the day's confirmed events. That gap between "the sale" and "what the kitchen actually has to cook and pack" is exactly where this module lives.

ECOSIRE builds a dedicated Catering Service Management app for your Odoo. At its core is a menu and package layer: a catering.menu / catering.package model where each package carries per-head pricing, course structure, and links to the product.product and mrp.bom records that define what must be produced per cover. Event orders are a purpose-built model (extending or bridging sale.order) that captures headcount, event date and time, venue, service style (plated, buffet, drop-off), and dietary counts. A @api.depends('headcount', 'package_id') compute recalculates the priced quote and, critically, the production demand — so changing 200 guests to 230 reflows both the customer total and the kitchen's ingredient requirement without a single manual edit.

The production side is where the engineering earns its keep. We explode each confirmed event's packages down through their bills of materials so you get an aggregated, date-bucketed ingredient and sub-recipe demand across every event on a given production day — the "cook list" and the shopping list. Kitchen production and packing schedules are generated as their own records with QWeb reports (production sheets, packing labels, delivery run-sheets, per-event kitchen dockets) that your team actually prints. Staffing and delivery logistics are modelled as assignable resources against each event, with a delivery schedule view that sequences drop-offs by time and route. Access is locked down with ir.model.access.csv plus record rules so kitchen staff, event coordinators, and finance each see only what they should, and automated actions handle the reminders (production cutoffs, final-headcount deadlines, delivery day). Everything is reachable over Odoo's XML-RPC / JSON-RPC API for integration with a website enquiry form or a delivery app.

Because this is build-to-order, you are not downloading a generic module and bending your process to fit it. We start from your real menus, package structures, and production workflow, build the module against your Odoo version (17.0, 18.0 or 19.0) and edition (Community or Enterprise — MRP-dependent features are scoped to your edition), and deliver clean, documented source with a proper __manifest__.py, model layer, security, views and reports. Typical delivery is one working week from confirmed scope, depending on how deep the BOM explosion and logistics requirements go. You get the installable code, a staging UAT with a rollback plan, training for your coordinators and kitchen leads, a git repository handover, and a post-go-live support window so the first real event weekend has us behind it.