The new Returns module offers a powerful yet flexible way to process incoming returns, mark the returned items, capture return reasons and item condition. Here we will show how you can process this information and which events come into play.
In order to receive notifications for new or updatedItemReturnJobs, you need to set up subscriptions for the event types ITEM_RETURN_JOB_CREATED and ITEM_RETURN_JOB_UPDATED. Please refer to the documentation on Eventing for detailed instructions on setting up subscriptions via the API.
Item Return Job is created
Once the handover process is completed, the platform automatically creates a new ItemReturnJob entity. You will receive a notification through the ITEM_RETURN_JOB_CREATED event.
The initial status of the ItemReturnJob is OPEN. The returnableLineItems array contains all items from the order that are eligible for return. Regardless of whether the order was split into multiple pick jobs, you will always be able to process all items from the entire order. The itemReturns array is empty as no items have been returned yet.
Here's an example (some fields omitted for better readability):
The first return is processed and a new ItemReturn entity is created
Let's imagine the customer has sent back an item to the shop where the incoming return is now processed with the Returns App. Here's an example for the ITEM_RETURN_JOB_UPDATED event:
The returnableLineItems array reflects the updated values of the returnable and returned fields.
The itemReturns array contains the first ItemReturn with details about the returned items in the returnedLineItems array. The status of the ItemReturn is FINISHED because the process has been completed in the Returns app. For each returned item, there can be return reasons and comments, and an item condition based on your configuration. This will help you to capture individual reasons and quality levels for each returned line item. The status of the returned line item is ACCEPTED.
Another item is returned and a second ItemReturn is added
Continuing with our example, the customer has also returned the second item and the return was received and processed. The ITEM_RETURN_JOB_UPDATED event will include another ItemReturn in the itemReturns array:
A second ItemReturn was added to the itemReturns array.
If you look closely, you will see that the second item return has a different returnFacilityRef. This is to show that it is possible to process returns in different facilities (e.g. customer returns one item in the shop and the other is sent back to central returns facility).
Already existing ItemReturns will not be changed - meaning, once an item has been processed you cannot remove it or change its quantity.
The second item in the returnableLineItems array has updated values for the returnable and returned fields.
Once all items have been returned (returnable = 0 for all returnableLineItems), processing additional returns is not possible.
Currently, the status of the ItemReturnJob does not automatically switch to FINISHED. This functionality is planned for future development. However, you can update the status through the API using the updateItemReturnJob call with FinishItemReturnJob payload. This action will trigger another ITEM_RETURN_JOB_UPDATED event.
ItemReturnLineItem status ACCEPTED/REJECTED
In the next example we will process a new order with different items. When processing the incoming return in the Returns app, the user can also request an additional quality check to be performed for the received goods. This functionality is particularly useful for high-valued goods that require a more thorough inspection of their quality.
These line items will have status of WAITING_FOR_INPUT as you can see in the example below:
Once the quality check has been performed, an item can either be accepted or rejected. This decision can be made through actions in the Backoffice or a corresponding mechanism. As a result, another ITEM_RETURN_JOB_UPDATED event will be triggered, and the status of the line item will be updated accordingly. For example, if a line item is rejected, the status will be REJECTED. Here's an example:
The final example shows an ITEM_RETURN_JOB_UPDATED event that is triggered once a refund process has been started in the Backoffice or through a corresponding API call. Here you can see the details for the selected line item in the refund property:
In your integration with the fulfillmenttools platform, you can evaluate the status of ItemReturns and ItemReturnLineItem to initiate the necessary follow-up processes. For example, you might need to start a refunding process or take other appropriate actions based on the order and return status. The availability of different status codes at each level assists you in performing the right actions for the order at the right time.
Fore more details and information, refer to the relevant sections of the API specification.
