As you may know we use Meta-Heuristic for our VSR-optimization. We call it evolutionary local search. One important part in such an approach are the local steps to check every possibility in a neighborhood and some random steps to get new aspects into your plans. But beside of that it is very important we have very efficient steps to construct the transportation plans. That means we have to exploit all the information of our data and to concentrate on that kind of plans which are usual rated as good or very good.
Because of that our algorithms inside VSR are highly sophisticated. They are created and adapted to the feature-set of TM and what we learned from our customers about good transportation plans.
If you now want to change that behavior of it, to support new features, constraints or cost functions, it would be no good idea, to just do a minimal change and add this feature or constraint. As long as you don’t adapt the constructions step, so that your kind of wanted plan becomes possible, the optimizer would not work efficiently. Without deeper changes the algorithms would still try to construct the same plans like before. Adding new cost functions to express what is expected are required, that the engine can decide, when a plan is better than another. But much more painful: All the algorithms for construction have to be adapted. Otherwise they would destroy the new wanted feature of the plan directly in the next step after they have found it.
That means enhancing the algorithms to get a new behavior can be cumbersome and expensive. But there is another possibility, which helps in a lot of requirements: We change the data instead of the algorithm
Let’s look what’s happening, if we call the optimizer: The application is reading all data which is required for the optimization run. It collects all this data and sends it in one large package to the optimizer. After the optimizer has found its solution, we have the same into the other direction: The optimizer sends back the transportation plan und explanations to the TM system, which is saving these results during the post-processing.
As the data are transferred from the application server to the optimizer and back, we have a copy of the data. A copy implies, that we can change the copied data without changing the TM-system itself. For example you can delete objects in the optimizer data set, without deleting these objects inside TM.
We introduced the BADI /SCMTMS/PLN_OPT to allow such manipulations to the data, which are send to or from the optimizer engine. The BAdI is running on the application server. It is a usual ABAP-BAdI, whereas the optimizer itself is written in C++.
The BAdI has two methods: After the pre-processing you can manipulate the input data for the optimization engine. After optimization you can manipulate the results of the optimizer, before saving it into the TM system.
Like you can see in the drawing above, the BAdII call for transforming the input data and manipulating the result, are inside the calls of the explanation tool. This means
- If you manipulate the input data, you see the original input data in the explanation tool. You don’t see your manipulation
- In upload stop you can write additional information into the explanation, to write details about your changes to the objects.
- In general you can see the BAdI as part of the optimization process. Whereas the explanation tool describes the state before and after optimization and BAdI.
Let’s have a look, on what you can do with the BAdI: The simplest usage is the deletion of some constraints. There are already several parameters in the planning profile, which you can use to disable some constraints. But these switches work on a general level. If you want to ignore or modify some but not all constraints of one type you can do it with the BAdI.
- Ignoring or modifying of you dates, acceptable or requested dates on Freight Units
- Capacities of trucks, trailers, compartments bookings or schedules.
- Changing of distances or durations to overwrite the general geo information
Whereas the examples above manipulate the input data for the optimizer, it is also valid to change the results:
- You can delete specific Freight Orders or Bookings, if they don’t satisfy your expectations, for example if the utilization is too low.
One of the most important data to the optimizer is the transportation network. Especially if you want to keep it simple for the maintenance and manual planning, but you want to have some more complex effect inside your automatic planning you can do that in the BAdI, too:
- In the blog about simple networks I introduced a modelling to enforce that some locations are the first delivery locations on tours. Instead of a persistent modelling like in the blog you can transform your network on the fly when calling the optimizer.
- So far the optimizer cannot handle via-locations. You can add them in the BAdI, if you add the additional duration, distance and cost in the distance table. This guides the optimizer engine too consider the additional effort to go via the via-location.
In the result of the optimizer you add this via-location whenever such a distance is selected.
One very common usage of the engine is to add data which are not yet maintainable inside TM into the optimization process. In some special areas we have the situation, that the optimizer already supports functionality, which is not supported in TM application:
- Ship-With-Groups
The optimizer can respect groups of FU-stages which should be planned together in one common Freight Order. You can find Details in this note. - Cost-Model
The optimizer has a sophisticated model for cost on bookings and schedules. Currently only very basic cost rates are transferred to the optimization engine. - Sustainability
The engine has features to reduce the carbon emissions. The can be handled like additional costs.
You see, there a lot of different possibilities to adapt the engine via the data to your scenarios. In principal we can see, this is quite simple, as long as you only change some values, or delete some constraints in the input data.
As soon as you introduce new objects into the input of the optimizer, these new objects may become part of the solution. Then you have to do the mapping into the objects of your TM system after the optimization,too.
In some cases the required new behavior, cannot be implemented vie the BAdI. You might need to change the behavior of the optimization engine itself. For example, to create somehow different transportation plans or to add a new cost function to evaluate plans. In these cases it’s often not enough to change only the data. We have to adapt the logic and the coding of the optimizer.
If you expect to need such a change inside the optimizer engine, you should contact our expert consulting first. They can give you hints how other users solved similar requirements or if there was a similar enhancement done already. If there is no such mitigation, you have to think about a customer development project. There are experts in our department for customer developments, which are specialized to the optimizer and will find fast and efficient solutions to utilize this BAdI for your extensions.
- SAP Managed Tags:
10 Comments
| User | Count |
|---|---|
| 8 | |
| 7 | |
| 6 | |
| 4 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 |
