Multi-cashier retail and restaurant operations bleed cash through the gaps ERPNext core leaves at the till. Native ERPNext ships a POS Opening Entry and POS Closing Entry, but the closing screen pre-fills the expected cash from POS Invoice totals — the cashier sees the number they are supposed to hit before they count the drawer. There is no enforced opening float per denomination, no paid-in/paid-out log for petty cash movements mid-shift, no blind count, and no structured over/short trail you can report on by cashier or terminal. For a business running several tills across shifts, that means shrinkage is invisible until month-end and there is no accountability chain when a drawer comes up short.

ECOSIRE builds pos_shift_cash, a proper Frappe app (its own module, DocTypes, and hooks.py) installed onto your bench alongside ERPNext. At its core is a Cashier Shift DocType that a cashier opens with a denomination-wise opening float (a Cash Denomination child table capturing note/coin counts that roll up to the float total), links to the assigned POS Profile and terminal, and closes with a genuinely blind count — the expected-cash field is hidden by a client script and permission-level (permlevel) restriction until after the physical count is submitted, so the counter never sees the target. A Cash Movement DocType records every paid-in and paid-out event during the shift with a reason, category, and the operating user, keeping petty-cash and drops out of sales figures.

Technically, the logic lives where Frappe expects it. Server-side validate and on_submit controller methods (registered through doc_events in hooks.py) compute over/short as counted minus expected, apply your configured tolerance threshold, and flag variances that breach it for supervisor review. Denomination roll-ups and float carry-forward are enforced server-side so they can't be bypassed from the client. Whitelisted methods (@frappe.whitelist()) expose the shift open/close and cash-movement actions to the POS UI and to the Frappe REST API (/api/method/...) for any integration or hardware you use. A scheduler event can auto-flag shifts left open past a cutoff and notify a supervisor. Access is governed by dedicated Role Profiles — Cashier, Shift Supervisor, Finance — with field-level permlevel locks so only supervisors can approve a flagged variance or edit an opening float after submission.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call to map your POS Profiles, terminals, shift patterns, denomination set and currency, tolerance rules, and approval chain. We then build against your ERPNext version — Frappe/ERPNext v15 or v16 — on a staging bench, run UAT with your real terminals and cashiers, and hand over installable source, a git repository, and documentation. Typical delivery is one working week from confirmed scope, and every install includes a post-go-live support window plus a tested rollback plan.