Adding German objects to NL Database

mdPartnerNL

We have a NL Customer who is expanding to Germany. At this moment they want to create a German Company and we must add specific DEU objects.

1.
Is this doable? How much time will it take?

2.
Later on that German Company will be buying a new DEU license. Can we backup that Company and restore to a DEU database?

panosk

1.
It is doable, but take some time, but I would not advise to do this [-X , I would advise using the German database and not inserting the German local functionality into a Dutch database, this will give you much trouble down the road. If you only do some basic stuff like purchases and sales just create a new company in the Dutch database and with German ledger and posting setup. Then when the German database is purchased you can transfer the financial information (open customer balance etc.).

2.
No object set would be different.

mdPartnerNL wrote:

We have a NL Customer who is expanding to Germany. At this moment they want to create a German Company and we must add specific DEU objects.

1.
Is this doable? How much time will it take?

2.
Later on that German Company will be buying a new DEU license. Can we backup that Company and restore to a DEU database?

mdPartnerNL

Option:
Can I open a German database with a NL License? I expect to transfer some DEU objects to NL object range but use the same functionality.

mdPartnerNL

Little bump to get renewed attention. Sorry for this.

Marije_Brummel

This is a tough question.

Technically everything is possible, but not always recomended.

Germany has two layers, the legal layer and the DACH add-on database. Which one do you need?

Implementing some of the legal issues in the NL database can be done quite easily, but I would never implement the entire DACH add-on in an NL database.

It's almost easier to go the other way around, e.g. start with the DACH database and implement NL objects since they are far less in quantity and complexity.

If your end-goal is to implement a seperate database anyway I would not merge anything.

With a partner license you can open any country database but a end-user license cannot.

einsTeIn.NET

Mark Brummel wrote:

If your end-goal is to implement a seperate database anyway I would not merge anything.

I would even say if that is your end-goal then you should think about if another goal could be a better choice. I can tell you from our experience that it's not very nice to mix business logic of two different countries. We started with a merge of Germany and Switzerland. These two countries are from NAV Object point of view not far away because the base of NAVDACH Objects are the same. But there are Add-Ons, country specific changes, some slight differences because of hotfixes that cover legal issues, ... and so on and so on. So I think it's much easier (support, update, maintenance) to have two different databases.

Mark Brummel wrote:

With a partner license you can open any country database but a end-user license cannot.

Yes, this is also an issue. The language of the licence must match the language of the installation. That means maybe you have to install all your clients again from W1 installation package. Furthermore CaptionML property must be set for each and every object.

kriki

[Topic moved from 'NAV Three Tier' forum to 'NAV/Navision Classic Client' forum]

mdPartnerNL

Mark Brummel wrote:

Germany has two layers, the legal layer and the DACH add-on database. Which one do you need?

1.
Im not sure where the DACH Add/on is for ?

The legal layer must be implemented, i guess.

2.
I just tested a DEU database with our development license.

Tables
3010501-5005363 Can Edit
5055250-5055272 No edit possible

Forms
3010501-5005399 No edit possible
5055251-5055293 Can edit

Codeunits
5005350-5005351 No edit possible

3.
We have another DEU customer who started with the NAV BA from Germany. They use our addon. For this our development license was modified with the DEU objects.

Marije_Brummel

A partner can requist license files for all countries in their region (America's, EMEA and Asia) and AFAIK recently refresed licenses should have more permissions since there was an issue with the license system.

Every localisation has two pieces.

1. Legal issues

These are issues that you really need to do business in that country to be for example tax compliant

2. Competitive advantages

A couple of years ago localisations were done in each country and apart from the legal issues, these localisation teams developed features that they found where absolutely nessesairy to be able to be competitive in the local market, for example in NL you can import the Post Code table and validate its validity. Technically and legaly you don't need them, but for a company its hard to use the system without.

Most countries have 1 and 2 combined in the download from partnersource. In the DACH region they decided to split them in the general download database and a special DACH "add-on".

More information can be found on partnersource and with every German partner. (I am only a Dutch guy).

Maximus

At the company I work for we have Belgian, Dutch, French, German, Greek, Italian, Portugese, Spanish, UK and USA databases. As an Administrator I am pretty happy that we have decided to only have one localization per database. Much easier to manage because we use a W1 kerneldatabase to do all customizations in and deploy from there to the localized databases. This has to do with the fact that a localization consists of two parts: there are country specific (seperate) objects which don't conflict with other objects. But there are also local changes in general objects like Codeunit 80 and these can differ and even conflict when you merge them. To solve this you can program IF THEN clauses, but this is a lot of work.

Also I was told by our accountants, that in some countries it's not legally permitted to have more than one localization in your database.

Finally I would advise you to think on a long term base about this. Now you are thinking about merging two localizations into one database which is doable. But what if the company expands and you have to add a third localization or a fourth one? Trust me: don't merge localizations.

Regards, Max

DenSter

I just want to say that it IS possible, it HAS been done successfully a number of times. Personally I was involved in a one-database implementation in which localizations for NL, DE, FR, UK, UK and IT (and I think some far eastern localizations were added later on too) were merged into one code base, and each localization was its own separate company (with extensive customizations as well). Due to licensing restrictions we had to renumber most of that into custom ranges, which is very impractical. To divert code for localized processes, if I remember correctly, we had a LOT of CASE statements and creative exits out of some of the code.

Looking back, I don't know that I would recommend going that way, but it is certainly possible. I think there's something to be said for multiple databases, develop customizations in a W1 baseline and localizing each mod out to every other database. On the other hand, having one code base forced us to make everything fit.

Practical? No. Doable? Absolutely. Expensive? Heck yes!

Miklos_Hollender

We have merged Austrian and Italian localization (this is a big one), and it roughly looked like this:

- Generally it is not possible to have two localisation ranges in once licence, i.e. two countries. Only through Internationalization.
- So we purchased the Internationaliztion granule in the licence.
- Moved Italian objects into Internationalization range.
- Change the GUI everywhere so that Italian menu items are in their own menu, fields are on their own tab etc. not disturbing other users.
- Also, settings to make Italian localization logic work only in the Italian company

It was a major work, but the advantage is that now we can have an Austrian company and an Italian company in the same database, both technically works well, and we can legally use just one licence for it. This saves a lot of money in licence price and maintenance fees in the long run.

Marije_Brummel

How can it save on the license?

With BRL you pay per user so you might as wel have two licenses?

Just curious.

einsTeIn.NET

@Miklos
And now think of what will happen if you (or your customer) starts a new company in a third country.
How do you implement country specific changes from hotfixes, Service Packs and Add-Ons? You will always have to merge them on your own. I'm not sure if you consider all the maintenance and licence fees against all the effort and time of merging and maintenance by yourself, did you really save money?

DenSter wrote:

Practical? No. Doable? Absolutely. Expensive? Heck yes!

I guess this is the right answer in summary.

Miklos_Hollender

einsTeIn.NET: I will merge them in. They are not that many and I have the time. Not that hard. Most of them are not really necessary. If you are an external consultant then of course you need everything to cover yourself and because you have little contact with users daily. I am an internal now. I sit next room to accounting. They just come and say if they think something important legal change needs to be covered. Easy.

DenSter

Miklos Hollender wrote:

Easy.

Yep, and you just added a LOT of money to the next upgrade project.

Miklos_Hollender

Given that any upgrade above 2009 would mean going over to RTC and that would be a huge pain in everybody's backside... I don't see that coming for a long, long time. Putting it in other words, upgrading to the RTC will be difficult anyway, many custom reports and suchlike, will only happen if it is very, very justified or absolutely necessary (like newer versions of Windows not suppporting Classic), and in that case merging some localisations will not mean much of a difference.

einsTeIn.NET

Yeah, ...and you save your position.

Miklos Hollender wrote:

It was a major work, ...

Miklos Hollender wrote:

Easy.

Isn't that a contradiction in terms? 8)

To be serious, no one said that it wouldn't be easy for an experienced NAV developer. But I don't see any essential benefit.

Miklos Hollender wrote:

... but the advantage is that now we can have an Austrian company and an Italian company in the same database, both technically works well, and we can legally use just one licence for it. This saves a lot of money in licence price and maintenance fees in the long run.

All the effort you have to do on your own just to have one database instead of two? ...just to save a little bit of the licence fees? Have you set your time and salary against that? I'm sure you could do much more meaningful work in that time.
I also work for an end-user and beside all things I already mentioned, from a company's point of view it's very important that

• someone could easily take over my work if I'm gone
• upgrades and hotfix implementations are as easy as possible
• some partner or producer is responsible for any kind of issue in standard objects (of course the company should be happy if an inhouse employee is able to fix it in a fast way, but (legal) responsibility should be on the partner's/producer's side)
• if there's a major issue with the system of one country then it shouldn't effect any other country (I know there're situations where both databases are affected but the risk is lower if you have one database for each country)
• ...

Miklos_Hollender

On the other hand, the ability to make consolidated stock, sales, etc. reports all over the group with a simple CHANGECOMPANY in a loop is golden. A lot better than messing about synchronizing stuff into linked tables or linking SQL views into tables or something. As long as you are a fairly simple company who buys and sells stuff, your localizaton needs, hotfixes and legal updates in most EU countries are generally low (Italy is an exception) and generally apply in all countries like the EU-Service thing in 2010 December. However, easy consolidation (CHANGECOMPANY) of stock, sales, purchase, finances, is very important. Management wanted to know stuff like total outstanding PO value in all subsidiaries, I simply wrote a report that loops through all companies, done. Really easy. I think overall it worths it. I have a reporting table based on item ledger entries in all companies together plus a few new fields from other tables, and its like almost every report ever they need, consolidated globally, is just like copy-paste to excel and throw up a pivot table. Really awesome.

DenSter

It's always a cost-benefit question isn't it

As a developer I always loved having all of it in one database, but I can see how the sheer amount of development (the customer I'm talking about had massive amounts of customizations on top of combining the localizations) would only be available for companies with deep pockets, or have their own developer in house. You must still have access to a partner license.

einsTeIn.NET

NAV is neither a consolidation tool nor an MI / BI platform nor a data warehouse system. I can see your point, it's very easy to create management reports for the whole company group out of NAV if all companies are in the same database. But it's also very simple if you have two or more databases and use the right tool that is build to deliver exactly such kind of reports.