Usually with a manual planning action (like assigning a freight unit to a truck, changing stops…) you are changing freight documents in a way that times need to get redetermined to create an executable plan. Therefore, I highly recommend you to add scheduling to all of your manual planning actions. As most of you will know manual planning is controlled by a process controller strategy and therefore you should add the strategy method “VSRI_SCHED” to your MP strategy.
The scheduling engine is part of TM optimizer engines which are not written in ABAP code but in C++ and are connected via RFC. This brings two drawbacks for customers – more setup & no customer enhancements possible inside the engine. I would rate both as not really critical as usually the current TM customers want to use any of the other optimizer engines (like VSR, LCO, LSO…) and will have to do the setup on their own and I would rather recommend to exchange the input data for the scheduling engine instead of the engine as such (I will give some hints in a later blog).
Anyways for the so-called Basic Shipping Functionality all optimization engines (including VSS) are not included. So, till 2020 all the times needed to be maintained manually (or stay on the default timings), when just using Basic Shipping. To close that gap SAP decided to introduce the so called “Embedded Scheduling” which is a new engine written in ABAP, exchanging the engine call via RFC.
You can easily switch between the engines with changing the scheduling strategy in the planning profile of your scheduling settings to the strategy VSS_EMBED.
Basically, both engines trying to solve the same problem (creating times which fit well to the document time windows, constraints and the scheduling direction) they are not a copy of each other, but the new engine was created independently. Therefore, one of the most important statements of mine is: Embedded Scheduling will create semantical correct results BUT not the same results as the optimizer services engine. Semantical correct in this case means that there aren’t any constraints violated.
As the implementation of the algorithm is quite new, I’m happy for feedback if you encounter weird looking scheduling results (e.g. huge – not with e.g. operating time windows explainable – gaps between load and travel activities) and I guess we will have to sharpen it a little troughing the next releases.
Now let’s spend some words on differences between the embedded scheduling and the optimizer engine based once. Basically, there are only a few. Both engines will consider the most constraints like acceptable and requested times, vehicle availabilities, and operating times but the embedded scheduling does not support the so called scheduling constraints you can maintain in the customizing (and which are our current approach to model driver regulations). But there is also a feature only embedded scheduling has, which is a simple cost-based approach which you can activate in the scheduling settings. This mode is less orientating on the scheduling direction but more on the requested dates and maintained earliness and lateness costs.
Regarding performance the new engine performs better in small volume scenarios (volume in matter of stops and requirement documents) because there is no call to an external service needed. With a few hundreds of stops or requirement documents scheduled at once the optimizer services will getting the faster engine. Anyways I don’t expect performance issues with embedded scheduling.
As the new embedded scheduling engine is directly plugged into the old code using the same interface as the optimizer services once I would expect customer enhancements you did before to work independent on the engine you use.
On long term SAP will invest more in the embedded scheduling so I recommend getting familiar with it. If you use scheduling constraints for sure you need to stick with scheduling via optimizer services for now.