Different countries in one database

micieborismicieboris Member Posts: 7
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!

Comments

  • ara3nara3n Member Posts: 9,256
    We have implemented UK company on NA version and it has worked fine. There are bank integration "BACS" that your company might use but you can rip it out of UK db and put it in your local db.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • FDickschatFDickschat Member Posts: 380
    We had integrated UK, BE, NL, DE, FR, ES in a DE database. As Rashed pointed out you might need BACS. The UK db also has a separate Accounting Periods table which is not necessary. Some reports exist which are mandatory though.

    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.
    Frank Dickschat
    FD Consulting
  • einsTeIn.NETeinsTeIn.NET Member Posts: 1,050
    I would never merge two or more country specific databases. Sooner or later you'll come to a point where you'll get in trouble because the business logic doesn't match in certain objects. Then you would need to add some programming to decide whether one piece of code should be executed based on the home country of the user. So, you'll have a lot more work in support, maintenance and update afterwards.

    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.
    "Money is likewise the greatest chance and the greatest scourge of mankind."
  • FDickschatFDickschat Member Posts: 380
    The complexity differs per Country. You can very easily integrate DE, UK, BE, NL, BG and FR (and even CN and SG). ES and IT is a completely different topic and with todays experience I would probably advise the customer against it.

    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.
    Frank Dickschat
    FD Consulting
  • einsTeIn.NETeinsTeIn.NET Member Posts: 1,050
    It also depends on the modules you want to use in the countries, e.g. Payment is very different in the countries you mentioned. And I'm sure you know about the situation regarding German Cost Accounting.

    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?...
    "Money is likewise the greatest chance and the greatest scourge of mankind."
  • FDickschatFDickschat Member Posts: 380
    Payment and Intrastat is always different. But in the end payment is more or less different file types. FR payment is very different (but after you have understood it it is the most flexible of all).

    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.
    Frank Dickschat
    FD Consulting
  • einsTeIn.NETeinsTeIn.NET Member Posts: 1,050
    FDickschat wrote:
    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.
    I see 743 country specific objects in UK and 427 in BE. Maybe we have another understanding of how much effort is needed to create, maintain and update these objects.
    FDickschat wrote:
    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.
    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.
    FDickschat wrote:
    NAS you need per country but this is not different whether you have 2 databases or 1 with 2 companies.
    One NAS per license is free. So, it does matter.
    FDickschat wrote:
    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.
    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.
    FDickschat wrote:
    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.
    :thumbsup:
    FDickschat wrote:
    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.
    Just for interest, why do you think it depends on whether or not the customer has his own IT department?
    "Money is likewise the greatest chance and the greatest scourge of mankind."
  • Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    I agree with most said in this thread.

    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).
  • FDickschatFDickschat Member Posts: 380
    You are right with the pure number of objects but most of these changes you simply don't need. This is where the first meeting with the local NAV partner is essential. You need to find out what you need and what you don't. And I don't mean Objects but functionalities.
    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).
    Frank Dickschat
    FD Consulting
  • FDickschatFDickschat Member Posts: 380
    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.
    Thanks Mark :oops:
    Another specialist company to contact would be Partner Power International. (PPI).
    I fully agree.
    Frank Dickschat
    FD Consulting
  • einsTeIn.NETeinsTeIn.NET Member Posts: 1,050
    That's exactly where I'm coming from. One day you start merging and it belongs only to a few objects that are really needed. Later processes might have changed, business needs have grown, the group expanded to another country... then the merge process becomes larger and larger and its complexity increases and increases.

    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.
    "Money is likewise the greatest chance and the greatest scourge of mankind."
  • micieborismicieboris Member Posts: 7
    :D Wow, thanks for all the feedback guys! I will take your remarks, and consider the different possibilities. Thanks again!!
Sign In or Register to comment.