Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
Showing results for 
Search instead for 
Did you mean: 

The VSR optimizer is mainly driven by Freight Units. As long as there are not planned Freight Units it is searching for capacity to transport these Freight Units. As result the optimizer is creating Freight Orders or Bookings to describe how and when the transport is planned.

In this blog I want to explain what’s happening if we do not start with new Freight Units only, but also with an existing plan containing planned Freight Units, Freight Orders and Bookings. The described features are available since SAP Transportation Management 9.0.

For the first step let’s concentrate on usual road scenarios with a lane based planning and routing approach. So let’s imagine that there are already some Freight Units and Freight Orders existing and we call the optimizer with some additional new and unplanned Freight Units.

Freeze parts of existing plans

In a first step we have to check, if the optimizer is allowed to change the existing Freight Orders. For several reasons, it might happen that the optimizer must keep the Freight Order unchanged. The most recent reasons are:

  • The Freight Order is explicitly fixed by its status.

  • The Freight Order is not completely inside the planning horizon.

  • There are dependencies between fixed and not fixed objects, which enforce the optimizer to fix also dependent object to keep consistency. For example Trailer-Units cannot be changed, if the passive resource is not in the selection. Then the optimizer cannot change the Trailer Unit and indirectly not the coupled Fright Order. For the optimization run the Freight Order is fixed, too.

Copying existing plan and improving it

If the Freight Order is not fixed, we can change it during the optimization per default. Internally the optimizer always starts with an empty plan to guarantee, that there are no alerts or violated constraints. To benefit from the previous plan it tries to rebuild the existing Freight Orders. I describe it as ”tries” because in some cases the optimizer cannot succeed in rebuilding the plan. For example, if Freight Orders are overloaded or several Freight Orders overlap, then the optimizer engine cannot rebuild such Freight Orders, because internally the solution must be consistent in each and every planning step. So it is not possible to just copy such a Freight Order, if you want to keep a state free of alerts. Therefore the optimizer analyzes the sequence on the different resources and is rebuilding these sequences by adding Freight Unit by Freight Unit as long as it can be planned and it is satisfying all constraints.  If this is not possible for certain Freight Units, they are skipped and the optimizer continues with the other Freight Units.

The result of this step is a plan inside the optimizer which is very similar to the plan before the call of the optimizer. We have still have most of our Freight Orders, we have our new Freight Units, and we have perhaps some Freight Units which we removed from the original plan to get rid of alerts.
Now the optimizer is starting its usual work. It is adding unplanned Freight Units to the plan and changing the plan again and again. As a result after the optimization it might be, that there are Freight Orders which are very similar to Freight Orders before the optimization call and there are other Freight Orders completely different from all Freight Orders in the original call.
All the Freight Orders have one common attribute: they don’t know if they are a result of a previous existing Freight Order or not. There is no link between the input and the result.
Before sending the result back into the TM system the optimizer tries to find some similarities between input and output. Sometimes it can judge, that the Freight Orders are similar enough , so that the new Freight Order should reuse the Id of the old Freight Order. But in most cases, we delete the old Freight Orders and create new ones.

This behavior of the engine to generate completely new Freight Orders is very bad for at least two scenarios:

  • If you want to publish your Freight orders to Carriers or into Tendering before you have all Freight Units. Planning the new Freight Units with the optimizer would delete the published Freight Order.

  • If you want to add Freight Units to Freight Orders which are already in execution, we must somehow avoid that they are completely fixed and we have to specify, what we can change in such a Freight Order.

Incremental planning

If we want to keep existing Freight Orders, we have to tell it to the optimizer. We must specify which Freight Orders must survive and how they can be changed. We call such a Freight Order Incremental Freight Order. Let’s use the acronym IFOR for these incremental Freight Orders.

