A central kitchen runs on a clock that ERPNext core does not know about. You take orders for a wedding on Saturday, three corporate lunch drops on Monday, and a rolling retail line for two dark-kitchen brands — and then you have to work backwards: explode every menu into recipes, net off what is already in the walk-in, decide what gets cooked Friday night versus Saturday morning, raise purchase orders for perishables that must land the morning of production, and dispatch finished food against a delivery window measured in minutes. ERPNext gives you genuinely good primitives for this — BOM, Work Order, Production Plan, Material Request, Stock Entry, Batch, Delivery Note — but they were designed for discrete manufacturing where a unit is a unit and a plan is monthly. They have no concept of a menu sold per head, of a portion yield that changes when you scale a recipe from 40 covers to 400, of an event that is one logistical object spanning production, packing, transport, on-site service and equipment return, or of a shelf life measured in hours.

What we build is a proper Frappe app — its own repo, its own module, installed with bench get-app and bench --site <site> install-app alongside erpnext — that adds the catering layer on top of those primitives rather than replacing them. The core DocTypes are typically Menu and Menu Item (a sellable menu priced per head or per platter, with child rows linking to ERPNext Item and BOM records), Recipe Card (yield quantity, portion size, prep and cook steps, allergen flags, and a costing roll-up that walks the BOM tree and revalues against your chosen rate — Valuation Rate, Last Purchase Rate or a negotiated contract rate), Catering Event (venue, service window, headcount, staffing, equipment, transport legs), and Production Batch (a cook-day grouping of Work Orders with a station and a shift). Menu costing is computed server-side in whitelisted methods so the same number is returned to the Quotation form, the desk report and any external system calling over the Frappe REST API — the cost of a menu never depends on which screen you opened.

The engine is a demand-to-production planner. Confirmed Sales Order rows for catering items, plus the headcount on each Catering Event, are exploded through the recipe tree into a net requirement, offset against on-hand stock at the kitchen warehouse and against already-planned Work Orders, and turned into a dated production schedule and a Material Request set for procurement. Perishables get a required-by date derived backwards from the service window and the ingredient's shelf life rather than a flat lead time, so you are not ordering cream a week early. hooks.py doc events wire the flow together — on_submit of a Sales Order flags the event for planning, on_submit of a Stock Entry closes the loop on actual versus theoretical consumption, on_cancel unwinds cleanly — and a scheduler_events hourly job re-checks the horizon, raises shortage alerts and flags batches whose use-by has passed. Wastage is captured as its own document with a reason code and a station, posted through a Stock Entry of type Material Issue against a wastage expense account, so the variance between theoretical yield from the recipe and actual issue from the walk-in is a real number in a report instead of a guess. Client scripts add the kitchen-floor ergonomics: scale a menu by headcount and see the plan and cost recompute, print a station-level prep sheet, confirm a dispatch on a tablet. Permissions are delivered as role profiles — Head Chef, Production Planner, Purchase, Event Manager, Dispatch — with user permissions scoping people to their own kitchen or brand, so a dark-kitchen operator running several brands on one site does not leak menus or margins between them.

This is build-to-order, and we are explicit about that: there is no instant download and no Frappe Cloud Marketplace listing to click. You request a quotation, we run a scoping call, and we write the app against your Frappe/ERPNext version — v15 or v16 — your naming series, your warehouse and cost-centre structure, and the way your kitchen actually works. Typical delivery is one working week from confirmed scope, depending on how much event logistics and procurement automation you want in the first release. You get the installable source for your version, a git repository handed over to you, installation on your bench, technical and user documentation, a training session, UAT on a staging site with a rollback plan before anything touches production, and a post-go-live support window while your first real service weeks run through the system.