Returns: RMAs, RTVs and changing asset ownership

What it does

An RMA (return merchandise authorisation) records parts or equipment coming back — off a work order, out of a customer site, or from a van. Each returned line carries a processing action that decides what happens next: back into a warehouse, on to the vendor as an RTV, or a change of ownership on a customer asset.

Key facts

RMAs live at Inventory > RMAs. Fields on the header include an optional Work Order (which auto-fills the service account), a Substatus, Ship Via and tracking numbers.
Substatus is an open list you extend — exchange, repair, retire, upgrade are the usual starting values.
Lines are RMA Product records. Each needs a Quantity, a Product and a Processing Action.
The three out-of-box processing actions are Create RTV (needs a Vendor), Return to warehouse (needs a Return to Warehouse) and Change Asset Ownership (needs the destination account in Change Ownership).
If the RMA is linked to a work order you can use Add Work Order Product on the command bar to pull lines straight from what was used. Those lines use Quantity to Return rather than Quantity.
Nothing moves until receipt. Create an RMA Receipt (Related > Receipts) with a name and date, then RMA Receipt Product rows saying what actually came back and how much.
On receipt of an inventory-tracked product destined for a warehouse, Field Service writes an inventory journal that increases Quantity on Hand at that warehouse.
Change Asset Ownership is how a customer asset legitimately moves between accounts — end of lease, site sold, equipment swapped out — rather than editing the account on the asset.
RTVs are created from the RMA with the Create RTV command and then live at Inventory > RTVs. You track them by moving System Status through Approved, Shipped and Received.
Crediting the customer is a separate, deliberate step: set Credit to Account = Yes on the RMA product via the receipt, then use Credit To Customer on the receipt.
Same access as the rest of inventory — Field Service - Administrator or the Inventory Purchase role.

When to use / skip

Use RMAs when returns are a real operational flow: exchange units, warranty parts going back to a manufacturer, unused stock coming off a van, leased equipment coming home. The RTV path in particular earns its place for anyone whose margin depends on claiming faulty parts back from suppliers, because otherwise those claims live in someone's inbox.

Skip the full flow for casual over-picking. If a technician takes three fittings and uses two, that's an inventory adjustment or a transfer back, not an authorisation with a receipt and a status chain. Making people raise RMAs for routine surplus is how the process gets abandoned in week two.

Also skip it where the client's returns are entirely financial — a credit note with no physical movement. That's a Sales or finance job; RMAs are built around goods actually coming back.

Configuration decisions

Which return scenarios are in scope, and which of the three processing actions each maps to. Clients describe returns in their own vocabulary and it rarely maps one-to-one.
The Substatus list, since it's the only real classification you get and it drives whatever reporting the client wants on return reasons.
Whether crediting the customer happens in Field Service or in the finance system. Two credit mechanisms is a reconciliation problem.
Whether returned stock goes back into general availability or into a quarantine warehouse pending test. Field Service will happily put a faulty part back on hand if you point it at the main warehouse.
Who raises RMAs — technicians on mobile, the service desk, or stores — and what that means for security roles and offline profiles.
Whether RTV status is maintained by hand or driven by an integration with the vendor's process. Manual status chains decay unless someone owns them.

Gotchas

Approving or creating an RMA moves no stock. Only the receipt does. Expect at least one "the return didn't work" ticket that turns out to be a missing receipt.
Return to warehouse puts the item straight back into on-hand at whatever warehouse you named. Faulty parts returning to the main stores means they get issued again — use a separate quarantine warehouse if condition matters.
Change Asset Ownership is the correct way to move an asset between accounts, and people who don't know it exists edit the asset record instead. That leaves history attached to an asset the old account can no longer see under default asset validation.
Crediting is opt-in per receipt product. Nobody discovers Credit to Account by accident, so it has to be in the training or credits silently never happen.
The RTV status field is descriptive, not enforcing. Nothing stops a record sitting at Approved forever, and there's no ageing built in.
Pulling lines from a work order only works when the RMA is linked to that work order. Create the RMA standalone and the command isn't much use.

Consultant notes

Ask the client to describe their three worst returns from last quarter. That conversation maps their process onto the three processing actions faster than any workshop template.
Demo the RTV path if warranty recovery matters commercially — it's usually the part of returns with money attached, and it's the part clients don't expect to be in the box.
Push back on using RMAs for routine van surplus. Point people at transfers and adjustments and keep the return process meaningful.
Set up the quarantine warehouse question before go-live. It's a five-minute decision now and an awkward one after faulty parts start circulating.
Check who can see RTVs and receipts under real security roles. Returns tend to be handled by a small stores team whose role wasn't in the original design.

Worth another look if the client starts claiming warranty from vendors at volume, or if return-to-quarantine becomes a native concept.