Your message has been sent.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
Data item Sections
Earlier in our discussion on reports, we referred to the primary components of a report. The Triggers and Properties we have reviewed so far are the data processing components. Next in the report processing sequence are Sections. In Classic RD reports, Sections are the output layout and formatting components. In RTC reports, Sections have a much more limited, but still critically important, role.
In the process of creating the initial report design, you may be entering data either completely manually as we've done in our example work, or you may use the Classic Report Wizard. If you use the Wizard, you will end up with Sections defined suitable for Classic Client Report processing.
Those Sections may be only rough draft equivalents of what you may want your final report to look like, but they are a suitable starting place for the Classic RD layout work, if that were the tool you were going to use. If you are creating your report completely manually, that is by not using the Wizard, you may also find it appropriate to define Sections to the point that the Classic Client could print a basic, readable report.
In our case, we are focusing our production report development effort on the RoleTailored Client, so we will invest minimal effort on Classic Client compatible report layouts. We might do just enough to allow test report runs for data examination purposes and logic flow debugging. However, creating basic Section layouts provides us with another benefit relative to our VS RD layout work, especially if we can create them using the Report Wizard, because all the fields to be used by VS RD must be specified in the Sections.
Creating RTC reports via the Classic Report Wizard
Let's look at the RTC report development flow again. The preceding image is very similar to the one we studied earlier in this articles, but this flowchart only shows the steps that are pertinent to VS RD.
In Step 6 of this flow, there is an option to Create Layout Suggestion in the Visual Studio Report Designer as shown in the following screenshot:
When you choose Create Layout Suggestion, the C/SIDE Report Designer will invoke a process that transforms the layout in Sections to a layout in the Visual Studio Report Designer. If a VS RD layout previously existed, the newly created layout will overwrite it. Therefore, this option will normally be used only once, in the initial stages of report design.
Let's experiment by using the Report Wizard to create a simple report listing the gifts received by ICAN. We will access the Report Wizard in the Object Designer. Click on Reports | New, then fill in the Wizard screen as shown in the following image.
Then click on OK and choose fields to display in the report as shown in the following screenshot.
Click on Next, then choose the sorting order (that is index or key) that starts with Donor ID. Click on Next again and choose to Group the data by Donor ID. Click on Next again and choose to create totals for the Estimated Value field. One more, click on Next and choose the List Style for the report, then click on Finish. At this point, you will have generated a Classic Client report using the Report Wizard. If you View | Sections, you should see a C/SIDE report layout that looks much like the following screenshot.
Let's save our newly generated report so that, if we need to, we can come back to this point as a checkpoint. Click on File | Save As and assign the report to ID 50002 with the Name of Gifts by Donor.
Now click on Tools | Create Layout Suggestion. The process of transforming the Classic Report Layout to a Visual Studio Report Designer Layout will take a few seconds. When the report layout transformation process completes, you should see a screen that looks very similar to the following screenshot.
The primary data layout portion of the same VS RD screen is shown in the next image.
Compare this to the Classic RD data layout we just looked at a couple of steps ago. You will see some similarities and some considerable differences.
Without doing anything else, let's save the VS RD layout we just created for the RoleTailored Client, then run both versions of the report to see the differences in the generated results. To save the VS RD layout, start by simply exiting the VS Report Designer. Once the VS RD screen closes, you will see the following question.
Respond by clicking Yes. Then, when you exit the Classic Report Designer, you will see this question.
Respond by clicking Yes. You will then be presented with the following message.
Again, click on Yes. If there were an error in the RDLC created within the VS RD (such as an incorrect variable name used), an error message similar to the following would display.
Since, hopefully, we didn't get such an error message, we can proceed to test both the Classic Client and the RoleTailored Client versions of our generated report.
We can test the Classic Client (or C/SIDE RD) version of Report 50002 from the same Object Designer screen where we did our initial design work. Highlight the line for Report 50002 and click on the Run button. You should see the following screen:
If we were running this as users, we might want to make a selection of specific Donors here on which to report. As we are just testing, simply click on Preview to see our report onscreen. The report will then appear, looking like the following:
As you can see, with minimum development effort (and a minimum of technical knowledge), we have designed and created a report listing Gifts by Donor with subtotals by Donor. The report has proper page and column headings. Not only that, but the report was initiated withs a Request Form allowing application of filters.
Close the Classic Client report; now let's run the RTC version. Just like we could do with Pages, we will run our Report test from the Windows Run option. Click on Run and enter the command to run Report 50002, as shown in the next screenshot.
Click on OK. If the RoleTailored Client is not active, after a short pause, it will be activated. Then the Request Page will appear. Compare the look and contents of this Request Page with the one we saw previously for the Classic Client.
As before, click on Preview and view the report. Of course, this time we're looking at the RTC version.
This method of automatic transformation is very useful for getting an initial base for a new report or, obviously, for the complete generation process for a simple report where the requirements for layout are not too restrictive.
eBook Price: $41.99
Book Price: $69.99
Learn by experimentation
One of the most important learning tools you have available is experimentation. This is one of the areas where experimentation will be extremely valuable and informative. It will be very good for you to know which types of report transformations work well and which do not. The best way to find out is by experimentation. You should create test Classic reports, using a variety of the Report Wizard options, then transform those to RTC reports and examine the results.
You should also work on test copies of some of the standard reports that are part of the NAV system. Make sure you are working on test copies, not the originals! Open the test copy of a report in Design mode, then Create Layout Suggestion. This will wipe out the VS RD layout that came with the report from Microsoft, hence the emphasis on using test copies. You will find that some reports will transform fairly well and some not well at all. The more you test, the better you will be able to determine which RTC report designs can be generated using this approach, and which ones will need to have most or all of their layout design work done manually within the VS RD.
When NAV prints a report (to screen, to hardcopy, or to PDF), NAV will format using the printer driver for the currently assigned printer. If you change the target printer for a report, the output results may change depending on the attributes of the drivers.
When you preview a report in the RTC, by default, it will be displayed in an interactive preview mode. This mode will allow you to access all of the dynamic functions designed into the report, functions such as sorting, toggling for expand/collapse display, and drilling into the report. However, it may not look like the hardcopy, if you print it. If you click on the Print Layout button (pointed to by the cursor icon in the following screenshot), then the printer layout version of the report will be displayed.
In most cases, the display on screen in Preview – Print Layout mode will accurately represent how the report will appear when actually printed. In some cases though, NAV's output generation on screen differs considerably from the hardcopy version. This appears to most likely occur when the selected printer is either an impact printer (such as a dot matrix) or a special-purpose printer (for example, a barcode label printer).
Inheritance operates for data displayed through report controls just as it does for page controls, but is obviously limited to print-applicable properties. Properties, such as decimal formatting, are inherited. Remember, if the property is explicitly defined in the table, it cannot be less restrictively defined elsewhere. This is one reason why it's so important to focus on table design as the foundation of the system.
Other ways to create RTC reports
In the example we've gone through to create an RTC report, we generated everything using the Report Wizard and the automatic report transformation tools. There are at least two other ways to create RTC reports. They are probably obvious, but let's list them:
- Use the Report Wizard to create the basic report. Then use the Classic RD to modify the Sections, followed by transforming the sections into the VS RD Layout. If you are going to use any data in your final report other than that inserted in sections by the Report Wizard, you will have to include that data in a section. For example, if you want to have some heading fields such as a display of the Filters applied to the report, you will have to add those fields to the sections before moving on to work in the VS RD.
- Create the Classic RD without use of the Report Wizard, in other words, manually design the Data Items and manually insert all data elements into the Sections. If you are not going to run this report as a Classic Client report at all (that is, have no concern about its appearance in the Classic Client environment), this is perfectly acceptable. In this case, it doesn't matter how the Sections are structured or where the data elements appear in the Sections. What matters is that all of the data elements needed by the VS RD are defined in the Sections Designer. Of course, if you want the transformation of the Sections to create a useful VS RD layout, then you should layout the Sections accordingly.
A very important item to remember is that even though Sections created for use in the Classic Client have triggers and those triggers may contain code, the transformation tool will discard that code in the process of creating the VS RD Layout definition. If the Classic Client version of a report has any code embedded in the Sections, it must be removed and redesigned to operate inline within the processing of the Data Items or as part of RDLC property based logic. If a report is to operate in both Classic and RTC environments, you must be careful that such code will work in both without conflict.
Modify an existing RTC report
Not surprisingly, when we modify an existing report, the path into the Visual Studio Report Designer is different than when we are creating a report for the first time. Let's make some modifications to the last report we created, the simple list of Gifts by Donor, Report 50002.
The first step is to open the report in Design mode in the Classic RD. You should know the route there by now, but just in case, it's Tools | Object Designer | Reports | highlight Report 50002 | Design. The report will open in the Classic Report Designer.
Assuming that we don't need to keep the Classic version of the report up to date, the only reason we have to do anything within the Classic RD is to update the Sections for any additional required data elements. Before we can judge what additional data we might need, obviously we need to decide what we're doing.
Let's do the following:
- Count the number of donations Add the ICAN Campaign data field to the report lines with a heading of "ICAN Campaign"
- Add an interactive expand/collapse feature
- Add interactive sorts by Date and by Amount
- Add a Report Page option to optionally include/exclude gift of Services entries
Before you get started with this effort, you should enter enough test data into the Gift Ledger table to make your testing meaningful. As the system is in the testing stage, it's reasonable to simply Run the Gift Ledger table directly from the Object Designer. This will give you a basic form showing all the data fields. That form is a good way to enter test data.
We can guess that the interactive functions will not require any additional data fields. Adding the ICAN Campaign data field to the report lines will obviously require defining that data element in sections, so that it will be available to the VS RD. The same can be said for adding a heading field showing the user filter applied to the report.
Adding a donation count could be done by adding the count to the Classic report (that is to Sections). Or perhaps we can find a record Count function in the VS RD that will do the job without a new field. We'll try the latter approach first, then, if we need to do so, we will come back and make additional changes to the data definition.
Adding the ICAN Campaign field to Sections is very simple. With the report open to the DataItem screen in the Report Designer, click on View | Sections. That will display the following screen:
Click on the Field Menu, shown in the following image:
This will open a form listing all the fields in the Gift Ledger table. Highlight the desired field, ICAN Campaign, then click on one of the Sections to show a locating crosshairs. Click again to drop the field at the desired spot. It makes sense to put the new field on the same line with the other data fields, but that's not required. Adding the data field this way will also add a header label field for ICAN Campaign. It can be moved or left where it landed. Position will not matter to the VS RD when we are simply adding the field as a modification to the RTC report. It would matter only if we were to go through the transformation process again (that is, choosing the Tools | Create Layout Suggestion option).
The next modification step is to proceed to the Visual Studio Report Designer. If we used the same access method as before, we would create a new VS RD layout, wiping out the previous layout. In this particular case, that might not matter much, but generally that wouldn't be a good idea. We can access the VS RD layout non-destructively for the purpose of enhancement via View | Layout.
That will bring us back to the VS RD layout looking just like it did when we saved it earlier. The only change to the VS RD information so far is in the Data Sources panel, which will contain the two fields we just added to Sections. Before we continue to make our modifications to the VS RD layout, let's study the structure and contents of the VS RD layout.
The Visual Studio Report Designer layout screen
Some of the primary parts of the VS RD layout screen are shown in the annotated screenshot following. This is the VS RD layout for Report 103 – Customer Register.
- Toolbox Tab: The source of the various data control types can be obtained for "drag and drop" insertion into the layout grid.
- Data Sources: This panel shows all of the data elements that are available to this report. All data elements that are shown here must have been previously defined in the Classic RD Sections Designer for this report. That is the only source of data for the VS RD.
- Table Elements: This column is displayed only when one of the data elements in the report body has been highlighted. These icons represent the different types of reporting table elements (that is lines) that are present. Note that "table" here refers to a data display grid in the layout tool, not a NAV data table.
Table Elements—icons and purpose
The following list shows the individual Table Element icons and a description of the purpose of each Table Element type:
- Page Header: This section's content appears at the top of pages, depending on how properties have been defined.
- Body Section: The Body section usually contains a layout table. The layout table is a grid format, which contains the definition of the data that is to be printed repeatedly based on the dataset passed in from the NAV report processing.
- Element Properties: This panel shows the properties for the highlighted report element. It could be the properties for the overall Report, for the Page Header, for a Table Element, for an individual Data Control.
- Property Pages Button:Selecting this button will display the Property Pages for the highlighted report element. This is an easier to read display of element properties, displaying a more complete set than that shown in the Element Properties panel. The Property Pages for the Report Properties for Report 103 is shown in the following image.
- Page Footer:This section's content appears at the bottom of pages, depending on how properties have been defined.
SSRS Reports designed in Visual Studio have a number of Report Items available, all accessible from the VS RD Toolbox as shown in the screenshot following (note that the very similar term "ReportItems" is the name of a collection of text boxes that can be displayed on a report). Most of these items are not utilized when reports layouts are transformed automatically. But, with thoughtful design work, they are available to the developer to create useful, sophisticated outputs as part of NAV enhancements. There are some instances of creative use of new SSRS reporting capabilities in the standard reports. For example, Report 111 – Customer – Top 10 List offers a choice of graphic displays as well as the option to sort the report on any of several columns of data, when in interactive preview mode.
Among the features that are new to NAV 2009 reporting are the following:
- Interactively hide or show data, expand or collapse details, sort data, change filtering
- Display multiple formats as charts as well as images
- Standard output to PDF and Excel formats
- Drill down to underlying data, drill through to pages and other reports
A snapshot follows of the Toolbox from which Report Items can be selected, for drag-and-drop addition to a VS RD layout.
An excellent method of learning about the properties for each Report Item is to view the Help for that Report Item. The easiest way to view the Help for a Report Item is to display the properties form for that item, then click on the Help button on that form.
One way to view the Properties form for each of the Report Items, once you are in the VS RD layout screen, is to highlight a Report Item of the type of interest, right click on it and then select Properties. If you are interested in what properties are available for a Report Item which is not part of the layout you are viewing, you can drag and drop the Report Item to your report layout, examine the properties form, then delete the Report Item from the VS RD layout.
Studying the properties for Report Items (and all of the other components of a NAV system) is highly recommended for the developer who really wants to dig in and learn about the inner workings of the system. Combining that technique with experimentation and studying the makeup of objects in the standard product are very effective ways to become more knowledgeable about design and development options for NAV 2009.
Among the new features in NAV 2009 are properties that can be assigned values based on expressions. The values of the expressions can then be changed dynamically at run time, thus allowing properties to be changed on the fly. In previous versions of NAV, a more limited variation of this capability to dynamically change property values was provided through functions such as Visible, Editable, and UpdateFontBold. These functions are not supported in the RTC, but have been replaced by the ability to assign an expression to the property. Examples are the Visible property in Pages and the Hidden property in various Report Items (or even the SHOWOUTPUT function used in RD Sections). In fact, almost all Report Items can be assigned values based on expressions. Determining how these will behave in a particular situation is a perfect example of where you must let existing designs and your testing be your guide.
If you have read this article you may be interested to view :
- Report components in NAV 2009: Part 1
- Report components in NAV 2009: Part 3
- A Short Tour through NAV 2009: Part 1
- A Short Tour through NAV 2009: Part 2
- A Short Tour through NAV 2009: Part 3
- NAV 2009: Reports
eBook Price: $41.99
Book Price: $69.99
About the Author :
David Studebaker is Chief Technical Officer and a founder of Liberty Grove Software with his partner Karen Studebaker. Liberty Grove Software, a Microsoft Partner, provides development, consulting, training, and upgrade services internationally for Microsoft Dynamics NAV resellers and end user customers.
David has been recognized by Microsoft as a Certified Professional for NAV in all three areas: Development, Applications, and Installation & Configuration. He has been honored by Microsoft as a Lead Certified Microsoft Trainer for NAV.
David just celebrated his first half century of programming, having started programming in 1962. He has been developing in C/AL since 1996. David has been an active participant in each step of computing technology from the first solid state mainframes to today's technology, from binary assembly language coding to today's C/AL and C#.
David's special achievements include his role as co-developer of the first production multi-programmed SPOOLing system in 1967. David has worked on a diverse set of software applications including manufacturing, distribution, retail, engineering, general accounting, association management, professional services billing, distribution/inventory management, freight carriage, data collection and production management, among others. Prior to co-authoring this book, David was the author of Programming Microsoft Dynamics NAV (for the Classic Client) and Programming Microsoft Dynamics NAV 2009 (for the Role Tailored Client).
David has had a wide range of development, consulting, sales and management roles throughout his career. He has been partner or owner and manager of several software development businesses, while always maintaining a hands-on role as a business applications developer.
David has a BS in Mechanical Engineering from Purdue University and an MBA from the University of Chicago. He has been writing for publication since he was an undergraduate. David has been a member of the Association for Computing Machinery since 1963 and was a founding officer of two local chapters of the ACM.