Best practices

Transaction Integrity with Connected Systems

  • Reading time:4 mins read

Broken pencilWith .NET Interoperability around, it’s very likely you’ll be synchronously calling external web services from C/AL, to exchange data. I won’t go into discussing whether or not this kind of architecture is good (my own position is that it isn’t), you may end up having situations where your C/AL code simply makes a synchronous call to external systems, such as web services.

Any external call is an expected point of failure. An important question you must always have in mind when calling external functions is transaction integrity. When writing code that targets only NAV, the structure of code is largely irrelevant, as long as you are not using COMMITs (which is another thing you should avoid at all costs). However, as soon as you introduce external calls, the structure becomes critically relevant. Critically relevant.

I’ve talked about this during my 2012 NAV TechDays session, and I promised I’d blog about it – so, here it goes.

Continue ReadingTransaction Integrity with Connected Systems

SQL Server Configuration Recommendations for Microsoft Dynamics NAV

  • Reading time:1 min read

Microsoft Dynamics NAV Team Blog has just published a mega-useful post about recommendations for configuring Microsoft SQL Server for optimum Microsoft Dynamics NAV Performance. If you haven’t yet, you should check it here.

The blog post delivers a PDF document summarizing certain important parameters, configuration settings and suggestions for improving and maintaining a speedy SQL Server for your NAV installation. The recommendations have been written for x64 version of SQL Server 2005 SP3, SQL Server 2008 SP1 and SQL Server 2008 R2. The document was compiled by Michael De Voe, a Senior Premier Field Engineer at Microsoft specializing in performance, scalability, infrastructure and high-availability for in NAV and AX.

Continue ReadingSQL Server Configuration Recommendations for Microsoft Dynamics NAV

10 reasons that make design absolutely necessary

  • Reading time:12 mins read

Unfinished buildings, by net_efekt (on Flickr)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.

Continue Reading10 reasons that make design absolutely necessary

Setup-dependent requirements

  • Reading time:3 mins read

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.

Continue ReadingSetup-dependent requirements

Development best practices – the aftermath

  • Reading time:3 mins read

image 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”.

Continue ReadingDevelopment best practices – the aftermath

Development Best Practices

  • Reading time:2 mins read

image “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 2: Documenting changes: about how to document different kind of changes in code, and also about the level of effect a specific type of change has in the long run
  • Code of coding 3: Die, hard(coding)!: about avoiding embedding output text into code
  • 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.

Continue ReadingDevelopment Best Practices

5th rule of agile ERP: interface where possible

  • Reading time:5 mins read

imageOne 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?

Wrong.

Continue Reading5th rule of agile ERP: interface where possible

4th rule of agile ERP: avoid heavy customizations

  • Reading time:4 mins read

You can’t avoid customizations. Vanilla ERP is a great first step, and a valuable tool for establishing common language between the customer and the consultant. But in the long run? Probably not. Pristine uncustomized ERP won’t be sufficient, because of the gaps between your way and ERP’s way. Sooner or later, gaps will have to go.

Two most common ways of closing functionality gaps are customizing the software, and changing the processes. You can almost always touch general processes, optimize them, twist them, bend them, make them more efficient or even eliminate them. But when it is about industry specifics that add true value or contribute to company’s competitive edge, customization is the answer.

Continue Reading4th rule of agile ERP: avoid heavy customizations

3rd rule of agile ERP: focus on value

  • Reading time:5 mins read

image – “We need a report which groups our sales by product components.”

– “And we need it broken down by cost centers.”

– “And it must show comparison with last month, quarter and year, and with budget and forecast, with indexes and trends. In linear regression.”

– “And it must let you choose if it is by posting date or by document date. Or by shipment date. Maybe some other date as well.”

– “And it must exclude returns, and include only those re-shipments that were linked to original returns in the shown period.”

And it must be a disaster if you agree to half of these.

Continue Reading3rd rule of agile ERP: focus on value

2nd rule of agile ERP: deploy gradually

  • Reading time:4 mins read

Eat an elephantHow do you eat an elephant? One bite at a time. Swallowing it all at once might be tempting as it has all the potential you need to get into the next edition of Guinness World Records. Likewise, trying it with an ERP implementation has all the potential you need to get into to the next edition of Chaos Report. One way or the other.

ERP software is huge. It contains thousands of features potentially touching every single tiniest aspect of your business. Implementing ERP is about introducing change into your company, and change can be evolutionary, or revolutionary. Your pick.

Continue Reading2nd rule of agile ERP: deploy gradually