Maintenance of route definition is treated as a configuration item and thus requires transport move from development box.
While some data in route definition surely should be treated as a config - such as transportation relevancy or stage setup - there are other elements which I believe are more related to masterdata.
A perfect example here is assignment of forwarding agent. There it is expected to maintain Vendor code of forwarding agent. But that implies we need to define the same Vendor number in development system before we create transport with route definitions..
Another case is related to transit times. Why do we need to define transit time as configuration item to be transported between boxes? If let's say during winter time the transit time is 1 day longer we need to either define alternative route for that or move transport with changed route details.
Most of the feedback taken that we receive is that the fields mentioned above should be treated as masterdata elements. That obiously means decoupling route maintenance into config & masterdata. Any custom solutions here are complex. We can create custom transactions to maintain eg. forwarding agent or transit times and update route tables directly. But obviously that is not a nice option. Alternative custom tables to be maintained directly in the box would be even more complex, since standard SD_sheduling routines would need to be adjusted to take into account custom tables.
So for now we can only hope that SAP folks might reconsider this setup in the long term and have the solution more user-friendly.
Any comments are welcome!
Cheers,
Dominik
