Most retailers hit the same wall a few weeks after go-live: the Odoo POS is a single trusted surface where any logged-in cashier can apply a discount, override a price, delete an order line, refund a paid receipt, or close the session and see the day's totals. Odoo core gives you a POS access group and a per-user cashier PIN, but it has no concept of "this cashier may sell but not discount" or "only a shift lead may process refunds." Once shrinkage, unauthorized markdowns, or end-of-day discrepancies start showing up, managers are left reconciling the damage after the fact instead of preventing it at the register. This is where the native model runs out of road — the granularity you need lives below the level Odoo exposes out of the box.

POS Access Rights by Employee is a made-to-order module ECOSIRE builds to close that gap. We introduce role-driven permission flags — modeled as boolean and selection fields on hr.employee and/or a dedicated pos.access.profile model, secured through ir.model.access.csv and record rules — that map each capability (apply discount, edit unit price, remove/void a line, delete a whole order, issue a refund, reprint a receipt, open the cash drawer, apply a manual loyalty adjustment, change customer, close the session, view session totals) to an employee or a reusable profile. The POS front end is where it becomes real: we extend the OWL point-of-sale components and patch the relevant action handlers so a blocked action is either hidden, disabled, or gated behind a manager-approval popup, rather than silently failing. Because Odoo evaluates the cashier at login via the employee PIN, the correct permission set loads the moment a cashier signs into the session, and every gated attempt can be written to a log for later review.

Technically, the module ships as a clean __manifest__.py with pinned dependencies on point_of_sale (and pos_hr where employee-mode is used), server-side models with @api.depends computes where a permission is derived rather than stored, XML/OWL view extensions for the POS UI plus back-office configuration views, and optional automated actions or a lightweight audit model to record overrides. Where a manager override is required, we implement the standard supervisor-PIN challenge so an authorized employee can approve a one-off exception without handing over their own session. Everything is enforced on the server side as well as the client, so the rules cannot be bypassed by a crafted JSON-RPC call — the UI gating is convenience, the record rules and access CSV are the real boundary. We build and validate against Odoo 17.0, 18.0, and 19.0, and we account for Community vs Enterprise differences (for example, Enterprise-only POS features such as certain restaurant/loyalty flows) so the permission surface matches exactly what your edition actually exposes.

Delivery is build-to-order: nothing is downloaded off the shelf. It starts with a short scoping call to map your roles to concrete POS capabilities, confirm your edition and version, and agree on override behavior. We then build your version, validate it through UAT on a staging database, and install it on production with a documented rollback plan. Typical delivery is one working week from confirmed scope, depending on how many roles and edge cases you need. Pricing starts from $999 (indicative, single-company base scope); additional roles, multi-company or multi-shop permission matrices, deeper audit/reporting requirements, and integrations with existing HR or loyalty customizations increase the quoted scope.