Local Legal Requirements

in a global Microsoft Dynamics NAV roll-out project

When a consolidated, global ERP system is implemented in a subsidiary, the issue of local legal requirements always emerges. Each group ERP solution, including the Global Template (Core), comprises a database, settings and documentation. The database, among its elements, contains the international version of Microsoft Dynamics NAV W1. This means that for each system roll-out (local implementation), local functionality is required.

Local functionality for Microsoft Dynamics NAV added to the Global Template (Core)

Local functionality for Microsoft Dynamics NAV is provided to some countries directly by Microsoft or a local Microsoft Dynamics NAV partner. Southern and Eastern Europe are examples where such distinction between providers exists, which was described by my colleague in another blog post. When the Global Template (Core) database is supplemented with a functionality provided as a local version of Microsoft Dynamics NAV ERP, we obtain the system that meets local legal requirements and is compliant with the group standard. Obviously, there is some risk that when objects are merged, local functionality for Microsoft Dynamics NAV will be modified to such a large extent that the system will not be compliant with local legal requirements. How do we minimize such risk? We perform additional analyses of local legal requirements based on the Microsoft Dynamics Sure Step Methodology. When analyzing object merge results, the methodology guides us through all local requirements.

WHY IS IT NOT WORTH ADDING THE WHOLE LOCAL FUNCTIONALITY?

The other option that was used for one of our international clients, is also possible. With this option, the international Microsoft Dynamics NAV W1 version can be merged only with objects that are absolutely indispensable. However, it should be remembered that local versions of Microsoft Dynamics NAV, as other ERP systems, do not include legally required functionalities. This fact might appear unacceptable for local accountants. The other example applies to bank transfer functionality that for many years has been incorporated into the local functionality for Microsoft Dynamics NAV in Holland. Obviously, bank transfers can be performed manually and the bank transfer functionality was not incorporated into the system due to local requirements. The fact is that local functionality usually contains all elements that might appear needed in a country. But not all functions are applicable to each client.

What does local law require from the ERP system?

There is one more issue that is worth mentioning. In most countries worldwide, it is required that the system should print registers as specified by the local law. This is always feasible. Theoretically, it is possible even by means of using MS Excel worksheets. Auditors/inspectors do not investigate how operations are calculated within the ERP system. What is only controlled, it is the way the data is stored. Most auditors do not control the ERP system itself, but only printouts it generates.

Standardization, not ERP system customization to local requirements is the aim of a global project

It should be remembered that it is ERP system standardization that is the aim of a group project (global consolidation). Therefore, a group ERP solution should not be modified too much for each subsidiary (country). If it is customized for each implementation, standardization pales into insignificance. The aim is not to fulfill all expectations of individual employees or subsidiaries. The objective is to implement one standard of work for all stakeholders. It is obvious in this situation that all requests submitted by local users cannot be implemented in local subsidiaries.

How to persuade subsidiaries to adopt group standards?

For an advanced project where an ERP system was implemented in multiple subsidiaries, the problem is easy to explain. If the consolidated ERP system was implemented in multiple subsidiaries, it is not reasonable to modify its functionality due to requirements of only one of these. In this situation, it will be easier when employees from all subsidiaries understand why group standards are worth adopting. It may happen that one subsidiary realizes that other subsidiaries within the group obtain substantial benefits due to working with a standardized ERP solution. Such benefits are particularly noticeable within master data management.

Working with one global team of Microsoft Dynamics NAV ERP consultants

It is important whether the project is delivered by one consultant team or the ERP system is implemented by local partners coordinated by a global team of consultants. It is obvious that local partners are more susceptible to suggestions for adding new modifications to a group ERP system. As they do not cooperate with the client’s headquarters directly, they are oriented towards the requirements of a specific local subsidiary. You can read more on global and local requirements in the blog post Advantages of working with one global team of consultants. On the other hand, it is critical that an international company undergoing the implementation of a group ERP system should attach importance to change management. Change management requires that the project objectives are communicated accurately to all subsidiaries. In such a case, it is easier for employees in all subsidiaries to understand why group standards are worth adopting. More on group PR tasks that should accompany such projects in the post Avoid local problems and promote the project with effective internal PR activities.

WHEN IS IT WORTH ADDING A LOCAL REQUIREMENT TO THE GLOBAL TEMPLATE (CORE)?

