When you work with or for large multinationals you quickly get to LOVE international standards, especially ISO codes. I started my IT career at a large multinational and have worked for or with large multinationals over more decades than I care to think about - so standards are "mother's milk" to me.
But even in 2020 every so often international standards can lead you astray.
Such as with one of my current SAP S/4HANA customers where they wanted to use ISO 3166-2 region codes, and came across a stumbling block. It took us several weeks and a ridiculous amount of networking to finally understand the underlying issues.
In the process I noticed several customers had asked the same question and were mostly just given the default "that's just the way things are" answer.
So hopefully this short article will solve one of life's little mysteries for a few of you.
Here's what happened.
This SAP S/4HANA customer is doing a very large multi-phase digital transformation to the intelligent enterprise with SAP S/4HANA on a hyperscaler and multiple SAP Cloud Solutions, including SAP SuccessFactors, SAP Ariba, and several others. One of the critical drivers for such a large program is to undo or remove a lot of the technical debt that had built up with modification after modification and thousands of custom code lines. So "back to standard" is a very strong mantra for this project.
Now as they have employees in over 50 countries and provide services to their customers in over 100 countries, we aren't just talking back to SAP standard here. There's a very strong push to incorporate as many international standards possible. So there's ISO values everywhere.
For the most part this approach has worked very well. After all, most SaaS solutions have similar challenges with providing services to many countries, so they align to many of these standards as well. So incorporating ISO standards has simplified data model alignment, simplified integration, and simplified user training/instructions.
There's always an exception to every rule... and it can come from the most unexpected places.
ISO region codes is not something you would expect to cause a problem. Countries and regions are an obvious place to use international standards:
So you would think in a digitally-aware world, in 2020, in the 21st century, that there would be an international standard, and that you could safely use international standards for country and region codes everywhere.
Sure enough ISO 3166 is the relevant standard. It covers both countries and their regions. The regions part of the standard is designated as ISO 3166-2. So far so good.
It was already clear that SAP generally uses these ISO code 3166 values widely too, but there are exceptions.
For SAP S/4HANA the exceptions are listed in SAP Note 1164216 - T005, T005S content. T005 and T005S are the 2 database tables that hold the country and region codes respectively.
The reasons given for why SAP does not use ISO region codes for some countries are rather vague, e.g. "Legal requirements based on standard which deviates from ISO". As a customer or to a consultant this can sound awfully similar to "historical reasons" or "that's just the way SAP have always done it and no-one wants to change it now".
Furthermore, as SAP Note 1164216 explains, as a customer you are permitted to change/overwrite entries in table T005S. This is useful because regions (and even countries) can change on government decree and without a lot of warning (especially if there was a war involved in that boundary change). There's even a SAP Note with a video showing how to update the tables. SAP Note 2149999 - How to update region codes in table T005S [VIDEO]
So no problem! The project just updated table T005S with the ISO region codes for the exception countries.
Across all the program and all the interfaces between on premise and cloud solutions, ISO countries codes were working fine, and for the vast majority of countries regions were working fine as well. All the data was going through from cloud solution to on premise and vice versa, end to end processes were working fine. Or so they thought.
Then the System Integration Testing and User Acceptance Testing started to run through some localization use cases for Spain, and all of a sudden there was a problem.
When employee addresses were replicated from SAP SuccessFactors to SAP S/4HANA and the ISO region code was used for Spain, there was an error given from small and hard-coded validation check within SAP S/4HANA.
For those interested in the fine details this was the "Province to Post code check" for Spain, which insists that the Spanish region code should be a 2-digit number matching the first 2 digits of Spain's 5-digit postcode. The validation check itself was coded in ABAP Class CL_HRPA_INFOTYPE_0006_ES.
If this had been any other large multinational customer, they might have simply used the modification assistant to remove the unwanted validation. And that would have been a mistake!
Tip: Using the modification assistant, while not desirable, is technically something we can still do in SAP S/4HANA any premise solutions. Of course for SAP S/4HANA Cloud you have to abide by stricter Cloud-first rules, as per: SAP Note 2756046 - Differences of country region codes for S/4HANA Cloud compared to ISO-3166 standa...
Because the customer had such a strong strategic direction to stick to standards, they did the right thing and raised a SAP Incident via the official support channel. In the incident they asked for the check to made optional, so they could use ISO 3166-2 regions everywhere.
If you do this you will get a frustrating response, something like the below.
In SAP S/4HANA SAP uses ISO codes for regions for the majority of the countries. However there are a few exceptions - and Spain and Portugal are two of them. In this case due to Business reasons in applications SAP decided to deviate from ISO. Hence it is not possible to change these codes.
The trouble with answers like these is they give the impression that this is not a business or legal requirement but some sort of historical reason or even whimsy on the part of SAP. Not so!
Most customers generally give up at this point - and either stick with standard, or make the modification. Because of the particular mix of SAP S/4HANA and SAP cloud solutions this customer has a little more SAP executive support than the average customer so we decided to use that to delve deeper and solve the mystery:
There's even a precedent for this! In 2011, SAP changed the region codes for Ireland to ISO 3166-2 as explained in SAP Note 1641607 - Update region codes for Ireland according to 3166-2
Plus you would think with all SAP's Intelligent Enterprise activity and data model alignment across the related SAP any premise and cloud solutions, now would be a great time to fix all those exceptions, once for all.
Well, several weeks and a LOT of networking later, we finally came across someone who could explain why not, and it's as simple as this:
For Spain, it is not only a legal requirement to provide numeric province codes (and not ISO codes), it is also a business practice at Spain to use the numeric codes. For example:
If you are interested, you can even take a look official references from the Spanish Tax Agency (you can swap the site to English in the bottom right hand corner of the webpage). One examples from the site is shown below:
Naturally SAP has had customers based in or operating in Spain for many years. So SAP's financial reporting and general business operations for Spain supports Spanish business practice and legal requirements, and so uses the 2-digit province code and not the ISO 3166-2 region codes.
There are other countries with similar issues where it is not possible to use the ISO 3166-2 Codes like Russia, Portugal, etc. so the exceptions list in the SAP Note 1164216 - T005, T005S content needs to be taken seriously.
In other words, national legal and business practice rules trump International standards in these cases.
So end result is to return the T005S table to the standard content, and use a mapping table to convert Spanish province codes to ISO 3166-2 codes where possible, such as in integration scenarios between solutions. Fortunately SAP SuccessFactors already provides a mapping from Internal 2-digit province code to the External IS... that helps with this.
So I hope this has solved one of life's little mysteries for you or your project, and reduced some frustration.
It's one of the joys of working with multinational and the impact of national sovereignty (i.e. "it's our country and we make the rules").
Maybe one day all countries will truly abide by the same international standards, and all behave as citiizens of a single and united world.
Life would be so much simpler for all of us in business and business software!
However since most of those scenarios currently seem to involve science fiction, an attack on the Earth by aliens, and an assortment of super heroes, I won't be holding my breath.
But even in 2020 every so often international standards can lead you astray.
Such as with one of my current SAP S/4HANA customers where they wanted to use ISO 3166-2 region codes, and came across a stumbling block. It took us several weeks and a ridiculous amount of networking to finally understand the underlying issues.
In the process I noticed several customers had asked the same question and were mostly just given the default "that's just the way things are" answer.
So hopefully this short article will solve one of life's little mysteries for a few of you.
Here's what happened.
This SAP S/4HANA customer is doing a very large multi-phase digital transformation to the intelligent enterprise with SAP S/4HANA on a hyperscaler and multiple SAP Cloud Solutions, including SAP SuccessFactors, SAP Ariba, and several others. One of the critical drivers for such a large program is to undo or remove a lot of the technical debt that had built up with modification after modification and thousands of custom code lines. So "back to standard" is a very strong mantra for this project.
Now as they have employees in over 50 countries and provide services to their customers in over 100 countries, we aren't just talking back to SAP standard here. There's a very strong push to incorporate as many international standards possible. So there's ISO values everywhere.
For the most part this approach has worked very well. After all, most SaaS solutions have similar challenges with providing services to many countries, so they align to many of these standards as well. So incorporating ISO standards has simplified data model alignment, simplified integration, and simplified user training/instructions.
There's always an exception to every rule... and it can come from the most unexpected places.
ISO region codes is not something you would expect to cause a problem. Countries and regions are an obvious place to use international standards:
- Every customer, supplier, and employee has one or more addresses that need them
- Orders, delivery instructions, and invoices need delivery and billing addresses that need them
- Financial reports typically need them for reporting to federal and regional level governments
- Manufacturing and field services rely on locations and can need country and region to determine the correct local work regulations
So you would think in a digitally-aware world, in 2020, in the 21st century, that there would be an international standard, and that you could safely use international standards for country and region codes everywhere.
Sure enough ISO 3166 is the relevant standard. It covers both countries and their regions. The regions part of the standard is designated as ISO 3166-2. So far so good.
It was already clear that SAP generally uses these ISO code 3166 values widely too, but there are exceptions.
For SAP S/4HANA the exceptions are listed in SAP Note 1164216 - T005, T005S content. T005 and T005S are the 2 database tables that hold the country and region codes respectively.
The reasons given for why SAP does not use ISO region codes for some countries are rather vague, e.g. "Legal requirements based on standard which deviates from ISO". As a customer or to a consultant this can sound awfully similar to "historical reasons" or "that's just the way SAP have always done it and no-one wants to change it now".
Furthermore, as SAP Note 1164216 explains, as a customer you are permitted to change/overwrite entries in table T005S. This is useful because regions (and even countries) can change on government decree and without a lot of warning (especially if there was a war involved in that boundary change). There's even a SAP Note with a video showing how to update the tables. SAP Note 2149999 - How to update region codes in table T005S [VIDEO]
So no problem! The project just updated table T005S with the ISO region codes for the exception countries.
Across all the program and all the interfaces between on premise and cloud solutions, ISO countries codes were working fine, and for the vast majority of countries regions were working fine as well. All the data was going through from cloud solution to on premise and vice versa, end to end processes were working fine. Or so they thought.
Then the System Integration Testing and User Acceptance Testing started to run through some localization use cases for Spain, and all of a sudden there was a problem.
When employee addresses were replicated from SAP SuccessFactors to SAP S/4HANA and the ISO region code was used for Spain, there was an error given from small and hard-coded validation check within SAP S/4HANA.
For those interested in the fine details this was the "Province to Post code check" for Spain, which insists that the Spanish region code should be a 2-digit number matching the first 2 digits of Spain's 5-digit postcode. The validation check itself was coded in ABAP Class CL_HRPA_INFOTYPE_0006_ES.
If this had been any other large multinational customer, they might have simply used the modification assistant to remove the unwanted validation. And that would have been a mistake!
Tip: Using the modification assistant, while not desirable, is technically something we can still do in SAP S/4HANA any premise solutions. Of course for SAP S/4HANA Cloud you have to abide by stricter Cloud-first rules, as per: SAP Note 2756046 - Differences of country region codes for S/4HANA Cloud compared to ISO-3166 standa...
Because the customer had such a strong strategic direction to stick to standards, they did the right thing and raised a SAP Incident via the official support channel. In the incident they asked for the check to made optional, so they could use ISO 3166-2 regions everywhere.
If you do this you will get a frustrating response, something like the below.
In SAP S/4HANA SAP uses ISO codes for regions for the majority of the countries. However there are a few exceptions - and Spain and Portugal are two of them. In this case due to Business reasons in applications SAP decided to deviate from ISO. Hence it is not possible to change these codes.
The trouble with answers like these is they give the impression that this is not a business or legal requirement but some sort of historical reason or even whimsy on the part of SAP. Not so!
Most customers generally give up at this point - and either stick with standard, or make the modification. Because of the particular mix of SAP S/4HANA and SAP cloud solutions this customer has a little more SAP executive support than the average customer so we decided to use that to delve deeper and solve the mystery:
- Why can't you use ISO 3166-2 region codes for Spain?
- Why can't SAP change the T005S table & avoid the Province to Post Code validation check?
There's even a precedent for this! In 2011, SAP changed the region codes for Ireland to ISO 3166-2 as explained in SAP Note 1641607 - Update region codes for Ireland according to 3166-2
Plus you would think with all SAP's Intelligent Enterprise activity and data model alignment across the related SAP any premise and cloud solutions, now would be a great time to fix all those exceptions, once for all.
Well, several weeks and a LOT of networking later, we finally came across someone who could explain why not, and it's as simple as this:
For Spain, it is not only a legal requirement to provide numeric province codes (and not ISO codes), it is also a business practice at Spain to use the numeric codes. For example:
- Spain's tax office uses a 2-digit province code for tax reporting
- Many Spanish financial statements are required to be reported to the Spanish government using the 2-digit province code
- Because of this Spain business practice is to use the 2-digit province code and not the ISO code
If you are interested, you can even take a look official references from the Spanish Tax Agency (you can swap the site to English in the bottom right hand corner of the webpage). One examples from the site is shown below:
Naturally SAP has had customers based in or operating in Spain for many years. So SAP's financial reporting and general business operations for Spain supports Spanish business practice and legal requirements, and so uses the 2-digit province code and not the ISO 3166-2 region codes.
There are other countries with similar issues where it is not possible to use the ISO 3166-2 Codes like Russia, Portugal, etc. so the exceptions list in the SAP Note 1164216 - T005, T005S content needs to be taken seriously.
In other words, national legal and business practice rules trump International standards in these cases.
So end result is to return the T005S table to the standard content, and use a mapping table to convert Spanish province codes to ISO 3166-2 codes where possible, such as in integration scenarios between solutions. Fortunately SAP SuccessFactors already provides a mapping from Internal 2-digit province code to the External IS... that helps with this.
So I hope this has solved one of life's little mysteries for you or your project, and reduced some frustration.
It's one of the joys of working with multinational and the impact of national sovereignty (i.e. "it's our country and we make the rules").
Maybe one day all countries will truly abide by the same international standards, and all behave as citiizens of a single and united world.
Life would be so much simpler for all of us in business and business software!
However since most of those scenarios currently seem to involve science fiction, an attack on the Earth by aliens, and an assortment of super heroes, I won't be holding my breath.
- SAP Managed Tags:
8 Comments
