Most restaurants outgrow ERPNext's stock POS Profile and POS Invoice flow within weeks. Native ERPNext POS was designed for retail counters — it has no concept of a table, no floor plan, no way to fire a Kitchen Order Ticket to the grill versus the bar, and no split-bill or per-seat ordering. When a busy service has to be run through a retail cart, servers work around the system instead of in it: orders get scribbled on paper, the kitchen loses track of course timing, and by the end of the night the numbers in ERPNext no longer match what actually happened on the floor.

We build a proper Frappe application (installed on your bench with bench get-app / bench install-app, not a pile of customizations bolted onto core) that adds the restaurant layer ERPNext is missing while keeping every transaction inside ERPNext's real inventory and accounting engine. New DocTypes such as Restaurant Table, Floor Plan, Menu, Menu Item, Modifier Group, Combo and Kitchen Order Ticket model the front-of-house, and a touch-optimized POS screen (a Frappe Page / client script bundle) lets servers open a table, add items with modifiers, and send a KOT to the correct prep station. Each menu item maps to an ERPNext Item, so every sale still decrements stock, drives your Bill of Materials for recipes, and posts to the correct income and tax accounts — no reconciliation gymnastics.

Technically, the flow is enforced server-side rather than trusted to the browser. hooks.py doc events (on_submit, validate, on_update) fire KOT routing and consolidate a table's running orders into a single POS Invoice at checkout; whitelisted methods (@frappe.whitelist()) back the POS screen and expose a clean surface for KDS displays, delivery aggregators or a customer QR-order page over the Frappe REST API (/api/method/...). Split bills, discounts and multiple tender types (cash, card, wallet, UPI) are handled in server logic so totals and tax always tie out. Role Profiles and permission rules separate Server, Cashier, Kitchen and Manager access, and scheduler events (scheduler_events in hooks.py) handle end-of-day close, stale-cart cleanup and daily sales digests. Dine-in, takeaway and delivery each run as a distinct order mode with its own KOT template and, where needed, its own numbering series.

Because this is build-to-order, nothing ships blind. After a short scoping call we confirm your menu structure, station routing, tax setup and payment methods, then build against a version you pin — Frappe/ERPNext v15 or v16. You get the installable app source for that version, a staging install for UAT, a git repository handover, and a defined post-go-live support window. Typical delivery is one working week from confirmed scope, depending on how many outlets, stations and integrations (KDS hardware, delivery platforms, fiscal printers) are in play.