This morning I received an update mail from Microsoft support on a technical incident that felt I had logged ages ago. To be honest: it’s 3 months old, reported on April 13th of this year. A good old colleague is the Escalation Engineer (EE) on this, and as he handed off the issue to the Sustained Engineering (SE) team, he updates me on a regular basis. It’s nice to have still these kind of interactions. [;)]
Well alright, as the bug has been sitting their for such a long period I dutifully browsed to the bottom of the mail, only expecting to see nothing more than an “issue is still worked on” kind of phrase. Well … you are right: it wasn’t the case. Surprise: I was presented a code suggestion to tackle the bug. [G] On the first glance my gut feeling wasn’t positive and I can say: it makes sense most of the time. Investigating the code suggestion more closely I was at the verge of shouting aloud: please, don’t reinvent the wheel!
Changes in Service Documents
Without going too much into the details of the issue I should explain it just a little bit. The issue I reported concerns some Dutch local feature that had been implemented on sales and purchase documents and has been part of NAV NL as long as I can remember. My bug report is addressing the fact that this is not implemented on service documents. As you might recall the first version of the Service Management module did not have it’s own documents but was using the sales documents. So the Dutch feature was there already. However when the dedicated service documents were introduced, we, at the Microsoft Dynamics localization team (GDL), had overseen this change and did forget to implement the Dutch feature on these documents. [:$]
Solution Suggested
So basically the whole thing could be solved by examining how the feature had been implemented on the sales documents and apply it to the service documents. More or less (haven’t used that term for a long time): copy and paste!
BTW: on my initial report I even provided a short description on how it could be fixed. All in vain as the SE developer probably thought he had to invent the wheel and made his own (and wrong!) solution. For heaven’s sake! [8o|]
Basic Rules of NAV Development
One of the basic rules we taught in our Solution Developer courses was to use the NAV application as the main reference when building features. Apparently this story shows that still isn’t common sense. So please, all you developers out there, please …
… don’t reinvent the wheel …
… improve it!
.. unless you really need to build something (really) new. [8-|]
Your customers are in need of a solid and sound solution, not a piece of art.
Glad to see that the fix in Service Management is to be found in NAV 2013.