Skip to Content

With this MKS I would like to shine a light on a pretty complicated part of the transportation network determination. One crucial element are transportation lanes defining links for locations between which transports are possible. For example the available means-of-transport can be set, cost can be defined, distance and duration is set. For more details check here in MKS13.

It is possible to define transportation lanes for transportation zones to reduce the maintenance effort and enable planning for address based locations. And here comes the point: Locations can be assigned to multiple zones AND zone can have hierarchical relations AND in addition there is also a hierarchy for means-of-transport. In SAP TM processes, there is very often the requirement to find the most specific transportation lane for a location pair. For example when determining the distance of a stage, or in the tour optimizer, or the carrier selection. The logic to find the most specific lane must consider all 3 hierarchies (start location-zone hierarchy, destination location-zone hierarchy, and means-of-transport hierarchy) and it must do this very quick. Obviously it is first of all important to define the priorities how the logic shall search through those hierarchies.

MKS64_0_LaneSettings.png

MKS64_1_LaneSettings.png

It can be defined if the means-of-transport hierarchy shall be evaluated first. This would force the logic to stick to the locations as long as possible and only start to search based on zones if there is no connection for any means-of-transport. Also the priority for the start and destination can be defined. For example if the customer prefers lanes that start with the specific location (maybe the warehouse or terminal in outbound scenarios), it would find a lane warehouse to a zone before a lane zone to destination.


So far so good. BUT: Due to the fact that a location can be assigned to multiple zones, multiple result lanes can be on an equal level. In this case the standard logic sorts those results by cost, distance, and duration and picks the one with lowest value. Also there is a enhancement method available (enhancement spot /SCMB/ES_LDDD_LD, method /SCMB/IF_EX_LDDD_LD~DETERMINE_MOST_SPECIFIC_LANE) in case a different logic is required.

And now comes the complicated part: When having lanes for zones within a hierarchy (/SAPAPO/RELHSHOW), the lane determination considers this, but only after the location – zone assignment. As a first step the logic always determines zones including the location directly and puts them on the first hierarchy level. Then it searches those zones for results. If it finds lanes for multiple of those zones, the results are assumed equal and handled like described above. Only when not having results for those zones, the logic will start to go through the zone hierarchy and consider this correctly.

Basic assumption was that no zone in the hierarchy includes locations on its own that are already included by any child zone. So for example you want to cover the US with a top zone and have all states as single zones below you would not maintain a location inclusion at all for zone US, but only for the state zones. Any location within the US would then first fall into a state zone and indirectly using the hierarchy into zone US. Well, sounds reasonable for this simple example, but reality proved that this is sometimes hard to do. You have to always reduce the location inclusion for the top zones by all child zone definitions. This is technically possible, but cumbersome and error prone. In addition, the system does not enforce or check this.

Result is that situation occur, where lanes are determined as result that do not fit to the expectation that the zone hierarchy is also evaluated for the results including the location directly.

MKS64_LaneHierarchy.png

Lane determination theory

MKS65_LaneHierarchyExample.png

Lane determination example

So in the example, you could expect Lane A as more specific also for the right side.

With note 2362806 Lanes on same hierarchy level the lane determination has been improved. Challenge is that this logic can not be done automatically as it changes the standard behavior and there can already be live scenarios depending on the logic without the zone hierarchy. After implementing the note, it is possible to activate the zone hierarchy by using enhancement spot method ADJUST_SETTINGS and setting the indicator APPLY_ZONE_HIERARCHY to ABAP_TRUE.

The report /SCMB/TEST_LDDD has also been enhanced to offer this setting:

MKS65_LaneDeterminationTestReport.png

The flag will also be added to the TM lane determination settings, but this requires another TM specific note.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Richard J. Tkachuk

    Marcus, thank you for providing this very detailed information and note 2362806!  You have enabled a great standard solution at 3M that will greatly reduce our master data setup and/or custom coding.  

    (0) 

Leave a Reply