Return statuses, groups, and transitions

Returns statuses are configured by the company. A status gets its meaning from the group it belongs to.

All settings are under Settings → Warehouse → Returns. Note the subtab names: the button for creating a workflow and the process steps are under General; transitions and groups are under Automation.

Step by step

Create a workflow from scratch

1. Open Settings → Warehouse → Returns and stay on the General subtab.
2. Scroll to the Create default returns workflow card.
3. Click Create default workflow.
4. In Create default returns workflow?, read the message: It will create any missing status groups, transitions, reasons, and baseline settings for this company. Existing returns and their statuses will not change — only new returns will use this workflow. Confirm with Create workflow; Cancel backs out.
5. Enter a 2FA code. The dialog is called 2FA verification required, the field is Verification code, and the button is Confirm. After verification, the system will not ask again for 15 minutes.
6. On success, you see Default returns workflow created. and a green box such as Created: status groups: N, transitions: N, reasons: N. with Groups: and Reasons: listed.
7. A refusal says Could not create the default returns workflow.
8. You can run it again; it adds only missing items.

Add a status transition

1. Go to the Automation subtab and find Status transitions.
2. Click Add transition. A blank row appears at the bottom of the table.
3. Fill in Order (a number that determines evaluation order), Trigger, Source group (leave (any) for a universal rule), and Destination status. Leave the Active switch on.
4. Save with the green checkmark at the end of the row. The × beside it discards the row.
5. Success: Transition added. Refusal: Error adding transition.
6. Edit an existing row with the pencil and save with the disk icon: Transition updated or Update error. The trash icon does not delete the row; it disables it: Transition deactivated or Delete error.
7. An empty table says No transitions. Click “Add transition”.

There are thirteen triggers: Return created, Linked to order, Parcel received, Validation, Product assessment, Partial put-away, Full put-away, Processing, Completion, Rejection, Cancellation, Marked as problematic, and Dock receipt.

Configure group flags

1. On the same Automation subtab, find Status group permissions.
2. If the group is not in the table, choose it in Select a group to add at the bottom and click Add group. Confirmation: Group added to returns.
3. Under Properties, set the Final and Editable switches. The starting group has a non-editable Initial badge instead; you cannot change that here.
4. Under Filter visibility, set Returns list, Problematic list, and Expand statuses.
5. Under Allowed triggers, choose the actions allowed for this group. An empty selection allows all.
6. Save with the disk icon on the same row. Confirmation: Permissions for group “…” saved; refusal: Save error.
7. The trash icon detaches the group from returns: Group “…” removed.

Configure process steps

1. Return to General, to the Process steps (pipeline) card, labelled Select the steps that should be active in the returns process.
2. In the left Enabled steps column, select stages that are part of the workflow at all. Empty means all enabled.
3. In the right Required steps column (labelled Block return completion), select the steps that must be completed before a return can be closed.
4. Click Save steps. Confirmation: Configuration saved.

Both columns contain the same seven steps: Parcel receipt, Order linking, Validation, Condition assessment (class A/B/C/D), Decision (what to do with the product), Put-away on shelf (receive into warehouse), and Processing (bulk stock receipt).

You will see the effect during warehouse work. A disabled step is refused with Step '…' is disabled in pipeline config; closing a return with a missing required step gives Required steps not completed: …. Both messages are in English.

Group flags

Visibility flags are also available: show the group in the returns filter, show it in the Problematic filter, and expand the group’s statuses into separate filters.

Transitions

A transition is a source group + trigger → destination status pair. The table has Order, Trigger, Source group (which can be any), Destination status, and Active columns.

Order determines evaluation: an exact source-group match is checked before the universal rule.

Triggers are return creation, order linking, parcel receipt, validation, product assessment, partial put-away, full put-away, processing, completion, rejection, cancellation, marking as problematic, and dock receipt.

Check ERP credit notes

The card under General now configures only which ERP the system reads sales credit notes from. Checking is performed by an Automation rule with the Check ERP credit note action: the rule decides which returns to check and when, and its following actions decide what to do when a credit note is found or missing (Actions — what a rule can do). The system never issues credit notes; it only reads them.

