A real-time kitchen display that streams ERPNext POS orders straight to cook stations with color-coded prep timers, bump-bar controls and multi-station routing. ECOSIRE builds, installs and supports it as a native Frappe app after we scope your kitchen with you. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $399.00 USD; request a quote for a scoped proposal.

A real-time kitchen display that streams ERPNext POS orders straight to cook stations with color-coded prep timers, bump-bar controls and multi-station routing. ECOSIRE builds, installs and supports it as a native Frappe app after we scope your kitchen with you.
Sin pago ahora. Esto envía una solicitud de presupuesto a nuestro equipo; te responderemos por correo con precios y próximos pasos.
Restaurants and cloud kitchens running ERPNext POS take orders cleanly, but the moment the ticket needs to reach the line it falls back to printed KOTs or shouted callouts. ERPNext core has no live kitchen screen: there is no POS Invoice fan-out to a cook display, no prep-timer state, no per-station routing, and no "order ready" acknowledgement flowing back into the system. As soon as you run more than one prep station, or a cloud kitchen with several brands sharing a pass, paper tickets stall, items get re-fired, and expo has no view of what is actually late. That gap is exactly where a purpose-built KDS earns its place.
Native Frappe app installed into your bench (e.g. `ecosire_kds`) with `KDS Ticket`, `KDS Ticket Item` and `KDS Station` DocTypes — no external iframe or third-party cloud dependency
`hooks.py` `doc_events` on `POS Invoice` (`on_submit`/`on_update`) that creates and syncs tickets automatically as orders are rung up
Live order queue rendered over the Frappe realtime websocket (`frappe.realtime`) so tickets appear on screen with no refresh or polling
Color-coded prep timers that transition green→amber→red against per-item-group target times you define
Multi-station / multi-kitchen routing driven by a server script that maps ERPNext item groups to `KDS Station` records
Cloud-kitchen mode: several brands sharing a pass each get isolated station views filtered by brand/POS profile
ECOSIRE builds a proper Frappe app (for example ecosire_kds) installed into your ERPNext bench, not a bolt-on iframe. The core is a set of DocTypes — a KDS Ticket and child KDS Ticket Item that mirror each POS Invoice/POS Order, plus a KDS Station DocType defining each screen and the item groups it owns. A hooks.py doc_events handler on POS Invoice (on_submit, on_update) creates and updates tickets, and a server script applies your routing rules so a burger line, a fryer, and a drinks station each see only their own items. The screen itself is a Frappe-served page (or Frappe UI/Vue app) that subscribes over the realtime socket (frappe.realtime/websocket) so new orders appear instantly with color-coded prep timers that shift green→amber→red against your target times.
On the line, cooks drive the board with a physical bump bar or touchscreen: bump an item, bump a whole ticket, recall an accidental bump, and fire an "order ready" that writes back to the ticket status and can notify the pass or front-of-house. Modifiers and allergen notes are highlighted so nothing gets missed, and a scheduler event (a scheduler_events cron entry) reconciles any tickets whose POS document changed out-of-band, so the screen never drifts from ERPNext. State changes are exposed through whitelisted methods over the Frappe REST API, and every action is permission-gated with dedicated role profiles (Kitchen Staff, Expeditor, Kitchen Manager) so only the right people can void or recall. If a screen or the network drops, an optional KOT printing fallback keeps the line moving.
Because this is build-to-order, we start from your real kitchen: how many stations, which item groups route where, your target prep times, whether you run one brand or several under a cloud-kitchen pass. After a short scoping call ECOSIRE writes the app against Frappe/ERPNext v15 or v16, tests it on a staging copy of your site, runs UAT with your team, and then installs it on production with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. You receive the full source in a git repository, so nothing about the system is locked away from you.
Runs a kitchen with separate grill, fryer, cold and drinks stations and wants each screen to show only its own items, with expo seeing the whole pass — replacing printed KOTs and shouted callouts.
Operates several delivery brands out of one facility on shared ERPNext POS and needs paperless, brand-isolated ticket flow so orders from different brands never collide on the same board.
Owns the ERPNext deployment and wants a native Frappe app — proper DocTypes, doc events, REST-accessible methods and role permissions — rather than a fragile third-party integration they can't inspect or extend.
Needs a consistent, timer-driven kitchen workflow rolled out across outlets, with the source code in hand so the same KDS can be standardized and extended per location.
Compre la licencia en ecosire.com y descargue la aplicación ZIP de Kitchen Display System (KDS) for ERPNext desde el panel de su cuenta.
Extraiga el ZIP en la carpeta de aplicaciones de su banco o ejecute `bench get-app` con la ruta a la aplicación extraída.
Ejecute `bench --site SITE_NAME install-app APP_NAME` seguido de `bench migrar` para instalar Kitchen Display System (KDS) for ERPNext y aplicar su esquema.
Abra la configuración de licencia de ECOSIRE en su sitio y active su clave de licencia. Requiere las aplicaciones gratuitas ecosire_connect y ecosire_license_client.
| Criterio | ECOSIRE | Construcción personalizada | Competidor | Odoo Nativo |
|---|---|---|---|---|
| POS integration | Native `POS Invoice` doc-event hooks, streamed over Frappe realtime | Depends on your team's depth in Frappe hooks | Often generic sync, may not match your POS profile | |
| Multi-station routing | `KDS Station` DocType maps item groups to screens | Buildable but you design the schema yourself | Fixed routing model, hard to bend to your layout | |
| Prep timers | Color-coded green→amber→red against your target times | Whatever you have time to implement | Basic timers, limited configurability | |
| Bump bar / order-ready | Physical bump-bar + touchscreen with recall and ready-back | Hardware wiring and state left to you | Sometimes touchscreen-only, recall varies | |
| Cloud-kitchen brand isolation | Per-brand / POS-profile filtered station views | Possible with significant effort | Usually single-brand assumption | |
| Permissions | Dedicated role profiles for staff, expo and managers | You define and maintain the role model | Coarse or fixed roles | |
| Source ownership | Full git repo handover, you own and extend it | You own it but also carry all the build cost | Typically closed / license-locked | |
| Delivery model | Build-to-order, tested on staging, 2–4 weeks | Timeline depends on internal capacity | Instant install but generic fit |
This is a build-to-order product, not an instant download. After a short scoping call to lock your stations, routing rules and target prep times, typical delivery is 2–4 weeks from confirmed scope. That covers building the Frappe app, testing it on a staging copy of your ERPNext site, UAT with your team, and production install.
We build against Frappe/ERPNext v15 and v16. During scoping we confirm your exact version and POS setup so the app is written and tested for the site it will actually run on.
The app hooks `POS Invoice` doc events in `hooks.py`, so when an order is submitted or updated a `KDS Ticket` is created and streamed to the right station screens over the Frappe realtime websocket — no manual re-entry and no separate order source to keep in sync.
Yes. Routing is driven by `KDS Station` records that map ERPNext item groups to screens, applied by a server script. A grill line, fryer and drinks station each see only their items, and cloud kitchens can isolate views per brand or POS profile.
Every build includes a post-go-live support window for defect fixes and adjustments. Because you receive the full source in a git repository, you can also extend it yourself, and ECOSIRE can quote ongoing maintenance or version-upgrade work (for example an ERPNext v15→v16 move) separately.
We include an optional KOT printing fallback so the line keeps moving if a display or the network drops, and a scheduler reconciliation job re-syncs any ticket whose POS document changed while a screen was offline, so the board never drifts from ERPNext.
Yes. You receive the full app source in a git repository at handover, along with technical documentation of the DocTypes, doc events, whitelisted methods and scheduler jobs. Nothing is locked away — you own your version.
A real-time kitchen display that streams ERPNext POS orders straight to cook stations with color-coded prep timers, bump-bar controls and multi-station routing. ECOSIRE builds, installs and supports it as a native Frappe app after we scope your kitchen with you.