The default configuration allows all trips across all stores included in the scope - however, this can be restricted by forbidding specific trips or allowing specific trips only.
Through this window, the user can control stock movements based on single stores or store categories, ensuring that trips align with operational strategies.
In this article, we will explore how to configure Allowed Trips and Forbidden Trips to tailor stock movements within transfer scenarios.
Allowed Trips
The user can select manual or automatic categories (or even single stores) in the allowed trips configuration boxes. In the example below we can see that, within our scope, the only allowed trips would be from the store categories of Milano and Firenze to all other stores in the scenario. This means that exclusively trips with origin in the stores contained in those two categories will be proposed:
⚠️When selecting an allowed trip configuration, ensure that the categories or stores selected are included in the original store transfer store scope, or else it may result in zero trips.
Forbidden Trips
Inversely, the user can configure any trips that are forbidden within the store transfer scenario, ensuring that specific trips are never proposed within the scenario. This is also available at single store or store category level:
In the example above we have set the restriction that Store 3 cannot transfer any stock (to any other store). Likewise, we have set the restriction that no store can supply any stock to Store 1.
As a consequence, in the ST scenario we might find cases where store 3 receives stock from other stores across the network (but never sends out), and cases where store 1 is sending stock to others (but never receiving).
It is important to note that the restrictions set on allowed and forbidden trips will have a noticeable impact on the platform's ability to identify potential store transfers and generate ESI value from the scenario. The more trips forbidden, the less optimization potential the system will have.
It’s crucial to define all relevant restrictions at this stage of the process to ensure that the engine respects real-world constraints from the outset—rather than relying on manual adjustments after scenario results are reviewed. If the Nextail algorithm doesn’t have all restrictions upfront, there’s a risk it will propose movements that, while beneficial, are actually not permitted. Providing these constraints in advance allows the algorithm to drive the majority of the store transfer strategy, minimizing manual corrections later and ultimately delivering greater time savings, efficiency, and ESI value from the start.
Example Use Cases
Some real life examples in which the trips restriction capability comes in handy, could be:
- Keep stock under the same area, manager or region: in cases where stock can only be transferred within specific regions, this can facilitate the execution.
In the example below, we are ensuring that the trips proposed will be within the Stores handled by Manager1 and the Stores handled by Manager2, without crossing between them.
- Prevent long trips or high logistic costs: the user can limit long-distance transfers or costly logistics by restricting trips between distant stores, ensuring efficient and cost-effective inventory movement. In the example below, the engine will never suggest any trips from the northern stores to the southern ones and vice versa :
- Prevent your online store from participating in a scenario: If your business has one or more online marketplaces it is possible these should not be considered for store transfers like brick and mortar ones. By using this configuration, your online store will be completely excluded.
By carefully setting up allowed and forbidden trips, users can ensure that store transfers align with both logistical constraints and business objectives. Thoughtful trip restrictions help the platform generate the most relevant and impactful transfer proposals, optimizing inventory allocation while reducing unnecessary movements.
