Skip to content

Estimating costs for code changes in Microsoft Dynamics NAV

I’m sometimes asked why an estimate for a simple change is so high.

ArcherPoint’s Matt Traxinger discusses estimating costs for code changesFor example, a customer recently wanted to add a field to their Sales Order, which had no business logic behind it. If you are familiar with the Microsoft Dynamics NAV development environment, you know that this change can quite literally be done in two to three minutes, so they were expecting a 15 minute quote. That is typically the unit of time most service organizations bill in. However, I will usually quote an hour to do it because it is one of the most deceivingly simple tasks in Dynamics NAV. To do it right takes time. Let’s take a look.

To add the field, you can do the following:

  • Design the table in question (36 – Sales Header in this case)
  • Add the field in the 50,000 to 99,999 Field ID range
  • Close and save the object
  • Design the page in question (45 – Sales Order);
  • Add the field to the page using the Field Menu
  • Close and save the object

Done. Simple as can be. But have we missed anything? What’s buried in the 2,000,000 or so lines of Dynamics NAV code that we don’t know about? What if there was another related table that had a field with the same field ID, but a different field type?

Screenshot showing the fields of Table 36-Sales Header and Table 112-Sales Invoice Header

Figure 1 – Image showing the fields of Table 36-Sales Header and Table 112-Sales Invoice Header

A commonly used command in posting routines called TRANSFERFIELDS will now fail if that happens. You won’t notice it right away because you tested the change and the change only. The field was on the page, so everything must be working fine. Nothing could be further from the truth. I speak from experience, having brought down a production database or two with this error in my younger days.

As an experienced Dynamics NAV developer, I now know the main tables with which this command is used:

  • Contact -> Customer, Vendor, Bank Account
  • Sales Header -> Sales Shipment Header, Sales Invoice Header, Sales Cr. Memo Header
  • Sales Line -> Sales Shipment Line, Sales Invoice Line, Sales Cr. Memo Line
  • Purchase Header -> Purch. Receipt Header, Purch. Invoice Header, Purch. Cr. Memo Header
  • Purchase Line -> Purch. Receipt Line, Purch. Invoice Line, Purch. Cr. Memo Line

But that doesn’t mean that another developer hasn’t customized the database and used that command with another table. I may have even customized it several months or years ago and forgotten about it. You could have internal developers making changes that I don’t know about.

The takeaway is that every time I log in to your database, I have to treat it as a new system that I have never seen before. I have to do proper analysis to understand the current state of affairs. 99% of the time there would be no issue; I could make the change in two to three minutes and deliver it in 15, but I’m not willing to bet your company’s up-time on a 100 to 1 shot. Are you?

Blog Tags: 

Comments

Andri Wianto's picture

Comment: 

Good insight!

Comment: 

I'll take your....

  • Design the table in question (36 – Sales Header in this case)
  • Add the field in the 50,000 to 99,999 Field ID range
  • Close and save the object
  • Design the page in question (45 – Sales Order);
  • Add the field to the page using the Field Menu
  • Close and save the object

...and raise you...

  • Log into development database
  • Export table 36
  • Design the table in question (36 – Sales Header in this case)
  • Add the field in the 50,000 to 99,999 Field ID range
  • Update documentation trigger
  • Close and save the object
  • Export page 45
  • Design the page in question (45 – Sales Order);
  • Add the field to the page using the Field Menu
  • Update documentation trigger
  • Close and save the object
  • Check change is working as expected
  • Export modified table 36 and page 45
  • Transfer fob to production environment (which can sometimes be easier said than done depending on how secure the customers system is!)
  • Organise with administrator for all users to be out of the system, or do this after hours (yay!)
  • Log into produciton database
  • Export table 36 and page 45
  • Import new table 36 and page 45
  • Confirm all is well

And then of course there could also be an interim step of doing this in a UAT database so the customer can test and sign off before it goes into production.
Even an hour can be tight!!
 

Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube
Get Help Now