Microsoft Dynamics NAV 2009: Professional Reporting: Discover all the tips and tricks for Dynamics NAV report building

Reports are used to present information from the database, structure and summarize information, and print documents such as invoices. Reports can also be used to process data without printing anything.

Reports can be created or customized via the Report Designer, which can be found in the Object Designer.

The Report Designer is the development environment that is available in the Dynamics NAV Classic Client to create or customize report objects. It contains a data item designer to define the data model for the report, a section designer to design the layout of the report for the Classic Client, and a request form designer to create an optional request form in which the user can select options when running the report.

The workflow for designing a Classic report in Dynamics NAV 2009 can be visualized with the following diagram:

There are two ways to create a new report: from scratch or by using the wizard. I will start with an explanation of the report wizard and then dive...

The first thing you have to do when you want to design a new custom report is create the data model. Where is the data coming from that I want to show in the report? Is it all in one table or do I need multiple tables? If there are multiple tables, how will I connect the records from the different tables? A good suggestion that I can give is to first make a draft drawing on a piece of paper of the layout of the report you want to create. Write down the fields that need to be visible on the report and then find out which table they are coming from. After that, if there are multiple tables find out how the tables are related and write that down.

This way, when you open the designer you already know what you need to do. Many novice and experienced developers make the mistake of not thinking before they begin. And then it can get confusing very quickly in the report designer.

Now that we have a good idea of the tables that we will require, it's time to open the report...

A processing-only report is a report that does not print but instead only processes data or C/AL code. Processing table data is not limited to processing-only reports. Reports that print can also change records. This section applies to those reports as well.

It is possible to specify a report to be "Processing Only" by changing the ProcessingOnly property of the Report object. The report functions as it is supposed to (processing data items), but it does not generate any printed output.

When the ProcessingOnly property is set, the request form/page for the report changes slightly, as the Print and Preview buttons are replaced with an OK button. The Cancel and Help buttons remain unchanged.

When the ProcessingOnly property is set you also cannot create any sections.

There are advantages to using a report to process data rather than a code unit:

This is how the sections look like when you take the Work Order report into design mode:

When you look a little closer and click on one of the cells, you will notice that when you have a look at its properties, they are the properties of a Shape control. When you select a Shape control in the toolbox and put it on a section you can decide via the property ShapeStyle which type of Shape you are adding.

These are the possible values for the ShapeStyle property of a Shape control:

You have to put the Shape control on top of the other controls (labels, textboxes) that contain the actual data. To do this you can select a Shape and bring it to front or send it to back using the Format menu on top of the report designer like this:

Certain functions can only be used in reports. These functions can be useful for complex reports:

In this chapter, we have covered the basics on how to create a simple report. We've seen how to implement sorting, grouping, totalling, and how to indent data items. You also have an idea on what's involved to be able to print a report to Microsoft Excel. And when you want to make changes or customizations to these kinds of reports it can quickly become complicated.

Furthermore, you should also have an idea by now of the limitations of the Classic report designer. A good example is the lack of colors at runtime. Also, the steps that need to be performed to have an Excel look and feel can become very tedious. Regarding the interactivity features of Classic reports, those are limited to what you can do with the request form.

A lot, if not all, of the shortcomings or difficulties that are inherent to the Classic report designer are solved, more intuitive and more user and developer friendly in RDLC reports for the Role Tailored Client.

The idea of this chapter was to give you a good introduction...