In Dynamics Ax2012, the country/region context has replaced the country configuration keys. That brings a set of advantages. Configuration keys had to be enabled by the admin manually, and they were installation wide. If the installation included legal entities from multiple countries or regions, all were affected by the configuration keys settings. The country/region context framework uses instead the primary address of the current legal entity to determine the appropriate context.  

Dynamics Ax2012 contains a rich set of country/region specific features. They are either addressing a regulatory requirement in a specific country/region, or a specific business practice. All country/region specific features have country/region context assigned to them. Mostly in the form of a property setting on menus, and other UI elements. That property is called CountryRegionCodes, as on the example below:

Typically, all UI components belonging to a country/region specific feature, would have assigned a specific country/region code. Further, if there is an alternative code execution logic required for a specific country/regional requirement, those code paths would follow a code pattern as below:

If (SysCountryRegionCode::isLegalEntityInCountryRegion([isoCode]))

{

executecountry/region specific code;

}

Occasionally, we receive feedback from our customers and partners, which would like to use a country/region specific feature in a country/region, which is different from the one shipped with Microsoft Dynamics Ax2012. Frequent are arguments that in earlier versions of Microsoft Dynamics AX they would simply enable country configuration key which contains the feature of interest and start using it.

That is something what we discourage our partners or customers to do. Using features in a country/region different from the one for which they were designed might result in an incorrect system behavior. Every country/region specific feature is designed and tested only for the targeted country/region. There is no guarantee of a proper system function if features are used outside of those.

The country/region context in Microsoft Dynamics Ax2012 is designed to prevent mistakes during the system setup, automatically determining the proper context for a legal entity. The UI and the code execution logic will automatically adjust to that. This cannot be changed by any system parameter setup and is only driven by the primary address of the current active legal entity.

Changing the country/region context for a feature in Microsoft Dynamics Ax2012 would require assistance of an experienced developer and a developer license. The developer would need to use available reverse engineering tools to identify all components of a given feature, alter the CountryRegionCodes properties of the AOT elements across the feature scope. Further, all code paths executed in the feature flow would need to be identified and enabled for the altered country/region ISO codes. Many features have dependencies on another set of features and cannot be used independently. Identifying all those dependencies would be necessary for successful completion of the modification.

The process described above is highly risky and not recommended. Partners and/or customers would be fully and solely responsible for any such modifications.