A build-to-order ERPNext application that runs several delivery-only brands from one physical kitchen, with brand-level menus and tax, aggregator order routing, shared inventory deduction, and true per-brand profitability. ECOSIRE builds, installs, and supports it to your confirmed scope. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $799.00 USD; request a quote for a scoped proposal.

A build-to-order ERPNext application that runs several delivery-only brands from one physical kitchen, with brand-level menus and tax, aggregator order routing, shared inventory deduction, and true per-brand profitability. ECOSIRE builds, installs, and supports it to your confirmed scope.
Şimdi ödeme yok. Bu, ekibimize bir teklif talebi gönderir — fiyat ve sonraki adımlarla e-posta ile dönüş yapacağız.
Cloud-kitchen operators typically run four, six, or a dozen virtual brands out of one back-of-house — and stock ERPNext has no concept of a "brand" that owns its own menu, pricing, tax profile, and P&L. You end up modelling each brand as a separate Company (which fragments your one shared inventory) or crushing everything into a single price list and item group, at which point you can no longer answer the only question that matters: which brand actually makes money after aggregator commission and food cost? Sales Orders arriving from Talabat, Deliveroo, Careem, Uber Eats or your own web checkout all land in the same Sales Order list with nothing that routes, tags, or reconciles them by brand and channel. That is exactly where ERPNext core runs out of road for this business model.
`Virtual Brand` DocType owning each brand's menu, Price List, Item Tax Template, branding and target margin
`Kitchen Channel` DocType mapping each aggregator/direct channel to its commission %, prep-station and default warehouse
`hooks.py` `doc_events` on Sales Order (`validate`/`before_save`/`on_submit`) that applies the brand's price list + tax template and injects channel commission as a deduction
Whitelisted REST ingest method (`@frappe.whitelist()`) for pushing aggregator orders into ERPNext, stamped with `virtual_brand` and `channel`
Custom fields (`virtual_brand`, `channel`, `commission_amount`) added to Sales Order / POS Invoice via fixtures, so brand/channel travel through the whole order lifecycle
Kitchen Display Page using `frappe.publish_realtime` to route tickets to the correct prep station in real time
We build a proper Frappe app (its own module, git repo, and hooks.py) that adds first-class multi-brand structure on top of ERPNext instead of fighting it. A Virtual Brand DocType owns each brand's menu (linked ERPNext Items via a child table), its own Price List and Item Tax Template, its logo/branding, and its target margin. A Kitchen Channel DocType maps each delivery aggregator or direct channel to its commission percentage, prep-station, and default warehouse. Incoming orders — whether pushed via the Frappe REST API / a whitelisted ingest method or entered at POS — are stamped with virtual_brand and channel custom fields, and a doc_events hook on Sales Order before_save/on_submit applies the brand's price list and tax template, injects the channel commission as a deduction line, and routes the ticket to the correct prep station via a Kitchen Display screen (a Frappe Page / Portal view backed by realtime frappe.publish_realtime).
Under the hood the shared pantry stays shared: all brands deduct from the same ERPNext Warehouse and Stock Ledger, so a kilo of chicken consumed by three different brand menus draws down one real inventory balance and triggers one reorder — no double-counting, no per-company silos. Server Scripts and scheduled jobs (scheduler_events — hourly/daily) roll up a per-brand P&L: revenue, aggregator commission, theoretical food cost from linked BOMs/recipes, and contribution margin, surfaced through a Query Report and dashboard chart filtered by virtual_brand. Client Scripts add brand-aware validation and one-click brand switching on the order form, and a Role Profile ("Brand Manager") plus User Permissions scope each operator to only their own brands' orders and reports.
This is build-to-order, not a marketplace download — there is no instant install. After a short scoping call we confirm which aggregators, brands, tax jurisdictions and reporting cuts you need, then build and hand over an installable Frappe app tested against ERPNext v15/v16. Typical delivery is 2–4 weeks from confirmed scope. You receive the source, a UAT pass on a staging bench with a rollback plan, training, and a post-go-live support window — installed and maintained by ECOSIRE.
Runs 4–12 delivery-only brands from one kitchen and needs each brand's menu, pricing, tax and P&L cleanly separated while stock stays pooled — without spinning up a Company per brand in ERPNext.
Wants trustworthy per-brand contribution margin after aggregator commission and food cost, reconciled against the shared Stock Ledger, delivered as ERPNext Query Reports and dashboards rather than exported spreadsheets.
Needs incoming aggregator and direct orders routed to the right prep station in real time on a Kitchen Display, with tickets clearly tagged by brand and channel so the line never mixes up which brand an order belongs to.
Maintains the bench and wants a clean, migratable Frappe app with proper DocTypes, hooks and fixtures — not scattered manual customisations — that survives `bench migrate` across v15/v16 upgrades.
Lisansı ecosire.com adresinden satın alın ve hesap kontrol panelinizden Cloud Kitchen / Multi-Brand Ops for ERPNext uygulamasının ZIP dosyasını indirin.
ZIP dosyasını tezgahınızın uygulamalar klasörüne çıkarın veya çıkarılan uygulamanın yolunu içeren "bench get-app" komutunu çalıştırın.
Cloud Kitchen / Multi-Brand Ops for ERPNext yüklemek ve şemasını uygulamak için `bench --site SITE_NAME install-app APP_NAME` komutunu ve ardından `bench move'u çalıştırın.
Sitenizdeki ECOSIRE Lisans ayarlarını açın ve lisans anahtarınızı etkinleştirin. Ücretsiz ecosire_connect ve ecosire_license_client uygulamalarını gerektirir.
| Kriter | ECOSIRE | Özel Yapı | Rakip | Odoo Yerlisi |
|---|---|---|---|---|
| Multiple virtual brands | First-class `Virtual Brand` DocType in one Company | Possible, but you design the data model from scratch | Usually assumes one brand per site | |
| Shared inventory across brands | One Warehouse + Stock Ledger, deducted by all brands | Achievable with careful modelling | Often silos stock per brand/company | |
| Aggregator/channel routing | `Kitchen Channel` + whitelisted REST ingest + doc-event routing | Build ingest and routing yourself | Limited or single-channel | |
| Per-brand P&L with food cost | Scheduled roll-up: revenue, commission, BOM cost, margin | Custom reports to build and maintain | Basic sales report, no margin | |
| Channel commission handling | Auto-injected as deduction via `hooks.py` doc event | Hand-coded per channel | Rarely modelled | |
| Kitchen display routing | Realtime Page via `frappe.publish_realtime` per station | Build the realtime layer yourself | May need a separate KDS product | |
| Upgrade safety (v15/v16) | Versioned app, fixtures, `bench migrate` safe | Depends on discipline of the build | Varies; may lag versions | |
| Support & source ownership | Full git handover + post-go-live support window | You own it and all its maintenance | Vendor-locked, generic support |
No — this is build-to-order, not a marketplace download. After a short scoping call to confirm your brands, aggregators, tax jurisdictions and reporting needs, typical delivery is 2–4 weeks from confirmed scope. You get a UAT pass on a staging bench before anything touches production.
Every engagement includes a post-go-live support window for defect fixes and configuration tweaks. Because you receive the full source in a git repository, you're never locked in. We keep the app compatible with ERPNext/Frappe v15 and v16, and can quote ongoing maintenance or feature extensions separately.
No — that's exactly the pattern we avoid. Brands are modelled as a `Virtual Brand` DocType inside one Company, so they share a single Warehouse and Stock Ledger. Each brand still gets its own menu, Price List, Item Tax Template and P&L; you get separation of reporting without fragmenting inventory.
Through a whitelisted Frappe REST method that accepts aggregator payloads and creates Sales Orders stamped with the correct `virtual_brand` and `channel`. If you use a middleware or the aggregator's webhook, we map it to that ingest contract. Orders can also be entered at POS. Commission per channel is applied automatically via a `hooks.py` doc event.
Both. When your menu items are linked to recipes/BOMs, scheduled jobs compute theoretical food cost per item and roll it into a per-brand P&L alongside revenue and aggregator commission, giving you real contribution margin — not just top-line sales — in a filterable Query Report.
Frappe/ERPNext v15 and v16. It's packaged as a proper versioned app with fixtures and migrations, so it's `bench migrate` safe. If you're on an older version, we'll flag any upgrade needs during scoping.
Yes. We ship a `Brand Manager` Role Profile plus User Permissions so each operator only sees the orders, reports and dashboards for the brands they're assigned — enforced at the ERPNext permission layer, not just hidden in the UI.
A build-to-order ERPNext application that runs several delivery-only brands from one physical kitchen, with brand-level menus and tax, aggregator order routing, shared inventory deduction, and true per-brand profitability. ECOSIRE builds, installs, and supports it to your confirmed scope.