Our support engineers have assembled the top recommended solutions for you.
Microsoft Dynamics AX 2012
Data Import, Export, and Migration
Upgrading to Microsoft Dynamics AX 2012
Microsoft Dynamics AX 2009
Application Object Server (AOS)
Enterprise Portal and Role Centers
SSRS and SSAS Integration
We have renamed the 3 digit country region code with corresponding 2 digit country region code in ax 2012. After databse synchronization we had 3 digit as well as 2 digit country region code in the system. If we delete those 3 digit code and do databse synchronisation then still we get both country code(2 digit and 3 digit). If anybody can tell us that how we can prevent to create those 3 digit country region code during database synchronize, it will be appreciated.Tables are - LogisticsAddressCountryRegion and LogisticsAddressCountryRegionTranslation
When you install AX2012 and initialize the system, AX will create about 260 country/region codes with a mark in the field "IsImmutable". This field indicates that you should not touch these records. The standard AX logic prevents you from changing these records.
AX2012 is shipped with these countries because of a reason. Microsoft has chosen for the 3-digit ISO coding for the countries.
You have to know that some country specific features in AX depend on this table and the 3-digit codes.
So please use the country codes shipped with AX2012. It is not possible to use the 2-digit. The ISO-2 code is available as a field as well, so for integration with other systems it is not a problem.
André Arnaud de Calavon | Microsoft Dynamics AX Solution architect | My blog | My company
This post is my own opinion and does not necessarily reflect the opinion or view of my company, Microsoft, both its employees, or other MVPs.
"If it ain't broke, don't fix it"
Zvika Rimalt * Dynamics AX Business Analyst/Functional Consultant * Vancouver, BC, Canada
Unfortunately... Country codes are not static because humans are so fond of killing each other, so labeling ANYTHING like a country code as Immutable is dumb. While I don't see the point of attempting to override the use of a 3-byte (not 3 digit) country code, I see the advantage of providing a proper and correct list of ISO Country Codes in AX. Specifically, the ANT country code "Netherlands Antilles" no longer exists having been replaced by non-Dutch entities. This table has records in it that should be removed allowing the ANT Country code to be removed. Otherwise, some unsuspecting user will attempt to use it, and then we'll find that the shipping application won't ship it since that country code doesn't exist.
The country list already contains the proper ISO 2-byte code for each of the countries, and it is still possible to add new countries if necessary.
Indeed, it is not possible to delete existing countries, which is a flaw, but personally I found this flaw to be offset by the fact that I get, out of the box, a comprehensive list of countries, rather than having to waste time creating them in each instance from scratch.
@Zvika -- the word "comprehensive" is inaccurate once you compare to the official ISO sources. I found several differences; specifically ANT doesn't exist anymore, and the following country codes were missing: BES, CUW, ESH, SSD and SXM. I also found errors in Canadian province codes and Mexican state codes compared against their respective postal websites -- another 10+ errors. And, finally at least it's an issue in the US, they were missing the 3 Armed Forces state codes. I appreciate the record sets being provided, however we need to be responsible to validate the values and correct them.
At time of developing AX2012 it is possible that the ISO source had other contents. I have not checked this. We all know we are living in a world with changes. The missing countries and states can be added if needed.
If you decide to have an old country code deleted, you can also use XDS for restricting this value.
then you don't have to bypass intended AX logic.
I also suspect that the countries of BES, CUW, ESH, SSD and SXM are only relevant to 0,000001% of AX implementations.
On the other hand, the fact that there is a pre-loaded list of countries, is valuable for 99% of implementations.
@Zvika -- I'm happy with the pre-loaded list of countries, but not with the restriction that I can't delete one if it's a "deceased parrot" (montypython.50webs.com/scripts/Series_1/53.htm). These SQL statements will allow the specified country code to be deleted -- though you should delete the country code using the AX Client to assure that any existing references are properly maintained (cascade/delete).
set IsImmutable = 0
where IsImmutable <> 0
delete from LogisticsAddressCountryRegionTranslation
where CountryRegionID = 'XXX'
and LanguageID <> 'yyyyy'
Please read all previous remarks above again carefully. The field IsImmutable has a name with a meaning. Immutable means "do NOT touch it". Other solutions were provided. Why do you ignore warnings? If you will encounter problems because of deleting the countries anyway, it is at your own risk.
I think it is not a wise decision to bypass intended functionality. For sure not if the field has a meaningful name.
@Andre -- I'd noticed that when I add new countries (there are several) using the proper AX interface, that the IsImmutable flag wasn't being set. That means I could delete the countries that I add, but not the ones that MS added. Why is that? Why is their data special? It's just data (assuming all referential integrity rules are followed). Just because someone at MS assumed that countries would never, ever go away doesn't mean they won't. I appreciate MS's IsImmutable assumption, but it's incorrect as a rule.
This webpage (geography.about.com/od/politicalgeography/a/missingcountry.htm) shows that lots of countries have ended their existence, such as – Burma (now Myanmar), Ceylon (now Sri Lanka), East and West Germany (now Germany), East Pakistan (now Bangladesh), Hawaii (now a US state), Persia (now Iran), Rhodesia (now Zimbabwe), Siam (now Thailand), North and South Vietnam (now Vietnam), Texas (now a US state), Tibet (now part of China unfortunately), USSR (broken up into 15 countries), Zaire (now DROC) and way, way more examples…
Question: At what point are we allowed to use REALITY as a guide to the world around us, and ignore the line in the sand that some misguided DBA pulled out of his a$$?
Just imagine keeping East and West Germany in the table for the users to choose (because there isn’t an inactive flag in this table). Which would they choose? East Germany, West German, or plain old Germany? Are your users smarter than a 5th grader? Mine aren’t. I choose science.
My apologies if I offend.
I know your frustration about this topic. I don't feel you offended, neither did I. As I know that some functionality depends on this table, I would not delete, but hide the old countries with use of XDS. Recently I indeed had to add Aruba as country. The Antilles are not used anymore. If needed, we simply hide them.
I think deleting some companies does not hurt when there are no features depending on it. But I don't take this risk.
Oh...yes indeed you can delete your own created companies. Then MS assumes no functionality is depending on this table,,, however you could create your own country specific features...
No worries -- just a n00b trying to make sense of this huge and complex product (haven't learned XDS yet). Once am in this for a while (2 years?) I expect to be more conversant. Cheers and have a great day.
For more information about XDS you can read this whitepaper:
Also I wrote a blog with another example. Maybe you can pick the concepts from this post as well:
Other Microsoft Sites
I'm a Customer
I'm a Partner
Follow Microsoft Dynamics