We enhanced the optimizer, so that you can specify, which Freight Orders must survive. For these IFORs

  • The optimizer keeps the resource (truck or trailer)

  • The optimizer keeps all stops of an IFOR.

  • The optimizer keeps all Freight Units of such an IFOR.

  • You can specify if you can add new stops to IFOR or not.

  • We allow adding new Freight Units to the IFOR. Dependent on a parameter, we control if we can add new locations or if we only add new Freight Units at the existing locations.

  • We reschedule the Freight Order with its potentially new stops and Freight Units to get consistent dates inside the Freight Order but also to other documents, like other stages of the Freight Units or the subsequent Freight Order on the same resource.

We decided that we don’t do other changes to an IFOR as we don’t want to destroy any manual decision made before. So we don’t change the resource. We don’t’ change the assignment of a trailer to a truck and we don’t remove Freight Units from an IFOR.  All these actions need an approval by a user and shouldn’t be done automatically by a mass run like the optimizer. If you want to do even this decision by the optimizer in an automatic manner, you still have the possibility to use the usual handling of the Freight Order inside the optimizer.

To the things we don’t want to destroy inside an incremental Freight Order belongs the sequence of the existing stops.  If we add new stops, we can do that at the beginning, between any existing stops, or at the end of the IFOR, whatever has the best result. But we don’t try new sequences of the existing stops. in most cases this stillr esults in very good routes, as the oroginal stops are usually already in a good sequence. But it might be that some Freight unitd cannot be added in the case of thight time windows, which would require a new sequencing.

In Transportation Management you can control the incremental planning by a parameter in the planning profile. You can decide if you want incremental planning and if new stops are allowed or not. This parameter is relevant for all Freight Orders.  Currently you are not able to control each Freight Order separately by some settings.

If you want to have more control about the incremental planning you can use the BAdI before the optimization call. Here you can flag each Freight Order separately.  Additionally you have the following possibilities

  • You can define time frames, how much change is allowed in the rescheduling

  • You can define if it is allowed to add stops as first or last stop or only between.

  • You can define which locations are potentially allowed to insert and which ones not.

How incremental planning can be controlled is described in the note 1866364 .

Now to the ugly restrictions: Unfortunately the optimizer cannot handle really all Freight Orders as incremental: Inside the enginewe handle it like any other Freight Order which is generated by the engine. We apply all the consistency constraints like for any other Freight Order:

  • There must be a resource assigned to the Freight Order

  • If it is a Trailer Unit, there must be one or several Freight Orders with active resources assigned.

If such a consistency check is failing, we handle the Freight Order or Trailer Unit as fixed for the optimizer, so it is not changed at all and no Freight Units are added. Above I mentioned the use case of Freight Orders in Execution. Such Freight Orders often have already information from execution, which are not totally consistent to the planning and they often start before the planning horizon. We check such IFORs and select that part of the IFOR, which is inside the horizon and without alerts. For this part we allow incremental planning. The part before is fixed for the optimization run.

The following drawing gives the simplified overview, how the engine decides in which way a Freight Order or Trailer Unit is handled inside the engine:

Schedules and Bookings

So far I wrote about Freight Orders, which are based on lane information. Now let’s have a look onto bookings and schedules. They have already their complete stop sequence, so the optimizer has no need to add stops. Because of that the behavior is not controlled via the incremental flag in the optimizer settings of the planning profile.

The optimizer does not delete bookings. That means a booking in the input data of the optimizer is always incremental in the sense, that new FU’s can be added. If you don’t select Freight Units already existing on the Booking, they automatically stay on the Booking. If you select them for the optimization run and they are not fixed, the engine is allowed to re-plan them on any other document.

If we have a Freight Order which is based on a schedule in the input data of the engine, there is the possibility that the optimizer can delete it like other Freight Orders. It can be avoided via the fixation of such a Freight Order. For the Freight Units, we have the same behavior like on Bookings.

What's next?

This blog is a first overview about incremental planning. You see that the incremental planning is working on complete Freight Orders and offers new features for scenarios like planning on IFORs in tendering or execution. Because of that I am interested, which other scenarios you would like to handle with incremental planning and which features would be important for it. For example: Should we search for a resource for IFORs, should we change the sequence of stops inside a IFOR or what else? If we add such additional flexibility, how would you like to control it?