Monday Knowledge Snippet (MKS) – 18 Transportation Zone hierarchy

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.

SCMB customizing – hierarchy structure activity

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.

Transportation Zone hierarchy maintenance entry screen

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).

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!