Category Archives: Implementation

In my previous post I’ve (what, again?) shared some statistics about success and failure rates of software projects in general and ERP projects specifically. It seems that ERP projects fare somewhat worse than generic software projects, which I stated might have a lot to do with how requirements are handled.

Agile is an unpopular word in ERP world. We, the ERP people, love the glory and the thunder of The Waterfall. It has worked for us since forever, after all. Yes, we’ve all seen it fail every so often, but we’ve learned to learn from failure, and we know there is no better approach. Don’t we?

Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.

At the core of any agile approach is an assumption that whatever the requirements might be at the beginning of a project, they won’t be the same at the end of the project. The longer the project, the more truth there is in this assumption. To mitigate this situation, agile methodologies start with smaller sets of requirements, they start small and deliver functionality incrementally in a series of releases. No single release covers all requirements, but every release delivers more than the previous one.

With ERP implementations, we generally don’t subscribe to this idea. And at that, we might be wrong.

For a long time, the ruler of project reports was Standish Group’s (in)famous Chaos report, which analyzed IT project success/failure factors. While many of the Chaos report’s findings applied to ERP implementation, the report as a whole was primarily about software development projects. And as we all know, implementing ERP is not the same thing as software development. Hopefully.

Panorama Consulting Group, an independent ERP consulting firm from Denver, Colorado, has conducted a market research in 2008, that explains ERP implementation project success factors and reveals some interesting metrics about real ERP costs, duration and benefits. Finally, we have a decent ERP project report, which reveals some important facts about Microsoft Dynamics.

Implementation is like marriage. For better or worse, you choose a piece of software, take it under your roof and commit to it for a long term, so help you God.

And as in marriage, if you want to live happily ever after with your new software, the my way or the highway attitude doesn’t help much—you must be open to compromise.

Last Monday, I argued for avoiding customizations if at all possible, an argument I stand by firmly. It’s like forcing your wife to color her hair pink. I don’t know about your wife, but mine doesn’t color her hair pink. If you like it pink, it’s probably something to think about before turning your yes in.

But NAV is NAV, isn’t it? It has what it has, and if I need it different, I have to customize it, 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);