Multiple Localizations

joshplummer

Can anyone give me a bit of guidance on this issue...

I have a company that operates in many countries.

I'm interested in having multiple localizations exist in one database.

Example: I have one database now that can operate fluidly in both China and the US.

What are the pifalls of adding further localizations to this database such as Singapore, Taiwan, India, then followed by several in Europe like Netherlands, Denmark and France.

It's my understanding from both reseach and experience that the localizations are 1) Reporting (both print and data feeds) and 2) Some Additional functions and 3) Translations.

In general, the localizations appear to make very little, if any, change to the core of NAV.

I appreciate your input.

kapamarou

joshplummer wrote:

In general, the localizations appear to make very little, if any, change to the core of NAV.

Have you seen our localization??? ](*,) #-o

matttrax

Our company thought about doing this...keyword thought.

Things to consider:

1) Countries have legal requirements that localization teams implement. Unless you know what code is for a legal requirement and what is not you have to merge everything.

2) Future upgrades will be limited based on the last country released (Tier 1 / 2 / 3). And they will be a nightmare.

3) Any SQL jobs / maintenance have less of a window to run in because you constantly have users in the database.

4) It becomes very difficult to make company specific changes. Unless all of your companies have the exact same set of operating procedures, which probably isn't the case.

5) You still have to get access to the objects to merge in, which you have to pay for. For example a US license doesn't give you access to NL objects. So unless you have a license that can open those NL objects you can't merge them.

It's a pain that's not worth it in my opinion.

joshplummer

Thanks for the input.

1) Countries have legal requirements that localization teams implement. Unless you know what code is for a legal requirement and what is not you have to merge everything.

2) Future upgrades will be limited based on the last country released (Tier 1 / 2 / 3). And they will be a nightmare.

3) Any SQL jobs / maintenance have less of a window to run in because you constantly have users in the database.

4) It becomes very difficult to make company specific changes. Unless all of your companies have the exact same set of operating procedures, which probably isn't the case.

5) You still have to get access to the objects to merge in, which you have to pay for. For example a US license doesn't give you access to NL objects. So unless you have a license that can open those NL objects you can't merge them.

It's a pain that's not worth it in my opinion.

1) Most legal requirements are in reporting. I don't care where you are on earth, double entry bookkeeping is double entry bookkeeping.
2) Good point. Upgradability could be an issue.
3) I can handle this.
4) We are standardizing globally. This could serve as a forcing function...as it should.
5) I would still buy the applicable localization code.

Let me ask this then.

1) If you have operations in the US and China...and 200 users in each country...would you seriously purchase a new license and instance of NAV for each region? I think that's insane. When the US is sleeping, China is working, so I should be usign the 200 licenses I already purchased rather than having a total of 400 with 200 idle at any given time. Knowing that, does it make FINANCIAL sense NOT to merge localizations?

kapamarou

joshplummer wrote:

1) Most legal requirements are in reporting. I don't care where you are on earth, double entry bookkeeping is double entry bookkeeping.

It will be VERY VERY difficult.

For example:

Our localization has more than 80 new tables, not to mention new fields in standard tables...

Furthermore, there are things like primary keys that are different in some tables...


I think it would require a huge amount of coding to be able to post a transaction that would handle localization for all countries (if it can be done) ...

MBerger

Just did a little check in the NL localization...there are 219 NAVNL objects, of which only 24 reports. and i know for a fact that the dutch localization has different functionality for VAT and telebanking, among others

And the bookkeeping might be the same, but WHAT goes into the bookkeeping is different per localization too...

I think that you are opening a can of worms here...Good luck !

DenSter

Don't you already have multiple localizations in one system?

It really depends. Localizations include two things: mandatory legal requirements and common local business practices. The legal requirements alone are usually not very complicated. However, common local functionality can be extremely intrusive. I remember a project where we were told that it was impossible to merge in the Italian localization, but when we excluded the non-legal requirements it turned out to be much easier to do.

There might be localizations that have far fetching implications (I heard that the tax functionality in India is VERY complex for instance), and obviously it becomes more complex the more localizations you add to the solution. The best thing you can do is find local NAV partners in each area and have them list all legal requirements. You might want to send a PM to the webmaster over at http://dynamicsuser.net/, he works for a company with many Asian localizations.

By the way, I am sure that Microsoft will be happy to work on a cost effective solution. Talk to your NAV partner.

kriki

joshplummer wrote:

1) If you have operations in the US and China...and 200 users in each country...would you seriously purchase a new license and instance of NAV for each region? I think that's insane. When the US is sleeping, China is working, so I should be usign the 200 licenses I already purchased rather than having a total of 400 with 200 idle at any given time. Knowing that, does it make FINANCIAL sense NOT to merge localizations?

