Should you use single or multiple databases for international NAV implementations?

Can I use my Microsoft Dynamics NAV in multiple countries on the same install, thus on a single database? It’s one of the most frequent questions about international NAV implementations, and the answers tend to vary depending on who you ask. Let’s bust the myths!

What is the problem of having a single NAV instance for several countries?
Basically and put simply, there are two main problems:

• Local legislation and statutory requirements vary from country to country
• Most organizations have different internal processes – and are therefore un-harmonized organizations.

In order to run on a single instance, you must make sure that your processes that utilize the same code in the system are standardized or at least harmonized so that they can co-exist in a database. So first of all you need to make sure that you understand your processes.

Typically, in a company some processes are in areas that are consistent, and other processes are in areas, where there are different local requirements from country to country, and therefore an area of conflict. Typically, the processes that are key in any ERP implementation (and therefore also in international NAV implementations) belong to this last category.

 

International NAV implementations: the localization factor

Isn’t it just about running a worldwide version of NAV and applying a few additional fields and reports, collaborating with a local accounting firm to make the reporting compliant with local requirements? I wish it was that simple, but it rarely is.

I’ve made the analysis several times, every time with more sophisticated elements to figure out how difficult or easy it is to apply two countries or more in one and the same database. The picture below shows the complexity of localization from one country to another based on the size of the localization documentation. These are just the changes required on top of the Worldwide (W1 version) – which in some cases are huge, and the reason why Microsoft is providing localized versions of NAV either directly or via localization partners.

 

The difference are typically critical compliance requirements that are absolute must-do. Many of the differences are linked to financial processes. Before you decide to deploy your ERP in multiple countries you should always make a simple analysis like the one shown below for Germany:

 

In reality, for many countries it’s not like an overwhelmingly complex localization, but very often the requirements conflict on code-level in the application, and then it becomes tricky to maintain – especially because Microsoft is releasing patches to the localization as part of their cumulative country-upgrades, and then, what should have been an automated process becomes a manual process to merge and maintain.

 

Succesful international NAV implementations are all about localization strategy

There are pros and cons for running a single database vs. country databases. Sometimes we build single instances, but then we apply a minimal localization strategy to reduce the number of potential conflicts, and to some extent utilizing external accounting firms to finalize the reporting. It’s not very easy to maintain, but there can be business reasons for preferring this type of setup.

The most common localization model is to develop a company CORE including all required functionality to support the group in a NAV worldwide version, and then apply the country localization on top of this. It’s a fast, flexible and a proven way of working.

 

But in fact there are many ways to secure statutory compliance of your NAV:

•    Minimum localization (Slim)
•    Full localization (traditionally provided by MS)
•    Rich (provided by MS partners)
•    Regional Cluster Localizations
•    W1 with Interface to local solutions
•    W1 or slim with local CPA collaboration

Localizations have to be seen in a bigger picture where support structure, application life cycle management, upgrades, process harmonization and economy are evaluated and fitted together.

Many companies get in trouble when implementing in multiple countries because they get started the wrong way or with the wrong perception of what it takes. Getting it right the first time is so much easier than having to deal with cleaning up the problems afterwards.