Classical Reports - Dynamics NAV 2009

In this post I'm going to share you some basic details about Classical Reports in Dynamics NAV 2009. Most of the content are taken from MSDN Blog (Designing Reports for the Classic Client) 

The Purpose of Reports

              Reports are used to extract and print information from a database in a structured way. For example, you can create a report that lists all the customers and all the orders placed by each customer. To print an invoice, you must create a report that is automatically filled out with the relevant information.

Reports can also be used for tasks other than printing. A report can be used to automate many recurring tasks such as updating all the prices in an item list. You can do this by writing C/AL code in a codeunit, but using a report is much easier because you can take advantage of the powerful data modeling facilities available in the report designer

Report Components

Report Description	A complete description of the report including how data is collected, and how it is presented on paper when the report is run. The report description is stored in the database.
Data Item	Corresponds to a table. To retrieve information from tables, you define data items that refer to tables. When a report uses more than one table, you must set relations between the data items so that you can retrieve and organize the data the way that you want.
Section	In a report that is going to be printed, each data item has one or more sections. A section can be thought of as a block of information that should be printed. The complete report is composed of several sections. Some sections are printed only once, for example, headers. Other sections are printed for each record retrieved from the database. The information printed in the sections is composed of controls. The available controls are: Text boxes – for printing the result of the evaluation of any valid C/AL expression, such as the contents of a table field (also used for complex calculations). Labels – for printing static text such as a caption for a column of data. Shapes, images and picture boxes – for printing graphical elements (lines, circles) and bitmap pictures.
Request form	A form that is run before the report starts to execute. You use request forms to enter requests and select options for the report, for example, the sort order or the level of detail that you want in the report.
Property	An attribute of an object such as a report, data item, section and so on. The attribute may be for example, color, size, and whether or not it is displayed. Properties are set in the Properties window of the object.
Trigger	Certain predefined events that cause the system to execute a user-definable C/AL function. The event triggers the function. The report itself, the data items, the sections, the request form, and the controls all have triggers.

The C/SIDE Report Designer

You use the Report Designer window to define the data model by adding data items and indenting them appropriately.

You can edit the properties and triggers for each of the data items by selecting the data item and opening the Properties window or the C/AL Editor, respectively.

To edit the properties of the report itself, select an empty line in the Report Designer window and open the Properties window.

 To edit the triggers of the report itself, select an empty line in the Report Designer window and click View, C/AL Code.

                Alternatively, you can click Edit, and then click Select Object, and then open the Properties window or the C/AL Editor.

The Section Designer

After you have defined one or more data items, you can design the visual layout of the report in the Section Designer. You can use the Field Menu to select fields and place them in the sections as controls.

You can think of each section as one or more lines on the paper that the report will eventually be printed on.

A header section is printed only once, while a body section is typically printed several times as each loop of the report is iterated.

You can control whether the header should be printed every time a page break occurs while the body sections of the same data item are being printed.

You can edit properties and triggers for each section by opening the Properties window or the C/AL Editor, respectively, while the section is selected.

The controls you place in the sections have a subset of the properties that controls have on forms, not all the properties are relevant for a report.

You can use the same tools to modify the properties (the Font Tool, the Color Tool). You can see a list of the properties in the Properties window.

The Request Options Form Designer

You use the Request Options Form Designer to create a form with fields that prompt the user to select some options before running the report. This designer works like Form Designer.

What Happens When a Report Runs?

When you initiate the report run, the OnInitReport trigger is called. This trigger performs any processing that is necessary before the report is run. It can also stop the report. If the OnInitReport does not end the processing of the report, the request form for the report is run, if it is defined. Here, you select the options that you want for this report.

You can also decide to cancel the report run. If you decide to continue, the OnPreReport trigger is called. At this point, no data has yet been processed. When the OnPreReport trigger has been executed, the first data item is processed provided that the processing of the report was not ended in the OnPreReport trigger. When the first data item has been processed, the next data item, if there is any, is processed in the same way. When there are no more data items, the OnPostReport trigger is called to do any necessary post processing, for example, removing temporary files.

How a Data Item is Processed

Before the first record is retrieved, the OnPreDataItem trigger is called, and after the last record has been processed, the OnPostDataItem trigger is called. Between these two triggers, the data item records are processed. Processing a record means executing the record triggers and outputting sections. C/SIDE also determines whether the current record should cause the outputting of a special section, such as a header, footer, group header or group footer. If there is an indented data item, a data item run is initiated for this data item (data items can be nested 10 levels deep). When there are no more records to be processed in a data item, control returns to the point from which processing was initiated. For an indented data item, this means the next record of the data item on the next highest level. If the data item is already on the highest-level indentation is zero control returns to the report.

Saving, Compiling, and Running Reports

