An international solution should be able to co-exist with any other add-on. License wise this has been enabled by specific objects ranges assigned to the add-on which assures that CSIDE objects - i.e tables, table fields, forms, reports, etc. - do not conflict (however see note 1).
Unfortunately NAV does not have an automatic mechanism that prevents that lower level objects in your solution, like controls and variables - including functions and text constants -, might conflict with other solutions. So you have to make sure controls and variables have ids within your number range. There for you need to enable the GetUidOffset function in COD1. That's what we did for our solutions.
With version 3.xx, and until version 4.xx, the only way to do this was:
This applied for both development partner and NTR - Navision Territorial Representative - (see note 3).
Version 4.00 was the first NAV release under the umbrella of MS. The first release where one team had to take care of multiple localizations. Like our WEMEA team that took care of 15 of them (AT, BE, CH, DE, ES, FI, FR, GB, GR, IT, NL, NO, PT, SE, TR). The first release where single developers were going to write code for multiple countries. And instead of forcing them to switch license whenever they had to change from one country to the other a new technical feature was designed, i.e. function 212122 in COD1: GetUidOffset.
Veterans among us will recall that in the first major and minor releases of 4.xx this function could be found in COD1, but after that the NAV build did clean it from the database before a release and a lot of you felt like having been taken away one of your major toys not knowing/being aware you could easily revive it by simply adding the code to COD1. Read more here.
If GetUidOffset does not exist in COD1 the client will fall back on the range that applies for thecountry in your licens (see note 2).
Navision United Kingdom
Navision Czech Republic
Navision New Zealand
Navision South Africa
General customer modifications
Add-ons and converted objects
Good to hear and fully agree with "your annoyance" as you might have concluded from some of my earlier posts of which most of them eventually ended up as incidents reported to MS. And ... resulted in some kind of fix. So if possible I would encourga you (and anyone else) to report everything to MS. Let them know, bug them, and push it to the limit (in a positive way).
If you don't want to do that yourself be free to ask me.
No, don't misunderstand me. I fully agree with what you say and I'm following this concept for years already.
Anyway it is annoying to see IDs changing in standard where not necessary and see IDs coming in which make merging as difficult as it was in the good old Navision Financials times (where additional custom controls have been just numbered following the ones already in the object.
Valid observations, Thomas.
Note that what I am writing in my BaIS sequel are thoughts and considerations. And of course these are the basis to our decisions, but your free to choose. ;-)
Why should we worry about ID's if Microsoft doesn't?
With 2009R2 we received plenty of objects which have controls in the range used by a noremal DEV license.
Bad Job Microsoft. A simple Beyond Compare would have avoided that.