Open Suggestions to Make Navision RDLC Reporting More Efficient

Working with the new RDLC reporting for a few months now after the NAV2009 release, I thought I would like it as I work with it more. Sad to say, that hasn’t happened yet. It’s like being in a bad relationship and hoping some day that it’ll magically get better. And from the general consensus from NAV forums like and, I’m not alone.

The new RDLC reporting tool in Visual Studio makes creating new reports is a lot longer (and tougher) than if you were to create the same report in the C/side report writer. For NAV, we’re all about efficiency. This RDLC reporting tool is by no means efficient. The report writer should be simple and can be easily picked up by non-developers (i.e. end users), RDLC reporting tool is not.

When I saw the demo for the capabilities of the new reports, I must admit I was drooling. If only I had known at the time that I would have to pull all of my hair out to realize only a portion of those capabilities.

Microsoft said that NAV2009 (Navision 6.0) was going to create new opportunities for partners, I’m not sure who they’re referring to. For companies that create external reporting tools like Jet Reports or Pivotier, I have to say this RDLC reporting tool benefits them the most. They are probably laughing all the way to the bank. But for the rest of the general public, I’m not so sure what kind of opportunties they’re talking about…

So in an attempt to make this relationship better and easiers for partners and end users alike, I would like to make 2 suggestions on how Microsoft can help us improve the relationship we have with the new RDLC reporting tool. Yes, just 2 suggestions.

Suggestion #1:
If Everything Has to be in Table Format, Why Not Just Get Rid of the Layout Designer?

For this suggestion, I’m going to use report 10048 (Customer/Item Statistics). This is one of the more popular reports for customers to analyze who bought what.

Before a standard C/Side report can be converted into the RDLC format, you must first create the sections in the C/side report designer. This is what it looks like on the Section Designer:

The report printed from this is pretty straight forward:

It’s not perfect, but a novice Navision developer or the ned user can easily go in and modify the formating easily and add and remove fields very easily.

Now let’s look at the RDLC layout for this same report:

The output is almost exactly the same. If you save this report to Excel, the formatting would still be messed up. So all the features stayed the same and all of the problems came along with it. Other than the ability to save it as PDF, there’s no benefits that can be seen.

This report is not what the customer signed up for and it’s not what we’ve all see in the demos. I spent a few hours creating the proper layout so the report can take advantage of the features described in COURSE: 80146B – Report Design in Microsoft Dynamics NAV 2009. Here’s what I came up with:

This is the RDLC layout that I had to create in order to generate a report like that:

In order to take full advantage of the capabilities that you saw in the NAV reporting demo, you have to put everything into Table(s). For every standard NAV report, none of the formats created allows you to easily convert it into the format that is needed. Even if you used the Create Layout Suggestion feature in the report designer, it wouldn’t format it properly into what is needed.

The problem is that the reporting tool is still trying to replicate how standard C/side report works. Standard C/side report does not work well in the RDLC environment. It’s what we’ve been told. We get it. But why is the tools built within NAV saying the opposite?

If everything nice and cool in the RDLC requires Table(s) to work, why not just eliminate the RDLC layout designer completely? For list type reports (which is what we’re dealing with), we only use the layout designer to put fields we want to be displayed. We’re not making anything pretty like Sales Order, Sales Invoice, etc. If the user needs list type report to look pretty, or add some wierd format, it’s easy enough to export this report to Excel and manipulate the formatting there.

If that’s the case, why not just allow a table-like report designer and have this designer automatically create the report layouts for us? This designer should allow us to easily group records, create formulas, bold, underline, etc. Allow us to utilize the capability of charting, document mapping, etc with option like interface.

Basically, as I mentioned previously, eliminate the layout designer completely and have the computer AUTOMATE the layout process for us. Create the appropriate tables for us to allow us to take advantage of the new reporting features.

Having this will allow the end users to easily create their own reports within NAV with greater efficiency and would promote the non-IT end users to be more involved with NAV. And we know for a fact that the more involved the user becomes with how the data flows, the better they will trust in the system and the happier the users will be.

The last thing we want NAV to become is a software that only people with high technical ability knows what’s going on.

