A made-to-order Odoo Point of Sale extension that forces a password or manager PIN before any refund, return, or negative-quantity line is authorized. ECOSIRE builds it to your workflow, installs it, and supports it. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
Uygulama manifestosu
İş akışınıza göre tasarlandı
A made-to-order Odoo Point of Sale extension that forces a password or manager PIN before any refund, return, or negative-quantity line is authorized. ECOSIRE builds it to your workflow, installs it, and supports it.
Kendiniz kurmanıza gerek yok — ECOSIRE tarafından geliştirilen, kurulan ve desteklenen çalışır bir uygulama.
Tek seferlik geliştirme fiyatıyla başlayın. Kapsamı başlangıçta sizinle birlikte belirleriz.
ECOSIRE, Odoo ortamınızda geliştirir, yapılandırır ve kurar.
Yaklaşık 2–4 haftada yayına alırsınız; lansman sonrası bir destek süresi de dahildir.
On a busy POS floor, refunds are the softest point in your cash controls. Odoo lets any logged-in cashier open a refund order, add a negative-quantity line, and hand cash back without a second signature — and once the order is validated, the money is out of the drawer and reconciling it away becomes a manual accounting chore. Native Odoo POS ships cashier login and a manager-approval prompt for a small set of hard-coded actions (discount limits, price changes, deleting an order in some editions), but there is no built-in gate specifically on the refund / return / negative-line path. Teams that run Odoo across multiple registers and shifts feel this most: shrinkage from "friendly" refunds, disputed returns, and no clean audit trail of who approved what.
We build a Point of Sale extension that inserts a password (or manager PIN) challenge at the exact moment a refund is initiated. Technically, the work lives mostly in the POS frontend: an OWL override of the refund/return action and the "Refund" button on the ticket and product screens, wired so that pressing it opens a modal that must be cleared before the order flow continues. The entered credential is validated against a server endpoint we expose through a small Python model (models.Model) — never checked client-side — so the secret and the authorization logic stay on the server. Depending on your policy we validate against the employee/user password, a dedicated refund PIN configured per pos.config, or a specific set of authorizer users; a compute field and @api.depends logic can drive who is allowed to approve. We also handle the offline case: because POS runs against a cached datastore, we define the fallback behavior (block, or allow-and-flag for review) explicitly with you rather than leaving it to chance.
Beyond the gate itself, we make the control auditable and configurable. A settings section under Point of Sale (view XML plus res.config.settings fields) lets you toggle the requirement per register, choose the credential type, set a maximum refund amount that can be approved at cashier level before escalating, and decide whether partial-line refunds are covered too. Every authorized refund writes an audit record — approver, cashier, order reference, amount, timestamp — stored on a dedicated model with ir.model.access.csv rules so only managers can read the log, and surfaced through a simple list/search view and an optional QWeb report for shift reconciliation. Security is enforced with access rights and record rules, not just hidden UI, so a determined user cannot bypass the check by calling the ORM directly over the JSON-RPC/XML-RPC API.
Delivery is build-to-order. After a short scoping call we confirm your exact policy (credential type, per-register rules, amount thresholds, offline behavior, audit needs) and your target Odoo version, then build against Odoo 17.0, 18.0, or 19.0 for Community or Enterprise. You get the module on a staging environment for UAT first, then installation on production with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company setups, many-register rollouts, deeper approval hierarchies, and data migration of historical refund records increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise on the invoice.
Runs multiple registers and shifts and needs to stop unauthorized refunds at the point of sale while keeping a clean audit trail of who approved what, without slowing down legitimate returns.
Owns cash-handling controls and shrinkage numbers. Wants refunds gated by a manager credential, a per-shift approval log, and reporting that ties every refund back to an authorizer for reconciliation.
Maintains the Odoo instance and wants an upgrade-safe extension that uses proper inheritance, `ir.model.access.csv` security, and record rules — enforced server-side so it cannot be bypassed via the API — across Community or Enterprise.
Operates several outlets on one Odoo database and needs per-register or per-company refund policies, so head-office rules apply consistently while individual stores keep the flexibility they need.
| Kriter | ECOSIRE | Özel Yapı | Rakip | Odoo Yerlisi |
|---|---|---|---|---|
| Refund-specific password gate | Built exactly for the refund/return/negative-line path with a server-validated challenge | Possible but you scope and build it yourself | Often gates only some actions or the whole order, not refunds precisely | |
| Server-side enforcement | Validated on the server and enforced with access rights and record rules | Depends entirely on your developer's rigor | Varies; some check only in the UI and can be bypassed via API | |
| Audit trail of approvals | Dedicated manager-only audit model plus optional QWeb report | Only if you specify and build it | Rarely included or limited | |
| Per-register / per-company rules | Configurable per `pos.config` and scoped by company where needed | Achievable with extra effort | Often global on/off only | |
| Offline behavior | Explicitly defined with you (block or allow-and-flag) | Must be designed deliberately or it breaks | Frequently undefined or ignored | |
| Fit to your workflow | Built to your exact policy after a scoping call | Fully bespoke but on your budget and timeline | Fixed feature set; you adapt to it | |
| Support and handover | Post-go-live support window plus full git repo and docs | Whatever you arrange internally | Vendor-dependent, often ticket-based only | |
| Upgrade safety | Inheritance-based, upgrade-safe, built for your Odoo version | Depends on how it was written | May lag new Odoo releases |
This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope. After the scoping call we agree the exact policy and your Odoo version, build against it, run UAT on staging, then install on production. Larger multi-company or multi-register rollouts can extend the timeline, which we state in the quote.
Pricing starts from $249 as an indicative figure for a single-company base scope. The real number depends on credential type, per-register rules, approval hierarchy, offline behavior, and any migration of historical refund data. You get a fixed written quote after a short scoping call — no surprises on the invoice.
Every build includes a post-go-live support window for defect fixes and questions. Because you receive the full source and git repository, your own team can maintain it too. Version upgrades (for example moving from Odoo 18.0 to 19.0) or new features are scoped separately as a follow-on engagement.
No. The password is validated server-side and the refund permission is enforced with access rights and record rules at the ORM level, not just hidden in the UI. A user cannot skip the gate by calling the JSON-RPC/XML-RPC API or a crafted client request.
Yes. We build for Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. POS refund flows differ slightly between editions and versions, so we confirm your exact target during scoping and build specifically against it.
Odoo POS runs against a cached datastore and can operate offline. We define the offline behavior with you explicitly — either hard-block refunds until connectivity returns, or allow them and flag each one for manager review once the register is back online — so there is no undefined edge case.
Yes. Rules are configurable per `pos.config` (register) and can be scoped by company for multi-store databases, so head office can set thresholds while individual outlets keep the flexibility they need.
A made-to-order Odoo Point of Sale extension that forces a password or manager PIN before any refund, return, or negative-quantity line is authorized. ECOSIRE builds it to your workflow, installs it, and supports it.