Obviously, we are not always very strict about maintaining standards. Sometimes, it turns out that a local process or requirement is an asset worth incorporating into the Global Template (Core) and propagate within the whole organization. The Bonsus module is an example of such a solution. The module was implemented in French subsidiaries of our client. However, while implementing the consolidated ERP system in subsequent subsidiaries, it turned out that other companies within the group are also eager to adopt it. Needless to say, that if it had not been for the global roll-out of the Microsoft Dynamics NAV ERP system, other subsidiaries would probably not have realized that France uses the specific process. If such process or template is to be added to the Global Template (Core), the system version is updated which means that the latest version of the consolidated ERP system is deployed in all subsidiaries where the system was already implemented before. After the version update, the functionality is operational for all subsidiaries that use the group, consolidated ERP system and is implemented in subsequent ones.

Political issues…

The last issue is of a political nature. It is typical for an international company that some subsidiaries have a stronger position within the group and that headquarters are more likely to take their requirements into account. In such a case, the reasons for modifying the Global Template (Core) vary from the causes mentioned above. However, it is a topic for the new discussion…

Local versions of Microsoft Dynamics NAV

The issue of local functionality for Microsoft Dynamics NAV is of a primary importance in group projects. Eventually, local regulations have to be incorporated into the system, which has been deployed in subsidiaries. In order to gain a better insight into local functionalities, the structure of Microsoft Dynamics NAV has to be understood.

Local functionalities as an element of Microsoft Dynamics NAV

Let us explain briefly how the application which is implemented by a partner and used by a customer is structured. From the technical point of view, it is based on objects. Objects can be classified into the following four categories:

Standard objects – they are included within the worldwide version of Microsoft Dynamics NAV which is called This version does not provide any local functionality; it consists only of elements used globally.
Local functionality objects – this is a set of objects which are used for Microsoft Dynamics NAV development to meet both local legal requirements and custom user needs e.g. due to habits in accounting practice. Although such needs are not based on legal regulations, they are very common. Local functionality can be provided either by Microsoft or local partners in respective countries.
Add-on objects provided by ISV (independent software vendors) – these objects are used in modules which provide a functionality designed for specific industries in order to streamline specific industry processes. Add-on solutions are used commonly in implementation projects as they reduce the number of modifications to be implemented into a system.
Objects developed by a partner – a set of objects which are prepared by a partner during the implementation project to meet the customer’s specific needs.

After implementation is completed, the application is uniform, therefore the user is not aware whether the functions it uses are embedded within the standard system or a local functionality.

For many years, particularly in the years of 2003 to 2011, i.e. starting from the release of 3.7 version until the 2009 R2 version, Microsoft used to provide local functionalities for nearly 40 countries worldwide. This has been shown in the table below. Therefore, the availability issue of Microsoft Dynamics NAV local version was of minor importance when delivering global roll-out projects. In most countries where projects were delivered, partners would use versions provided by Microsoft. The situation changed substantially at the end of 2012, when Microsoft launched the 2013 version and withdrew from the provision of local versions for multiple countries. This made many local partners develop local versions on their own. To develop Polish Functionality for Microsoft Dynamics NAV 2013, IT.integro joined Microsoft Partner Localization and Translation Program.

The change in Microsoft’s localization policy had a great impact on global roll-out projects. Starting from the 2013 versions, partners have to search for local versions on their own in many more countries than before. Local versions are available at various prices depending on the country and vendor. In many countries, more than one vendor offer their local versions. Microsoft, including its local subsidiaries, is not entitled to recommend any local functionality version, as such recommendation is a breach of the principle of equal treatment for all partners.

Local functionalities have not become a primary objective of global Microsoft Dynamics NAV roll-out projects. The certification process for localized products is quite efficient and the worldwide Microsoft partner community actively deals with the gap left by Microsoft. This means that local version availability is not a problem. Microsoft Dynamics NAV is available in 150 countries worldwide. However, it should be understood that if a global project is delivered outside Western Europe and North America, the issue of local functionality comes up for discussion in many countries.

At the end, one more localization issue is worth mentioning, namely, the export restriction on exporting Microsoft products to some countries. Microsoft products (including Microsoft Dynamics NAV) are subject to U.S. government jurisdiction and may not be exported without authorization to countries commonly referred to as Group E. (There is one exception: after Russia’s invasion on Ukraine, the region of Crimea was listed – although practically, it is not a country and consequently cannot be deemed a Group E country).

Export authorization is required for Microsoft products in the following countries:

Cuba
Iran
North Korea
Sudan
Syria
Region of Crimea

This restriction means that it is not permitted to use Microsoft Dynamics NAV in such countries.