Suggestion #2:

For form type reports, blow it up!

For form type reports, such as sales order, sales invoice, purchase order, etc. We don’t need nice features like document map, expand/collapse, etc. So why are we fussing with the RDLC layout report writer?

Even when the sales order is properly formatted in the RDLC, the preview of the report will not match what’s actually printed. If you print a sales order right now, the preview will not match what is being pritned on paper.

Microsoft seems to have taken away the WYSIWYG (What You See Is What You Get) functionality in print preview. Any report writer will tell you that having a WYSIWYG preview is very important when we create a delicate form type report with nice graphics, lines, boxes, etc. How can we make quick changes to align everything perfectly if we cannot quickly view them? We have to either print them on paper or print them to PDF.

The suggestion here is simple, again, eliminate the RDLC layout designer and create a new report designer for forms that allows NON-TECHNICAL to create nice and professional forms.

I will repeat this over and over again. The best customers we have are the customers that actively tries to learn the system. Most of these users are non-technical.

I understand the desire to move to a more general report writing tool like Visual Studio, I understand the need to move into a language that are more generally accepted. However, I can easily teach someone how to create and modify reports in C/side environment to a non-IT person. I cannot say the same with RDLC reporting tool and Visual Studio.

As I mentioned in the previous article, NAV is a business software, NOT an IT software. As such, everything in NAV must be designed so a business person can easily utilize its full potential. The ease of use should not stop at the front end, it should extend to the back end as well. Including development.

7 thoughts on “Open Suggestions to Make Navision RDLC Reporting More Efficient

  1. Andrew Storrs says:

    With respect to end-user report design I would hope that effort is being made to allow end-users to use Report Builder 3.0 from SSRS in SQL 2008 R2 once NAV 7 finally finishes.

    If they can use C/SIDE Report Builder it will be even easier for new end-users to grasp Report Builder 3.0

    Have a look at how easy this can be:

    I’d be happy designing reports for users in Visual Studio (as long as they do away with the c/side layout and you can create reports like you normally would with SSRS) so we can take advantage of all the layout enhancement features that SSRS can bring – but you’re right, they need to not forget the end-user and their need for ad-hoc or simple reporting needs.

  2. Alex Chow says:

    Hi Andrew, thanks for the link! The creation of a new report in Report Builder 3.0 look very similar to the C/Side report wizard, but I hope they don’t do away with the ability to create reports within the NAV environment in favor of the environment offered in SQL Server or Visual Studio. The reason is again, keeping it simple for the end users who are not IT.

    Part of the reason why the report creating and modifying process in RDLC is so unfriendly is because they needed to support both C/SIDE environment as well as the new environment. Instead of satisfying both worlds, they probably made it much worse…

  3. Pingback: Open Suggestions to Make Navision RDLC Reporting More Efficient - Confessions of a Dynamics NAV / Navision Consultant

  4. Andrew Storrs says:

    Don’t forget with NAV 7.0 you will pretty much say goodbye to Forms, Classic style Reports, etc; so that eliminates supporting both environments.

    I would hope that when they do that they greatly simplify the way we open/edit RDLCs. Let IT or NAV Partners develop in Visual Studio, let end-users develop with Report Builder.

  5. Alex Chow says:

    I’m not sure how much additional investment they will put into the RDLC since it’s so new. I don’t expect much changes with how it works when NAV 7 comes out.

    I’m hoping if enough people make a big deal out of it, they’ll put it higher on their to-do list.

    Any changes is better than the current RDLC reporting tool in Visual Studio.

  6. Pingback: Navision RDLC reporting – SetData and GetData – Why It Is REQUIRED - Confessions of a Dynamics NAV Consultant - NAV Technical Blogs - Microsoft Dynamics Community

  7. Dave Machanick says:

    The problem with SSRS and Report Builder is multi-company support. I have got around this with SQL Synonyms when there was only one SSRS reports user.
    I would like to see NAV switch to useing schema names for company names, and then duplicate the tables within each schema.
    Right now the RTC has taken way the simplicity of development for the non-techie user. I always thought that was Navision’s biggest selling point – the speed with which you could develop and deploy simple additions and changes.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.