انتقل إلى المحتوى الرئيسي
يتم عرض تفاصيل المنتج باللغة الإنجليزية. الترجمات قريبا.
Cloud Kitchen / Multi-Brand Ops for ERPNext — A build-to-order ERPNext application that runs several delivery-only brands fro — 1/1معاينة توضيحية

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.

ما هو Cloud Kitchen / Multi-Brand Ops for ERPNext؟

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 $999.00 USD; request a quote for a scoped proposal.

الميزات الرئيسية

`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
Shared-inventory deduction: all brands draw from one ERPNext Warehouse and Stock Ledger — one real balance, one reorder trigger
Recipe/BOM linkage so theoretical food cost per menu item feeds the margin calculation
Per-brand P&L Query Report: revenue, commission, food cost and contribution margin, filterable by `virtual_brand` and date range
`scheduler_events` (hourly/daily) that roll up brand consumption and profitability snapshots into a report DocType
Dashboard Charts and Number Cards broken out by virtual brand and channel
Client Scripts for brand-aware order validation and one-click brand switching on the Sales Order form
`Brand Manager` Role Profile + User Permissions scoping operators to only their own brands' orders and reports
Compatible with ERPNext / Frappe v15 and v16, packaged as a versioned, migratable app (`bench migrate` safe)

مبني حسب الطلب، ننجزه بالكامل لك

لا إعداد يدوي — تطبيق جاهز يبنيه ويثبّته ويدعمه ECOSIRE.

  1. 1

    تطلب

    ابدأ بسعر بناء لمرة واحدة. نحدّد النطاق معك عند الانطلاق.

  2. 2

    نبني ونثبّت

    يقوم ECOSIRE ببنائه وتهيئته وتثبيته على ERPNext الخاص بك.

  3. 3

    الإطلاق + الدعم

    تنطلق خلال أسبوع عمل واحد تقريبًا، مع أسبوعين من الدعم بعد التشغيل. نصلح عيوب الكود الذي نسلّمه مجانًا.

المواصفات التقنية

توافق ERPNext
—
الترخيص
يلزم تأكيد الترخيص
متطلبات Python
Python 3.10+
قاعدة البيانات
MariaDB 10.6+

عن هذا المنتج

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.

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 one working week 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.

ما تحصل عليه

  • Installable Frappe app (full source) for your confirmed scope, versioned in a git repository
  • Installation and configuration on your bench: brands, channels, price lists, tax templates and role profiles wired up
  • Technical documentation: DocType schemas, hooks, whitelisted methods, scheduler events and REST ingest contract
  • End-user guide plus a live training session for brand managers and kitchen staff
  • UAT on a staging bench with a signed-off test plan and a documented rollback procedure
  • Post-go-live support window for defect fixes and configuration adjustments
  • Git repository handover with commit history, README and upgrade notes for v15/v16
  • Data mapping / seed for your existing menu items, brands and aggregator channels

لمن هذا

Cloud-Kitchen Operator (Multi-Brand)

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.

Finance / Operations Controller

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.

Kitchen / Station Manager

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.

IT / ERPNext Administrator

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.

كيف يقارن Cloud Kitchen / Multi-Brand Ops for ERPNext.

المعيارECOSIREبناء مخصصمنافسERPNext الأصلي
Multiple virtual brandsFirst-class `Virtual Brand` DocType in one CompanyPossible, but you design the data model from scratchUsually assumes one brand per siteNo brand concept; forced into Company-per-brand
Shared inventory across brandsOne Warehouse + Stock Ledger, deducted by all brandsAchievable with careful modellingOften silos stock per brand/companyCompany-per-brand fragments inventory
Aggregator/channel routing`Kitchen Channel` + whitelisted REST ingest + doc-event routingBuild ingest and routing yourselfLimited or single-channelManual Sales Order entry only
Per-brand P&L with food costScheduled roll-up: revenue, commission, BOM cost, marginCustom reports to build and maintainBasic sales report, no marginNo per-brand cut of profitability
Channel commission handlingAuto-injected as deduction via `hooks.py` doc eventHand-coded per channelRarely modelledManual adjustment each order
Kitchen display routingRealtime Page via `frappe.publish_realtime` per stationBuild the realtime layer yourselfMay need a separate KDS productNone
Upgrade safety (v15/v16)Versioned app, fixtures, `bench migrate` safeDepends on discipline of the buildVaries; may lag versionsN/A — no such feature to upgrade
Support & source ownershipFull git handover + post-go-live support windowYou own it and all its maintenanceVendor-locked, generic supportCommunity/self-service only

الأسئلة المتداولة حول Cloud Kitchen / Multi-Brand Ops

How long until it is live? Can I download it now?

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 one working week from confirmed scope. You get a UAT pass on a staging bench before anything touches production.

How are updates and support handled after go-live?

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.

Do I need a separate ERPNext Company for each brand?

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.

How do orders from delivery aggregators get in?

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.

Will per-brand profit actually reflect food cost, or just revenue?

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.

Which ERPNext versions is this built for?

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.

Can operators be restricted to only their own brands?

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.

طلب عرض سعر

Cloud Kitchen / Multi-Brand Ops

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.

  • `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`

طلب عرض سعر

أخبرنا باحتياجاتك من Cloud Kitchen / Multi-Brand Ops وسنرسل لك الأسعار وخيارات الترخيص وعرضًا مخصصًا، عادةً خلال يوم عمل واحد.

لا حاجة للدفع الآن. يؤدي هذا إلى إرسال طلب عرض سعر إلى فريقنا — وسنتواصل معك عبر البريد الإلكتروني بالأسعار والخطوات التالية.