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.
- Transaction: These reports provide a list of ledger entries for a particular Master table. For example, a Transaction list of Item Ledger entries for all of the items matching a particular criteria, or a list of General Ledger entries for some specific accounts, as shown in the following screenshot:
- Test: These reports are printed from Journal tables prior to posting the transactions. Test reports are used to pre-validate data before posting.
The following screenshot is a Test report for a General Journal batch:
- Posting: This is a report printed as an audit trail as part of a "Post and Print" process. The printing of these reports is actually controlled by the user's choice of either a Posting Only option or a Post and Print option. The Post portions of both the options work in a similar manner. The Post and Print option runs a report that is selected in the application setup. The default setup uses the same report that one would use as a transaction history report. This means that such a posting audit trail report, which is often needed by accountants, can be regenerated completely and accurately at any time.
The following screenshot is for another General Journal batch, containing only one transaction, but with multiple problems, as indicated by the warning messages displayed:
Report types summarized
The following table contains a list of the basic different NAV report types.
Used to list volumes of like data in a tabular format, such as Sales Order Lines, a list of Customers, or a list of General Ledger Entries.
Used in "record-per-page header" + "line item detail" situations, such as a Sales Invoice, a Purchase Order, a Manufacturing Work Order, or a Customer Statement.
Generally a list of transactions in a nested list format, such as a list of General Ledger Entries grouped by GL Account, Physical Inventory Journal Entries by grouped Item, or Salesperson To-Do List by Salesperson.
Printed in list format as a prevalidation test and data review, prior to a Journal Posting run. A Test Report option can be found on any Journal page such as General Journal, Item Journal, or the Jobs Journal. Test reports show errors that must be corrected prior to posting.
Printed in list format as a record of which data transactions were posted into permanent status (that is, moved from a journal to a ledger). A posting report can be archived at the time of original generation or regenerated as an audit trail of posting activity.
There are other standard reports which don't fit within any of the above categories. Of course, many custom reports are also variations on or combinations of standard report structures.
Simple reports are often named the same as the table with which they are primarily associated, plus a word or two describing the basic purpose of the report. The report type examples that we've already looked at illustrate this: General Journal–Test, G/L Register, and Customer Order–Detail.
Common key report purpose names include the words Journal, Register, List, Test, and Statistics.
The naming of reports can have a conflict between naming based on the associated tables and naming based on the use of the data. Just as with pages, the usage context should take precedence in naming reports. One requirement for names is that they must be unique; no duplicate names are allowed for a single object type.
In this article, we learned about two NAV report designers and also the types of NAV report.
If you have read this article you may be interested to view :