Central kitchens and catering operators live on two numbers Business Central will not give them out of the box: the true landed cost of a portion, and how many portions have to leave the pass at 06:00 tomorrow. Standard Business Central models an Item, a BOM and a Production Order — but a menu is not a BOM. A menu item has yield loss on prep, sub-recipes that are themselves produced (stocks, sauces, marinades), a portion size that differs by channel (buffet tray vs. individual box vs. aggregator SKU), an allergen and dietary profile that must follow the recipe, and a cost that moves with every purchase invoice. Meanwhile the demand side is not a Sales Order in the classic sense: it is an event with a date, a service window, a headcount that changes twice before it locks, a delivery address, equipment that goes out and must come back, and staff to assign. Operators end up running the real business in spreadsheets and pushing only the invoice into Business Central, which is exactly how food cost drifts unnoticed and wastage never gets attributed to anything.

We build an AL extension that closes that gap inside Business Central rather than beside it. Recipes are held in new tables — a Recipe Card with versioned lines that resolve recursively into sub-recipes, yield and shrinkage factors per line, and a costing engine (a codeunit) that rolls up standard, last-direct and moving-average cost so a menu engineering matrix can classify every dish by contribution margin and popularity. Menus, price lists and channel-specific portion definitions extend that: the same biryani recipe can publish at 180g on an aggregator, 220g on a corporate box, and per-kilo on a buffet line, each with its own price and its own theoretical cost. Demand is captured on an Event Order (or on channel-imported orders through API pages) that carries service date, service window, venue, headcount, dietary splits and equipment lines. A production planning codeunit explodes the confirmed demand across a date range into a Production Plan bucketed by day-part and kitchen section, nets it against on-hand and already-planned quantities, and either drives Business Central production orders or writes lightweight kitchen production tickets for operators who do not licence the manufacturing granules. Ingredient requirements flow into requisition worksheet lines so purchasing stays in native Business Central with your existing vendors, blanket orders and approval workflow.

On the outbound side, delivery waves group event orders into routes with load lists, equipment out/in tracking and signed-delivery capture, and warehouse shipments or transfer orders are created against your existing location and bin setup. Wastage is a first-class posting: prep loss, over-production, spoilage, returned trays and staff meals each post with a reason code to their own dimension and item journal, so the difference between theoretical food cost and actual food cost becomes a report you can act on rather than a monthly surprise. Everything is wired the Business Central way — table and page extensions on Item, Vendor, Customer, Sales Header and Location; event subscribers rather than base-application changes; job queue entries for nightly cost roll-up, plan regeneration and channel polling; API pages over REST API v2.0 / OData v4 so a chef-facing tablet, a Power App or a Dataverse flow can read the plan; and granular permission sets so a kitchen supervisor sees production and wastage but not margins.

This is a build-to-order product, not an AppSource download. After a short scoping call we confirm your Business Central version and deployment (SaaS online or on-premises), your existing chart of accounts, dimensions, locations and item structure, the channels you take orders from, and which of the capabilities above you actually need on day one. We then build the extension against your configuration, deliver a signed app or per-tenant extension into a sandbox for UAT, migrate your recipes and menus, and go live with a rollback plan. Typical delivery is 2-4 weeks from confirmed scope, longer only where you want aggregator or POS integrations that depend on a third-party API we must first confirm access to. You receive the AL source code, and you keep it.