When modifying an inactive Route Version, set its start date at least as many days in advance as the highest "Routes.DaysInAdvance" value found on the Routes table for the old route version. This proactive measure prevents unwanted plans from the old version and ensures a smooth transition. Failing to set this date before plans are generated from the old version will likely require you to delete and regenerate them.
​
​

For a new Route Version, its Start Date must be the first delivery date for that version. Aligning this date with the initial delivery facilitates a seamless transition for plans and invoice routing.
​
​
​
​

Ensure the route version's End Date is either null or a distant future date to prevent premature termination. If a Route Version ends without an active alternative, no plans will generate beyond that end date. Once the new Route Version's Start Date is confirmed, set the old version's End Date to the day prior. This, like the start date, should be set in advance—specifically, at least as many days ahead as the highest "Routes.DaysInAdvance" value on the Routes table for the old route version.
​
​
​
​

Be aware that the system will generate plans for pre-sell events before a Route Version's start date if the corresponding Delivery Stop Next Date is on or after the Route Version Start Date. For instance, if a pre-sell stop is on Friday, the delivery stop on Monday, and the new Route Version goes live on Sunday, the Friday pre-sell event will still generate in the new Route Version, even though it's not yet active.