Upgrading NAV Classic Reports to Microsoft Dynamics NAV2013

Recently I had been tasked with an upgrade project for Microsoft Dynamics NAV; namely upgrading one of our clients from their old NAV5 installation to a brand new NAV2013 implementation.

I say brand new implementation because it was almost exactly that – a reimplementation of their existing ERP solution in a new piece of technology.

I won’t list the all of the differences between the versions but one of the key issues is the removal of the ‘classic’ client and the transition to a fully fledged role-tailored client (RTC) which runs outside of the development environment (in older versions of NAV such as NAV5 and lower there was only a classic client which also served as the development platform).

The upgrade path for NAV is quite like the path to Mordor – fraught with danger. It’s a very manual process in places, a lot of the upgrade work must be done via text compare tools in order to ensure that bespoke code is preserved during the switch. I’m sure a lot of people from a .NET background who find themselves working with NAV at some point will agree that the current toolset is lacking (no intellisense, method browser in a separate pop-up window which you need to access a menu item to get to, variables also declared in this window…!)

In addition to the removal of classic NAV, Microsoft have also completely removed the proprietary report rendering engine and replaced it with SQL Server Reporting Services. If you are familiar with reporting services you will know that although it is a great reporting platform it is not without its gripes. The reports don’t actually run on the server. The report data is streamed to the client as a giant XML based dataset, and the report rendering happens on the client machine (using RDLC reports). This means that you need to build your data set in NAV with a clunky tree based interface which has been made more difficult to work with in NAV2013 by the addition of the data fields into the tree (previously only the data items were present but not the field names). You can’t collapse just the fields; collapsing a data item hides all child items!

The proprietary engine worked more like Crystal Reports in that it was quite easy to determine how a page was going to render without any guesswork (Crystal even allows you to edit a report preview meaning that you can quite easily position elements etc). Reporting services also doesn’t really understand the concept of ‘a page’. You can’t create one or more data items that appear at the bottom of a page. You can have a footer, but headers/footers are not allowed to house data containers. You can use expressions to lift data off data containers in the body area, but that data must be rendered on the page you are viewing or your expression will return a blank value (funnily enough you can make a section invisible and still get the data from it, but only if it’s invisible on the current page!?). Luckily you can use aggregate functions to grab the first/last/max/min data item for your header/footer which can work around most issues.

Due to the above, you can’t have dynamically sized page headers and footers (the header and footer always takes up the same space no matter the content) yet the body of the report can expand and contract based on what is present. This means it’s not that easy to replicate what a client once had in their previous NAV installation in the new reporting engine, leading to longer development time and a lot of ‘tweaking’.

It doesn’t seem to be uncommon to spend a couple of days chopping and changing a single report and then to have to compromise on the final output. Microsoft bundled a tool to create layouts for SSRS reports based on classic NAV reports, and though this works for simple table based reports (which to be fair will usually be the majority), it doesn’t do a very good job for document layouts such as quotes and delivery notes. In fact, I’d find myself starting again from scratch for some reports as the upgrade had made a massive mess of them.

I suppose the morale of the story is: if you find yourself in a similar situation and are quoting for NAV2013 report upgrades, make sure to look into the amount of documents with complex layouts and give yourself at least a couple of days for each one!