Upgrade concern with customization

Forza

Our Company is in the process of implementing Navision 4.0 and had engaged a NSC to carry out the project.

During the requirement study process, we found out that there are many additional information (primarily in item, sales header and sales line table) that needs to be added on.

The NSC suggested that we use existing field in the table that we did not utilize to represent those additional information. Their reasoning is that by adding additional fields to the tables, there will be issue with upgrades when new version is released.

I must say that I don't feel comfortable with that explanation. But with my lack of hands-on experience with Navision and did not understand how an upgrade from 4.0 to 5.0 might be carried out, I really could not counter argue them.

I wonder if anyone can give me some insight into the upgrade process of Navision. I am aware there are technical upgrade and client upgrade, but don't understand the difference.

If wonder also if the following scenario will create a concern for future upgrades. I create a few new tables with corresponding forms in tabular form (list view). In the item table, I created a few new fields that lookup to those tables. When I print the Sales Order, some value from these fields will be printed out.

Any kind of help will be appreciated. Thanks a million.

ssingla

Customization should be avoided if the standard can be followed with some modification in the user company process. If the standard functionality or data is insufficent in fulfilling the needs of the user company then customization has to be done and most of the implementation involves the same.
In upgradation the customization needs to be upgraded too in the new version which makes is costilier as it involves more time for upgradation. Rest there is no problem which cannot be sorted in upgradation of customized database.

Forza

I guess it all comes down to $$$ in the end. Which is sad to say is always a drag when presenting it to the m*n*g3m3nt.

ssingla

Nobody recommends you to upgrade on each and every release. Implementation of upgrade is not that easy. To some extent it is a new implementation with a lot of user training due to new functionalities and modification in existing ones.
If one upgrades in 2-3 years then spending a few thousand $ is not too much.

themave

If you want to even do service pack upgrades, you have to watch every customization, we are on Nav 4.0 no service packs, we identified a problem that was fixed in service pack one, so I said, great apply the service pack then, they said, great we can give you a quote on the cost of applying the service pack for $1200, for that we will inspect all the modified objects and give you an estimate of the cost to upgrade them..., so instead I had to pay them $300 to just program the fix manually rather then apply the whole service pack.

now sp2, has come and gone, and then Sp3, it is not cheap and it is not just a few thousand dollars. if you want to upgrade to 5.0 soon, then have your solution center do everything they can to prepare for that. which is sounds like they are giving you good advice. use existing stuff when ever possible.

Also, rather then change existing code, have them copy it to a new form, or new codeunit if possible. that way the original stays untouched, and you can upgrade much easier, and your new code most likely will still work unchanged or with little modification.

Also, buy extra report packs, and use those instead of modifing existing reports. If it takes them 30 minutes to compare the old report with the upgrade version of the report and then make the changes that can really add up. say you modified 50 reports, just to show the whole part number field, or hide a unit of measure code you don't care to see on a report, 50 reports at a 1/2 hour @ $200/hour equals $5000 just to upgrade your reports, from 4.0 to 5.0

Forza

themave:

Also, rather then change existing code, have them copy it to a new form, or new codeunit if possible. that way the original stays untouched, and you can upgrade much easier, and your new code most likely will still work unchanged or with little modification.

I can understand and is prepared to spend some hard earned budget from m*n*g3m3nt to purchase more forms, reports and copy from existing one in Navision whenever we want to customise them.

My concern is not so much on forms and reports, but more on tables.

themave:

If you want to even do service pack upgrades, you have to watch every customization, we are on Nav 4.0 no service packs, we identified a problem that was fixed in service pack one, so I said, great apply the service pack then, they said, great we can give you a quote on the cost of applying the service pack for $1200, for that we will inspect all the modified objects and give you an estimate of the cost to upgrade them..., so instead I had to pay them $300 to just program the fix manually rather then apply the whole service pack.

Are you talking about tables?

themave

During the requirement study process, we found out that there are many additional information (primarily in item, sales header and sales line table) that needs to be added on.

it may seem like just a few tables, but I bet it will be a bunch more, if you want the info in the sales header, then you will also need to include the posted sales header, the posted shipment header, ect, then you say you want the sale line table, add the psoted sales line, posted shipment line, ect ect ect. not to mention the value entry table.

now for forms, you will need to modify the sales order form, the sale invoice form, the posted sales invoice form,

if you can use existing fields, you likely do not have to modify any tables, just the form and reports, which you can learn to do on your own.

Only problem with using existing fields it you have to really make sure they don't do something else you don't expect. and microsoft can change the licensing even off a field. We used the bin field in Navision 2.0, not the whole bin functionality, just the field, it was on the item card and no restrictions, when we finally upgraded to 4.0, we had a problem because to use the bin field required the whole granual.

ssingla

Bug fixing can be at any place may it be report,form, table, codeunit.

If you want to even do service pack upgrades, you have to watch every customization, we are on Nav 4.0 no service packs, we identified a problem that was fixed in service pack one, so I said, great apply the service pack then, they said, great we can give you a quote on the cost of applying the service pack for $1200, for that we will inspect all the modified objects and give you an estimate of the cost to upgrade them..., so instead I had to pay them $300 to just program the fix manually rather then apply the whole service pack.

Wonder how you have not covered the same in implementation contract. Implementor can not run or charge money by saying it is a standard problem, he/she has to give a running solution and not just install the standard product.

Forza

themave:

Only problem with using existing fields it you have to really make sure they don't do something else you don't expect. and microsoft can change the licensing even off a field. We used the bin field in Navision 2.0, not the whole bin functionality, just the field, it was on the item card and no restrictions, when we finally upgraded to 4.0, we had a problem because to use the bin field required the whole granual.

:-s The rope is only as long as it is; pull either end, the other end will fall short. :-s

themave

ssingla wrote:

Bug fixing can be at any place may it be report,form, table, codeunit.

If you want to even do service pack upgrades, you have to watch every customization, we are on Nav 4.0 no service packs, we identified a problem that was fixed in service pack one, so I said, great apply the service pack then, they said, great we can give you a quote on the cost of applying the service pack for $1200, for that we will inspect all the modified objects and give you an estimate of the cost to upgrade them..., so instead I had to pay them $300 to just program the fix manually rather then apply the whole service pack.

Wonder how you have not covered the same in implementation contract. Implementor can not run or charge money by saying it is a standard problem, he/she has to give a running solution and not just install the standard product.

we don't have an implementation contract, the software is aleady up an running, just took a while to fine this particular bug. we pay the 16% annual maintenance to Microsoft, which gives us the right to upgrades, service packs ect, but it doesn't get them installed. we do not have the developer license, and can not use merge tools, or text compare tools to see which changes are made in a a service pack between the old form, report, code, ect and the new. The solution center doesn't get paid by Microsoft to do the work, so someone had to.

themave

Forza wrote:

themave:

Only problem with using existing fields it you have to really make sure they don't do something else you don't expect. and microsoft can change the licensing even off a field. We used the bin field in Navision 2.0, not the whole bin functionality, just the field, it was on the item card and no restrictions, when we finally upgraded to 4.0, we had a problem because to use the bin field required the whole granual.

:-s The rope is only as long as it is; pull either end, the other end will fall short. :-s

exactly, and with the lessons learned over 7 years as an end user, I am trying to help make that rope as long as possible. nothing is free with the Navision, and there are consequences to different tracks you can take, the key is to really learn the product and you can limit the cost of those things.

ssingla

exactly, and with the lessons learned over 7 years as an end user, I am trying to help make that rope as long as possible. nothing is free with the Navision, and there are consequences to different tracks you can take, the key is to really learn the product and you can limit the cost of those things.

The same is true to all the products. As a user one has to limit his wish list and should go only for the necessary functionalities. It is very difficult and almost impossible to please everybody but the management has to really do a cost benefit analysis to decide which way to go.
Very diificult to define what is necessary

Forza

themave:

exactly, and with the lessons learned over 7 years as an end user, I am trying to help make that rope as long as possible. nothing is free with the Navision, and there are consequences to different tracks you can take, the key is to really learn the product and you can limit the cost of those things.

But at least we have a large enough installation based looking at the same piece of puzzle and poll our energy to get something back from MS. I believe this is the biggest advantage of Navision. Or maybe because I have not seen enough of other solution out there.