Today we would like to give you an insight into the current development of returns in the JTL-Fulfillment Network (JTL-FFN). Since returns have always been an important part of online business, their processing must be as simple as possible, especially in JTL-FFN. So we have given this some thought. You can find a current overview of the topic of removing from stock and fulfillment listings for retailers on the landing page.
The basics
First, we defined the principles for returns processing. Our goal was for a merchant to be able to create a return in JTL-Wawi as usual when a customer requests one. On the retailer side, everything should remain the same. The catch in our case was the synchronization between the retailer’s ERP and the fulfilment service provider. After all, the fulfillment provider needs to know that a return will arrive and should then process it accordingly.
In addition, the fulfiller should also have the option of creating a return himself if unregistered items are returned. Because we also hear of such cases time and again. The JTL-Fulfillment Network takes care of the data exchange.
Problems
Our plan encountered a direct problem: In JTL-Wawi, Applications can create any number of statuses and return reasons for an item. If the retailer manages their returns themselves, this is an advantage. However, when it comes to synchronization, the process is far too time-consuming. Does all this information really need to be exchanged?
After a lot of back and forth, we decided against it. For JTL-FFN, returns processing will therefore change, albeit slightly. We only provide predefined statuses and return reasons to reduce information overkill. However, the predefined statuses and reasons can be mapped to user-defined variants.
We are also faced with the problem of being able to determine whether data has changed within a return. For example, if there is a comment on the item condition, we would like to transfer this information to the fulfiller or retailer without having to do this with the entire return. We have a few possible solutions for this, but they will first have to undergo a few tests before they are actually implemented.
The current status
We are currently working on implementing the synchronization described above as smoothly as possible. For example, the information that a return has arrived at the fulfiller should of course also be passed on to the retailer. The retailer should then be able to process it as usual – for example, initiate a replacement order or create an invoice correction. We are clearly working towards making it irrelevant for retailers when processing returns whether they create a return for a fulfillment warehouse or their own warehouse. The process should be as identical as possible – without any retraining! However, the returns function is not yet included in the closed beta.
What is planned?
Returns processing is currently in a comprehensive concept phase, which we have already implemented to a large extent in a prototype. However, this needs to be further developed before we give it to participants in the closed beta for test runs. This expansion includes, for example, the above-mentioned change of data in the event of a return.
Until the start of an open beta, we would like to make returns – i.e. their complete processing and comparison on both sides, correct transmission and forwarding of any changes – already possible. So why the beta phase? We are using it to put the returns function through its paces. We are dependent on your experience in order to expand and refine the entire process with possible additional requirements.
If you are now curious about the JTL-Fulfillment Network, you can log in directly on the JTL-FFN portal page and join in. And as you could see in the interview with fulfillment service provider MIMO , there are already a number of customers on the merchant and fulfillment side who are already using the network productively in its current state.
