What is a report?
A report is a vehicle for organizing, processing, and displaying data in a format suitable for outputting. In the past, reports went to hardcopy devices (for example printers). Reporting technology is now more general purpose and flexible. Reports may be displayed on-screen in preview mode rather than being printed, or output to another device (for example, disk storage in PDF format), but with the same formatting as though they were printed. In fact, all of the report screenshots in this article were taken from reports generated in preview mode.
Once generated, the data contents of a report are static. Part of the new flexibility of NAV 2009 is the capability to output reports in preview mode, which have interactive capabilities. However, those capabilities only affect the presentation of the data, not the data included in the report dataset. Examples include dynamic sorting and show or hide data (expand or collapse). Even so, all specification of the data selection criteria for a report must be done at the beginning, before the report is generated. NAV 2009 also allows dynamic functionality for drill down into the underlying data, drill through to a page, and even drill through into another report.
In NAV, report objects can also be classified as processing only by setting the correct report property (that is, by setting the ProcessingOnly property to Yes). A ProcessingOnly report will display no data to the user in the traditional reporting manner, but will simply process and update data in the tables. A report can add, change, or delete data in tables, whether the report is ProcessingOnly or a normal printing report.
In general, reports are associated with one or more tables. A report can be created without being externally associated with any table, but that is an exception, not a rule. Even if a report is associated with a particular table, it can freely access and display data from other referenced tables.
Two NAV report designers
NAV 2009 report design uses a pair of Report Designer tools. The first is the Report Designer that is part of the C/SIDE development environment. The second is the Visual Studio Report Designer. For simplicity, we will refer to these as C/SIDE RD and VS RD in this article.
The C/SIDE RD is the only tool needed to create reports for the Classic Client. If a NAV 2009 system is using only the Classic Client, then only reports created using the C/SIDE RD can be run. However, when using the RoleTailored Client, both C/SIDE RD and VS RD reports can be run. The RTC runs C/SIDE RD reports by invoking a temporary instance of the Classic Client, running the report, and then closing down the Classic Client instance (no additional license slots are used). In this article, we will focus totally on the design of reports for the RoleTailored Client using the VS RD.
The typical report development process for an RTC report begins by doing foundation work in the C/SIDE RD. That’s where all the data structure, working data elements, data flow, and C/AL logic are defined. The only way to create or modify report objects is to start in the C/SIDE RD. Once all of the elements are in place, the development work proceeds to the VS RD where the layout and presentation work is done, including any desired dynamic options.
The following flow chart provides a conceptual view of the creation of a new report using the two different Report Design approaches—one for the Classic Client and the other for the RoleTailored Client. The functions in the center and left chart paths are those done in the C/SIDE RD (steps 1 through 7). Those in the right set of the chart are the ones done in the VS RD (steps 4 and 6 through 10). Steps 1, 2, 3, and 5 are essentially the same (but not quite) regardless of the target client. Step 4 is done in the C/SIDE RD Sections Designer for both clients, but what you do is quite different in each case.
As you can see, many of the functions are the same regardless of the target client. Most of those are done within the Classic Report Designer. Therefore, the accurate claim for NAV 2009 that, even though the layout function uses Visual Studio Report Designer, a large part of the report design is still done within the traditional NAV Report Designer.
For the experienced NAV Classic Client developer who is moving to RTC projects, the biggest challenges will be to learn exactly which tasks are done using which development tool, and to learn the intricacies of the Visual Studio Report Designer layout tools. Those intricacies include understanding just how the VS RD features interact with the NAV data structures and the C/SIDE RD definitions.
This chart shows the general flow of NAV report design in order to make it easier to understand which functions are done in which of the Report Design tools, and allows comparison of the Classic and RoleTailored design processes. In practice, the actual flow will depend on the specifics of a particular report.
It’s feasible for a simple C/SIDE report to be entirely generated by the Wizard, but that is generally not true for a VS RD report. It’s important to note that some of the steps defined in the chart can be performed in a different sequence than that is shown, and some can be repeated in an iterative fashion. Nevertheless, the chart that follows is a good introductory guide to NAV Report Design.
Terminology for the following chart: Working Data is all the non-database data needed to process the report; Report Data is what will be displayed in the report.
A Hybrid Report Designer
The Report Designer toolset in NAV 2009 represents a set of compromises tied back to some initial NAV 2009 product feature goals. One product feature goal was to retain the ability of developers of developers to do their to do their work within C/SIDE, thus avoiding scrapping more than a decade of knowledge and experience. A second product feature goal was to provide a much more fully featured set of reporting capabilities.
After much thought and experimentation, the decision was made to create a toolset that would target report generation using the functionality of SQL Server Reporting Services (SSRS). The method of accomplishing that was to “glue together” the data and logic definition parts of the C/SIDE Report Designer to the layout parts of Visual Studio Report Designer, in order to create a hybrid.
When a report is designed, VS RD builds a definition of the report layout in the XML-structured Report Definition Language Client-side (RDLC). When you exit VS RD, the latest copy of the RDLC code is stored in the current C/SIDE Report object. When you exit the Report Designer and save your Report object, the C/SIDE RD saves the combined set of report definition information, C/SIDE and RDLC, in the database. If you export a report object in text format, you will be able to see the two separate sets of report definition. The XML-structured RDLC is quite obvious (beginning with the heading RDLDATA).
NAV report—look and feel
NAV allows you to create reports of many different kinds with vastly different “look and feel” attributes. The consistency of report look and feel does not have the same level of design importance as the consistency of look and feel for pages does. The standard NAV application only uses a few of the possible report styles, most of which are in a relatively “plain-Jane” format.
While good design practice dictates that enhancements should integrate seamlessly unless there is an overwhelming justification for being different, there are many opportunities for providing replacement or additional reporting capabilities. The tools that are available within NAV for accessing and manipulating data in textual format are very powerful. Unlike the previous versions of NAV, this new version includes a reasonable set of graphical reporting capabilities. And, of course, there is always the option to output report results to another processing/presentation tool such as Excel.
NAV report types
The following are the types of reports:
- List: This is a formatted list of data. A sample list report in the standard system is the Customer – Order Detail list shown in the following screenshot:
- Document: This is formatted along the lines of a pre-printed form, where a page (or several pages) represents a complete, self-contained report. Examples are Customer Invoice, Packing List (even though it’s called a list, it’s a document report), Purchase Order, and Accounts Payable check.
The following screenshot is a Customer Sales-Invoice document report:
The List and Document report types are defined based on their layout. The next three report types are defined based on their usage rather than their layout.