Wild Card Postal Codes in Transportation Zones and Postal Code Range in TCM

[former_member194164]

Hello Experts,

I have 2 queries on Postal Codes usability in SAP TM:

1. Postal Code Transportation Zones:

Business Scenario: Some countries have non-numeric Postal Codes and you can not maintain From and To Postal Code range. System supports Postal Code to be entered as Wild Card (XY1*) in Transportation Zone but does not respect them during charge calculation.

2. Postal Code Range in Rate Table:

There are standard Calculation Bases for Source/Destination Postal Code Range but these do not allow maintaining values like Source Postal Code Range (90100-90199) to Destination Postal Code Range (63100-63199). I am unable to understand the use of these 2 calculation bases since they do not accept range.

Kindly suggest.

Thanks and Best Regards,

Vikas Chhabra

[former_member186731 · Accepted solution]

I start with the first question: Well, well, well. Probably one of the most underestimated topics in the transportation network. A bit of a background: Postal codes are alphanumeric meaning they allow numbers and characters. Of course for some countries only numbers are required and those are pretty easy to handle. Nevertheless, SAP produces global software and there are countries having postal codes with unfixed length, character first, in the middle, at the end. This makes ranges ugly, tough, sometimes impossible.

The range definition works alphanumeric, which is a position to position comparison based on single chars. You can check the inclusion results in excel or with any database. For the zone definition this can mean that you are forced to enter postal codes and no ranges. Of course this blows up the maintenance effort in the beginning, but ensures the correctness.

I was surprised by your comment that the zone definition allows '*' because this would make this whole thing even more complicated and error prone. I tested it and it does not work, at least for Germany. I think in the address definition per country you can define valid formats for postal codes and there '*' is not valid for Germany. The transportation zone location inclusion will not work with pattern!

In case you have manages to maintain this: I would advise to take the effort and enter at least valid ranges.

[former_member186731 · Accepted solution]

Check note 1841448 - Location inclusion using postal code not working correctly

[former_member194164 · Accepted solution]

Hello Marcus, for GB, System supports entering wildcard for postal code range to specify GB Postal Codes that are alpha-numeric and also contains space (like NN15 5JR, NN15 5YT, NN16 8SD, NN37 2AP and so on..these are just examples but mentioned postal codes really exist in GB). But they are not read by the system in TCM.

[former_member194164 · Accepted solution]

Hello Marcus,

To continue on my query 1:

We are already on SAPK-12003INSAPTM so the note suggested by you is already a part of it and hence I get the remark "can not be implemented".

Moreover, in response to my incident to SAP 294000 / 2015, I was very recently suggested to implement a performance note 2048937 (in my opinion this performance note will not be able to handle the issue, still I will test once this suggested note once my technical team completes the implementation of this note).

Thanks and Best Regards,

Vikas Chhabra

[former_member186731 · Accepted solution]

Note 1841448 is a consulting note, so it would suprise me in case you could implement it.

[former_member186731 · Accepted solution]

Yes, then the alphanumeric range inclusion will handle * as a character and not as pattern. I see no way to enable this technically. We have spend quite some time to come up with something here, but there are always combinations where the user expectation is not met. So: Maintain your postal codes without pattern.

[former_member194164 · Accepted solution]

My Bad

Thanks.

[Bimal_S · Accepted solution]

Can you maintain it like NN1 000 to NN3 999 or NN1 0A0 NN1 9Z9?

[former_member194164 · Accepted solution]

Hello Marcus,

This note helped us and we could successfully create GB Transportation Zones with text, space, number POSTAL CODES as from and to ranges to our heart's content.

Thank you very much Marcus.

Vikas Chhabra

P.S: Please also help us in second issue which is more on the TCM side.

Message was edited by: vikas chhabra

[former_member186731]

For the second question: Could you explain a little bit more detailed what exactly you maintain and where?

[former_member194164]

Hello Marcus,

For second use case of Postal Code Range in TCM, Business Requirement is to maintain rates based on Source CITY to Destination CITY in US.

I never liked Calculation Base CITY (along with State/Country Calculation Bases), because City is a text field and hence can be written in so many ways in Customer/Vendor/Location master data so the permutation combinations would be huge and every combination will have to be maintained in Rate Table for CITY (e.g. a CITY San Antonio can be entered in Customer Master as S. Antonio,            San Antonia, SanAntonio, San.Antonio etc etc and then also consider chances of name mistake by user in entering City in master data).

I thought of using Source Postal Code Range instead of Source City and Destination Postal Code Range instead of Destination City and used these 2 standard calculation bases in the rate table. But Rate Table maintenance does not allow range here, so I was thinking how to use these 2 calculation bases.

I am sorry for not being clear in once. Hope this detailed explanation will help.

Thanks and Best Regards,

Vikas Chhabra