Category Archives: Best practices

Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.

As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.

Here I list the ten most important reasons that I believe make design absolutely indispensable.

While designing a custom functionality for a customer, there was an issue with posting groups: the way the custom functionality was designed would result in value entries being always posted to a single posting group, resulting in inventory balances always going to the same inventory account.

When I brought this issue to my customer’s attention, they said: “but we only have one single inventory account, and we only use one single posting group, so we don’t need this functionality to be smart about this”.

This was an example of what I like to call setup-dependent requirements.

So I would guess that was it. I’m just returning to Kristiansand, my Norwegian base, after delivering the “Microsoft Dynamics NAV 2009 Development Best Practices” course to a partner, my first custom-developed training ever. My impression is—mission accomplished.

I was not sure at first how this would turn out. Teaching NAV best practices to people some of whom have more experience than I’ll have any time soon, isn’t an easy thing. The challenge for me was—how to deliver something new, really valuable to those people, something they could go home with saying “wow, if only I knew this earlier”.

“Best practices” is one of those beloved and hated concepts. There are people who just embrace “best” practices for the sake of their bestness. And there are people who just shun them for the very same reason—those know-it-alls who have opinion on everything and know it better before even learning about it. What’s-best-for-you-is-not-best-for-me kind of people. Neither of approaches is actually, well, best.

For a best practice to be the best for you, you need to understand it, and if you find any pitfalls, improve it.

In two days I’m delivering the NAV Development Best Practices training for a service provider in Norway. They approached me two two months ago and asked if could do something like that. This brought to memory some good posts I made years ago, and here I bring the links. If you want me to share my best practices, this would be my starting point:

Code of Coding: emphasizes the need for understanding the effects of a change in code, and making others understand your intention

Code of coding 4: Die, hard(coding) 2: about avoiding embedding settings into code, with detailed explanation what exactly is wrong with it, and some good guidelines on how to detect less obvious cases of settings hardcoding

NeverENDing story: about a very bad example I once encountered, and how to avoid situations such as that

Featuritis Cure: now this one is definitely not a “best practice”, it’s about a situation when a developer pulled a prank on a customer so subtly that I just had to share it with the world. A far better cure for Featuritis (a dangerous and ugly disease indeed) is given by Mark Brummel, in his fantastic post Tip #20 – Save Report Usage. If you aren’t yet following Mark’s blog, now would be a good time to start.

If you are interested in development best practices, check these posts, and if you find them useful, then I’m happy. If you don’t, share your thoughts. Best practices develop over time, improving slowly, and gradually until one day they just become the norm.

One of the biggest absurdities about ERP systems springs from the very word we use so often when describing ERP: integrated.

ERP is an integrated system: it integrates all data and processes into a single application. Different modules look over different aspects of data and processes, but a change in one module automatically reflects in all others.

A fantastic concept. When it was invented, it streamlined processes, boosted productivity and eliminated overhead and error.

So, whenever a new functionality is needed by a company, it should be integrated into the ERP, to benefit from the integrated system. Right?

Posts navigation

When comparing .NET variables, including Enums, you cannot use C/AL comparison operators. To compare .NET variables, you must use the Equals method (of the System.Object type) that all .NET types implement or inherit. So, instead of IF var1 = var2, or IF var1 = var1.EnumValue (in case of an Enum), just write IF var1.Equals(var2), or IF var1.Equals(var1.EnumValue).

I see this mistake often being made or attempted by developers, even though it has been documented inside .NET Interoperability documentation since it was introduced with 2009 R2.

Make sure that you don’t access the Microsoft.Dynamics.NAV JavaScript object before the document ready event fires. If you do so, you might experience problems on Chrome when the user refreshes the browser (F5). It appears that on refresh Chrome loads (and runs) scripts in different order, and depending on how complex scripts included in your project are, your code might get executed before Microsoft’s script is loaded, and it will cause nasty script errors. This occurs only on Chrome on PC.

When you have to format C/AL variables (numbers, dates/times, booleans) for exchange with other apps, call FORMAT(variable,0,9) instead of simply FORMAT(variable). The format 9 formats the variable according to XML standards, and this value can then be interpreted correctly on any system with any regional settings. This is useful also when passing string-formatted values from C/AL to C# or JavaScript.

To check if a BLOB field has a value, you call its HASVALUE function. For example: IF Item.Picture.HASVALUE THEN;

In older versions, earlier than NAV 2009, you had to call CALCFIELDS before you could check HASVALUE, which – if you think of it, did not make much sense. This was changed in NAV 2009, so ever since that version you can check HASVALUE before you decide to call CALCFIELDS first. It makes all the sense – you don’t need to pull up to 2GB of data over just to see if anything is inside.

If you are an old-school guy (or just old, as me), and you CALCFIELDS first, HASVALUE next, maybe it’s time for you to reconsider it.

Rembember – the pattern is: IF Field.HASVALUE THEN Rec.CALCFIELDS(Field);