July 19, 2012

Dynamics NAV RDLC Reports: Avoiding The Upgrade Conversion Crunch

Introduction

As a Microsoft-certified Dynamics NAV Upgrade Center, we see a lot of upgrades at Liberty Grove Software. In recent years, those upgrades have been to NAV 2009. Increasingly, with the end of NAV classic reporting now in sight, many of our upgrades have involved the conversion of classic reports to their RDLC equivalents.

For those readers not involved in the technical side of Dynamics NAV, RDLC stands for “Report Definition Language Client”. RDLC is part of Microsoft’s SQL Server Reporting Services toolset and it is the new standard technology for Dynamics NAV reporting.  RDLC and classic reports are supported in tandem in NAV 2009, but in NAV 2013 only RDLC reports will be available. So if you’ve already made the move to NAV 2009, read on to understand why you’re in a great position to do your Classic-to-RDLC migration now.  If you’re planning a NAV upgrade to 2009 or 2013, it is important to understand the report conversion process in order to invest your upgrade dollars wisely.

Understanding Your Report Upgrade Circumstances

If your company uses only Dynamics NAV standard reports, or standard reports with only minor modifications, you don’t need to read the rest of this article. Microsoft provides RDLC versions of all its standard reports out of the box.

The only caveat here is that, if you’ve made minor customizations to standard reports, do not attempt to retain these customizations by carrying your versions of the reports forward in the upgrade process and expecting Microsoft’s Create Layout Suggestion tool to make everything right. If you do this, you’ll overwrite all the manual work Microsoft did to fix up the RDLC versions of their standard reports, which will cause you a lot of grief. You’re much better off to manually reapply your minor customizations to the standard Microsoft RDLC reports instead.

You also don’t need to devote special attention to the report portion of your upgrade if you have only simple custom reports (i.e. lists). In this case, the Create Layout Suggestion tool will help, not hinder, and the total time required for such conversions will be minimal.

If, however, you have complex custom reports, especially if you have a lot of them, you should seriously consider making their conversion a separate project. As with any upgrade, the fewer changes you try to pack into one project (or one phase of a project), the better your chances of completing it on time, on budget, and without any significant problems.

Because they are generally independent units of code, reports are ideal candidates for this divide-and-conquer strategy. But there’s a much bigger reason to take this approach, and it has to do with quality of review.

Put Your Money on the Turtle, Not the Hare

When faced with a large body of work, most of us like to tackle it as quickly and intensely as we can, mainly to get ourselves over the hump.But when tasked with converting a large number of complex reports, it’s actually much better to take a slower approach, and the reason has to do with the completeness of each report upgrade and the quality of review.

If you ask your staff to review a large number of complex, completely rewritten reports in a short period of time, they’ll likely take a rubber stamp approach to the review process. That’s human nature.

Yet, if you’ve gone to the trouble of creating complex reports in the first place, not to mention paying to have them rewritten, they’re probably important to you. They probably play a key role in decision-making across your company.

Besides, if you’re on NAV 2009, you can still use the classic version of your reports while you create your RDLC equivalents. So go slow, convert and review one report at a time, and give your staff the time they need to get it right. This is especially true if your reports have many options and filters, which require a lot more time to test properly. The alternative is to rush things and risk running your company on potentially erroneous information.

The Problem With Microsoft’s RDLC Conversion Tool

So, why do you have to worry about rewriting all your complex custom reports in the first place, instead of using Microsoft’s Create Layout Suggestion tool to do it for you? The simple answer is, for reports with any degree of complexity, the tool doesn’t work. It’s not really Microsoft’s fault, either. The fact is, classic NAV reports and RDLC reports use completely different technologies, and are built on highly divergent paradigms. Automatically converting complex reports from one to the other is a tall order. So you’re going to need a programmer, which brings us to…

Resourcing Your Project

If, as you contemplate how you’re going to resource your report upgrade project, you find yourself thinking, “These are just reports. How hard can it be?”, and a picture pops into your head of that student programmer you just hired for the summer, think again. Rewriting a report created in one technology into the equivalent report in a completely different technology, especially if the report is not properly documented, is not a task for the inexperienced. It’s the subtle errors that will get you (such as a report that functions correctly in all circumstances except one), and inexperienced programmers are sometimes vulnerable to subtleties.

Assigning the conversion project to someone who has a lot of other tasks on his or her plate isn’t a good idea, either. Rewriting complex custom reports is a detailed, methodical, often monotonous task – not the type of work you can do with a lot of interruptions.

For these reasons, you should also consider using an official NAV upgrade center to do the work. There’s nothing like repetition to hone one’s skills at specific tasks, especially if the upgrade center has programmers who specialize in RDLC upgrades.

For more information on the technical aspects of converting classic reports to their RDLC counterparts, see the series of posts that starts here: Converting Classic Reports To Rdlc Part 1.

Tags

Article written by Liberty Grove Software
Liberty Grove Software grew out of its predecessor company, Studebaker Technology, which in 1996 became one of the first Navision developer/resellers in North America (Navision was the predecessor to Microsoft Dynamics 365 Business Central/NAV). ​ As you can tell from our website, we focus exclusively on Business Central/NAV. Almost all our certifications, third-party add-ons, associates, services, and projects are Business Central/NAV-related. This is intentional because we want to offer only the highest caliber expertise to our clients, and we feel we can achieve this only if we devote ourselves to one ERP product.
cross
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram