Skip to main content

POS Returns & Refunds

Purpose​

POS Returns & Refunds extends the native POS refund flow with return policies, controlled reasons, manager authorization and stock disposition. It reserves the remaining returnable quantity before payment, then links the accepted refund to a read-only return case. Cashiers still retrieve an original paid sale and use normal POS checkout.

The case records the original and return orders, quantities, reasons, approval, stock documents and financial snapshots. It is useful when staff must distinguish an item suitable for resale from one requiring inspection or disposal.

Before you start​

Install corvus_pos_return_disposition for the exact Odoo major version. The reviewed 19.0 package requires Point of Sale, Inventory and POS Employees (point_of_sale, stock, pos_hr). The native dependencies do not require Enterprise, so it is intended for Community and Enterprise installations with those addons. Use hosting that permits server addons.

This guide is source-reviewed, primarily for 19.0; no installation or return transaction was executed during this review. Configure the store's approved return policy and practice in a test database before processing real refunds.

Access and roles​

Point of Sale Users can read applicable policies and reasons and their permitted return cases. Case visibility follows allowed companies and assigned POS configurations or session ownership.

Point of Sale Administrators/Managers configure policies and reasons, inspect analysis, export results, and review emergency drafts. A protected return needs an eligible manager employee and server-validated PIN. The cashier who completes the return cannot approve their own protected return. Audit snapshots cannot be edited or deleted as ordinary records.

Setup and menu​

  1. Open Point of Sale → Configuration → Return Policies. Create an active company policy. Set its return window, allowed dispositions, proof/evidence requirements and manager amount threshold. Use scope fields when the policy should apply only to certain POS configurations, customers, products, categories or original payment methods. Higher priority policies are considered first.
  2. Open Return Reasons. Maintain ordered reasons and any required note, evidence reference, manager approval or default disposition. Included reason examples can be adapted or archived.
  3. Open each POS configuration and find Controlled POS Returns. Set Default Return Policy, Return Quarantine Location, optional Return Scrap Location, and Return Reservation Minutes. Quarantine must be an internal location compatible with the POS company.
  4. If charging the configured percentage fee, select a Restocking Fee Product and check the fee policy. The configuration restricts this to a POS-available service product.
  5. On relevant products, set POS Return Rule: Returnable, Exchange Only, or Final Sale / No Return. Configure cashier employee assignments and manager authorization before opening the POS.

Workflow​

  1. In the POS Orders/ticket screen, retrieve the original paid order and select the positive sale lines and quantities to refund. The server accounts for prior native refunds and live reservations from other terminals.
  2. Complete Return details. Choose a Reason, Stock disposition and any required Return note or Evidence reference. Evidence is a reference to a photo, inspection or receipt; this dialog does not upload a binary file.
  3. Select Original order / receipt shown or No receipt — manager exception. A no-receipt exception still refers to the selected original sale. Enter the exception justification and manager authentication when required, then choose Apply return details.
  4. The server checks policy, remaining quantity, lots/serials and authorization and creates a reservation before payment. A tracked return must identify lots or serials recorded on the original line. A serialized reservation binds one unit to one serial.
  5. For Exchange Only, add a replacement sale line to the same cart. Check the negative refund lines, any replacement and the configured fee. Do not change reserved return quantities, prices, discounts, taxes or identity after authorization.
  6. Complete the native POS payment flow. The server checks the reservation again. Accepted storable returns produce linked native stock moves; quarantine uses its configured location, and scrap disposition produces a linked scrap document after the return movement.
  7. Open Return Cases to inspect the result. Managers use Reporting → Return & Disposition Analysis and Export Return Analysis for accepted returns. The export offers CSV or XLSX with date filters. The case also has a return-authorization PDF report.

Practice scenario​

In an authorized test database, sell two fictional “Harbor Desk Lamps.” Configure a 30-day policy and a “Damaged packaging” reason with a quarantine disposition. Request one lamp back using the original sale. The expected sequence is a reservation, a native refund and an accepted case linked to the quarantine movement. Try a quantity above the remaining amount and expect rejection. This exercise is source-derived and has not been executed in this review.

Troubleshooting and limitations​

No active policy applies: review policy company, active state, priority, scope and the POS default. A default does not make an otherwise inapplicable policy valid.

Remaining quantity exceeded: another refund or reservation has used part of the sale. Refresh the original order and reassess the quantity; do not create an unrelated negative line.

Reservation missing or expired: return to Orders and reserve again before payment. A reservation is temporary; the default duration is 15 minutes.

Manager authentication failed: check the eligible manager, PIN and employee assignment. Final-sale and expired-window returns are protected exceptions, not unconditional approvals.

Offline: ordinary controlled returns require online authorization. If Allow Offline Emergency Drafts is enabled, a logged-in POS manager may retain a non-payable local draft. Reconnection synchronizes native orders first and submits drafts for manager review. Reviewed / Ready for Online Retry still requires a fresh online return; review creates no refund or stock movement.

This module does not provide portal RMA, repair orders, supplier returns, warranty claims or payment-provider reversal guarantees. A failed required native stock return can roll back acceptance; inspect the stock error before retrying.

Catalogue-qualified versions are 15.0, 16.0, 18.0, 19.0 and 20.0. Odoo 15.0 additionally requires base_sparse_field; 20.0 additionally declares pos_stock. Employee access fields differ: 15.0–16.0 use their older assignment model, 18.0 uses basic/advanced employees, and 19.0 includes minimal employees. Configuration layouts also differ. Only the 19.0 end-to-end source workflow is described here; no all-version runtime result is claimed.