Any NAV 2017 report design project uses at least two Report Designer tools. The first is the Report Designer that is part of the C/SIDE development environment. The second is the developer's choice of Visual Studio or the SQL Server Report Builder or Microsoft Word. Refer to the Microsoft Dynamics NAV Development Environment Requirements for information about the choice of tools for handling RDLC report layouts for NAV 2017. We must also be careful to make sure we obtain the proper version of the report tool compatible with the NAV Version we are using.The SQL Server Report Builder is installed by default during a NAV system install. There is also a free version of Visual Studio, the Community Edition, available at https://msdn.microsoft.com/en-us/visual-studio-community-vs.aspx.
For our work, we will use the combination of the C/SIDE Report Designer and Visual Studio Community Edition. If you want to access the SQL Server Report Builder, navigate to Tools | Options and set Use Report Builder to Yes, as shown in the following screenshot:
The option using Microsoft Word is aimed at the goal of allowing customers to be more self-sufficient handling quick, simple changes in format while requiring less technical expertise. Because our focus in this book is on becoming qualified NAV Developers, we will leave discussion of layout formatting with Word for later.
When a report layout is created, SQL Report Builder or Visual Studio (whichever tool you are using) builds a definition of the report layout in the XML-structured ReportDefinitionLanguageClient-side (RDLC). If Word is used to build a NAV 2017 Report Layout, the result is a custom XML part that is used to map the data into a report at runtime. When we exit the layout design tool, the latest copy of the RDLC code is stored in the current C/SIDE Report object. When we exit the C/SIDE Report Designer and save our Report object, Report Designer saves the combined set of report definition information, C/SIDE and RDLC, in the database.
If we export a report object in text format, we can see the two separate sets of report definition. The XML-structured RDLC is quite obvious (beginning with the heading RDLDATA), as shown in the following code snippet:
For the experienced NAV Classic Client report developer who is moving to Role Tailored Client projects, it is initially a challenge to learn exactly which tasks are done using which report development tool and to learn the intricacies of the SQL Server or Visual Studio report layout tools. The biggest challenge is the fact that there are no wizards to help with NAV 2017 report layout. All our report development must be done manually, one field or format at a time. If we would like Microsoft to invest in report layout wizards for future releases, we should tell them.
NAV allows us to create reports of many types with different look and feel attributes. The consistency of report look and feel does not have the same level of design importance as it has for pages. There may be patterns developed that relate to reports, so before starting a new format of report, it is best to check if there is an applicable pattern.
Good design practice dictates that enhancements should integrate seamlessly both in process and appearance unless there is an overwhelming justification for being different. There are still many opportunities for reporting creativity. The tools available within NAV to access and manipulate data for reports are very powerful. Of course, there is always the option to output report results to other processing/presentation tools, such as Excel or third-party products. Outputting a report to Excel allows the user to take advantage of the full Excel toolset to further manipulate and analyze the reported data.