Return authorizations

A return authorization is the document that permits a customer to return part or all of an order. It arrives from NetSuite and points back at both the order and the invoice it reverses.

Two transactions follow it and neither is the same thing: the item receipt is the goods coming back, the credit memo is the money going back. A return can produce one, both or neither.

Where it comes from

app/jobs/netsuite/returnauthorizations.php consumes the ns_returnauthorizations batch type, one batch per date. It is not part of the verkoopdump backfill: that import writes orders, invoices, fulfillments and payments only, so pre-2022 returns are not in CCC.

classify/returnauthorizations.php calls getblocked(array('ns_salesorders', 'ns_invoices')) and ends the run while either is still queued, because the return points back at both.

Tables

The return percentage

returnpercentage is the share of the order this return covers: the return's in-VAT amount against the order's in-VAT amount, both in the foreign currency rather than in euros, so a change in exchange rate between the order and the return cannot move it. The result is clamped to the range 0 to 100. An order with a zero total gives 100, because everything the order was worth is coming back.

It is a header figure on the return, not a running total on the order: two returns of half an order each are two rows of 50, not one row of 100.

What classification records

The order and the status, the sales channel, the country, the in-VAT and ex-VAT amount buckets, the line-shape flags multiline, linesinvonly and linesnoshipping, the engraving and aftikker flags carried over from what is being returned, and the return percentage.

What it contributes to margin

Return shipping cost, seeded from config/seed/cm_calculationrules/shipping_return.csv: one rule per shipper and country, each carrying its own activation window because those terms are repriced per period. That file pairs with shipping.csv, which is the same shape on the invoice.

calculate/returnauthorizations.php rebuilds a day at a time, deleting that date's return impacts from all four contribution groups before recalculating, and re-queues every order it touched into cm_impact_salesorders.

The expected figure does not model returns at all. It assumes the order is kept, so an expected margin and a realised margin will diverge on any order that came back. That is the definition working, not a fault.

Where to look, and where to change

The return is upstream data and is not editable in CCC. The rules that price it are.

Related

• Credit memos, the money going back
• Item receipts, the goods coming back
• Sales orders
• Expected margin

Evidence

Import and blocking from app/jobs/netsuite/returnauthorizations.php and app/jobs/classify/returnauthorizations.php. The return percentage from classify->classifyreturnauthorization(). Table family from app/jobs/install/install.php. Day rebuild from app/jobs/calculate/returnauthorizations.php. Types written by the historic import from app/jobs/verkoopdump/transactions.php. Returns not being faked from app/models/expectedimpact.php. Columns from templates/main/transactions/returnauthorizations.tpl. Basis: code-checked at 30f5313.