I am not a licensing specialist (so I don't know if it is legally possible), but technically this could be solved with a serverwide license (and not per DB. It the standard I think) and multiple NAV-DB's (like 1 for China and 1 for US).

DenSter

AFAIK, the licensing is based on named users, so you'd have to get 400 of them regardless of when they connect.

matttrax

It almost always makes sense financially. Obviously buying a 200 user license is not cheap and the time it would take to merge the code is, hopefully, less than that.

But you have to consider all the indirect costs. Like having to redo it every time you upgrade, every time a hot fix comes out. The amount of time it would take to properly test the solution before deployment and the amount of time for support afterward.

You'll probably pay something like $70k/yr for maintenance on a 200 user license. So if you can get all of the work done and you think yearly support and everything that goes with it will be less than the extra $70k for a second database, it's not such a bad idea. It borders on having a dedicated NAV person to support it in my opinion, though, which will probably cost more than that if they're any good. (If that person is you and you're looking for job security I say go for it )

joshplummer

I am not a licensing specialist (so I don't know if it is legally possible), but technically this could be solved with a serverwide license (and not per DB. It the standard I think) and multiple NAV-DB's (like 1 for China and 1 for US).

This is the most obvious and cost effective route...but the standard NAV Licensing Terms are that the license you purchase can govern only 1 database. Did I miss something? A second database then implies you have to buy a second license.

Kazansky

We have 170 US and 2 Canadian companies in one (Native) Navision database. AP, AR, HR, Payroll - all works pretty smooth. I will be glad to provide more details in interested.

Thanks

ara3n

The Canadian and US is one locatlization. NA (north American) and doesn't apply.
When deciding to combine multiple localizations, you have to decide country by country.
For example chinese use double byte characters, and Gov regulation require GL to be in chinese.

RobertMo

I am working now for a long time on international projects (also in many Asian countries). If there would be only few localizations to merge, I would think about the way to go. But since you plan much more or you are trying to set it as a strategy then I would not recommend it.

One of my customers went for "merging localizations" and gave up after 4th.
Of course highly depends on biz process unifications across companies, which might not be in your powers (unless you are GM/president/etc).

Perhaps a mixed mode: having more DBs, where each combines only few localizations together - e.g. per region, because localizations might be similar if not even common. Or just opposite approach to claim so called concurrent users benefits).

ara3n

I think MS needs to this to their localization to begin with.

They should start combining some of the European counties. Here in North American we have one version for 3 counties. It makes a no brainier to implement one database in three different countries. Mexico, US, Canada.

I'm pretty sure that they can combine, UK, Neatherland, France into one database.
They could also combine Spain in there.

They could save on resources to maintain all the different localizations.

Now on licensing, that's another question.

I'm sure there are many counties that have offices in multiple counties in Europe. They will save a lot of money and maintenance cost and
upgrades.

I've merged NA and Spanish, and I've merged NA and Neatherland, and so it is possible.
I've looked at GB and France db, and there is nothing major for government requirements.
For implementations that I've done that involved France and GB, we had just copy a couple of reports.

ssingla

joshplummer wrote:

Can anyone give me a bit of guidance on this issue...

I have a company that operates in many countries.

I'm interested in having multiple localizations exist in one database.

Example: I have one database now that can operate fluidly in both China and the US.

What are the pifalls of adding further localizations to this database such as Singapore, Taiwan, India, then followed by several in Europe like Netherlands, Denmark and France.

It's my understanding from both reseach and experience that the localizations are 1) Reporting (both print and data feeds) and 2) Some Additional functions and 3) Translations.

In general, the localizations appear to make very little, if any, change to the core of NAV.

I appreciate your input.

Did you mention India. The localization will surely stand among the top if voted for functionality/complexity. The worst thing is most of them is legal in nature and required for basic sales/purchase invoice and payments. Moreover you will get out of field in the table for Sales/Purchase Header/Line. You will probably end in customizing a shadow table in the global template.

I will suggest to do a comprehensive technical/financial feasibility study before deciding.

joshplummer

What is so special about the India localization?

ara3n

download the database and take a look at it.

kriki

Splitted some posts to new topic "Indian localization : taxes"

MarkD33

Does Microsoft have an official recommendation for this issue?

We've been talking to a client that has operations in 6 different "localized" countries and we're looking at the different options. One thing I can't put my hands on is MS's view on this issue.

I'd look on PartnerSource but I think rather rip my fingernails off before heading there.........

Mark

matttrax

They allow you to purchase functionality from another localization (document is actually on PartnerSource). So they'll add the object ids to your license. But you still have to merge the code.

ssingla

matttrax wrote:

They allow you to purchase functionality from another localization (document is actually on PartnerSource). So they'll add the object ids to your license. But you still have to merge the code.

Merging is the easiest part....

ara3n

matttrax wrote:

They allow you to purchase functionality from another localization (document is actually on PartnerSource). So they'll add the object ids to your license. But you still have to merge the code.

I believe you still need to renumber them to 50K range. I don't that has changed.

p.willemse6

There is a cross versioning guide for NAV, whoch describes the guidelines. Basically: buy the foundation pack, and renumber the objects. Please not: if you have 5 databases, you will have to buy the foundation packs and the custom objects 5 times.

Microsoft has a very easy policy / advice: if you want to implement internationally with Dynamics, there are 2 options:
1. one database per country, with localised, self operating companies.
2. one central database: AX...

Nothing in between, you could contact partnerpower (www.partnerpower.biz), they are the absolute experst on this area. They wrote a 5 page essay why not to go the way you describe...