How to handle local functionality.....

Iwan_Ubachs · 2006-05-03

Hi,

How to handle local functionality in case an organisation wants to run one database with companies located in more than one country.

For example:
1 database
company 1 located in The Netherlands
company 2 located in France
company 3 located in Canada

Should they take the NL-, FRA- or CAN- version?
Or the WW with all functionality of NL, FRA and CAN?

I look forward to hear your experiences and recommendations!

ara3n · 2006-05-03

I've done it the other way. Used a US version and merged netherland objects and moved them to 50K. France didn't have anything that US db couldn't provide. The solution we went with, the client had office in UK,France, NL,Hong Kong, India. Using citrix and one db was the best solution and the project was quickly finished.

DenSter · 2006-05-03

I agree there is no ONE solution, but it is possible for sure. I've done one starting out with W1, and adding mandatory elements from NL, France, UK, Italy and Germany to it. Since then they've also added far east countries to the database I believe, and they connect through Citrix.

kine · 2006-05-04

But you need to check for "conflicts" which can be between the local procedures. For example two countries can have some local modifications in posting of VAT but the modifications are in conflict...

kriki · 2006-05-04

In the company or general ledger setup, put a toggle for each country (or an option field) to indicate to which country a company belongs.
In the code you can use this switch to execute the code of the country or the standard code.

Denster:integrated Italy-objects. I think you have grey hair now

Iwan_Ubachs · 2006-05-04

ara3n wrote:

I've done it the other way. Used a US version and merged netherland objects and moved them to 50K. France didn't have anything that US db couldn't provide. The solution we went with, the client had office in UK,France, NL,Hong Kong, India. Using citrix and one db was the best solution and the project was quickly finished.

Is this because of conflicts in license? US end user license cannot use Dutch objects.

Iwan_Ubachs · 2006-05-04

BlackTiger wrote:

No single solution. No right or wrong solution.

Main difficulty - each country has own laws (what's why Terminal Services is not enough).

Best solution (imho):
- own Navision in each country.
- one "big" consolidated Navision in "main office". You and your customer have to decide what data you need to collect from regional database (for example, G/L only). This database is "read-only".
- some interdatabase (not only intercompany) communications (purchase-sale documents) (WebService+MSMQ+NAS+XMLPort will help you!)

Thanks for your answer, but the customer really wants to have one central database.

Iwan_Ubachs · 2006-05-04

DenSter wrote:

I agree there is no ONE solution, but it is possible for sure. I've done one starting out with W1, and adding mandatory elements from NL, France, UK, Italy and Germany to it. Since then they've also added far east countries to the database I believe, and they connect through Citrix.

I was thinking about the same solution, but I am affraid for al lot of maintainance in the future. Update W1 and then per local version.

What's your experience?

kriki · 2006-05-04

Iwan Ubachs wrote:

ara3n wrote:

I've done it the other way. Used a US version and merged netherland objects and moved them to 50K. France didn't have anything that US db couldn't provide. The solution we went with, the client had office in UK,France, NL,Hong Kong, India. Using citrix and one db was the best solution and the project was quickly finished.

Is this because of conflicts in license? US end user license cannot use Dutch objects.

Exactly.

kriki · 2006-05-04

Iwan Ubachs wrote:

DenSter wrote:

I agree there is no ONE solution, but it is possible for sure. I've done one starting out with W1, and adding mandatory elements from NL, France, UK, Italy and Germany to it. Since then they've also added far east countries to the database I believe, and they connect through Citrix.

I was thinking about the same solution, but I am affraid for al lot of maintainance in the future. Update W1 and then per local version.

What's your experience?

The best is to take the DB with the most localisations in and then add the others.
Once you do an upgrade of the DB, you have to redo all the work. So this is a lot of work to do in the future.

Iwan_Ubachs · 2006-05-04

Iwan Ubachs wrote:

I was thinking about the same solution, but I am affraid for al lot of maintainance in the future. Update W1 and then per local version.

What's your experience?

kriki wrote:

The best is to take the DB with the most localisations in and then add the others.

Once you do an upgrade of the DB, you have to redo all the work. So this is a lot of work to do in the future.

Thanks for your reply, I was already affraid for this answer.....

Miklos_Hollender · 2006-05-15

Actually localization differences might not be so huge between Western countries - one could make a list of them and ask the users which ones are really necessary. It migth turn out that there are only small differences and they can easily be merged into one database.

How to handle local functionality.....

Comments

Categories