Reroute

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.

What is a blacklisting?

Blacklisting means that we exclude a facility from a routing decision in a non-initial/ consecutive routing. Technically speaking a blacklisting of a facility is a fence.

We blacklist a facility when it no longer makes sense to consider it for routing, ensuring that it isn't selected again. This is typically done when a reroute is time-triggered (as explained below). If the environment hasn't changed (such as stock levels or capacities), rerouting would always result in the same facility being chosen, which defeats the purpose.

When performing a reroute after shortpick you can configure whether the current facility should still be considered (you find de config here). This enables you to make sure that the not-picked items have to find an alternative facility or become unroutable if the DOMS setting allows it.

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. Thereby we differentiate between an order reroute and a task reroute.

An admin can reroute an order manually. In order to do so this order must be a shipping order and all associated parts of the order (pickjobs or routing plans which are not finally routed) must be in an "open" state. If an operational process (like a pickjob) has been started we do not allow such a reroute. If you trigger a reroute on order-level it might be the case that we consolidate the order parts (if a split has been performed in the prior routing decision) with the new routing attempt.

When triggering a manual reroute on pickjob level this pickjobs must be again in the state open and it must be a shipping order. This action can be performed by an admin or a supervisor with permissions for the dedicated facility (see Manual Reroute in the order overview). The picking task is rerouted by the DOMS to another facility or it stays in the same 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.

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

Example for timetriggered reroute: All jobs whose target time is less than 48h in the future should be routed away from their original location after 24h if picking has not started by then.

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

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:

1. MANUAL when a picking task has been rerouted manually within the Backoffice

2. SHORTPICK when a picking task was picked incompletely and the event-based reroute on shortpick is active

3. TIMETRIGGERED when a picking task was rerouted due to inactivity

How to define reroute settings for shortpick?

See Order split after short pick

When exactly will the order be rerouted in case of an shortpick?

The order will be rerouted after finishing the Pickjob. So before the packing starts.\

Shortpicks in Case of Click & Collect - Ship to Store / Interfacility Transfer

1. Select “Network View”\

   
2. Select “DOMS Configuration”\

   
3. Open up “Routing decision in case of a shortpick”\

   
4. Activate Click & Collect Reroute\

   

How to activate the Reroute in case of inactivity?

1. Select “Network View”
2. Open up “Reroute tasks in case of inactivity”
3. Define reroute settings for the case if orders are not fulfilled in a certain timeframe. The function can be activitated for:

   1. Ship from Store tasks

   2. Same Day Deliveries

   3. Click & Collect tasks

   

How to activate the manual reroute?

1. Select “Network View”\

   
2. Open up “Reroute task manually”\

   
3. Activate Reroute to trigger the function\

   

When no store can fulfill the order in case of shortpick, will the order move into unroutable?

No, if "blacklistedassignedfacilities" is set on "true" , the order will stay in the last routed facility or you can define a fallback facility for it, so the order will then directed into that facility. If the settings are not set on "true" the order keeps rerouting through the facilities.

When exactly will the stock set to 0 in case of shortpick when feature is enabled?

The stock will be set to 0 after finishing the Pickjob. \

How fast will an order be rerouted that fits the criteria for a time-triggered reroute?

Open orders are checked every 10 minutes and are rerouted 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 missing 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. \

If an order is rerouted due to a shortpick, is it possible for a store that has already attempted to pick the item to receive the order again?

That depends on the configurations. If you have set 'blacklistedAssignedFacilities' to 'true,' the facilities that have already had the order will not receive it again. If not, it is possible that the order will be rerouted to the same facility again.\

How to set up a notification before a time triggered reroute is performed

Before a time triggered reroute will happen it might make sense to inform e.g. a supervisor that a reroute due to inactivity is about to happen. This might trigger an operational action like reminding the store manager to start picking.

This is how you can set up such a notification.

1.) Define when the notification should be triggered

With the API call: PUT/api/configurations/routing/reroutetimetriggered you can not only set up the timespan when a task is going to be rerouted in case of inactivity but you can also set the time span how many minutes before this reroute is being performed a user should receive a notification.

This call might look like this:

{
    "version": 1,
    "clickAndCollectReroute": {
        "active": false,
        "rerouteTargetTimeHours": 48,
        "rerouteAfterMinutes": 120,
        "leadTimeBeforeTimeTriggeredReroute": 30
    },
    "shipFromStoreDeliveryReroute": {
        "active": false,
        "rerouteTargetTimeHours": 101,
        "rerouteAfterMinutes": 120,
        "leadTimeBeforeTimeTriggeredReroute": 30
    }
}

In this example it is defined that the task is being rerouted after 120 minutes of inactivity and 30 minutes before the reroute would happen (in this case after 90 minutes being inactive) a notification is sent to a defined group of people.

2.) Set up the notification in our notification center

With the API call: PUT/api/configurations/notifications you can define in our notification center which addresses should receive an email if the time triggered reroute is about to happen. Therefore use the event UPCOMING_TIME_TRIGGERED_REROUTE.

This call might look like this:

{
    "channels": [
        {
            "enabled": true,
            "events": [
                "UPCOMING_TIME_TRIGGERED_REROUTE"
            ],
            "type": "EMAIL",
            "receiver": [
                {
                    "email": "PUT-IN-YOUR-EMAIL-ADDRESS",
                    "language": "de_DE"
                },
                {
                    "email": "PUT-IN-YOUR-EMAIL-ADDRESS",
                    "language": "en_US"
                }
            ]
        }
    ],
    "enabled": true,
    "version": 1
}

ℹ️: The set CRON_JOB in your tenant is responsible for triggering sending emails. Depending on the set intervals of this job it might be that there is a delay between the actual expiry of the previously set time and the email being sent.