SAP S/4HANA 2020 FPS2: Country-specific prefix for transportation zones
Dear friends of SAP TM,
In a former post, we already talked about the usage of prefixes and suffixes when creating locations in SAP Transportation Management. With SAP S/4HANA 2020 FPS2, we introduce another use case for adding prefixes in regards to transportation zones. With that, it will be easier to find automatically created transportation zones and their locations.
Basically, the transportation zone is a master data object in SAP TM used during transportation planning. It consists of one or more locations and represents the source or destination of a transportation lane. It can be assigned i.e. to a business partner or a shipping point in the respective address data.
You can use transportation zones in multiple ways to cluster locations for the planning process. A very simple example is to define transportation zones by basic geographical attributes in the customizing as shown in the following:
If you define the transportation zones in such a basic way, you might also want to reuse them for different countries, as shown in the above example.
When you now use order- or delivery-based TM integration, the transportation zones are in SAP TM created as master data objects and also as locations of location type 1005. Thereby, the identifier (here ‘NORTH’, ‘SOUTH’, ‘EAST’, ‘WEST’) is the default id for both.
But obviously, it’s quite likely that in a constellation as shown above, at some point a transportation zone or location with the same id is tried to be created a second time for another country. As it’s not possible to have different master data objects with the same name, the system will add a suffix to the id (as described in the mentioned post). I.e. the identifier ‘NORTH’ becomes ‘NORTH_01’. This is fine technically, but from the user perspective…not so much.
With SAP S/4HANA 2020 FPS2, we adjust the names automatically in a more meaningful way. Let’s describe the new feature by going on with the example from above.
In the customizing, we have assigned transportation zone ‘NORTH’ to the following shipping points:
Now assume, we create a sales order with shipping point 0003 in Germany (Country DE). During the integration with SAP TM, it’s checked whether the transportation zone and its location are already existing, and create both if necessary.
If we create both, the new feature comes into the play. We now always add the country code as prefix to the id of both, the transportation zone and the location.
Means, we create transportation zone ‘DE-NORTH’ (transaction /SCMTMS/ZONE):
….and location ‘DE-NORTH’ (transaction /SCMTMS/LOC3):
Of course, you still have the chance to change the identifier in the BAdI (as mentioned here). But always take care, not to create a dump because of doubled identifiers 🙂
So, if you examine your transportation zones and locations, don’t be surprised about this prefix. It surely makes life still another bit easier in finding both objects by their country.
Just for avoidance of doubt…this affects only locations of type 1005, meaning transportation zones.
For further information please refer to note 3006911:
Please feel free to leave any comments!
Hi Michael, I'm not sure I fully understand this functionality and whether i can use it to solve a problem I have.
We are introducing SAP TM S/4 Hana 2020. Unfortunately, all our routes and associated carrier payments are based on suburbs. There can be a number of suburbs for one post code. Is there any way I can set up suburbs as zones? Could this functionality help?
Thanks for your comment with this interesting use case.
If you define your transportation zones only by the postal code this could indeed be a challenge. The functionality described here will surely not help, unfortunately. Basically, a transportation zone is intended to be big enough to cover multiple postal codes which holds true for most of the cases.
Might there be any way you can define the transportation zone by its locations? I would assume there shouldn't be that much locations within a suburb?
Thanks for your quick response. I can probably use your suggestion for STO's which are, by their nature, between fixed locations and for SO's to regular customers. I'll have to think about what to do for one time customers.
Thanks for sharing these insights.
These blogposts are a great plus for the TM Knowledge sharing community.
Do keep them coming 😉
With logistic regards,
Thanks a lot, I appreciate!
I'll do my very best, there are still interesting topics left 🙂
Being that you later use Transportation Zones to define other kinds of master data (like Transportation Lanes), wouldn't this increase master data maintenance efforts?
I mean, let's say that you use the transportation zone NORTH to define a Transportation lane from NORTH to LATAM. But with the way this works now you'll have DE-NORTH, CH-NORTH, AT-NORTH. If you want to keep simple master data maintenance you'd need to either manually add the Locations to the pre-existing NORTH Transportation Zone, manually add the new zones to a Zone Hierarchy or manually maintain the other master data objects (Transportation Lanes, Trade Lanes, Default Routes, etc...) considering the new zones (DE-NORTH, CH-NORTH, AT-NORTH).
I think it would be better if you could control somewhere in customizing wether if you want a new Transportation Zone with prefix to be create (the new behaviour you described) or if a Transportation Zone with the same name already exists to append the new location to the pre-existing Transportation Zone.
Thanks for your comment!
But when I understood your example right, I disagree that the maintenance effort increases. DE-NORTH, CH-NORTH and AT-NORTH are basically different entities with different addresses etc. that need distinct transportation zone master data objects. We would never include them in a common transportation zone like NORTH: And up to now, we would have created NORTH, NORTH_01 and NORTH_02.
So the improvement is now that you don't have the suffix _01, _02 but the prefix with the country code. But the number of master data objects is still the same, and for a good reason.
I agree that there is one pitfall with that. If a transportation zone is within more than one country, the prefix with the country code is a bit confusing. But this is a rare case and the name can easily be adjusted in a BAdI. And in this case you would of course create only one transportation zone (and not for every country the transportation zone covers) with the prefix of the country code from its address data.
thanks for clearyfying these master data topics! I'm always interested and already looking forward to the next post
It's not about transportation zones, however some interesting thing that I tumbled about these days is that the location description is a language-dependent field.
There's a BAdI which can be used to handle this, but I was wondering - WHY ?!
Whats the sense having this field localizable?
I have a question regarding adding/removing prefixes/suffixes while creating locations in TM for "S4 1909 embedded" version. My client has 2 brands and they use 2 "ship to" BP's; "444_01" and "444_02" while creating sales orders for the same physical location/store actually.
My client does that because of ECC/EWM restrictions in order to process/handle products separately in the warehouse belonging to different brands. I recommend to use same "ship to" but 2 different "sold to" etc. for those 2 different brands, but they did not accept.
So I have to transfer 2 sales orders for 2 different brands going to same location/store but with 2 different "ship to".
I created TM locations out of those 2 BP's as "444_01" and "444_02" with the same address etc. But when I create a FO out of those 2 FU's, i see 2 different stages unfortunately.
My client wants to see one stage only as the store is the same. Is there a way to do it. What if I create one another BP as "444" externally with same address and assign this BP "444" to both SO's.
May i use this new BP rather than "ship-to" while creating FU's delivery location on TM. Of course this should not cause any issue on delivery integration either.
Thanks for your comment.
But I think this issue has nothing to do with the prefixes/suffixes added automatically when creating locations, neither with the transportation zones.
I ask for your understanding that I can't make a statement or provide a solution based on this basic description of the process. This would require some deeper analysis.