We are on our way expanding to first country abroad (a new company there). Naturally follows the question how to set up NAV.
Same database and multiple companies would seem reasonable for three reasons:
Now we have been discussing with different NAV software vendors - many of them seem to think that it can require much work to set up multiple localisations. Instead they are suggesting a new clean install - into a newer version.
Out of accounting perspective this seems odd - shouldn't NAV check the country code of the company and automatically fetch the right setup or definitions. So only import new localisation tables etc and start running the business? Ok, few new reports may be required?
???
*This post is locked for comments
BC looks the same as Nav in the regard of multiple localisations. I have seen that the mappings for the overlapping code units etc can be performed but given the scale of work and the issues with upgrades it looks like it is not financially viable. The only option is to install multiple BC systems on separate servers. One installation/localisation for each country. Then the consolidation is a mine field in SaaS but might be better in on prem. The whole concept of companies requiring an ERP solutions that will be rolled out for all their office around the world seems to have escaped MS in the BC context. BC is a hindrance to this concept rather than a solution. If anyone has successfully merged two or more localisations into one installation I would like to know how and what happens with upgrades and patches.
Noticed this old thread of a topic currently in my interest:
Is this case the same with the MS Business Central?
So there should be separate DB's for different localization packages?
Looking for a solution which is planned to have one DB, but separate Companies for different countries.
Hi,
as a rule of the thumb any country specific localization requires a separate database. I understand what you're saying about system 'knowing' which localization to use, but the truth is that localisations are developed separately and might clash if you try to apply two different country localisations to the same DB.
If the localization is the same (for example UK and Ireland, or Belgium and Luxembourg) then there is no problem in running the same DB and different companies, where the difference is only in setup (for example VAT). Otherwise it is still technically possible but depends on the amount of localisations for the country(ies), for example, merging French and Portuguese localisations might be very tricky from the development point of view.
Also, if there are any special characters in the language, you need to consider that as well as there is a compatibility issue in displaying foreign characters (some work fine, again depends on the countries you're talking about).
Robertas
It's better different DB. If you are planning to customize one db to fit all localizations, you may end up in a mess. Moreover, if you are planning to upgrade in future, it would be nearly impossible.
The upgrade toolkit differs on localization.
May be you need to study the localizations and based on that need to take decision.
Posting routines will be same with required/different conditions according to localizations need and it is not just VAT as it may have other taxes also which is built in localized DB with required parameters.
Thank you for fast reply!
I am just wondering that both countries follow very similar regulations and eg. posting routine should be very similar - of course VAT codes or VAT percents are different but otherwise. Still huge customization needed?
Each country has different localizations and based on that MS provides different database for those country . Accommodating localizations in one DB means it requires huge customization and it is not easy to import the objects as it uses common posting routine
So It is always good to have localized DB for the country you are going to work.
Community Member
2
EH-09052238-0
1
Sohail Ahmed
1