Settings and Permissions

Settings and Permissions

Getting started on your RTS/RMA flow

Your RTS flows rely on certain essential and optional settings as well as related functionalities AKA permissions. This page is specifically dedicated to explaining those, as well as the difference between RMA and RTS.

RMA or RTS?

Although these definitions are sometimes used interchangeably in the industry, we tend to use them in the following way: RTS is any request that comes from HQ and is sent to the stores as an RTS order. We see RMA as a request from a store to HQ to send something back.

To make it slightly more complicated, regardless of where the order is initiated, our App Suite calls all related functionality (and order type) RTS, while the Companion still calls it RMA.

Settings for RTS user task

There are a bunch of settings relevant to RTS. Before we head into the settings however, we'll give a brief description on your basic, default RTS flow.

When you create an RTS request in Admin Suite, a purchase order will automatically be generated. Simultaneously, an order of the type Return to Supplier will be created in your stores. This will show up in your Checkout App's or Companion's Orders list; from there on out you can simply process that order as you would any order.

Since an RTS order can be massive however (changing seasonal products for example), or becuase stores may want to deviate from RTS orders, settings become really handy about now.

Let's start off with the essential ones.

Setting	Default value	Description
Orders:ReturnToSupplier:EnableTasks	false	By setting this setting to true, the HQ's RTS request will no longer just generate an RTS order, but accompanying RTS user tasks as well. Such tasks can technically be ignored, mainly if an RTS request is small enough.
Orders:ReturnToSupplier:UseStockMovement	false	By setting this to true, the RTS user tasks can be split up into two sub-types. This is essential to allow for generating corresponding tasks when HQ makes changes to a store's RMA request. - RTS create order task: generated when either the store or HQ makes an RMA/RTS request. - RTS stock movement task: generated when HQ makes changes to the RMA request and goods have to be moved back.
Orders:ReturnToSupplier:UseTypedRtsTasks	false	Enable this as well to make use of the above UseStockMovement tasks. (This setting might default to true soon anyway.)

The following are optional, but are likely to prove useful to you.

Setting	Default value	Description
Orders:ReturnToSupplier:UseExcludePolicyOnShipment	false	This lets you toggle between Exclude/Include for the picking of items. In other words: do you want your employees to start off the detailed inspection by scanning all necessary items? Or by scanning any items which do not make it into the shipment instead?
App:ReturnToSupplier:ShipmentCanHaveTrackingCode	false	Enabling this means you will be prompted for scanning a shipment label when opening the Return to supply user task.
Orders:ReturnToSupplier:AllowConcurrentTasks	true	This will allow your employees to work together on an RTS task. This works by duplicating the parent task everytime it's started by another employee.
Orders:ReturnToSupplier:RequireOrderValidation	false	When you're working on picking an RTS task with multiple users, you'll want to be sure the task is not completed before everything is picked. Set this to true to require an employee (with relevant role) to confirm the RTS order.
Orders:ReturnToSupplier:AllowEaches	true	Do you want to allow your stores to send back individual items, or complete boxes only? See also Unit of Measure.
ListReturnableSuppliersForOrderLegacyMode	false	If set to true, this will force the the configuration of suppliers to not go fully down the relation tree. If the supplier was Netherlands (which is a container OU) for example, this will be returned, instead of the returnable OUs that are "under" this container OU.

Relevant permissions for the RTS creation and its user tasks

Only users with the ReturnToSupplierOrders permission enabled in their account are able to convert a regular order into a Return to Supplier type order.

If the RTS order however leads to the creation of an RTS user task, the employee won't be able to manage it without the HandleReturnToSupplierTasks permission. And even if they do have that permission, they cannot finish the Return to Supply user task in its entirety without the FinalizeReturnToSupplierOrder permission. Without the latter, the user task will remain available, even if all order lines contained in the task have been picked.

If a user with all necessary roles finishes the complete task while not all order lines have been picked, the shipment will be finalized regardless. Any non-picked order lines on the RMA order will be cancelled.

The VerifyOrder role is necessary only if order validation is enabled in the settings (see RequireOrderValidation in the optional settings). When the setting is enabled, an additional 'Order confirmation' note will be shown in the order details. When the employee has the VerifyOrder role, a button will be displayed there to confirm the order right away.

You can find a quick summary of these roles here below.

Role	Functionality
HandleReturnToSupplierTasks	Required for employees to pick up or partake in RTS user tasks.
ReturnToSupplierOrders	This is required for all employees that need to be able to convert a regular basket into a Return to Supplier type basket in the Checkout App and Companion.
ReturnToSupplierRequests	This is required for all employees that need to be able to manage RTS requests in Admin Suite.
FinalizeReturnToSupplierOrder	This is required for an employee to be able to finish the entire RTS user task. (See also Orders:ReturnToSupplier:RequireOrderValidation
VerifyOrder	This enables an employee to authorize a store's RMA order or a store's deviation from an RTS order.