Re-route
Last updated
Last updated
Sometimes, a routing decision must be questioned if the underlying circumstances that informed the decision have changed. If this is the case, the DOMS checks the routing decision for a specific order and decides whether a re-route into another facility should be initiated. A re-route can happen based on an event or time triggered.
Blacklisting means that a facility is excluded from a routing decision in a non-initial/ consecutive routing. Technically speaking, a blacklisting of a facility is a fence.
A facility is blacklisted when it no longer makes sense to consider it for routing, ensuring that it is not selected again. This is typically done when a re-route is time-triggered. If the environment has not changed (e.g., stock levels or capacities), re-routing would always result in the same facility being chosen, which defeats its purpose.
When performing a re-route after a short-pick, it is configurable whether the current facility should still be considered. This ensures that the not-picked items that could not be picked can be fulfilled in an alternative facility or become unroutable if the DOMS setting allows it.
There are two events that can trigger a reroute decision. When a short pick occurs during 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 short-picked items downgrade the current facility so that it would make more sense to fulfill the order elsewhere, then the already-picked items must be re-stowed, and the order will be re-routed to another facility after the pick job is finished (before the packing starts).
This functionality can be configured via reroute shot pick configuration REST API and in the .
If no store can fulfill the order in case of short-pick, the order will stay in the last routed facility if blacklistedassignedfacilities is set to true. Alternatively, a fallback facility to which the order will be routed can be defined. If the blacklistedAssignedFacilities settings are not set to true the order will keep being re-routed through the facilities. In addition, if blacklistedAssignedFacilities is set to true, the facilities that have already received the order will not receive it again. If not, it is possible that the order will be rerouted to the same facility again after a short-pick.
The event-based reroute can be enabled and configured for click-and-collect and ship-from-store orders. The reroute mechanism acts differently depending on the order type.
For click & collect orders, the customer has already chosen a facility where she wants to pick up the ordered items. Thus, a reroute option only makes sense in case another facility exists that can send the picked items to the click & collect facility. Choosing such a fallback facility is a two-step approach:
First, the DOMS checks whether multiple facilities were pre-defined when creating the C&C order. If this is the case, it makes a routing decision by evaluating those specified facilities against the current facility. A reroute is performed only if a facility performs better than the currently chosen facility.
Second, if no preselected facilities were specified, the DOMS makes a routing decision by evaluating all facilities with the service type ship-from-store based on the fences and ratings configuration.
For ship-from-store orders, the DOMS performs just the second step of the click-and-collect reroute,. For example, it makes a routing decision by evaluating all facilities with the service type ship-from-store based on the fences and ratings configuration.
If for a pick line at least one substitute item has been picked, such a line will not be considered as a short-pick, even if the picked substitute quantity differs from what the customer has ordered, because one cannot know if the substitute still fulfills the customer's need. In general, the system treats a substitution pick as if the line has been picked successfully.
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.
The second event is a manual trigger. It can be differentiated between an order re-route and a task re-route.
An admin can re-route an order manually. In order to do so this order must be a shipping order and all associated parts of the order (pick jobs or routing plans which are not finally routed) must be in an "open" state. If an operational process (like a pick job) has been started no reroute is possible. When triggering a re-route on order-level it might be the case that order parts are consolidated (if a split has been performed in the prior routing decision) with the new routing attempt.
This functionality can be activated and deactivated via routing configuration REST API on tenant level. When deactivated, the option for re-routing an order is not shown in the Backoffice “Orders” section.
The time-triggered reroute is the third re-route option. It performs a re-route if a picking a task has not been started for specific amount of time. By default, this timespan is set to 24h (but can be set to any desired value) after the pick job was created in the facility.
Open orders are checked every 10 minutes and are re-routed if they fulfill the criteria for a time-triggered reroute. This timeframe is reduced for old orders that have already surpassed their target time. In the first 24 hours after exceeding their target time, orders are only checked once per day. After the first 24 hours this frequency is further reduced to one check per day.
Time-triggered re-routes can be triggered for both ship-from-store orders and C&C orders. Although C&C orders are expected to be picked up at the facility requested by the customer, systems allow a re-route to enable a ship to store delivery in case not all items can be picked in the C&C-Facility.
When performing such a re-route, the previous 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 / re-stowed items.
Re-routing picking tasks also might affect the target time of that task. 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 re-routed, because there might be picking tasks that are already routed to a facility, but only have to be completed after several weeks. By default, only picking tasks that have a target time within the next 48h are affected by time-triggered re-route. This timespan can be configured to customers needs.
Considered Timespan = Checks how far in the future the target time of the pick job is
Maximum Processing Time = Specifies the time of inactivity after which the pick job is routed away
Within the notification center it can be configured that an email is sent out to a defined receiver group in order to inform about the inactivity caused upcoming reroute of the task x minutes in advance.
When a re-route occurs, the reason for re-routing is stored within the matching routing plan. The following re-route reasons are available:
Manual: A picking task has been re-routed manually via the Backoffice
Short-pick: A picking task was not completely picked and the event-based re-route on short-pick config is active
Time-triggered: when a picking task was rerouted due to inactivity
When triggering a manual reroute on pick job level, the pick jobs must be in status "open" and belong to a shipping order. This action can be performed by an admin or a supervisor with permissions for the dedicated facility in the . The picking task is either re-routed by the DOMS to another facility or it stays in the same facility based on the fences & ratings applied.
The configured reroute timespan is affected by the fulfillment times that can be configured for each facility individually in the facility settings of the .
This functionality can be configured via timetriggered reroute Configuration REST API and in the .