This is done by restricting the way the platform identifies trips to propose by setting parameters that look at the sales increase associated with a trip, the importance of visual rules, as well as the products which should be considered for transfer based on recent movements or if recently introduced.
Optimization Parameters
Min ESI by Trip
The Minimum Estimated Sales Increase (ESI) per Trip parameter defines the lowest commercial gain (in euros) that must be expected from a product transfer for it to be considered.
Only transfers where the total ESI exceeds the configured minimum threshold will be proposed in a scenario. This helps prioritize transfers that deliver meaningful commercial value, while filtering out inefficient ones.
⚠️The ESI is calculated based on the sales probability of each unit to be sold in the destination store and on the price of each product.
This effectively serves to only select sufficiently profitable trips to propose for the scenario:
In this example, we want to realize a transfer between Store A and Store B, where the total ESI has been calculated as €7.5 for the proposed trip. This value remains constant across all three cases, but the outcome changes depending on the configured Min ESI per Trip setting.
|
Scenario |
Min ESI per Trip |
Condition |
Explanation |
|
A |
€2 |
7.5 > 2 ✅ |
✅ The transfer is proposed because the calculated ESI (€7.5) exceeds the Min ESI per Trip (€2). |
|
B |
€4 |
7.5 > 4 ✅ |
✅ The transfer is proposed because the calculated ESI (€7.5) exceeds the Min ESI per Trip (€4). |
|
C |
€10 |
7.5 > 10 ❌ |
❌ The transfer is not proposed because the calculated ESI (€7.5) is below the Min ESI per Trip (€10). |
This means that the higher the Min ESI per trip, the fewer trips will be proposed.
Visual Merchandising Weight (VMW)
This is a parameter used to set the importance the scenario will give to the visual rules that apply to any product and store included in the scenario. It essentially helps to integrate in the store transfer scenario the balance between sales optimization based on demand (The ESI generated by the trip) with store presentation standards (An attractive product display before/after Store Transfer).
What Happens with a High VMW?
Nextail will give greater priority to respecting visual rules both at origin and destination stores.
- Some products can be retained in the origin store to avoid leftover situations post-transfer but keeping products in stores where they are less likely to sell.
- At destination, the store might receive more stock than necessary from the same item to comply with Visual Rules
This setting preserves product attractiveness and store consistency, but may reduce commercial efficiency and inventory optimization by keeping products in stores where they are less likely to sell or pushing more than necessary.
What Happens with a Low VMW?
It will give the algorithm more flexibility to propose transfers that aim to maximize sales, even if that means disrupting the visual setup.
- Nextail will prioritize sales potential, moving products more freely between stores to dispatch the inventory where there is more likely to sell.
- The store transfer might lead to leftover generation and visual inconsistency at origin store
If the VMW setting is too strict (high), the scenario may ignore high-opportunity transfers just to preserve visual rules at destination and lead to excess inventory at destination stores. But if it's too loose (low), transfers might lead to multiple leftovers situations and then overstock —especially for items that cannot be displayed anymore due to local Visual Rules policy.
For more detailed information about this parameter, go to the Visual Rules lesson of this course.
Efficiency Threshold
This parameter sets a minimum requirement to determine which transfers should be included in the scenario. It helps control the number of proposed units and trips—higher values make transfers more efficient but result in fewer units being moved.
In simple terms, it ensures that a unit will only be transferred if the difference in probability of selling in the destination store compared to the origin store (%) is higher than the threshold.
Let’s see a simplified example:
If the Efficiency threshold is set at 20%, it means that, for a SKU to be proposed, it should have a 20% more chance of being sold in the destination store than it had in the origin store.
The real formula of the efficiency threshold would be:
[ (Sales probability Store B - Store A) x Product Price ] - Operation Effort per Unit > Threshold x Product Price
Operational Effort Per Unit
This parameter allows the user to set a general effort associated with transferring a single unit or product as part of a transfer - taking into account the effort of searching for a product on the shop floor, picking out the relevant units and preparing them for transfer.
In the case where stores are experiencing a period of significant workload and would want to reduce the number of units required to process as part of store transfers, you can increase this number to represent the time and effort required to search, pick and pack each unit in the shop floor. Typical values range from 0.5 and 2, depending on the average product price
⚠️This should only be used when the algorithm suggests high quantities not manageable by store personnel for transfers. These cost methods may impose significant optimization limitations.
Blocks Advanced Parameters
Apply Replenishment Blocks
This allows the user to control whether the store transfer scenario should respect the blocks that have been set in the system. Activating this feature means that any store for which a given product or SKU is blocked for replenishment, will never receive it through a Store Transfer.
For more information about Blocks in the platform, go to the “Blocks” section in Transversal courses.
Block recently moved products
This will prevent any products that have already been transferred in previously Submitted Store Transfer Scenarios from being proposed in the current one.
You can set the timeframe you want the system to consider the product-store combination as “recently moved”.
This may be desirable to give them a chance to be sold in the stores that received them a few days/weeks ago.
⚠️In order for a product-store combination to be filtered out, it should have been part of a Submitted scenario through the Nextail platform.
Block recently introduced products
Likewise, this feature will filter out any products that have only recently been implemented to their origin stores. This is intended to allow new products a chance to be sold at their origin stores before being proposed within a store transfer scenario.
⚠️ For the system, a product-store combination is “introduced” the first time a sale or stock position is recorded for that store - this is also known as its available date. The value provided in block recently introduced products will then define the period the item will be excluded from the scenario.
As an example for a Product A in Store X
- Scenario calculation date: March, 12th 2025
- Product-Store available date: March, 1st 2025
- Recently introduced period: 30 days
The product A in Store X is excluded from the scenario calculation because it has been introduced in less than 30 days (March, 12th - March 1st >> 11 days).
As a conclusion, the configuration of these parameters allow users to set restrictions that reflect both strategic business requirements as well as the quantity and quality of trips that should be proposed as part of the Scenario.
