You only want to implement Government required localizations.
After looking at GB and France DB we found there were no Gov required modifications and we just used US db.
Another company had similar request with US and Spain, and Spain has Cartera and GL Accounts displaying in certain order. Spanish db also had partial payments which client required.
I had to merge the two db.
You would want to create New boolean in GLSetup. For example "France Company", "GB Company", and when you merge the databases only run the code if the field is checked.
US has the most localizations objects, so you would need to merge the other companies into it. Rename the objects to 50K range.
Also remove the Langauge Packs first from all the databases.
Also if the client wants the french Language Pack. I suggest to purchase the French Canadian language pack, and rename the French Language pack to French Canadian.
Keep track of Datetime Stamp for all the objects.
After merging two localizations, you would have the version tag with the localization. Reset the modified flag to false.
If the client upgrades in future, they will have to re-merge the 6.x US with 6.x GB etc.
Goodluck.
Ahmed Rashed Amini
Independent Consultant/Developer
Hi,
Thanks for your valuable inputs. I see it is a big challenge to merge these objects. What additional customizations, risks or conditions you foresee? If i can list out the activities to be undertaken...
I can list out few from your inputs:
1. Another company had similar request with US and Spain, and Spain has Cartera and GL Accounts displaying in certain order. Spanish db also had partial payments which client required.
I had to merge the two db.
2. You would want to create New boolean in GLSetup. For example "France Company", "GB Company", and when you merge the databases only run the code if the field is checked.
3. US has the most localizations objects, so you would need to merge the other companies into it. Rename the objects to 50K range.
4. Also remove the Langauge Packs first from all the databases.
Also if the client wants the french Language Pack. I suggest to purchase the French Canadian language pack, and rename the French Language pack to French Canadian.
5. RISK: If the client upgrades in future, they will have to re-merge the 6.x US with 6.x GB etc.
IMPACT: Extra effort
I also have similar kind of requirement, what are the risk is we merge two country localization into single coutry database.
Take the example what navimbs said that he want to merge US & France localization into UK database.
Can you brief what are risks that are associated, if we go for this kind of merging. :?:
Again not giving us any details. Without the details of your project, I don't have much to add to what Ahmed has said already. You've come to the wrong place to have your project evaluated. The best thing you can do is to hire someone who has proven experience with upgrades and help you guide you through this process.
One of the risk I remember is that I would get extremely bored during those merging of the objects. It's mind numbing.
The person who is doing this needs to know what they are doing.
Ahmed Rashed Amini
Independent Consultant/Developer
We are actually assesing development risks associated with merging localizations.
While we have the GB database, we need to merge the France & US databases with localizations into the GB database.
As Ara3n listed good points, i would further like to evaluate on the advantages and disadvantages in doing this merging.
As councluded from ara3n comments what steps i need to consider while merging, i am still apprehensive whether it is good to really merge or i carry on with single databases for each country(if i hv to suggest it to the client).
Request your inputs further.
PS: I am ok with chatting or discussing online provided i hv ur id
Comments
Company had US GB and France sub-companies.
You only want to implement Government required localizations.
After looking at GB and France DB we found there were no Gov required modifications and we just used US db.
Another company had similar request with US and Spain, and Spain has Cartera and GL Accounts displaying in certain order. Spanish db also had partial payments which client required.
I had to merge the two db.
You would want to create New boolean in GLSetup. For example "France Company", "GB Company", and when you merge the databases only run the code if the field is checked.
US has the most localizations objects, so you would need to merge the other companies into it. Rename the objects to 50K range.
Also remove the Langauge Packs first from all the databases.
Also if the client wants the french Language Pack. I suggest to purchase the French Canadian language pack, and rename the French Language pack to French Canadian.
Keep track of Datetime Stamp for all the objects.
After merging two localizations, you would have the version tag with the localization. Reset the modified flag to false.
If the client upgrades in future, they will have to re-merge the 6.x US with 6.x GB etc.
Goodluck.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
Thanks for your valuable inputs. I see it is a big challenge to merge these objects. What additional customizations, risks or conditions you foresee? If i can list out the activities to be undertaken...
I can list out few from your inputs:
1. Another company had similar request with US and Spain, and Spain has Cartera and GL Accounts displaying in certain order. Spanish db also had partial payments which client required.
I had to merge the two db.
2. You would want to create New boolean in GLSetup. For example "France Company", "GB Company", and when you merge the databases only run the code if the field is checked.
3. US has the most localizations objects, so you would need to merge the other companies into it. Rename the objects to 50K range.
4. Also remove the Langauge Packs first from all the databases.
Also if the client wants the french Language Pack. I suggest to purchase the French Canadian language pack, and rename the French Language pack to French Canadian.
5. RISK: If the client upgrades in future, they will have to re-merge the 6.x US with 6.x GB etc.
IMPACT: Extra effort
Regards,
RIS Plus, LLC
I also have similar kind of requirement, what are the risk is we merge two country localization into single coutry database.
Take the example what navimbs said that he want to merge US & France localization into UK database.
Can you brief what are risks that are associated, if we go for this kind of merging. :?:
It would be a bit silly to get a full project risk assessment from the forum even if we knew all the details, but you are not giving us ANY detail.
RIS Plus, LLC
This isn't a risk, it applies to any addon that when you upgrade will have to re-merge during upgrade.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
I am talking about development risk..?
RIS Plus, LLC
One of the risk I remember is that I would get extremely bored during those merging of the objects. It's mind numbing.
The person who is doing this needs to know what they are doing.
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
RIS Plus, LLC
Thanks for your valuable inputs.
We are actually assesing development risks associated with merging localizations.
While we have the GB database, we need to merge the France & US databases with localizations into the GB database.
As Ara3n listed good points, i would further like to evaluate on the advantages and disadvantages in doing this merging.
As councluded from ara3n comments what steps i need to consider while merging, i am still apprehensive whether it is good to really merge or i carry on with single databases for each country(if i hv to suggest it to the client).
Request your inputs further.
PS: I am ok with chatting or discussing online provided i hv ur id
Thanks,
Best regards,