Short answer: With the After-Sales options enabled on a Helpdesk team, a ticket can start a refund, a coupon, a return, a repair order or a field intervention, each from its own button. Each button leaves a smart button on the ticket, so the ticket becomes the index of the whole case. The Under Warranty box on a repair order does not test eligibility; it only zeroes the price. Someone has to decide that first.
Applies to
- Odoo version: Odoo 19. The after-sales page in the 20.0 documentation differs in one place: Field Service is described as planning an intervention through the Planning app, ending in a Scheduled smart button. The refund, coupon, return and repair sections read the same.
- Edition: Helpdesk is Enterprise only. The
repair.ordermodel is in the public 19.0 repository. - Apps: Helpdesk plus whichever of Accounting, Sales, Inventory, Repairs and eCommerce the options need. The documentation warns that enabling an option may install extra modules.
What should the ticket hold before anything moves?
Most of the work is making the ticket usable as a starting point. The after-sales forms read from it: the refund pop-up pulls in the Sales Order if one is on the ticket, and uses the ticket’s Product to narrow the sales orders, deliveries and invoices it offers. For tracked products there is also a Lot/Serial Number.
That means the first agent action, before any button, is to link the right customer, product and order. If those are missing, later steps either offer too many choices or offer none. The Return button, for example, only appears if the customer has a recorded delivery.
Who decides whether it is covered by warranty?
You do, or your policy does. On the repair order, Under Warranty is a checkbox. The 19.0 source help text says that if ticked, the sales price is set to zero for products transferred from the repair order. There is no date comparison or eligibility rule behind it.
So the decision has to be recorded somewhere visible, ideally in the ticket chatter, before the box is ticked. If your business needs a rule such as “within N months of delivery”, that is custom logic, and I would put it in an explicit check rather than hide it in a default.
How does the physical return fit in?
Click Return on the ticket. The pop-up asks for a Sales Order or Delivery to Return, with the quantity defaulting to what was validated on the delivery, and a Return Location. Return creates a reverse transfer for the incoming goods. Return for Exchange also creates the outgoing delivery of a replacement. A Return smart button appears on the ticket.
A repair order can then point to that return. On the order, the Return field holds the return from which the product comes. In the source, that field (picking_id) is limited to transfers that are returns, which keeps the chain consistent: delivery, return transfer, repair.
What happens in the repair order?
The Repair button opens a form with Customer, Product to Repair, Lot/Serial, Return, Under Warranty, Scheduled Date, Responsible and Tags. Parts go on the Parts tab, notes for the workshop on Repair Notes. Confirm Repair confirms it, or Create Quotation prepares a quote for a paid repair. A Repairs smart button links back to the ticket.
The documentation adds that the user can open the repair order from that smart button even without access rights to the Repairs app. That is convenient for support agents, but it also means access control on the ticket matters more.
Where do the financial records come from?
The Refund button needs a posted invoice. Choose the invoices to refund, the journal and a reversal date. Reverse creates a draft credit note that you can edit, which also suits a partial refund. Reverse and Create Invoice posts the credit note and creates a draft invoice copy. A Credit Notes smart button appears afterwards.
When can the ticket close?
Not when the customer says thank you. I would close when the stock, repair and accounting documents behind the ticket are finished: the returned item received, the repair done or the replacement sent, and any credit note posted. Folded stages mark a ticket as closed, so one stage called Awaiting Warehouse before Solved keeps the board honest.
When it fits and when it doesn’t
This flow fits a business that sells tracked physical goods through Odoo and repairs or exchanges them itself. It does not fit when warranty work is done by a third party outside Odoo, or when delivery history lives in another system. In that case the buttons have no records to work from.
A worked example
An online e-bike seller receives a ticket about a battery that no longer holds charge. The agent links the sales order and product, and a manager confirms the bike is covered. The agent clicks Return with the serial number, then Repair on the returned item, ticking Under Warranty and adding a replacement cell on the Parts tab.
The ticket now shows a Return and a Repairs smart button, and no credit note, because nothing was refunded. It moves to Solved only after the bike has been shipped back.
Common mistakes
- Ticking Under Warranty without a recorded decision. The price becomes zero silently.
- Enabling every after-sales option. Extra modules may install.
- Expecting Return on a ticket with no delivery. The button needs one.
- Closing the ticket when the customer is told. The documents may still be open.
Related
- What Odoo Helpdesk does covers the ticket model that these buttons sit on.
- Odoo Helpdesk for clinics and vet practices touches on product returns for service businesses.
There is a longer screen by screen walkthrough of this on sajjalbajaj.in.
Official references
How this article was checked: I read the Odoo 19 after-sales page, compared it with 20.0 and read the 19.0 repair order source for the warranty and return fields. I did not run a live Helpdesk database, so the button behaviour is as documented.
If you need Odoo support, stock and repairs working together, the portfolio is the place to start.