After you have designed a report, you must save and compile it before it can be run. Normally, you do this after you finish designing the report. However, you may want to save a report that is not yet finished and therefore cannot be compiled, for example, if the report contains C/AL code that is incomplete. You can also test compiling a report without closing or saving it.

Saving and Compiling a Report

A report is closed when the Report Designer window is closed. When you close a report, you are prompted to decide whether or not the report should be saved. If it is a new report, you must give it an ID and a name.

The ID must be unique and follow the rules for numbering objects - your local Microsoft Certified Business Solutions Partner can provide you with this information. If you enter ID and Name as report properties, these values are used, and you are not prompted for an ID and a name when you close the report. The Compiled option field is set to TRUE by default. If your report is not yet ready to be compiled, clear the check mark, and click OK to save the report. You can save a report without closing it by clicking File, and then Save or Save As. By using Save As, you can rename an existing report. Like all the other objects in C/SIDE, reports must be compiled before they can be run. When you are designing a report, you might want to test compiling it to find any errors that it may contain (this is more important when the report contains C/AL code in triggers). To test compiling a report when you are designing it, click Tools, and then Compile.

Running a Report

In the application, your reports can be incorporated into menus, or they can be called from, for             example, a command button on a form. However, when you are designing reports, you will often want to run them before they are integrated into the application. When you are designing a report, you can test running the report by clicking File, and then Run. The report is compiled and run in its current stage of development. It is not saved, which means that you can use this function to verify that the changes you are making work as intended before you save them. You can run a report from the list of reports in the Object Designer window by selecting a report, and then clicking the Run button.

Report Properties Overview

                Properties are a feature which can be found in every application object. This topic provides an overview of the report properties.

Properties	Select properties by
The report	Clicking an empty line in Report Designer or by clicking Edit, and then Select Object. https://msdn.microsoft.com/en-us/library/dd354985.aspx
Data items	Clicking the data item in the Report Designer window. https://msdn.microsoft.com/en-us/library/dd338878.aspx
Sections	Clicking either the section bar or somewhere in the section (not on a control.) https://msdn.microsoft.com/en-us/library/dd355138.aspx
Controls in a section	Clicking the control.

                When an object is selected, click View, and then click Properties to open the Properties window. You can set the value of each property in the Value field. When you leave this field (by pressing ENTER or by moving with the arrow keys), the property is updated. Default values are displayed in angle brackets (<>). You can reset any property to its default value by deleting the current value and then moving out of the field. This only applies to properties that have a default vale.

How Properties Are Inherited

                Controls that have a direct relationship to table fields inherit the settings of those properties that are common to the field and the control. For example, if you have an accounting application that stores calculated amounts with five decimal places (for precision), but on a printed report, you only want to display currency amounts with the usual number of decimal places. You can change the DecimalPlaces property of the text box control to display fewer decimals than the default (but not more).

Types of Report Sections

              The following table lists the different report sections.

Section name	Output
Header	Prints before a data item loop begins. If the PrintOnEveryPage property of the section is set to Yes, the header is also printed on each new page.
Body	Prints for each iteration of the data item loop. When there is an indented data item, the complete loop for this data item begins after the body section of the higher level data item has been printed.
Footer	Prints after the loop has finished. If the PrintOnEveryPage property of the section is set to Yes, the footer is also printed on each new page. If the PlaceInBottom property of the section is set to Yes, the footer section is printed at the bottom of the page, even if the data item loop ends in the middle of a page.
GroupHeader	A new group starts.
GroupFooter	A group ends.
TransportHeader	Prints if a page break occurs during a data item loop, the header is printed at the top of the new page. This section is printed after any header section of the data item.
TransportFooter	Prints ff a page break occurs during a data item loop, the header is printed before the page break This section is printed before any footer section of the data item.

Request Forms

                Request forms are used in connection with reports to let the end-user specify search criteria and filtering in a report.

Filtering on Request Forms

                On a new report, the fields that you define as ReqFilterFields are shown, but you can determine if you want to place a filter on other fields by adding lines below those already used.

Note

Remember that users can choose to set filters on fields which you did not specify. We recommend that you add fields that the users of the report will frequently set filters on. You should always strive for balance in your design. If the table has a lot of fields, inexperienced users may find it difficult to find the relevant fields that they want to set filters on. To remove the tab where you set the filters, do not define any ReqFilterFields for the data item and set the DataItemTableView to define a sort order. If you create a request options form, it will still be shown.

                If there is no request options form, an empty form is displayed. On this form, users can choose options such as Print and Cancel. If you set UseReqForm to No, the report will start printing as soon as it is run. In this case, users cannot cancel the report run. It will still be possible to cancel the report, but some pages may still print. If a DataItemTableView is not defined, users can select the key and sort order at run time.

                Be careful what you allow users to change. In complex report that involves data from several tables, the functionality may depend on a specific key and sort order. Letting the user choose filters freely does not interfere with the logic of the report.