Where return orders come from: platforms, manual entry and existing orders all land in OMS

Every consumer return — pulled from a sales channel or a returns platform, created by hand, or carried over from RMS — becomes one OMS return order in one list, with one number.

Returns used to land in different places depending on where they started. That is over: every consumer return now becomes an OMS return order first. The OMS return order is the one document that tracks the return — where it came from, which warehouse it goes to, and how it ends. Warehouse work still happens in RMS when your setup uses it, but the RMS document is an execution order derived from the OMS return order, never a second, separate return.

See every return in one list#

1. Open OMS → Returns (/oms/rma). Each row is one return order: its number, the original order number when known, the client, the status, and three extra columns — Source, Warehouse assignment and Handling.
2. Use the Source filter to look at just one inlet — for example only the returns pulled from returns platforms, or only the ones your team created by hand.
3. Two quick filters sit above the list: “Awaiting assignment” (returns that still need a warehouse — see the routing article) and “Derivation failed” (returns whose warehouse execution order could not be created).

Source 1: returns that arrive from platforms on their own#

1. Returns on a connected sales channel or returns platform are pulled in automatically by a flow: OMS and Integration ship with two ready-made flow templates — “Channel returns sync” (every 30 minutes) and “Returns platform reconciliation” (every 2 hours). Enable the one that matches your connections under Integration → Flows.
2. Need one right now instead of waiting for the schedule? Open the connection under Integration → Connections and use its “Pull returns” action — it pulls one round immediately, with the same result.
3. Pulling the same platform return twice never creates two return orders: each platform return is matched by its platform number, so a re-pull only moves the existing order forward. The Shopify channel and ReturnGO are the first connections with return pulling; other connections keep working exactly as before.

Source 2: a return your team creates by hand#

1. On the returns list, click New return and pick the original sales order first — the lines you can return come from that order, so a line that was never on the order cannot be returned by mistake.
2. For each line, fill in the quantity coming back and pick a standard reason (the shared reason list maintained under Master Data → Reason codes). A broad group cannot be picked for a line — choose the specific reason; if none fits, pick “Other” and write what the customer said.
3. If you already know which warehouse should receive it, pick the warehouse right on the create form and the order starts out assigned; leave it empty and the order goes through automatic assignment or waits in the assignment queue (see the routing article). Creating the same return twice for the same order lines is blocked with a plain message — the open return is already there.

Source 3: created from the RMS pages — still an OMS order first#

The warehouse team’s familiar entry point still works: RMS → Return orders → + New RMA keeps its form, but saving now creates the OMS return order first (you land on its OMS detail page) and the RMS execution order is derived from it. On the OMS detail page, the execution area shows the RMS order number with a link to open it; on the RMS side you see the OMS number the same way — whichever number someone gives you, you can find the other side in one click. This is the Docklify pattern to remember: one return, one OMS document, and RMS purely as the warehouse execution desk.

Existing orders, platform-held returns and no-return refunds#

• Returns that were still open in RMS when this started have been carried over: each one got its OMS return order (Source shows “Carried over”), and the two stay in step until the return finishes. Returns that were already finished stay in RMS only — the OMS list tells you where to look instead of showing a half-empty copy.
• Some returns never travel to your warehouse at all: on platform-fulfilled channels (for example marketplace fulfilment), the platform receives and grades the goods itself. Those returns still land in OMS — marked as platform-handled — purely so you can reconcile them; they never enter the warehouse queue and never create warehouse work.
• A refund with nothing coming back (the platform tells the customer to keep the item) is recorded as a no-return refund: the order closes without any warehouse step, so nobody waits for a parcel that will never arrive. On the detail page of such an order the warehouse-assignment entry is hidden — there is no warehouse step to assign.
• If a platform return cannot be matched to its original order, it is still created — nothing is turned away. The order is flagged “Original order not matched” on the list and the detail page, with a “Link order” action to attach the right order by hand.

Docklify features used in this article#

• Returns list with Source / assignment / handling columns and quick filters — OMS → Returns (/oms/rma)
• Return flow templates (channel sync every 30 min, platform reconciliation every 2 h) — Integration → Flows
• Pull returns on a connection — Integration → Connections → open a connection → Pull returns
• Manual return create with standard reasons — OMS → Returns → New return (/oms/rma)
• RMS create page that files through OMS, and the linked execution order shown on the OMS detail page — RMS → Return orders → + New RMA (/rms/new)
• Standard return reasons — Master Data → Reason codes (category: return)