Rerouting
It could be that a routing decision must be questioned if the circumstances on which a routing decision was made have changed. If this is the case our DOMS double checks the routing decision for a certain picking task and then decides whether a reroute into another facility would make sense or not. We divide those occurrences into an event based rerouting and a time based rerouting.
Event-based reroutes
Routing in case of shortpick
There are two events which can trigger a reroute decision. When there was a shortpick within the picking process the DOMS re-evaluates its routing decision by considering the current facility with the updated stock information and comparing it to all other suitable facilities within the network.
If the shortpicked pickline(s) downgrades the current facility in such a way that it would make more sense to pick a task elsewhere, then the already picked items must be restowed and the picking task is being rerouted to another, more suitable facility.
If for a pickline at least one substitute article has been picked, such a line will not be considered as a shortpick, even if the picked substitute quantity differs from what the customer has ordered, because one cannot know if the substitute still fulfills the customers need.
Example: customer orders 2x 500ml milk and gets 1x 1000ml milk as a substitute article - the picker has then picked less than ordered, but it is still valid to fulfill the need of a customer.
In general the system treats a substitution pick as if the line has been picked successfully.
Additionally, the DOMS can also evaluate reroute options for other open picking tasks which would require a lately shortpicked article as well if they have to be finished within a specified timespan. This is done to avoid additional shortpick situations which most likely will occur as long as no replenishment takes place since the article was rendered out of stock when the first picking task had a shortpick.
Currently, the following settings related to the DOMS can be set either via API or via our Backoffice:
Define a replenishment-cycle when using the listing-based rating (see Ratings ) With our rating, based on the amount of available listings, we enable you to minimize out-of-stock situations although there is no stock-keeping system connected to FFT. We do this by considering articles as available or not available. If a picker performs a shortpick the article changes the status from available to not available. This information is used by upcoming order routing decisions. To make the article available again, one can set it to being available manually, but there is also a possibility to set a counter for how long an shortpicked article is viewed as not available. After the set amount of time has passed, this article will be seen as available again.
This timespan starts as soon as the shortpicked articles were restowed and is set to 48 hours by default. As a result, the DOMS will check if any other open picking task in this facility exists, which has a target time within the next 48 hours. If this is the case and if the DOMS finds a more suitable facility a reroute is performed. If not, the picking task remains in its original facility (the current facility is not blacklisted).
The event-based reroute can be enabled & configured for either Click & Collect and Ship from Store orders. Depending on the order type, the reroute mechanism acts differently.
For Click & Collect, a reroute option only makes sense in case another facility exists which then can send the picked articles back to the Click & Collect facility, since the customer will come along at that facility eventually. Choosing such a fallback facility is a two step approach:
First, it is checked whether multiple facilities were pre-defined when creating the C&C order. If this is the case, the DOMS performs a routing decision by evaluating those specified facilities in comparison with the current facility. Only in case a facility is found that performs better than the currently chosen facility, the reroute is performed.
Second, in case no preselected facilities were specified, the DOMS performs a routing decision by evaluating all facilities with service type ship-from-store based on the fences & ratings configuration.
The above mentioned reroute mechanism that reroutes other most likely affected picking tasks is only available for Ship from Store orders. Click & Collect orders will not be rerouted automatically since they may have a target time at which the customer will come along to pick up his order. If this target time is too short (e.g. a couple of hours), the DOMS cannot guarantee that the fallback facility will have those articles delivered to the Click & Collect facility before the customer comes along.
For Ship from Store Orders the DOMS performs just the second step of the Click & Collect reroute, e.g. the DOMS performs a routing decision by evaluating all facilities with service type Ship from Store based on the fences & ratings configuration.
Generally this setting can be switched on and off via API.
Reroute task manually
The second event is a manual trigger. A user with the role “Supervisor” or “Admin” is able to trigger a manual reroute for an open (e.g. unpicked) Ship from Store picking task within the backoffice, see Manual Reroute in the order overview. Click & Collect picking tasks cannot be rerouted. If this is the case, the current and originally chosen facility is blacklisted so that the picking task cannot be routed to this facility again. The picking task is rerouted by the DOMS to another facility based on the fences & ratings configuration. This function can be activated and deactivated via the API on tenant level. If the function is deactivated, the entry which triggers the action is not shown within the backoffice “Orders” section.
Whenever a reroute has been performed successfully, one has to restow the items back into the shelf spaces. This has to be confirmed within the App. If the picker forgets to do so, the system considers the restowing to be done after 60 minutes (default setting, configurable via API). After that timespan, the stock levels are increased by the amounts that had been picked.
Reroute in case of inactivity (time-triggered reroute)
The time-triggered reroute is the third reroute option FFT offers. In essence it performs a reroute after some kind of inactivity. More precisely: if picking a task has not started for a given amount of hours - due to whatever reasons, maybe the employees are busy with serving offline customers - it will be rerouted to another facility.
By default, this timespan is set to 24h (but can be set to any desired value) and starts counting for each picking task individually as soon as it is created within a facility. This reroute only works for facilities with type store, since the DOMS should not manipulate picking tasks that have been routed to a warehouse - such facilities are not within the realm of FFT anymore.
Traditionally such a reroute would only make sense for ship-from-store orders, since C&C orders are expected to be picked up at the facility the customer has requested during checkout. Nevertheless FFT also allows C&C orders to be rerouted after a certain timespan, since we want to enable a Ship to Store delivery in case the order cannot be picked in the C&C-Facility(e.g. due to capacity reasons) and therefore is prepared in another Facility (e.g. a warehouse), which then sends the goods to the C&C-Facility where the customer picks up the order.
When performing such a reroute, the current facility is blacklisted (taken out of the routing decision) to ensure that the DOMS will not consider it anymore when performing its routing decision. Additionally already requested documents related to the original picking task are deleted from the facility and cannot be accessed anymore. Furthermore the stock and the reserved stock is adjusted according to the picked/restowed items.
Rerouting such picking tasks also might affect the target time of that task, see Target time and sorting. There is a dedicated option that allows the customer to define that only picking tasks which feature a target time in the near future are rerouted, because there might be picking tasks that are already routed to a facility, but only have to be completed after several weeks, because a customer made an early pre-booking of furniture (or any other good). By default, only picking tasks that have a target time within 48h are affected by this time-triggered reroute. Again, this timespan can be configured to customers needs.
The configured reroute timespan is affected by the fulfillment times that can be configured for each facility individually, see Facilities
Technical good to know
When performing an event-based reroute, the reason for rerouting is stored within the matching routingplan (see API docs). We know the following reRouteReasons:
MANUALwhen a picking task has been rerouted manually within the BackofficeSHORTPICKwhen a picking task was picked incompletely and the event-based reroute on shortpick is activeTIMETRIGGEREDwhen a picking task was rerouted due to inactivity
Last updated
