Guidelines to customizations

EC

Hi.

I work for a company that has a highly customized Navision. Many of these were made before I got hired, but I have also made many customizations. Some more elegant than others (I guess that's a well known phenomena in this line of work :-) )

But we are facing a major upgrade of our Navision system and I was wondering if there are any articles on doing customizations the "right" way, that is so the system is still upgradeable. When we get the upgraded system I want to do customizations without fearing that the system can't be upgraded.

Any help / info on this?

/eC

kine

1) Do as little modification into standard objects as possible (keep the new developed "modules" separate and use standard "interface" to connect it)
2) All changes in standard objects must be marked by some comments, if you are changing existing code, leave the original one (comment it out) and add new modified code after that block. Keep the changes to the minimum - it means just insert 1-10 lines of code, bigger block insert into some function, codeunit etc. and just call it from the correct point...
3) If you want to modify standard reports, it is better to copy them under customer IDs and modify them there

these are just the main one, I am sure, that others will add additional points...

EC

kine wrote:

1) Do as little modification into standard objects as possible (keep the new developed "modules" separate and use standard "interface" to connect it)
..

Thanks Kine. But what do you mean by standard "interface"?

What about adding new fields to standard tables? How can one do that without compromising a future upgrade?

/eC

kine

"Standard" interface I mean posting codeunits etc...

Adding fields is not problem, you add them, they are in separate ID range, merging them when upgrading is easy. Much harder is to make correct C/AL code which is added because this new field (filling some new field during posting etc.).

I will split the changes which are done into categories:
1) C/AL code changes
2) Visual changes - adding/deleting/changing editboxes and labels on reports and forms, changing dataitems etc.
3) Data model changes - new fields, changes in existing fields (data type, size)
4) Localization (translations of strings, field captions, button captions etc.)


Class 1 changes are the main source of problems during upgrade. Must be done correctly with focuse to easy reading of the code and that the change must be easy to recognize from changes made by the upgrade (changes of code between e.g. SP2 and SP3 are not commented, it means, all uncomented changes will be recognized as changes made by the upgrade, all commented changes are customizations...)

Class 2 changes are hard to merge, because in many cases you do not know why the field was deleted from the form (if it was not there, if customer wanted it etc.) and all the changes must be rethought, if they are still needed etc. Good documentation "what+why" it was done is good source of knowledge for you when upgrading.

Class 3 are easy to merge. Fields can be transfered without problem (you will have problem if there is some bigger change between the versions of NAV - for example the value entries were added between 2.60 and 3.xx versions and this changed the application logic...). In some cases you need to do own "migration toolkit" to correctly migrate the data into new structure. All changes on standard fields must be documented to be sure, that the change was not made by mistake etc.

Class 4 changes can be upgraded through exporting and importing language module, if the ID's of texts etc was not changed. You just needs to keep all text strings for translation in Text constants (global, not local), you never knows when you will need to translate the application into another language (for example, when the company will merge with another etc. ;-)).

EC

Thanks so much, Kine.

Much appreciated. Now I know what to be aware of when we upgrade.
/eC

Kowa

This documentation is useful too :
http://www.mibuso.com/dlinfo.asp?FileID=598