Les détails du produit sont affichés en anglais. Traductions à venir.
Faits en bref
- Prix
- $199.00 USD
- Versions Odoo
- 17, 18, 19
- Temps d'installation
- 30 minutes
- Licence
- Perpétuel unique
- Langues
- 11 langues
Achat unique
POS Cashier Management & Shift Control
A build-to-order Odoo POS extension that gives every cashier their own login, shift, and cash-drawer accountability — with blind-close counts, variance reporting, and a tamper-evident audit trail. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 environment.
$199.00USD
Aucun paiement maintenant. Ceci envoie une demande de devis à notre équipe — nous vous recontacterons par e-mail avec les tarifs et les prochaines étapes.
Fonctionnalités clés
PIN- and RFID/badge-based cashier login with fast in-session switch, implemented in the POS OWL frontend without ending the underlying pos.session
First-class cashier-shift model extending pos.session and linked to res.users, storing opening float, counted amounts, and computed variance
Blind cash-drawer close: cashiers enter a denomination-level count with the system-expected balance hidden until variance is computed server-side
Server-side variance calculation via compute methods with @api.depends, so the over/short figure cannot be edited or pre-seen by the counting cashier
Per-cashier sales, refund, and discount attribution captured as One2many lines against each order, not just the session opener
Manager approval workflow for refunds, voids, and manual discounts, gated by ir.model.access.csv plus record rules so approvals cannot be self-granted
QWeb signed shift-close report: float, gross by payment method, refunds, discounts, expected vs counted, and over/short delta
Per-cashier pivot and dashboard views for variance trend, average discount rate, and refund frequency over any date range
Configurable variance threshold with an automated action that flags out-of-tolerance shifts and notifies a supervisor
Denomination-level cash count grid (notes and coins) with running total, matched to your local currency configuration
Immutable audit trail: every login, drawer open, approval, and close is written as a tamper-evident log record tied to user and timestamp
Cash-in/cash-out (paid-in / paid-out) movements recorded per shift and reconciled into the closing variance
XML-RPC / JSON-RPC access to shift and variance records for head-office reporting and BI integration
Multi-terminal and multi-store aware, so one physical drawer handed between cashiers reconciles cleanly across shift handovers
À propos de ce produit
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.
Pourquoi choisir POS Cashier Management & Shift Control
PIN- and RFID/badge-based cashier login with fast in-session switch, implemented in the POS OWL frontend without ending the underlying pos.session
First-class cashier-shift model extending pos.session and linked to res.users, storing opening float, counted amounts, and computed variance
Blind cash-drawer close: cashiers enter a denomination-level count with the system-expected balance hidden until variance is computed server-side
Server-side variance calculation via compute methods with @api.depends, so the over/short figure cannot be edited or pre-seen by the counting cashier
Per-cashier sales, refund, and discount attribution captured as One2many lines against each order, not just the session opener
Manager approval workflow for refunds, voids, and manual discounts, gated by ir.model.access.csv plus record rules so approvals cannot be self-granted
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 2–4 weeks 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.
Ce que vous obtenez
- Installable module source code built and tested against your exact Odoo edition and version (17.0, 18.0, or 19.0)
- Installation and configuration on your environment, including POS payment-method and denomination setup
- Technical documentation: data model, security rules, compute logic, and XML-RPC/JSON-RPC endpoints
- End-user guide plus a live training session for cashiers and managers on login, shift close, and approvals
- UAT on a staging copy of your database with a documented, tested rollback plan before production cutover
- Post-go-live support window for defect fixes and configuration adjustments
- Private git repository handover with full commit history and tagged release
- Version-compatibility notes covering Community vs Enterprise POS differences and future upgrade guidance
Pour qui c'est
Multi-Staff Retail Store Owner
Runs one or more shops where several cashiers share terminals across shifts. Needs to know exactly who was on the drawer when it came up short, and wants shrinkage-reducing controls without slowing the checkout line.
Retail / Restaurant Operations Manager
Responsible for daily cash reconciliation across locations. Wants blind counts, forced sign-off on refunds and voids, and per-cashier variance trends to spot patterns before they become losses.
Finance Controller
Needs trustworthy, auditable cash figures flowing from POS into accounting. Values the signed shift-close report, the immutable audit trail, and API access to pull shift data into consolidated reporting.
Franchise or Multi-Location Operator
Oversees many terminals across sites and needs consistent cashier accountability and cash-control policy enforced identically everywhere, with head-office visibility via the JSON-RPC API.
Aperçu de l'installation
Télécharger depuis ECOSIRE
Achetez la licence sur ecosire.com et téléchargez le module ZIP POS Cashier Management & Shift Control depuis le tableau de bord de votre compte.
Télécharger sur Odoo
Extrayez le ZIP dans votre dossier de modules complémentaires personnalisés Odoo sur le serveur (ou téléchargez-le via Applications > Installer à partir du fichier sur Odoo.sh / runbot).
Installer le module
Activez le mode développeur, ouvrez les applications, cliquez sur Mettre à jour la liste des applications, recherchez POS Cashier Management & Shift Control et appuyez sur Installer.
Configurer les paramètres
Ouvrez le nouveau menu, collez votre clé de licence ECOSIRE, connectez toutes les informations d'identification externes (Shopify, Amazon, Stripe, etc.) et enregistrez.
Vérifier et mettre en ligne
Exécutez le test de connexion intégré, synchronisez vos 10 premiers enregistrements et planifiez le cron récurrent. Contactez le support si quelque chose échoue.
Comment POS Cashier Management & Shift Control se compare
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Odoo natif |
|---|---|---|---|---|
| Per-cashier accountability | First-class cashier model attributing every order, refund, and discount to the individual | Achievable but you design the data model from scratch | Often only tags the session opener, not each cashier | |
| Blind drawer close | Expected balance hidden; variance computed server-side after count | Possible if you build the compute and UI hiding yourself | Varies; many show expected balance before counting | |
| Refund/void approval control | Manager sign-off gated by access rights and record rules | You build and secure the approval flow yourself | Sometimes a simple flag, rarely rule-enforced | |
| Audit trail | Immutable log of login, drawer open, approval, and close per user/timestamp | Depends entirely on what you choose to log | Basic logging, often editable | |
| Fit to your workflow | Built to your terminals, payment methods, and cash policy | Fully bespoke but you own all design decisions and risk | Fixed feature set; you adapt to it | |
| Odoo version support | Built and tested against your exact 17.0 / 18.0 / 19.0 edition | Whatever you target and test yourself | Often lags new releases or drops old ones | |
| Reporting & BI access | Documented XML-RPC / JSON-RPC access to shift and variance data | You expose and document the API surface yourself | Limited; may not expose shift-level data | |
| Support & ownership | Post-go-live support window plus full git repo handover | In-house or contractor dependent | Vendor-dependent, per-seat or subscription |
Foire aux questions sur POS Cashier Management & Shift Control
+How long does delivery take?
This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope. After a short scoping call we agree on your exact requirements, build against your Odoo version and edition, validate on a staging copy of your database, and then schedule the production cutover with you.
+Does this work with Odoo Community, or do I need Enterprise?
It works with both. The core cashier-shift, blind-close, and audit logic runs on Community and Enterprise alike. Enterprise POS adds restaurant, self-order, and some payment-terminal features that change how we hook the frontend, so we confirm your edition during scoping and build accordingly. We support Odoo 17.0, 18.0, and 19.0.
+What does the blind cash-drawer close actually mean?
At shift close the cashier enters a denomination-level count of what is physically in the drawer without seeing the system-expected balance. The module computes the variance server-side after the count is submitted, so the cashier cannot adjust their count to match the expected figure. The over/short delta and a signed QWeb statement are produced automatically.
+Can we integrate shift and variance data with our own reporting or BI tools?
Yes. All shift, cashier, and variance records are exposed through Odoo's XML-RPC and JSON-RPC API, so head-office reporting, a data warehouse, or a BI tool such as Power BI can pull the data without direct database access. We document the relevant models and fields as part of the handover.
+How do refund and void approvals stay secure?
Refunds, voids, and manual discounts route through a manager-approval step enforced by ir.model.access.csv access rights plus record rules. A cashier cannot approve their own transaction, and approval records are written to an immutable audit trail tied to user and timestamp, so they cannot be edited or deleted after the fact.
+What about support and future Odoo upgrades?
Every engagement includes a post-go-live support window for defect fixes and configuration tweaks. Because you receive the full git repository with tagged releases, you own the code. When you later upgrade Odoo versions we can provide a migration engagement to port and re-test the module against the new release.
+Will this slow down checkout at busy times?
No. Cashier switching uses fast PIN or badge login inside the existing POS screen without ending the technical session, and the blind count only happens at shift close. The controls are designed around real checkout throughput, and we tune them during UAT against your actual peak-hour workflow.
Modules associés
Demander un devis
POS Cashier Management & Shift Control
A build-to-order Odoo POS extension that gives every cashier their own login, shift, and cash-drawer accountability — with blind-close counts, variance reporting, and a tamper-evident audit trail. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 environment.
- PIN- and RFID/badge-based cashier login with fast in-session switch, implemented in the POS OWL frontend without ending the underlying pos.session
- First-class cashier-shift model extending pos.session and linked to res.users, storing opening float, counted amounts, and computed variance
- Blind cash-drawer close: cashiers enter a denomination-level count with the system-expected balance hidden until variance is computed server-side
- Server-side variance calculation via compute methods with @api.depends, so the over/short figure cannot be edited or pre-seen by the counting cashier