Licensing Practices - Companies, Countries, DBs

markborges

Hello all,

I tried searching this information, but looks like some licensing issues are quite unique.

I understand that NAV Licensing is per Database, meaning that I can have 1 license for as many users, and I can simply add new companies to my Database, as long as it's one single Database. (Am I correct?)

So, we have a company in Hong Kong and we are now opening a branch in Korea. From what I understood, I have the option to create the Korean company in my Hong Kong DB, and just increase the number of users, if necessary, OR, I can go an create a whole new database for Korea, but for that I would need a new license for the Korean DB. (Am I still correct?)

If my thoughts are correct so far, what would be the technical pros and cons between creating a Korean Company in HK DB, instead of creating a new Korean DB, apart from the licensing matters?

Also, just for information, we are not considering any localization. We are using a W1 version for both countries. We opted for not using Hong Kong packages nor Korean packages. Everything is in english so far.

In my mind, for a standard point of view, I would keep separate DB's for growth in the future, and the option to include the Korean pack, but if it takes 2 years to get stage, I could save a lot with licensing, if I just kept Korea inside Hong Kong, don't you agree?

Thanks for any comments on this!

Miklos_Hollender

I did this with localization (Austria and Italy) and it was horrible to merge them. Without localization (how are you going to do regulatory compliance? like tax reports) the only issue is language and characters. I have not tested yet if in the new Unicode stuff this works well, in old Classic it did not but now it is theoretically unicode. Just test it. Enter some Chinese and some Korean customer names in the same database with the proper characters and see if they print out right on invoices.

Miklos_Hollender

I did this with localization (Austria and Italy) and it was horrible to merge them. Without localization (how are you going to do regulatory compliance? like tax reports) the only issue is language and characters. I have not tested yet if in the new Unicode stuff this works well, in old Classic it did not but now it is theoretically unicode. Just test it. Enter some Chinese and some Korean customer names in the same database with the proper characters and see if they print out right on invoices.

markborges

Hey Miklos, thanks for the feedback.

For the localization, we have an external accounting firm that will do all the regulatory compliance and tax reports aside from the system. For the language and characters, the local team claims that they can use the English version for both countries (don't ask me how).

So, I assume that I would be good to use the sabe DB for both companies, because we will not need any specific non-unicode languages, nor the localization packs.

I was just curious of other technical difficulties, and also the licensing matters.

Again, thanks!