At the counter, ERPNext POS shows the cashier a full cart, but the customer sees nothing until the receipt prints. That opacity costs trust: shoppers can't confirm items and prices as they're scanned, disputes surface after payment, and the idle second screen every retailer already owns shows a Windows desktop instead of your promotions. ERPNext core has no customer-facing display surface — the POS Awesomebar and cart live entirely inside the cashier's Point of Sale page, there's no read-only mirrored view, and nothing publishes cart state to an external screen in real time. This is where a native ERPNext build, rather than a bolt-on kiosk, pays off.

We build a proper Frappe app (ecosire_cfd) installed onto your bench alongside ERPNext, not a scraped overlay. The core is a lightweight public display route served by the Frappe web framework that subscribes to POS events over the built-in socket.io realtime channel. A client script injected into the Point of Sale page publishes cart mutations — item add/remove, quantity change, applied Pricing Rule discounts, coupon codes, and net/tax/grand totals — via frappe.realtime.publish scoped to a per-terminal room derived from the POS Profile. The display route renders the itemized cart, a running total with a full tax and discount breakdown computed from the same Sales Taxes and Charges logic ERPNext uses, and swaps to promotional/ad content between sales when the terminal is idle. Nothing is duplicated or re-keyed: the display reflects exactly what the cashier's POS state holds.

On checkout, hooks.py doc events on POS Invoice (on_submit) generate a digital receipt and render a QR code on the customer screen — linking to a hosted receipt or feeding a loyalty enrolment flow — plus an optional tip-prompt and a short feedback capture (rating/comment) written back to a custom DocType so the data stays queryable inside ERPNext. Content, ad rotation, per-terminal pairing and idle timeouts are governed by a CFD Settings DocType with its own permissions, and a scheduler event housekeeps stale display sessions. Everything is exposed through whitelisted methods and the standard Frappe REST API, guarded by role profiles so only the POS terminal role can drive a given display. It runs on ERPNext v15 and v16.

Because this is build-to-order, we start from your actual checkout flow rather than shipping a fixed product. After a short scoping call we confirm the terminal hardware, branding, promo/loyalty and tip requirements, then build against your scope. Typical delivery is one working week from confirmed scope. You get the installable source for your version, staged UAT on a copy of your site with a rollback plan, install and configuration on your environment, documentation, a training session, a git repo handover, and a post-go-live support window. No instant download, no generic template — a display built for your ERPNext POS and supported by the team that wrote it.