What language are you going to allow users to enter data into the system? Dynamics AX provides the application interface in 38 languages. You can read more about that here.
If you are a multi-national company implementing Dynamics AX or really any ERP application you need to decide what language you allow users to enter data into the systems.
Why is this important? Here are a few things to consider. Some of these topics you need to consider either if you are running in a single instance or a multi-instance deployment.
User language proficiency
User language proficiency. If you have a single instance deployment do users work across countries. If there data is entered into the system in different languages relative to the country that the legal entity is associated with. Can they understand those languages? For example you operate in the UK, France, Germany, China. Does the finance team work across those different countries? If you are working in multi-instances the same issue if each instance is specific to a region for example like Asia and you have corporate finance in North America. How will the corporate financials team audit the Asian instance if they can’t understand the characters that they see in the data.
Reference data
When implementing you create reference codes like reason codes, category codes etc. These will also have descriptions and get assigned to transactions. What language do you enter the data? If you allow each country to enter the codes and descriptions in the language associated with that country A. How do you educate an operator if they work on the systems. B. How do you compare data? For example if you are trying to do analysis across your countries to try to work out common defects in products if you don’t have consistent coding then you are going to have to transform that data and put it in a data warehouse otherwise it will be hard to consolidate the data for analysis. Another example is unit of measure, a specific packaging of a product might be called a BOX in North America but in Europe you might call it a PACK are they the same thing? That will be something you will have to assess in the implementation. You can only assign one default unit to an item in a legal entity and have unit conversions. Do you manage with a new corporate standard for the unit or try to run in each country as the respective unit but then when you look at on-hand across companies are people going to understand we have the same thing.
Customer/Vendor facing data
Some data you will need to translate to present on customer or vendor facing documents. For example product descriptions do you present this only in English or do you print them in a local language. There are applications features in some places in Dynamics AX that will allow you to enter translations like product descriptions and these will then be printed in the language assigned to the customer master. But there may be new data or other data you decide you want to show to a customer so you’ll need to assess if you need to customize to add a translation capability.
Customer/Vendor or other external party names
The party information is shared data in the global address book which means the Name you see for customer vendor is shared. Where is the customer entry originating from? For example someone from Sweden entering a local customer name is likely to use a keyboard with accents and enter the accent characters as per the name of the company. But someone searching for the sample company in the customer list in the US probably won’t know how to enter those character to search. If you are connecting to a legacy system that doesn’t support the language then you might need to consider adding a new field the GAB where you enter the company standard for the name without the special characters but make sure you don’t print it on documents as it won’t be pronounced correctly without those special characters.
Master Data management
If you are storing master data in another external systems like products, customer, vendors etc. Then that master data will likely dictate a data standard. That is then going to flow down into your Dynamics AX implementation.
2-tier deployments
If you are implementing Dynamics AX as a regional system connected back to another corporate system then you will need to have a data standard. This is a common deployment for Dynamics AX where the corporate HQ system might be an SAP GL for example. In these cases where it’s likely only GL journals going back and forward to the HQ systems then like not too many data language issues if the GL accounts are setup to be consistent. But if there is data like product, invoices, orders other master data then you will need to consider and manage the language the data is in.
Integrations
If you are integrating to other internal systems or external systems for customers and partners then you will need to decide on a language standard or what language each party is expecting to receive/send the data.
Data migration
What language was used in the legacy systems? If you are migrating data and in the process changing languages then you have a lot of work to transform that data on the way into Dynamics AX. Another challenge is to reconcile the two systems after the data has moved. If the legacy system is in another language you might have code page mapping problems so you’ll have to reconcile these in the transformation process. So you either need to be very select about what you migrate, keep balances etc. but consider starting fresh with creating reference data otherwise you will likely spend more time transforming data that you would using that data in the future. If possible, keep the old legacy system running for a limited set of users to access for reference or tax purposes.
Reports
Where does the report get distributed to? Some reports might need to go to external authorities like tax reports etc. Usually these will have to be in the language of the countries tax authority. Reports have two pieces of data they print. Labels and field data. Labels are the captions that you see describing what data is in that column/row/line etc. These are usually printed from the label system in Dynamics AX and so will print in the language of the operator running the report, unless they are specifically coded to pick up a language from another place like the customer master file for printing confirmations or invoices for example. Two things to consider, ISV solutions you are using as they may not be translated for all the countries you operate in and your own customization as the translations will have to be done for these. For data if it’s just numbers you will probably be ok but if there is a lot of text like reason code etc you will need to make sure the data is stored in the appropriate language for printing.
Business Intelligence
If companies are implementing a new business application they are usually doing it because of a need for better insight into their business. If they are global the greater the need for data consolidation. So the language you enter data into the system will affect the ability to compare data. So make sure reference data codes are common if you are running multiple instances or comparing data to other systems. If you are running single instance then keep the codes the same and use the translation functions to manage data there might be places were you need to add new translations capabilities. Also keep in mind the cubes and the language in which they are published.
Some common places these issues come up:
- Companies acquiring other companies that have different systems and wanting to unify systems.
- Companies that have allowed countries to operate independently with different systems in each country or region.
- Companies with homegrown systems that might have been coded in old programming languages but still need to run in conjunction with Dynamics AX.
- Companies deciding if they run multiple instances or single instance deployments of Dynamics AX.
There are a lot of things to consider and most of the time this is not something you can solve with the product but company practices analysis, people, project, data management alignment and agreement.
Cheers
Lachlan
OrganicAX 
Pingback: User interface language in the AX Client | OrganicAX·