Skip to Content

Todays MKS explains the concept for the Transportation Zone hierarchy used in SAP Transportation Management.

When starting to make the maintenance of a Transportation Network easier and allow the dynamic inclusion of Locations within a Transportation Zone using address fields, it became obvious that there would be all kinds of Transportation Zones. The next step was the idea that those would probably often have a hierarchical relationship. Back in SAP APO days Location were assigned to exactly one Transportation Zone (location) and those had no hierarchy. So the ‘new’ Network is really powerful in this area.

Within the SCM basis underlying SAP TM, there was already a function to handle hierarchies. Basically, in customizing you define which type of objects you want to handle, set a few criteria for this hierarchy structure (how many levels, a few texts, where shall it be stored, and so on), and here you go having a user interface allowing the maintenance. Including adding and removing elements, checks for cycles and a hierarchical display. For the Transportation Zone hierarchy the new hierarchy structure ‘RELHS_ZONE’ was created.

MKS18_01_Customizing_HierarchyStructure.jpg

SCMB customizing – hierarchy structure activity

MKS18_01_Customizing_HierarchyStructure_definition.jpg

SCMB customizing – hierarchy structure details

In the beginning there was the idea to also add the flexibility for TM customers to switch hierarchies, but I was kind of afraid that all this added flexibility (dynamic location inclusion, multi-level zone hierarchy, …) would make everything just so complex and hard to analyze that we skipped this: The ONLY considered Transportation Zone hierarchy RELH_ZONE. It can be maintained in transaction /n/SAPAPO/RELHSHOW. You can actually maintain other hierarchies, but there is no standard TM setting to switch them on.

MKS18_02_Hierarchy_Maintenance.jpg

Transportation Zone hierarchy maintenance entry screen

MKS18_03_Hierarchy_Maintenance_details.jpg

Transportation Zone hierarchy maintenance

So what does this hierarchy express? Well, easy to say – any Zone being a direct or indirecty parent (superordinate) of another Zone includes all Locations included by this Zone. As a Zone can be superordinate to multiple other Zones, it is actually grouping those. A typical geographical setup would: Country, below states/regions, below postal code areas. So when searching for Zones including a Location not only those appear having a it directly under it, but also superordinate Zones of those (->see advanced search option in Transportation Zone maintenance).

MKS18_04_Zone_search.jpg

Location inclusion

A obvious rule: a Zone can not include itself (directyl / indirectly).

So where is the hierarchy considered? I think everywhere Transportation Zones are relevant: Determination of Transshipment Locations, Transportation Lane determination (getting cost, distance, duration, TSP assignments between a start and a destination location; here also the sequence of the hierarchy levels is respected to determine the most specific lane), Trade Lanes (and of course implicitly all functions using the Trade Lane).

Best practices:

– Only add location inclusion for Zones on the lowest level: Even though you can also add such a definition (for example for a country zone) for any of the Zones in the hierarchy, I find it hard to understand such a hierarchy. And also it cost performance because for each definition the location inclusion must be analyzed.
– Do not add hierarchy levels just for structuring if there is no specific defintion / use-case for this level. For example you have country – state and postal code zones, but only maintain your lanes for country (as fallback) and postal code. I have seen many customer systems just adding level by level, but never using them. It will obviously slow down your system. And increase the Location – Zone shadow table data volume. Of course there are scenarios really making use of such deep hierarchies – that’s why we allow it. Think about it carefully!!!

Summary: Powerful, but complex!

To report this post you need to login first.

3 Comments

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

  1. Shivam Sharma

    Hi,

    Thanks for a wonderful and rare information 🙂

    Curious to understand – suppose we have a BP with ZIP code(in Master Data) defined in one Transportation zone, while other relevant factors to identify TSP for tendering like T.Zone defined in BP, country etc associated with other Transport Zone. And I have lanes defined with carriers separately for all these factors – then Carriers from which lane will be picked up ? a Lane with Zip, country, City, T.zone – or all ? I mean is there a priority given or all relevant lanes & hence carriers are identified for finding Carriers for Tendering.? ( Wish I can sound clearer)

    Regards,

    Shivam.

    (0) 
    1. Marcus Zahn Post author

      Hello,

      basically the lane determination is capable of determining a most specific lane within the geo hierarchy. It would for example pick up a lane defined on location -> location level and prefer it over all zone lanes. But I think the carrier selection gets all relevant lanes and combines those carriers assigned. Not sure how the geo hierarchy influences the ranking.

      In case you for sure have to exclude specific carriers for a defined area I see no other way then to define your network including the zones this way.

      Hope this helps,

      Marcus

      (0) 

Leave a Reply