Les détails du produit sont affichés en anglais. Traductions à venir.
Faits en bref
- Prix
- $499.00 USD
- Versions ERPNext
- —
- Temps d'installation
- 30 minutes
- Licence
- Perpétuel unique
- Langues
- 11 langues
Achat unique
Restaurant Inventory & Recipe Costing for ERPNext
A build-to-order ERPNext app that costs every menu item at the recipe level, deducts ingredients on POS sale, and surfaces the theoretical-vs-actual consumption variance that quietly erodes restaurant margins.
$499.00USD
Aucun paiement maintenant. Ceci envoie une demande de devis à notre équipe — nous vous recontacterons par e-mail avec les tarifs et les prochaines étapes.
Fonctionnalités clés
`Recipe` DocType with a `Recipe Ingredient` child table (Item, qty, UOM, yield/waste %) linked one-to-one with each sellable menu `Item`
Live theoretical plate-cost rollup from current `Item` valuation rates via a scheduler event, so an ingredient price change re-prices every affected dish
Multi-level and sub-recipe support (e.g. sauces and doughs as their own recipes) exploded recursively at cost time, mirroring ERPNext BOM nesting
Ingredient-level backflush on sale: a `hooks.py` `doc_events` handler on `POS Invoice`/`Sales Invoice` `on_submit` posts a Material Issue `Stock Entry` per recipe
Real `Stock Ledger Entry` movements against the outlet warehouse so ingredient on-hand stays accurate in real time, not end-of-day
`Wastage Log` DocType with reason codes (spoilage, prep waste, breakage, staff meal, comp) that posts its own stock issue and feeds the variance report
Nightly scheduled job that writes a `Consumption Variance` record per item and outlet: theoretical (recipe × units sold) vs actual (count / stock movement)
Menu-engineering Query Report classifying items into star / plough-horse / puzzle / dog from contribution margin vs POS popularity
Yield and portion control: cook-yield and portion-loss percentages applied at the ingredient line so as-purchased vs as-served cost is honest
Multi-outlet and multi-warehouse aware — variance, cost and wastage all sliced by outlet, with per-outlet valuation where item rates differ
UOM conversion handling (kg↔g, L↔ml, case↔each) using ERPNext UOM Conversion so recipes in grams reconcile against purchases in cases
Whitelisted REST methods (`@frappe.whitelist()`) so an external POS, KDS or BI tool can pull plate costs and post wastage programmatically
Role profiles and DocType-level permissions (`Kitchen Manager`, `Outlet Manager`, `Cost Controller`) that scope margin-sensitive data
Client Scripts adding an in-form live plate-cost badge, target-food-cost-% flag and allergen surfacing on the menu Item form
Theoretical food-cost % and actual food-cost % dashboards driven from ERPNext Dashboard Charts and Number Cards
À propos de ce produit
Restaurants bleed margin in the gap between what a dish should cost and what it actually consumed. ERPNext ships strong bones for this — BOM, Item, Stock Entry, Stock Ledger Entry, valuation methods and a POS Invoice flow — but out of the box it treats a plate of food like any other manufactured good. There is no first-class notion of a menu-item recipe that deducts raw ingredients at the moment of a POS sale, no built-in theoretical-vs-actual consumption reconciliation, and no structured wastage or spoilage capture. Kitchen managers end up reconciling food cost in spreadsheets, and the variance that eats three to six points of margin never surfaces inside the system where the decisions are actually made.
Pourquoi choisir Restaurant Inventory & Recipe Costing for ERPNext
`Recipe` DocType with a `Recipe Ingredient` child table (Item, qty, UOM, yield/waste %) linked one-to-one with each sellable menu `Item`
Live theoretical plate-cost rollup from current `Item` valuation rates via a scheduler event, so an ingredient price change re-prices every affected dish
Multi-level and sub-recipe support (e.g. sauces and doughs as their own recipes) exploded recursively at cost time, mirroring ERPNext BOM nesting
Ingredient-level backflush on sale: a `hooks.py` `doc_events` handler on `POS Invoice`/`Sales Invoice` `on_submit` posts a Material Issue `Stock Entry` per recipe
Real `Stock Ledger Entry` movements against the outlet warehouse so ingredient on-hand stays accurate in real time, not end-of-day
`Wastage Log` DocType with reason codes (spoilage, prep waste, breakage, staff meal, comp) that posts its own stock issue and feeds the variance report
We build a proper Frappe application — its own app in the bench, installable via bench get-app / bench install-app, versioned in git — that adds a Restaurant Costing module on top of native ERPNext without forking core. At its heart is a Recipe DocType (with a Recipe Ingredient child table whose rows reference stock Items with quantity, UOM and a yield/waste percentage) linked to the sellable menu Item. A scheduler event (recipe_cost.rollup) plus BOM-aware valuation logic compute a live theoretical cost per menu item from current Item valuation rates, so a change in the price of beef or cooking oil re-prices every affected dish automatically.
On each confirmed sale we deduct ingredients at the component level. A hooks.py doc_events handler on POS Invoice (and Sales Invoice) on_submit explodes every sold menu item into its recipe and posts a backflush Stock Entry (Material Issue) against the outlet warehouse, writing real Stock Ledger Entry movements so on-hand ingredient stock stays honest in real time. A Wastage Log DocType captures spoilage, prep waste, breakage and staff meals against a reason code and posts its own stock issue. Nightly, a scheduled job snapshots theoretical consumption (from recipes × units sold) against actual consumption (physical count / stock movement) and writes a Consumption Variance record per item and outlet, so the variance report is answer-first, not a spreadsheet exercise. A menu-engineering Query Report classifies each item into the star / plough-horse / puzzle / dog quadrant from contribution margin against POS sales popularity.
Everything is exposed through the Frappe REST API and whitelisted methods (@frappe.whitelist()) so a KDS, a third-party POS or a BI tool can read costs and post wastage; role profiles and DocType permissions (Kitchen Manager, Outlet Manager, Cost Controller) keep sensitive margin data scoped. Client Scripts add in-form helpers (live plate-cost badge, allergen flags) without touching the core desk. Because it is build-to-order, delivery works like an engagement, not a download: a short scoping call fixes your menu structure, outlet/warehouse layout, POS setup and reporting needs; we build and test your version against Frappe/ERPNext v15 or v16, run UAT on a staging bench, then install to production with a rollback plan and hand over the git repository. Typical delivery is two to four weeks from confirmed scope.
Ce que vous obtenez
- Installable source code for your version as a standalone Frappe app (`bench get-app` / `bench install-app`), pinned to Frappe/ERPNext v15 or v16
- Installation and configuration on your bench, including scheduler events, custom roles, warehouse mapping and initial recipe import
- Technical documentation: DocType schema, `hooks.py` doc events, whitelisted API reference and data-model diagram
- User guide plus a live training session for kitchen managers, outlet managers and cost controllers
- Post-go-live support window for bug fixes and adjustments after production launch
- UAT on a staging bench with a signed-off test plan, plus a documented rollback procedure for the production install
- Git repository handover (full history, branch and tag conventions) so your team or another vendor can maintain it
- Seed data and CSV/Data Import templates for bulk-loading recipes and ingredient mappings
Pour qui c'est
Multi-outlet restaurant operator
Runs several branches on ERPNext POS and needs food-cost variance and wastage sliced per outlet, not a single blended number, to see which kitchen is leaking margin.
Cost controller / F&B finance lead
Owns the food-cost line and wants theoretical-vs-actual reconciliation posted automatically from POS sales and recipes, replacing a fragile month-end spreadsheet.
Executive chef / kitchen manager
Needs a live plate cost per menu item, portion and yield control, and structured wastage logging so recipe changes and price moves show their margin impact immediately.
Cloud-kitchen / central-production operator
Produces sub-recipes centrally and deducts ingredients across virtual brands, needing multi-level recipe explosion and warehouse-aware backflush tied to each brand's POS sales.
Aperçu de l'installation
Télécharger depuis ECOSIRE
Achetez la licence sur ecosire.com et téléchargez le ZIP de l'application Restaurant Inventory & Recipe Costing for ERPNext depuis le tableau de bord de votre compte.
Ajoutez l'application à votre banc
Extrayez le ZIP dans le dossier d'applications de votre banc ou exécutez « bench get-app » avec le chemin d'accès à l'application extraite.
Installer sur votre site
Exécutez `bench --site SITE_NAME install-app APP_NAME` suivi de `bench migrate` pour installer Restaurant Inventory & Recipe Costing for ERPNext et appliquer son schéma.
Activez votre licence
Ouvrez les paramètres de licence ECOSIRE sur votre site et activez votre clé de licence. Nécessite les applications gratuites ecosire_connect et ecosire_license_client.
Comment Restaurant Inventory & Recipe Costing for ERPNext se compare
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Odoo natif |
|---|---|---|---|---|
| Ingredient deduction on sale | Automatic backflush per recipe on POS Invoice submit | Buildable but you specify and maintain the doc-event logic | Often manual stock entries or none at all | |
| Theoretical vs actual variance | Nightly job writes a variance record per item and outlet | Possible if you build the reconciliation engine | Rarely included; usually cost-only | |
| Wastage & spoilage tracking | Dedicated `Wastage Log` DocType with reason codes and stock posting | Design and build from scratch | Sometimes a basic note field | |
| Menu engineering | Star/plough-horse/puzzle/dog report from margin vs POS popularity | Requires custom report development | Seldom offered | |
| Fit to your menu & outlets | Scoped to your recipes, warehouses and workflow before build | Fully bespoke but you own all requirements | Fixed feature set, adapt your process to it | |
| ERPNext version support | Pinned and tested against your v15 or v16 bench | Depends on your team's testing discipline | Version support varies by maintainer | |
| Delivery & timeline | Build-to-order, 2-4 weeks from confirmed scope | Months, dependent on in-house capacity | Instant install but generic fit | |
| Handover & ownership | Full git repo, docs, training and support window | You own it but carry all maintenance | Closed source, dependent on the vendor |
Foire aux questions sur Restaurant Inventory & Recipe Costing for ERPNext
How long does delivery take, and how does the build-to-order process work?
This is built specifically for your restaurant, not an instant download. Typical delivery is two to four weeks from confirmed scope. It starts with a scoping call to fix your menu structure, outlet and warehouse layout, POS setup and reporting needs; we then build and test your version, run UAT on a staging bench, and install to production with a rollback plan and git handover.
How does it handle updates and support after go-live?
Every engagement includes a post-go-live support window for bug fixes and adjustments. Because you receive the full git repository, your team or another vendor can maintain it, and we can quote ongoing support or a version upgrade (for example v15 to v16) as a separate scope. We pin your build to a specific Frappe/ERPNext version so a bench update never silently breaks it.
Does this replace ERPNext POS, or work alongside it?
It works alongside native ERPNext POS and Sales Invoice. We do not fork core. The app listens to `POS Invoice`/`Sales Invoice` `on_submit` via `hooks.py` doc events and posts the ingredient-level stock movements, so your existing billing and payment flow is untouched — we add recipe costing, backflush and variance on top.
Can it integrate with a third-party POS or KDS instead of ERPNext POS?
Yes. All cost, wastage and consumption endpoints are exposed as whitelisted methods over the Frappe REST API (`@frappe.whitelist()`), so an external POS, kitchen display system or BI tool can pull plate costs and post sales or wastage. We scope the integration mapping during the discovery call.
How is theoretical-vs-actual variance actually calculated?
Theoretical consumption is your recipes multiplied by units sold from POS. Actual consumption comes from real stock movement and physical counts. A nightly scheduled job compares them and writes a `Consumption Variance` record per item and outlet, so the variance report — and the food-cost-% dashboards — are generated inside ERPNext rather than reconstructed in a spreadsheet.
Which Frappe and ERPNext versions are supported?
We target Frappe/ERPNext v15 and v16. We build and test against the exact version running on your bench and pin the app to it. If you are mid-upgrade, we will scope the build against your target version so you are not left on an unsupported release.
We already use ERPNext BOMs — why not just use those?
ERPNext BOM and Manufacturing can model a recipe, but they are built for production work orders, not real-time deduction from every POS sale, and they carry no wastage, yield-loss or theoretical-vs-actual variance concept for food service. This app adds those restaurant-specific behaviours as first-class DocTypes while still reusing ERPNext's valuation and stock ledger underneath.
Modules associés
ERPNext
Une fois
2Checkout / Verifone Gateway for ERPNext
A build-to-order 2Checkout (Verifone) payment integration for ERPNext, giving global digital-goods sellers card acceptance, 45+ local payment methods, multi-currency checkout, and reconciled invoices. ECOSIRE scopes, builds, installs, and supports it on your ERPNext v15/v16 instance.
Construit sur commandeproducts.card.fromPrice
Magento 2
Une fois
2Checkout / Verifone Gateway for Magento 2
A build-to-order 2Checkout / Verifone payment gateway for Magento 2 and Adobe Commerce: localized checkout in 12 languages, iDEAL, Giropay and regional methods, multi-currency global selling, subscription billing and tax/invoicing automation — engineered, installed and supported by ECOSIRE.
Construit sur commandeproducts.card.fromPrice
ERPNext
Une fois
360-Degree Feedback for ERPNext
A build-to-order ERPNext application for anonymous 360-degree reviews — configurable peer, manager, report and self rater groups, weighted competency scoring, and aggregated gap-analysis and heatmap reports. ECOSIRE scopes, builds, installs and supports it on your Frappe/ERPNext v15/v16 instance.
Construit sur commandeproducts.card.fromPrice
Demander un devis
Restaurant Inventory & Recipe Costing for ERPNext
A build-to-order ERPNext app that costs every menu item at the recipe level, deducts ingredients on POS sale, and surfaces the theoretical-vs-actual consumption variance that quietly erodes restaurant margins.
- `Recipe` DocType with a `Recipe Ingredient` child table (Item, qty, UOM, yield/waste %) linked one-to-one with each sellable menu `Item`
- Live theoretical plate-cost rollup from current `Item` valuation rates via a scheduler event, so an ingredient price change re-prices every affected dish
- Multi-level and sub-recipe support (e.g. sauces and doughs as their own recipes) exploded recursively at cost time, mirroring ERPNext BOM nesting
- Ingredient-level backflush on sale: a `hooks.py` `doc_events` handler on `POS Invoice`/`Sales Invoice` `on_submit` posts a Material Issue `Stock Entry` per recipe