Hello,
i have a question on implementing financials in a database, intended for different countries (companies). My customer has a belgian NAV 5.0 version, wherein another country (UK) - company, should be implemented. Does anybody see any difficulties? Anybody experienced? Are there differences in VAT, assets, etc... in UK version and belgian version?
Thanks in advance!
0
Comments
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
BE has some changes though to other country versions: E.g. the G/L No. is a text instead of a Code field in UK. In Sales & Purch Documents you always have to fill the Journal Template. This does not exist in other countries.
We always had a meeting with a local Partner first to check the differences between country versions.
FD Consulting
Also, think of moving to RTC. It's much easier to first start with one country, eliminate all the issues and then roll it out to all the other countries.
I see many advantages in hosting different databases for different countries whereas I see only one advantage (convenience for the programmers) if it is the other way round. But that's maybe accommodativeness.
You definitely should take a look at the different databases first to decide with which country version to start and which module to take from which country version. In the end the DE version was a good starting point.
Of course one of the first things you create are 2 fields in Company Setup and a single Instance CU:
- Company Country Code (Relation to Country)
- Company Code (Relation to new table Company, Data for all companies)
- CU Global Params with Functions like CountryIsDE, CountryIsUK, CompanyIsA (Single Instance so that NAV only loads it once)
The main benefit is that you can be absolutely sure that there are no differences in the code base and that you can very easily create Intercompany functions.. If you have different DBs per Country (with different partners) then after some time the code base will become different and you get problems in updating the DBs with some Add-On Code. Of course Intercompany functions are also possible. They will simply need some more work.
And of course you have the cost side. All companies will need to buy the user objects.
This setup only works if the Customer has it's own inhouse development team.
FD Consulting
Intercompany functionality is available in standard. You simply have to use it in the right way, which needs of course some preparation and training.
You would always need seperate partners in the countries as not all country specific modules could be bought and supported in other countries.
As I already said the code will be different anyway. It's just bundled in one object set, but within these objects the code will differ depending on the users home country. From my point of view that makes it even harder to analyse, debug and support issues.
Of course your release management has to be very clear and programmers have to work very accurate to avoid merge bugs. But that's something I would expect anyway.
Costs is another topic where one could argue in different directions.
What about concurrent users? Who decides how many users per country are allowed to open the database? And what will happen if the limit is reached? Which country has to buy additional user licenses?
What about NAS functionality? You'll have to buy another NAS for every additional country. (I know it depends on your version and there are some solutions to deal with it.)
What about database limits and performance? What about hardware sizing?...
Intercompany: I did not talk about the standard IC functionality which is ok but nor more. I am talking more about functions directly integrating 7 companies. Programming with Changecompany.
The local partners you only need once for a small amount of time. Of course some things you need to renumber (or the local partner). And yes, you have to follow updates not only in one country but in 2 now.
The differences in code are not so large that you have a "case Country of" construct in every Table or CU. Integrating BE and UK (that is where the question came from) there are not many differences.
Concurrent Users is actually easier. You don't need to buy 2 licenses with exactly 20 and 25 users but you buy one with 45. It simply does not matter in which company someone works. In this setup all NAV related IT cost is in 1 country and will be recharged as a usage fee to the other companies.
NAS you need per country but this is not different whether you have 2 databases or 1 with 2 companies. Hardware sizing of server/Performance does not really make a difference. On SQL level every company has it's own set of tables. There is no big difference to having 2 databases on the same server.
Coming back to the original question: UK and BE in one BE db? Maybe the main question is why the customer thinks about this. There are good reasons to do it and there are good reasons not to do it. So first analyse why the customer (or maybe the partner?) wants it and then decide.
If the customer does not have inhouse NAV business consultants/developers don't do it. In this scenario the customers IT takes the role of the NAV partner. The NAV partner(s) sinply holds the license and is used as a consultant. Not more.
FD Consulting
I think you never had to discuss about recharging fees with the companies in a group. Why should BE pay for users or objects that obviously are needed in UK? Your fee management has to be much more complex. That'll lead to more work. Or you and the countries have to accept that one country benefits more from your way of charging fees than the other countries.
One NAS per license is free. So, it does matter.
I never said that two databases have to be on one server. Of course that all depends on your current and future situation and what you exactly want to achieve.
:thumbsup:
Just for interest, why do you think it depends on whether or not the customer has his own IT department?
Both a single database and multiple databases have their advantages.
Official statement and advice from Microsoft is a single db per country. This is by far the easiest from a maintenance perspective.
I know Frank for a couple of years now and he is very knowledgeable of this subject. He works for one of the largest multiplecountry database customer I've seen and does an excellent job there.
Another specialist company to contact would be Partner Power International. (PPI).
We have "integrated" UK into a DE database by importing a few reports and buying some reports "every uk customer needs" from the NAV partner. All the other objects we did not touch.
Integration of BE version is adding a few fields to Sales/Purchase Header and updating the posting functions. And yes, you either renumber the payment module (~20 Objects in 2.000.000 range) or analyse it and just import the 2 necessary reports into the standard payment journal of DE.
Yes, we had the discussion about recharging fees. The solution was easy. Every company involved is charged a mothly fee per User which covers everything: Access to Citrix, Maintenance of Citrix and NAV, helpdesk, bugfising and even new functionality (at least the simple ones). The more expensive ones are quoted to the company and they have to pay for it. Very simple, very unbeurocratic. Yes it means that one company pays for functions they willnever use (e.g. sales and purchase although they are a finance only company). The discussion was actually not very long and the solution was more or less immediately accepted by all companies.
One NAS is free per company, ok. So we have to pay for NoOfCompanies-1 NAS additionally. But we can easily do things like creating Jobqueue entries in a different company automatically updating data (Yes, this can be done also when using separate databases, it only takes more time and effort)
Inhouse consultants/developers are in my eyes essential as a local Partner which holds the license has no interest in this scenario. For the NAV partner it is simply too much work with too less income. Partner would need to train its own developers to be bale to support not only the local NAV version (here DE) but also all the others. Helpdesk at Partner would need to answer questions like How do I create a bill (in spain) or how do I post a bill of exchange (in FR).
Every change request needs to be evaluated by the partner. In worst case partner needs to fly to Belgium, UK or NL to discuss CRs and then quote to the customer. Cost for the customer is too high while workload for Partner is also too high. If customer has no internal guys no one will be able to validate the CR: Is it necessary, good, bad?
The partner will never have the same standing with the "foreign" customers as an internal IT has.
If you have internal NAV guys they will take the role of the Partner for all the other companies. They build up the knowledge about the country versions, they do helpdesk. they have to discuss everything with the foreign companies, evaluating requests. Yes, some money you save on the license goes into travelling or phone conferences.
The local IT can "forget" requests or delay requests while a partner cannot easily do this.
As no local partner has access to the country databases you have absolute control over the code base. No one is creating things you don't want. No one is changing something in France (because someone in France wants it) although it will break the reporting system (which they did not realize and the french partner did not care about).
FD Consulting
FD Consulting
We've got twelve countries in Europe and ten in Asia. Some countries hold more than one company. We started a couple of years ago with a merge of DE and CH who are very similar. Since today we get some issues because of this merge.
You should be very happy that your discussion about the fees was that smooth. Some of our countries do have better processes and are better organised than the other ones. And of course that leads to less effort in maintaining and supporting these countries. So, they are asking every year why they should pay that much although they use the support only very rarely.
Yes, we decide for every change request if it is really necessary and if it is helpful for all countries. And for large changes we talk to every country beforehand (which doesn't mean these days you have to fly to every country). That means you must not follow each and every wish from the countries just because they are separated into different databases. If you would do that then you would get very soon to a point where your maintenance, update and support effort becomes too high to manage it.
I see some problems if everything is controlled by one partner in one country. Your dependency on this partner and maybe on single persons at this partner is too high. I think it's better to talk about certain issues in some countries with partners in that country. I hope you'll never have but in case you would have an accident, could you guarantee that your company could support your customer in the same way and quality than you did? Are you sure you know about every legal requirement of the countries of your customer?
I see where you're coming from when you say an internal IT department is needed. I totally agree with you on that. But I think all you mentioned is also applicable if you do it in one database. So, in my opinion you need someone at customer's site who takes care about all these things and processes. If you definitely want to merge your countries into one database and rely just on one partner that won't prevent the customer from the need of using his head.
Edit: Maybe this topic (http://www.mibuso.com/forum/viewtopic.php?f=23&t=49009) is also of interest.