When several staff share a single Point of Sale terminal, cash accountability quietly breaks down. Odoo's native POS session model attributes an entire session to whoever opened it, so a drawer that comes up short at end of day cannot be traced to the person who was actually ringing sales. Standard Odoo lets a cashier see the expected closing balance before they count, which defeats the whole point of a reconciliation, and it offers no per-cashier sales attribution, no forced manager sign-off on refunds or voids, and no immutable record of who did what. For a multi-staff store, that is not a reporting inconvenience — it is a shrinkage and trust problem that Odoo core simply was not designed to solve.

ECOSIRE builds a POS cashier management and shift-control extension that closes those gaps at the data-model level rather than papering over them in the UI. We add a first-class cashier concept with fast PIN or badge login and switch directly inside the OWN-based POS screen, so a new cashier can take the drawer without ending the technical pos.session. Under the hood this is a set of models.Model extensions — a cashier-shift model linked to pos.session and res.users, with fields.Monetary opening float, counted amounts, computed variance via @api.depends, and fields.One2many lines capturing individual order attribution. Every refund, void, and manual discount is routed through a manager-approval flow backed by ir.model.access.csv rules plus record rules, so an approval cannot be self-granted or edited after the fact.

The reconciliation itself is genuinely blind: at shift close the cashier enters a denomination-level count into the POS UI without ever seeing the system-expected figure, the module computes the variance server-side, and a QWeb report renders a signed shift-close statement showing float, gross sales by payment method, refunds, discounts given, expected versus counted, and the over/short delta. Per-cashier dashboards and pivot views surface sales, discount rates, and variance trends over time, and everything is exposed through Odoo's XML-RPC/JSON-RPC API so head-office reporting or a BI tool can pull shift data without touching the database directly. Automated actions can flag a shift whose variance exceeds a configurable threshold and notify a supervisor.

Because your POS layer is often the most customized part of an Odoo deployment, this is a build-to-order engagement, not a generic download. We start from your real workflow — how many terminals, whether you run Community or Enterprise (the Enterprise POS restaurant/self-order features change how we hook the frontend), your payment methods, and your cash-handling policy — then build against your exact Odoo version. The module ships clean against Odoo 17.0, 18.0, and 19.0, respecting each release's POS OWL architecture. Typical delivery is one working week from confirmed scope, and every build is validated on a staging copy of your database before it touches production, with a documented rollback path and a post-go-live support window included.