Independent restaurants, cafes and QSRs that run ERPNext for accounting and inventory usually hit a wall the moment they try to run the floor on it. ERPNext's native Point of Sale is designed for retail counter checkout: one cart, one customer, pay and print. It has no concept of a table that stays "open" across three rounds of orders, no floor plan, no kitchen ticket that fires to the grill station while the bar station gets only the drinks, and no graceful behaviour when the internet drops mid-service. Waitstaff end up scribbling on paper and re-keying at a terminal, kitchens miss modifiers, and the bill total never reconciles cleanly back to a Sales Invoice. That gap is exactly what this product fills.

We build a dedicated Frappe app (its own module, DocTypes and role profiles) that sits on your ERPNext instance rather than fighting it. The POS runs as a full-screen touch interface: the server picks a table from a visual floor plan whose status (free / occupied / billed) updates in real time, opens or resumes that table's running order, and adds items with modifiers and course timing. Sending an order writes a KOT DocType and routes print jobs per production center — hot kitchen, cold station, bar — using ERPNext Print Formats bound to the right network or Bluetooth printer, so each station only sees its own lines. Split, merge and transfer are first-class operations: split a table's items across several bills, merge two tables into one cheque, or move a running order to another table, each action recorded on the source documents for a clean audit trail. When the order is settled it posts a real ERPNext POS Invoice / Sales Invoice against the correct POS Profile, warehouse and payment mode, so inventory, tax and the general ledger stay correct with no manual re-entry.

Technically it is built the ERPNext-native way. Business rules live in server scripts and hooks.py document events (on_submit, validate, before_cancel) so KOT firing, stock deduction and invoice posting are enforced on the server, not just in the browser. The touch UI is driven by client scripts and a Frappe page/Portal view; the app exposes whitelisted methods and uses the Frappe REST API so handheld devices and the floor terminal talk to the same backend. Offline-first billing keeps a local queue when connectivity drops and auto-syncs on reconnect with idempotent keys so nothing double-posts, and a scheduler event reconciles any stragglers and closes stale open tables at end of day. Permissions are handled with Frappe role profiles (cashier, waiter, kitchen, manager) so voids, discounts and bill reprints are gated to the right people. The app targets Frappe/ERPNext v15 and v16.

Because this is build-to-order, you are not downloading a generic app and hoping it fits. After a short scoping call we confirm your exact floor layout, station-to-printer mapping, order modes, tax and rounding rules, and payment methods, then build against your requirements, run UAT on a staging copy of your site, and install on production with a rollback plan. Typical delivery is one working week from confirmed scope depending on how many stations, printers and edge cases are involved. You receive the full source code for your version and the git repository so you are never locked in.