16 Jun Language versions of a global, consolidated Dynamics NAV

The global implementation projects of the Microsoft Dynamics NAV ERP system that we deliver include the development of the Global Template to be deployed in all subsidiaries. As the system is to be used in various countries, it requires an additional language layer. Some of our international customers adopted Microsoft Dynamics NAV only with the English language version as a group standard. Such international approach was applied by Starco. In the case of this company, the problem of local languages does apply.

The approach to local language versions in a consolidated Dynamics NAV system is the issue that needs to be thoroughly discussed for global projects

A problem with language versions for Microsoft Dynamics NAV system modification

Adding a local language to a standard Microsoft Dynamics NAV ERP system version, is not a special task. If a local system version is available for a country, the language is added to the database as a part of a local functionality. Localizing modifications is a bit more challenging, however. Beside the Microsoft Dynamics NAV W1 international version, the Global Template has been enhanced with a variety of modules and functionalities that a foreign company requires for its subsidiaries. Usually, the add-on modules offer only some language versions – prepared for countries where a specific module has been implemented. On the other side, any functionalities developed by a Navision partner for the purpose of a global project originally are available only in the English language version.

What are the options of global localization for a consolidated Navision systems?

What we consider the most financially and functionally optimal option is adding the available local language layer to the system and maintaining all modules and functional extensions in the English version. We applied this solution for one of the international projects that we delivered and it proved to be the most accurate. If implementation is limited only to the English version, it may make getting used to the Microsoft Dynamics NAV ERP system more difficult for the user, especially if another ERP solution has been used before. Obviously, it might also be a problem when a global and consolidated ERP system is to be rolled-out in multiple countries, where users do not have sufficient knowledge of English.

What happens when translation for all system modifications is required?

We have already delivered international projects, for which the functionality was created from scratch (based on customer requirements) and it comprised a substantial part of the wholestandardized Microsoft Dynamics NAV systems. That was the case of the OT Logistics project which involved the development of an extensive functionality for transportation planning in Microsoft Dynamics NAV. Translation was required. As a Polish Navision partner, we developed both the English and Polish versions. In order to prepare the German version, we generated a worksheet containing all text strings and labels that were added to the standard version. The aim of the project was to develop a comprehensive module for transportation planning. The worksheet was delivered to key users in German subsidiaries, who translated the English language file into German with the assistance of a German translation agency. Upon translation, the Excel file was imported into Microsoft Dynamics NAV and the German version was ready. In my opinion, when Microsoft Dynamics NAV modifications have to be translated into a local language, key users who have a professional knowledge of their industry, are very helpful and willingly participate in the localization process with our assistance.

Managing multiple languages in a global Microsoft Dynamics NAV system

When a Global Template is implemented in a subsidiary (during the roll-out), a standard Microsoft Dynamics NAV object is merged with a modified object that is incorporated within the Global Template. Thus, it is necessary to export both the object from the local standard version of Microsoft Dynamics NAV and the same object from the Global Template, and finally merge the two.
When both objects are merged, the consolidated Microsoft Dynamics NAV system (global template) is enhanced with a new language version. This means that local languages cannot be added during a global roll-out. Each new language has to be added to the Global Template database and implemented in all countries where the system has already been put into operation. Only this approach ensures that objects in local databases will be uniform. However, this brings about huge problems with language management If we assume that each local database contains only two language versions (English and local) and that the two objects are different from each other, this means much more object management effort.

Multiple language management in Microsoft Dynamics NAV

Generally speaking, Microsoft Dynamics NAV does not fully support multi-language functionality. It is due to the method of implementing the language layer into Navision 3.0. Before this version, Navision was a single language system. The objects in each local version had their own local names (e.g. the table G/L Entry, Zapis K/G etc.). Following version 3.0, objects in the system are created in the English language notwithstanding the version. However, a special field has been designed for adding a translation. For a long time the system offered the possibility of adding only 5 such language versions. Starting from Microsoft Dynamics NAV 2013, there are 13 possible languages. However, the problem has not been definitely solved. To solve the problem, I would suggest moving translation strings from the object structure to a separate structure that could be called translation.

B2B Portal?

B2B  Portal is a separate solution worth considering. The solution IT.integro provides is based on the Joomla engine that communicates with the ERP Microsoft Dynamics NAV using Web services. The portal enables us to provide the user with the access to view information and enter data into the system, using an external application. If language versions for end users can be added only at this level, the multilanguage problem might be solved to some extent. However, this solution can be applied only if a huge group of employees uses only a limited set of functionalities.

Managing objects at the Global Template upgrade during the global roll-out of the Microsoft Dynamics NAV system

As I wrote above, if all companies have different objects on the level of a language layer, this generates change and object management tasks. This is due to the fact that the global phase of deploying a group consolidated ERP system in all subsidiaries takes more time depending on the number of business entities and their readiness for implementation. As a result, the changes have to be incorporated into the Global Template on ongoing basis during the project. Obviously, these are not changes of a critical importance for the whole concept. However, they result in change requests. Such requests are not only due to error in a standard system, but also due to the fact that within the timespan of the global roll-out, the user’s business and requirements are also evolving. Additionally, the issue of subsidiary arbitrariness at implementing the system has to be considered. We have already encountered situations when a subsidiary would decide to implement only a part of the group, consolidated ERP system, postponing the other parts for a later date. Thus, when the implementation of the Global Template in version 1 has been planned for a longer time, some of the subsidiaries might have version 2 implemented and some of them version 3, due to all modifications made as required. It may happen that a group makes a decision to implement one solution e.g. EDI in all subsidiaries, and it will have to be incorporated within the Global Template. This process will require updating such version in all countries in order to ensure that the versions used are the same.