1. Under Credit note source, choose Subiekt GT or WAPRO Mag. None (the default) means the action does not query any ERP; the return header keeps its existing KFS chip. The card says explicitly: Credit notes are not read from any ERP — rules with the “Check ERP credit note” action will not check anything.
2. ERP connection is the company ERP account from which credit notes are read. With None selected, the field is disabled and shows Choose a credit note source first. It must match the ERP selected above, or saving is refused with This connection uses a different ERP than the selected source. With an ERP selected, the field is required and a refusal names it.
3. Click Save settings on this card.
4. Click Add a rule in Automation (in the card description) and build a return rule:
   • Use Return status changed with Trigger on status (pre-filter) set to the status in which the return waits for a credit note — it checks once, on entry; or Cyclic: return in status with an Interval and the same status in the Return status field under the event — it checks at each interval while the return stays there (Events — what starts a rule). Such a rule can be enabled only with a status set in that field or a Return status condition; if both are set, they must share a status. Any action wait must be shorter than the interval.
   • Add a Return status condition for that status; usually also an Integration condition (is one of) to select the stores and marketplaces to check, and a Customer Service status condition if returns handled by Customer Service should be excluded.
   • Add Check ERP credit note and set No credit note after (hours) — how long a return can wait without a note before the action fails (0 = on the first check).
   • Then, for example, add Change return status with Run when = If previous succeeded, and Set Customer Service status with Run when = If previous failed. For both, set Track action = Check ERP credit note. Never use Always — the wizard displays this reminder permanently beneath the action.
5. Save the rule.

The card no longer has Waiting in, Only returns from connections, Check every, After credit note, No credit note after, or statuses to set when a note is missing. The rule now controls status, connections, frequency, deadline, and what happens next.

A found credit note is saved on the return (number and history entry); a missing note is marked once per stay in a status and is not repeated by later checks. The deadline is measured from when the return entered the status, so if it was already waiting there before the rule was created, the first check without a credit note can fail the action immediately.

If the ERP does not respond — network issue, temporary unavailability, timeout, or a check that does not fit within its 30 seconds — nothing changes: the return keeps waiting, the next rule run will check it again, and no issue is raised. A rule triggered by status change does not retry by itself; a second Cyclic: return in status rule for the same status provides retries. If the ERP cannot be queried until someone fixes the connection (bad key, disabled or missing connection, incomplete settings, or Subiekt rejecting the request), nothing changes either, but the company receives one issue in Problems; it closes automatically on the first check the ERP answers. An error reading documents for one return (the ERP replied, but that return could not be read) does not create or close an issue; it goes only to the application log with the return number. If the result cannot be saved on the return, the action ends neither in success nor failure, so the return is not sent to Customer Service as “no credit note.”

WAPRO Mag identifies a credit note by the BaseWMS: 123456 annotation (order ID) in its notes — the credit note inherits it from the invoice issued for the order. The system always compares the goods, even if there is just one return and one credit note: a note closes the return only if it reverses exactly the goods received in the return. A credit note for only the price or delivery costs does not close it. If a note matches several returns or none, including when WAPRO cannot provide its line items, the system does not assign it. After the No credit note after period, the action fails and the rule routes the return to Customer Service; its history explains the case (Credit note requires Customer Service review). A note already assigned to one return is never assigned to another.

Subiekt GT uses the same check that powers the KFS tile in return details. The old Verify KFS credit note action has been removed, and deployment migrates rules using it to Check ERP credit note. The KFS tile still works and reads rules with the new action: a closed return the rule is still checking has a blue clock tile KFS: waiting for credit note instead of a red one, provided it entered the status in the last 60 days (older returns are no longer checked) and is not a return from a wholesaler parcel. The statuses checked are those in the event status field (Trigger on status (pre-filter), or Return status for cyclic rules) and the Return status condition; when a rule has both, only their shared statuses apply. The Waiting for credit note chip uses the same rule.

What appears on the return: Close a return, mark it problematic, and set its Customer Service status.

Default workflow

Six warehouse groups plus Customer Service:

Return New (initial) → Return Received → Return In progress → Return Completed (final)
                                                             ↘ Return Rejected (final)
Return Problematic — for investigation, goods not ours, complaint, Customer Service decisions
Customer Service — separate customer service track

Two triggers in the default workflow do not change the status: partial or full put-away, and order linking. The action still takes place; the return simply stays in its current status.

Process steps (pipeline)

This is a separate layer from statuses:

• Enabled steps — which stages exist in the process. Blank means all are enabled.
• Required steps — which steps prevent the return from being closed if incomplete.

The step list is parcel receipt, order linking, validation, condition assessment, decision, put-away on shelf, processing, and completion.

A disabled step gives “Step '…' is disabled in pipeline config”. Missing required steps give “Required steps not completed: …”.

Create default workflow

The button creates any missing groups, transitions, reasons, and baseline settings. It works incrementally and idempotently: it adds only missing items and does not change existing returns or their statuses. You can click it more than once.

It requires a fresh 2FA verification. Along with return-refund settings, this is one of only two places in this module that asks for it.