Plenty of tools treat returns as edits on the original delivery. Back out a line, adjust the total, move on. It makes the dashboard simpler and the history impossible to reconstruct.
The edit-the-delivery approach has a superficial appeal. Why create a new document when the original delivery already has the line items? Just set quantity to zero on the returned items, adjust the totals, and pretend it never happened. The problem is that it did happen. The driver went to the customer site. The product was unloaded. Days or weeks later, part of it came back. Collapsing those events into a single edited record destroys the operational timeline and makes it impossible to answer basic business questions about return rates, customer behavior, and product quality.
A return note is its own document
Quotery models ReturnNote as a peer of DeliveryNote. It has its own draft → posted lifecycle, its own numbering (RN-YYYY-NNNN), its own items. Posting it increments on_hand and writes a RETURN row on the stock ledger. The parent quote's status does not change — per D8, a return does not roll the quote back.
This design has two consequences. First, the original delivery is immutable — once posted, its numbers are fixed. You can always see exactly what was shipped on which date. Second, the return is independently auditable. It has its own creation date, its own posting date, its own items and quantities. The time gap between delivery and return is captured naturally, not collapsed.
Why not reverse the delivery? Because the customer did not cancel the sale. They took delivery, decided they didn't want part of it, and sent some back. Commercially and legally, those are different events. Folding them confuses the audit trail and makes it hard to answer real questions like 'how much of what we shipped to this customer came back last quarter?'
The distinction matters for metrics. Return rate by customer is a leading indicator of satisfaction and fit. Return rate by product signals quality or description issues. Return rate by salesperson may indicate over-selling or miscommunication. If returns are folded into delivery edits, none of these metrics are computable — you've destroyed the data you need to improve the business.