Dine-in restaurants running ERPNext hit a wall the moment they want guests to order from their own phones. ERPNext POS is built for a cashier or waiter standing at a terminal — there is no customer-facing menu, no per-table session, no self-service cart, and no way for a guest to trigger a POS Invoice or a Kitchen Display ticket without staff keying it in. Printed QR codes that just link to a PDF menu solve nothing: the order still gets shouted across the floor, re-typed at the till, and lost when it is busy. That gap — between a scanned table and a costed, tax-correct order sitting inside ERPNext — is exactly what this build closes.

ECOSIRE builds a proper Frappe app (installed on your bench, not a hosted third party) that adds a guest-facing ordering front end and the server-side plumbing to land every order cleanly in ERPNext. We model the domain as first-class DocTypes: a Table QR DocType generates a unique signed token per table, a Guest Order Session tracks an open table from first scan to settled bill, and menu items map to your existing Item records with modifiers stored as a linked child table so a "no onions, extra cheese" choice carries a real price delta. The scan opens a mobile web menu served from a Frappe website route; guests browse categories, photos, allergen tags and translated names, build a cart with modifiers, and submit. Submission calls a @frappe.whitelist(allow_guest=True) method that validates the table token, prices the line items server-side against ERPNext (never trusting the client), and creates the order under a locked-down role profile so a guest can write only their own session.

On the kitchen and billing side we wire the order into your real workflow with hooks.py doc events and server scripts: an accepted order emits a POS Invoice (or a draft order document you approve at the till, depending on your close-out preference) and a KDS/print ticket, updates the Guest Order Session state, and fires Frappe real-time events so the counter and kitchen screens refresh without a reload. Pay-at-table is handled by integrating a payment gateway of your choice — the guest pays from the phone, the gateway webhook hits a whitelisted endpoint, and on confirmation a server script marks the invoice paid and closes the session. A scheduler event sweeps abandoned sessions and reconciles any half-paid tables so nothing is left dangling. Client scripts and a small Frappe UI panel give your managers a live table board inside ERPNext Desk. Everything targets Frappe/ERPNext v15 and v16 and uses the standard REST API and permission system, so it survives upgrades instead of fighting them.

Because this is build-to-order, nothing ships until we agree scope. You are not downloading a generic app off a marketplace and hoping it fits — we start with a short scoping call, confirm your table layout, menu structure, tax/pricing rules, KDS setup and which payment gateway you use, then build against your ERPNext instance. Typical delivery is one working week from confirmed scope, depending on how many gateways, languages and edge cases (split bills, service charge, tips) are in play. We install and configure it on a staging site first, run UAT with your team, then cut over to production with a rollback plan and a post-go-live support window. You receive the full source, the git repository, technical and user documentation, and a training session for your floor and kitchen staff.