Being a new programmer in Navision World, I have much to learn from you guys who have years of experience in Navision projects. I have heard suggestions from my colleagues that it is a good practice not to modify exisiting code in Attain but to duplicate necessary Application Objects. Reasons to this action are (a) when the new version/fix is released, it can be easily upgraded by adding customized Application Object. As easy as that without having to worry about appending the new version with customized code. (b) reduces the error in the business logic of Attain. However, with this idea, customers have to purchase many additional/duplicate Application Objects. I would appreciate if anyone can voice their opinion. 
- Topic moved from Open Subject to Implementation Methods As a rule of thumb your two statements are correct. In the ideal system you would not do any modifications - thus make it much easier to upgrade. But we are not in an ideal world - and if we were then there was not a need for so many with our abilities to modify the solution to fit every customer . So when you do modifications you must do them so that you can identify them as easy as possible and transfer them to the new system as easy as possible. The best way to do this is to have the changes in new objects and simply to integrate the new objects into the existing standard system. But this is not always the best solution! It really depends on the individual case and on what type of modification you’re dealing with. My own extended rules of thumbs are: 1) Don’t do any modifications - find a work around that the customer can accept If you still have to modify the system: 2) Group you customer modifications in modifications that you think you might be able to use for other customers and unique customer specific modifications. 3) When you do the modifications that you might be able to use for other customers, then use a object/control number range (still within 50000 to 99999). Keep everything very very close to the rule about not changing the standard system, but instead making new objects. 4) When you do the customer specific modifications you should first evaluate the change. But still remember to renumber everything to fit in the 50000 to 99999 range - also control id’s on forms/reports, the new functions you create in a objects etc. And in Attain also remember that the variants now has control id’s. Changing the control id’s secures you against first line conflicts when upgrading and makes it easier to you to identify your own work. You migth say that it doesn’t matter to rename the id on forms/reports etc. and your right - unless you want a nice tool to see if this was a change by you (or another profeessional) or if this was a change done by the customer himself! Then when you continue always think about how easy (difficult) it is to upgrade a object. I.e. changes done in a form or a report is not exactly easy to transfer. But fields are rather easy to transfer. Changes done in code sections must always be as structed as possible and preferrable in a separate codeunit or eventually just in a new internal function. Always mark and document you changes (search here for this - there are many threads about this topic). Last I would say that you should not worry so much if you would have to purchase 10 or 20 additional objects - because in most cases this comes back many times to the customer in saved upgrade costs. Best regards, Erik P. Ernst, webmaster