Preceding Posts In This Series

In Part 1 of this series of posts, we examined the underlying technologies behind RDLC reporting. In Part 2, we looked at the basic process of converting Dynamics NAV classic reports to an RDLC layout.

Since then, we’ve been working through the specific issues you will encounter during the conversion process.

In parts 5 to 7, we began converting Report 5703 – Transfer Order, which is a document report – the type of report that will likely pose your biggest challenge in transitioning to RDLC layouts. As part of that conversion, we analyzed the classic version of the report in some detail, fixed a problem with the multiple copies feature in the RDLC version, and resolved a labeling problem in the RDLC version created by NAV’s Create Layout Suggestion, where the program had improperly substituted one of its global functions for a perfectly valid text data field.

So what remains to be done?

Assessing the Remaining Problems With Report 5703 – Transfer Order

As a refresher, here’s an image of how the classic version of the report should look:

If you’re using the Cronus Ext database, the transfer order shown here is for the second transfer order in the database, i.e. Transfer Order No. 1002. Here’s the same transfer order presented in our latest version of the RDLC report:

The remaining problems are:

1. Column headings are missing in the body.
2. The report is much too wide. If you want to see the true effect of this, switch to the Print Layout in preview mode.
3. The Shipment Method label is missing.

Fixing the Missing Column Headings

Why are the column headings missing? Well, first, let’s keep in mind that we are dealing with a flattened dataset (if you don’t understand why, see Converting Dynamics NAV Classic Reports To RDLC – Part 1). The data for your column headings is therefore a set of fields within the same record structure as the rest of your data, i.e. the dataset passed to your RDLC report by the classic reporting engine. Whenever data is missing from a report, the first thing you should do is check whether the data has made it into the underlying dataset.

How do you check this? Perform the following procedure:

1. Run your RDLC report. Make sure you request 0 copies.
2. Under the Help menu in the upper right-hand corner of the report previewer, you should see an option labelled “About This Report”.
3. The first time you click this option, it will tell you that the feature you desire has been set up and that you need to run the report again (though not using that exact wording). Do as the message says and close the report, then run it again.
4. The second time you run the RDLC report, click the About This Report option again. This time, NAV will present you with a tabular listing of the dataset.

Now examine the listing, in particular the rows for the Transfer Order No. 1002, which we’ve highlighted in blue:

Compared to the report output, the first thing you should notice is that there are four data records for Transfer Order No. 1002, yet only three detail lines in the report itself.

Why is that?

The short answer is because, in the classic report designer,  the third Integer data item and the Transfer Line data item both have a DataItemLinkReference to the Transfer Header data item, and both share the same level of indentation. Thus, in a flattened dataset model, the header data item is joined first to the Integer data item, which contains only 1 record (thus producing 1 result record), then to the Transfer Line data item, which contains 3 detail records for this transfer order (thus producing 3 result records). The final dataset for our sample transfer order therefore has 4 records (for a complete description of the dataset’s creation, see Converting Dynamics NAV Classic Reports To RDLC – Part 6).

But, given that Integer data items are virtual tables with only 1 field (Number), what’s in all the other flattened dataset fields for that record, including the ones containing the column heading values?

If you said “nothing”, you win the prize. We can confirm our “nothing” hypothesis by scrolling right in our “About This Report” dataset listing until the leftmost column is none other than “Transfer_Line_Item_No_Caption” – our first column heading field:

As you can see, the column heading fields for the first record of any transfer order are all blank. This gives us our first likely suspect in why the column headings themselves are blank, but we cannot yet declare the crime solved. Before we can do that, we have to examine the RDLC layout, in particular the placement of the column headings.

When you do this, you will find that the column headings are in the top row of the table in the Body section, while the Shipment Method label (and data field) are in the bottom row. But these are not regular table header/footer rows, as you might expect. They are group header/footer rows.

Hmmm, the plot thickens. What is our table grouped on? If you right click the group header symbol and select “Edit Group”, it will open up the following window:

As you can see, the table is grouped on the Transfer_Header_No. field. This is an utterly useless grouping. It was useless at the moment of conversion because, in a report with potentially multiple copies of each transfer order, there could be multiple sets of data sharing the same Transfer Header No.

It became even more useless when we placed the table inside a List data region in Converting Dynamics NAV Classic Reports To RDLC – Part 6, which we then grouped on a combination of Transfer_Header_No. and OutputNo (essentially the copy number). The table grouping is therefore redundant.

However, that’s not the point of this post. The point is that table group header values are drawn from the first record in the group, which, as we’ve already seen, contain blank column heading values, and the grouping/sorting at the list and table levels have done nothing to change that fact.

Now that we understand the problem, how do we fix it?

There are actually numerous ways to fix it, some better than others given the functionality we still have to implement for this report. But, for now, let’s take the easy road and simply filter out the blank record at the table level. To do this, open the table properties and set the following filter in the Filters tab:

Now save, compile, and run the report, and you will see that your column headings and your Shipment Method label will both now appear.

Fixing the Spacing Issues

From a visual perspective, all that remains to be done with this report now (so long as we continue to run the simple version of it) is to fix the spacing issues. For instructions on how to do this, see Converting Dynamics NAV Classic Reports To RDLC – Part 3.

Next Post

In our next post, we’ll continue the repairs to Report 5703 – Transfer Order by implementing the Show Internal Information option, which will display the dimension values associated with each transfer line.

Preceding Posts In This Series

In Part 1 of this series of posts, we examined the underlying technologies behind RDLC reporting. In Part 2, we looked at the basic process of converting Dynamics NAV classic reports to an RDLC layout.

Since then, we’ve been examining specific issues you will encounter during the conversion process. In Converting Dynamics NAV Classic Reports To RDLC – Part 5 and Converting Dynamics NAV Classic Reports To RDLC – Part 6, we turned our attention to Report 5703 – Transfer Order as a sample conversion of a document report. We’ll now continue describing that conversion.

The Missing “Page” Label in the Upper Right Corner of the Header

At first glance, this appears to be a simple issue. However, there is more to it than meets the eye.

In the classic report, the line in the top right corner (i.e. the one that starts with “Transfer Order”) is a TextBox with a SourceExpr of “STRSUBSTNO(Text001,CopyText)”, where Text001 is a text constant set to ”Transfer Order %1″ and CopyText is a global variable set in the C/AL code of the CopyLoop data item to equal either “COPY” or blank.

Therefore, STRSUBSTNO(Text001,CopyText) = STRSUBSTR(‘Transfer Order %1′, ‘COPY’) = “Transfer Order COPY” in the case of a copy, and STRSUBSTR(‘Transfer Order %1′, ”) = “Transfer Order” where no copy is involved.

During the RDLC conversion process, the presence of this TextBox first results in a creation of a field in the RDLC data set. However, because this field must be used in the page header, where direct access to data fields is not allowed, the conversion process first creates an invisible Textbox to reference the field in the body of the RDLC report (the first small Textbox with the red font set in the far right portion of the body), then  creates a second Textbox in the header to reference the hidden Textbox by way of the VB expression: “=ReportItems!STRSUBSTNO_Text001_CopyText_.Value”.

This is shown in the following image of the RDLC layout:

1. TextBox in the classic report results in creation of an RDLC dataset field.
2. RDLC conversion process detects that the field must be used in a header, so it creates an invisible Textbox here in the body.
3. RDLC conversion process creates visible Textbox in the header, which uses an expression to reference the value of the hidden Textbox.

This is all standard behavior, but now let’s examine the TextBox that’s supposed to display the word “Page” followed by the page number.

It starts out quite similar to the “Transfer Order…” TextBox by using the SourceExpr “STRSUBSTNO(Text002,FORMAT(CurrReport.PAGENO))”, where Text002 is a text constant set to “Page %1″, and CurrReport.PAGENO is a function that allows you to set or retrieve the current page number.

This, in turn, does result in the creation of a field in the RDLC data set, called “STRSUBSTNO_Text002_FORMAT_CurrReport_PAGENO__”. But instead of treating this like the text value that is intended, the RDLC conversion process detects the attempt in the classic TextBox to use the CurrReport.PAGENO function, which is not supported in RDLC, and instead substitutes its own global page number function, “=Globals!PageNumber”, as shown below:

1. Dataset field is created, but it is not placed anywhere on the report.
2. Because of the presence of the CurrReport.PageNo function in the source TextBox, the conversion process creates a Textbox using the RDLC PageNumber function instead.

This not only results in the “Page” label being dropped. It also results in the display of the incorrect page number, which is supposed to reset to 1 for each new transfer order or copy thereof.

RDLC Conversion Behavior

Why spend so much time describing the page numbering mechanism in this report? First, because it explains the otherwise inexplicable difference in the conversion treatment of two classic TextBoxes that appear, on the surface, to be quite similar.

Second, to drive home a central point: the RDLC conversion process is not very sophisticated. To be safe, you should therefore expect the unexpected in the conversion of every single reporting object.

How do you fix the problem described in this post? The simple/crude answer is, you do what the RDLC conversion process should have done, i.e. use the standard approach, which is to create an invisible Textbox in the body of the RDLC report referencing the dataset field, then create a second Textbox in the page header to reference the value of the invisible Textbox.

However, there is a much more sophisticated solution to this problem (and others), which I’ll address later in this series of posts, but, for now, apply the simple solution to restore the proper page numbering.

Next Post

In our next post, we’ll continue with our repairs to the RDLC version of Report 5703 – Transfer Order, working our way from the top of the report  to the bottom.

Microsoft has just released the Dynamics NAV 2013 beta version for partners. If you’re a NAV partner, you can access the official launch portal on PartnerSource. If you’re not a partner, you can still get a lot of information about NAV 2013 from this site: Dynamics NAV 2013 Beta page on MSDN.

For more information, you can also access the links on this page Dynamics NAV Official Microsoft Sites and this one Other NAV Community Sites and Forums.

Preceding Post

In Converting Dynamics NAV Classic Reports To RDLC – Part 5 of this series, we began to convert the classic Report 5703 – Transfer Order to its RDLC equivalent. We’ll now continue that process.

Understanding Report 5703 – Transfer Order

The key to understanding Report 5703 – Transfer Order is understanding the basic processing loop set up by its data items, which happens to be the same basic processing loop for all Dynamics NAV document reports:

The top-level set of records in this processing loop is determined by the Transfer Header data item, as you might expect. If the filter criteria you set in the Request Page limits the result set to 4 transfer orders, the Transfer Header data item will contain header records for those 4 orders.

The next three data items all involve copies of the Integer table, which is a one-field virtual table (Field Name = “Number”) that is computed on the fly to contain one row per integer in the range of integers you specify. So, if you specified a filter against the Integer table where Number >= 1 and Number <= 6 , your Integer data item would contain 6 records with values in the Number field ranging from 1 to 6.

The first instance of the Integer table in this report is the data item called “CopyLoop”. Its contents are set in its OnPreDataItem() trigger, as follows:

NoOfLoops := ABS(NoOfCopies) + 1;
SETRANGE(Number,1,NoOfLoops);

“NoOfCopies” is an integer variable that stores the number of copies you have requested through the report’s Request Page. NoOfLoops is an integer variable set to equal NoOfCopies plus 1 (to account for the first output of a transfer order, which is not considered a copy). Finally, the CopyLoop data item is computed to contain one row for each of the integers between 1 and NoOfLoops inclusive.

So, if you requested 2 copies of a report:

• NoOfCopies would equal 2;
• NoOfLoops would equal 3 (NoOfCopies + 1);
• The CopyLoop instance of the Integer virtual table would be constructed on the fly to contain three records, one each for the integers 1, 2, and 3;

The second instance of the Integer table is the data item PageLoop. If you’re looking for the C/AL code that filters it, you won’t find it. It’s filtered in its DataItemTableView property: SORTING(Number) WHERE(Number=CONST(1)). This means there is one PageLoop data item for every CopyLoop data item.

There is no code associated with the PageLoop data item. As you’ll see, its purpose is to provide a report section that will act as the de facto header for each transfer order being printed.

The third instance of the Integer table is the data item DimensionLoop1. Ignore this for now, as it is only utilized when the “Show Internal Information” CheckBox is checked.

The next data item is Transfer Line. It is indented to the PageLoop data item, which means it will be processed at least once for each PageLoop record, but its data is actually restricted by a relationship with the Transfer Header data item, meaning it will contain all the detail lines for the transfer order, as you would expect.

Finally, there is another Integer data item, called DimensionLoop2, which is again related to the “Show Internal Information” Checkbox, so, again, we’ll ignore it for now.

Putting this all together, we end up with the following processing loop when we have requested one copy:

Click the “Okay” button, returning you to the List Properties page. Now switch to its “Sorting” tab and set the same two fields in the same order.

Testing The New Version of Your Report

Now save and compile your work, and run the new version of your RDLC report. If you have followed all the preceding steps correctly, you should see something quite similar to the following:

Observe the following:

1. There are now multiple pages to the report. In fact, in this case, because each transfer order fits on one page, the Number of Pages = Number of Transfer Orders + (Number of Transfer Orders x Number of Requested Copies).
2. If you navigate through the record set, you will see that each printed order is properly identified as either an original (no “Copy” beside “Transfer Order”), or a copy. Note, we have done nothing to set this labeling. It is a carryover from the classic report that now works because we’ve implemented the OutputNo variable.
3. The detail lines are now restricted to the lines associated with the current transfer order and only that order.

In other words we have fixed the multiple copy issue.

As you can see, however, there are still plenty of other issues to address.

Preceding Posts In This Series

In Part 1 of this series of posts, we examined the underlying technologies behind RDLC reporting. In Part 2, we looked at the basic process of converting Dynamics NAV classic reports to an RDLC layout.

In parts 3 & 4, we examined some of the issues you will encounter when you use NAV’s Create Layout Suggestion function to generate an RDLC layout, including horizontal and vertical spacing, the use of dataset fields in RDLC report headers and footers, and controlling conditional output.

We’ll now continue that approach by performing the conversion of a more complex report, the document report 5703 – Transfer Order. This example is important because document reports tend to pose the biggest challenge in converting reports to an RDLC layout.

Reversing Microsoft’s Preparations for the Conversion

First, make a copy of 5703 – Transfer Order. Call it “Transfer Order Test”.

Next, open the test copy in the classic report designer. View the report’s sections and delete any TextBoxes with a yellow font. These include “PageCaption” and “OutputNo” in the PageLoop header, “DimensionLoop1.number” in the DimensionLoop1 body, ”NoOfCopies” and “ShowInternalInfo” in the TransferLine header, the unnamed TextBox with a SourceExpr of “Transfer Line”.”Line No.” in the Transfer Line Body, and ”DimensionLoop2.number” in the DimensionLoop2 body.

Finally, view the  C/AL code associated with the CopyLoop data item and comment out any code blocks that begin with ‘IF ISSERVICETIER”.

We’ll be recreating all these TextBoxes and reactivating these code blocks later, but they were not part of the original report, i.e. they were created by Microsoft only to support the conversion to RDLC, and we want you to re-discover the need for them.

Test Your Starting Point

To ensure we haven’t messed up anything, run the classic version of both your test report and the original report and compare them. Make sure you request one additional copy of the report on the Options tab, but do NOT check the “Show Internal Information” CheckBox. Navigate to the first transfer order copy, which should look like this:

As expected, the report is showing the contents of one transfer order per page, followed by a copy of that transfer order, and so on through the record set. Creating multiple copies (and marking them as such) is one of the features we’ll have to implement in RDLC post-conversion.

Create Layout Suggestion Results

Now run the Tools->Create Layout Suggestion function from your test report to produce your initial RDLC layout (in this case, because your test report still contains a copy of the RDLC layout from the original report, you will  have to agree to overwrite that layout). Save and compile the report, then run the new RDLC version from the Windows run command (if you don’t know how to do this, see Converting Dynamics NAV Classic Reports To RDLC – Part 2). Again, on the Options tab of the Request Page, make sure you request one copy but leave the “Show Internal Information” CheckBox unchecked.

The initial RDLC report should appear as follows:

 Right away, we can see that:

1. The top right line indicates you are looking at a copy, but in fact you are looking at the first page of your report, i.e. you haven’t navigated to a copy yet. Furthermore, you will discover that there are no more pages to the report. You only have one page, and it is marked as a copy.
2. The word “Page” is missing from the next line down.
3. There are no column headings.
4. Two sets of identical data have been output. In fact, if you scroll down the report, you will see there are two sets of data being output for every transfer order that meets the report’s filter criteria. Why two sets? In this case, we have asked for 1 copy (i.e. the original report plus one copy of it), so the report seems to be printing all the original and copy information on the same page.
5. The “Shipment Method” heading is missing from the bottom left of the report.

If you switch to Print Layout, things get even more perplexing. You suddenly end up with two pages instead of one, and, stranger still, you end up with different from/to warehouses on each page.

Now let’s have a quick look at the RDLC layout, as follows:

At first glance, the layout appears to contain the basic header/details structure we’re after. But if you look closer, you start to spot a few basic problems:

1. The report’s far too wide at 12.5 inches.
2. A large number of invisible Textboxes have been inserted by the Create Layout Suggestion process (identified by their red font color).
3. All the data is being presented in a table.

If you are familiar with RDLC reporting controls, it is Point 3 that should immediately draw your attention. The Table data region is designed to expand vertically down a page to accommodate a variable number of records; it is not designed to print one record or one set of records per page.

The RDLC reporting control you want for that job is the List data region. So let’s start by doing the following:

Simply placing your details table inside a List data region won’t do the trick, however. If you read the Visual Studio help on List data regions, you will see their description is “A list data region repeats with each group or row in the report dataset”.

If you refer back to the way the data set is constructed for RDLC reports, you will quickly realize that repeating with each row won’t work in this case, as the dataset will contain one flattened row for every transfer order detail record in the report (see Converting Dynamics NAV Classic Reports To RDLC – Part 1 if you don’t understand why). What you need to do is group the list on some field. But which field?

Common sense suggests you’d group on the transfer “No.” field, but that won’t work because you have to contend with copies, remember? There could be more than one set of records in the dataset per transfer order.

A quick perusal of the RDLC dataset shows there is in fact no field that can help you distinguish between copies. That means you’ll have create one in the data items of the classic report. However, to figure out how to do that, you’ll first have to understand how the classic report works.

Preceding Posts

In Part 1 of this series of posts, we examined the underlying technologies behind RDLC reporting. In Part 2, we looked at the basic process of converting Dynamics NAV classic reports to an RDLC layout. In Part 3, we began examining some of the issues you will encounter when you use NAV’s Create Layout Suggestion function to generate an RDLC layout, starting with vertical and horizontal spacing.

We’ll now continue that approach by examining other common issues you will face in the conversion process, again starting with Report 101 – Customer List (see  Converting Dynamics NAV Classic Reports To RDLC – Part 3 for our previous work with this report).

Using Dataset Fields in Page Headers and Page Footers

If you run the original classic Customer List report, it will produce the following report header:

If you examine the header in the classic report designer, you will see it consists of labels and TextBoxes displaying either straight text or the results of various functions (such as the Database function COMPANYNAME and the CurrReport function PAGENO).

In every case, NAV’s Create Layout Suggestion will convert these values into RDLC dataset fields. The problem is, RDLC reports cannot use dataset fields in their page header or page footer. So the Create Layout Suggestion does the following instead:

1. It will use global functions where it can in the page header/footer, as in the case of date/time and the user ID.
2. Where it cannot use global functions, i.e. where the source data can only be found in dataset fields, it will insert Textboxes for these fields in the body of the report, set the visibility for these Textboxes to “Hidden”, and set their font to red to indicate they were created by the Create Layout Suggestion process.
3. It will then insert additional Textboxes in the page header/footer, and set the value of this second group of Textboxes to equal the values of the corresponding hidden Textboxes.

In other words, since the Textboxes in the page header/footer can’t directly connect to dataset fields, they connect instead to the hidden Textboxes in the report body, which, like proxies, essentially connect to the dataset fields on their behalf.

There is nothing for you, the programmer, to do in this arrangement. It is all done automatically by the Create Layout Suggestion process, except for one task, which is best illustrated by examining Microsoft’s manual post-conversion changes of the same Customer List report:

As item 1 shows, Microsoft moved the hidden Textboxes from the right-hand side of the table to unused cells within the main body of the  table. This was done because hidden Textboxes outside the width of standard paper may cause layout problems. In this case, it also has the added benefit of making the hidden Textboxes more visible to other programmers.

Of course, there may be times when you need to place your own hidden fields somewhere in the report, typically to support their use inside a page header/footer, but having nothing to do with Create Layout Suggestion. In this case, you are advised to use a yellow font  to distinguish such fields from those created automatically by Create Layout Suggestion.

Hiding the Filter Line When No Filter is Specified

If you run the copy version of the Customer List Report (the one we had you create in  Converting Dynamics NAV Classic Reports To RDLC – Part 3), you will notice that it displays a filter line in the report even when no filter is specified: 

This does not display in the original classic version of the report because of the following code in the OnPreSection() trigger of the header section containing the filter line:

CurrReport.SHOWOUTPUT((CurrReport.PAGENO = 1) AND (CustFilter <> ”));

However, if you recall from Converting Dynamics NAV Classic Reports To RDLC – Part 1, RDLC reports don’t run the section code from their classic counterparts (i.e. only the data items portion of the classic report is run), so this trigger code is never fired. Instead, you must insert a hidden control in the classic report that you can use as a variable in the RDLC report.

As you can see from item 1 above, Microsoft has already inserted the hidden control for you, namely a TextBox that uses the CustFilter variable as its source expression. This will then become a field in the dataset passed to the RDLC report, and also a Textbox in the body of this report:

The small Textbox identified as item #1 is the one that references the CustFilter dataset field. You can delete this Textbox, as it’s not required. The larger Textbox identified as # 2 is the one that actually displays the filter data. Right click this Textbox and select “Properties”, which will  bring up this panel:

Select the Visibility tab, then set the Initial Visibility section to “Expressions”, using the following formula, as shown by # 1 above:

=IIF(Fields!CustFilter.Value<>”",False,True)

Click OK and the RDLC report will now display a filter line only when a filter has been set.

Summary of Steps Required to Convert The Customer List to RDLC

Assuming Microsoft had done nothing to prepare for the conversion of Report 101 – Customer List, here are the steps you would have had to perform to do the conversion yourself:

1. Insert a hidden TextBox with the CustFilter variable as its SourceExpr into the classic version of the report.
2. Run Create Layout Suggestion to produce an initial RDLC layout, which will include your hidden CustFilter both as a field in the dataset and as a Textbox in the body of the RDLC report.
3. Delete the CustFilter Textbox from the RDLC report.
4. Use the CustFilter field value in the RDLC dataset to control the visibility of the RDLC report’s filter line, which is actually a Textbox with a name of “Customer_TABLECAPTION__________CustFilter”.
5. Adjust RDLC vertical spacing using the Height and Padding properties or report objects.
6. Adjust RDLC horizontal spacing. In particular, merge the customer address table cells with cells to their right to give them sufficient space for printing, while shrinking the width of other table columns to ensure the overall report width will fit inside your target paper size.
7. Move any hidden Textboxes inserted into the RDLC layout by the Create Layout Suggestion process into an unused space in the body of the report (in this case, into unused table cells). This will not only help you ensure the overall width of the report will fit inside your target paper size, but, if the table cells are larger, will also make the hidden cells more visible to other programmers.

Next Post

In the next post, we’ll convert a more complicated NAV standard report to demonstrate other issues you will encounter in the report conversion process.

Create Layout Suggestion

As described in see Converting Dynamics NAV Classic Reports To RDLC – Part 2, Dynamics NAV provides a Tools->Create Layout Suggestion menu option to automatically generate an RDLC layout for an existing NAV classic report.

Unfortunately, because classic and RDLC layouts are associated with two different reporting tools, they are not fully compatible. Some elements of a classic report will not properly translate to an RDLC layout.

The remainder of this article is devoted to these issues. It assumes you already have a firm grasp of both classic reports and Visual Studio’s Report Designer (if you’re weak on the latter, the online help of both NAV and Visual Studio are helpful, as is the book Microsoft Dynamics NAV 2009 Professional Reporting by Steve Renders – no affiliation).

Now, onto the issues, which we’ll tackle by making copies of some of Dynamics NAV’s standard reports, deleting their existing RDLC layouts (i.e. the ones created by Microsoft), then attempting to recreate those layouts.

Vertical Spacing

From the classic object designer, run Report 101, Customer List. Without selecting any of the filters, click the Preview button, which should result in something similar to the following:

If you were to run the RDLC version of this report (i.e. from the RoleTailored Client), you would see that there are only minor differences between the two. That’s because Microsoft did the RDLC conversion for you.

To repeat the conversion process, return to the classic report designer and make a copy of the Customer List report under a different name and report number.

Then click the Tools->Create Layout Suggestion menu option for this copy. Because an RDLC layout already exists for the report, you will see the following message:

Click the “Yes” button, at which point the system will open Visual Studio Report Designer and show you your new layout. Complete the proper save and compile process and use the Windows Run command to run the RDLC version of the report (see  Converting Dynamics NAV Classic Reports To RDLC – Part 2 for instructions), resulting in the following report:

Comparing this report to the classic version and looking at issues 2, 3, and 6, it should be immediately apparent that the desired vertical space is missing between certain sections of the report. This is unfortunately a recurring problem when converting classic reports to RDLC, one you’ll have to fix manually by going into the Visual Studio Report Designer and adjusting the height and padding properties for each report item (or, in this case, because a table object is being used to display the data, each table row).

This is obviously a minor issue that is easy both to spot and fix. The danger lies in the situation represented by issue # 5. Here, it appears as if the vertical spacing has been preserved between the address and contact information. This is not the case, however. What’s happened is that 7 table rows (text boxes)  have been reserved for address information, both in the classic and RDLC versions of the report, yet only 4 or 5 rows are typically used, making it appear as if the desired vertical spacing has been preserved. But should the report encounter a customer record that requires all seven address rows, the extra space will be entirely consumed.

The lesson here is that you can always expect vertical spacing issues in the RDLC layout generated by Create Layout Suggestion, so you need to manually check each situation and not assume it’s okay based on visual appearance alone.

Note, there is a more formal and conditional way of dealing with vertical spacing, which involves the use of a BlankLineCounter section in the classic version of the report, but we’ll address that in another post.

Horizontal Spacing

Another spacing issue is that of column width. See how the address information is chopped off on the right (issue # 4 in the image above)? If you examine the underlying RDLC layout, you will see that it appears as if Create Layout Suggestion allocated sufficient space to print the full width of the address (it didn’t, but let’s just pretend it did):

However, if you notice the ruler bar along the top, you will see that the report is already space-stressed horizontally for letter-size paper (especially when you add in margins). As a result, this expanded field is collapsed when you print the report, thereby chopping off the address information.

How do you fix this? In this case, because you are dealing with a table as a data region in the RDLC layout, you do what Microsoft did and merge some of the table cells, as follows:

This is accomplished in the Visual Studio Report Designer by selecting the cells you wish to merge, right-clicking, and choosing the “Merge Cells” option. Note, also, that Microsoft increased the width of the address text boxes to 6.66 cm from 4.50 cm as part of this fix, and manually adjusted the size of other table columns to reduce the overall width of the report (see ruler at top).

The point of this section is that, as with vertical spacing, you can also expect to make significant manual adjustments to the horizontal spacing of any suggested RDLC layout. And, as with vertical spacing, you cannot rely on cursory visual observations alone to detect problems. What if, for example, the address fields had only been collapsed 10 % instead of 50 % in the above scenario? You may not have noticed the problem at first glance, but it could still cause an error when printing certain records.

Review, Review, Review

If you are a technical person, we’re sure you will find samples of vertical and horizontal spacing issues somewhat trivial, and certainly they are trivial to fix. The real issue here is about process. When you generate an RDLC layout using Create Layout Suggestion, you are strongly advised to check all vertical and horizontal spacing issues to the same degree you would when building a report from scratch.

You should also use the Print Layout Mode when previewing a report in the Visual Studio Report Viewer, as Print Preview won’t reveal all the layout issues.

Finally, we hope you have seen the value of making a copy of a standard NAV report, generating a new RDLC layout via Create Layout Suggestion, then comparing this layout to the one provided by Microsoft. Not only will this teach you about the shortcomings in the generated layout; it will also teach you how to address them.

Next Post

In the next post, we’ll go deeper on this Customer List report and examine the issues of conditional output and using data fields in page headers & footers in RDLC reports.

The Basic Report Conversion Process

First, we might as well be up-front: the basic process of converting Dynamics NAV classic reports to RDLC layouts is clunky, time-consuming, and somewhat error-prone. This is caused in large part because you have to repeatedly work back and forth between the NAV classic report designer and the Visual Studio report designer (if you don’t understand why, see Converting Dynamics NAV Classic Reports To RDLC – Part 1).

The best way to demonstrate this is with a walk-through of the simplest possible report: a two-column (Code and Name)  list of salespeople that looks like this in the classic Print Preview:

The report has no true header or footer, no global variables or C/AL code, no hidden fields – no complications whatsoever. It also has no RDLC layout, meaning it can only be run in the NAV classic client.

To create an RDLC layout, you have to first open the report in the classic report designer. NAV then provides us with two menu options:

1. View->Layout; or
2. Tools->Create Layout Suggestion.

If you choose View->Layout, NAV will either open the report’s existing RDLC layout, if one exists, or create a new blank RDLC layout.

If you choose Tools->Create Layout Suggestion, NAV will attempt to create a new RDLC layout based on the report’s classic layout, overwriting the existing RDLC layout, if any (though it will first request your permission to do so).

In either case, NAV will launch the Visual Studio Report Designer and load the RDCL layout in effect. For now, choose option # 2, the Create Layout Suggestion, which should result in the following Visual Studio Report Designer screen:

Naturally, the first thing you’ll want to check is how the report looks with its new RDLC layout, but here you run into your first challenge: there’s no way to preview the report from this environment. What you have to do instead is:

1. Click File->Save Report.rdlc in the Visual Studio Report Designer.
2. Switch back to the data items form of the classic report designer.
3. Click the data items form, giving it focus (that’s the trigger for the next step in the process).

NAV will then respond with the following form:

Click  ”Yes” to this question.

What are you answering “yes” to? You’re loading the RDLC layout saved in the Visual Studio Report Designer into the classic report object.

Loading is not the same as saving and compiling, however, so if you want to properly complete the process, you will have to click File->Save in the NAV classic report designer and make sure the “Compiled” box is checked.

Where’s your RDLC report preview? Still not there yet. To this point, all we’ve done  is ensure that the RDLC layout we saved in Visual Studio is the same as the one we’ve saved in the NAV report object, i.e. we’ve put them in sync.

With your report properly saved, you have to type the following at the Windows command prompt: ”DynamicsNAV:////runreport?report=XXXXX”, where you replace “XXXXX” with your report ID. Note, this form of the command is dependent on the availability of a local service tier. If you’re missing said tier, you’ll have to run a more specific form of the command, as follows: DynamicsNAV://server/service/company/runreport?report=XXXXX, where you replace the bolded elements with your NAV server name, service, and company, in addition to providing the correct report ID.

Do all this correctly and you will be rewarded with the RDLC Report Viewer preview of your report, as follows:

Now picture doing this for every review cycle (i.e. every time you want to preview a change you’ve made to an RDLC report), and you’ll understand why we refer to the process as “clunky”. It’s not as bad as it seems, mind you. After a while, your fingers get pretty quick at such repetitive tasks, but that, of course, can cause other problems…

Beware the Gotchas

There’s a reason we just dragged you through the preceding process loop, and it’s not because we’re sadists. Look again at the steps involved:

1. Open report in classic report designer.
2. View or create an RDLC layout and load it into the Visual Studio Report Designer.
3. Perform layout work in Visual Studio. When you’re finished, save the Report.rdlc file.
4. Switch back to the classic client, click on the data items form.
5. NAV will ask you if you want to load the changes made to the RDLC layout. Say yes.
6. Click File->Save to save and compile the report.
7. Use the Windows run command to launch a preview of the updated RDLC version of the report (you can alternatively provide access to a report by putting it in a menu on a page in the RTC, but that won’t do much to shorten the process).

Now consider for a moment what will happen if you make changes during Step 3 of the process, save these changes in Visual Studio, then make some more changes, then switch back to the classic report designer without saving your second set of changes. NAV will still inform you that the RDLC layout was changed by Visual Studio. You will no doubt proceed to save and compile the report. But when you run a preview of the report, it will not render the report based on your latest version in Visual Studio. It will render it based on the version you last saved in Visual Studio, i.e. excluding any changes you made after that point (which may well be more your fault than NAV’s, but keep in mind the messages give you no clue; in fact, they go a long way to reassure you that all is well).

This may seem like a small issue, and indeed NAV will prompt you to close and save your layout in Visual Studio when you attempt to close the classic report, but if you’re new to the Visual Studio Report Designer and need to go through a lot of change/review loops during development, this type of gotcha can seriously mess up your debugging process.

So the moral of this post is: be careful in this environment, because it’s not only clunky – it’s a bit tricky, too.

Next Post

In the next post, we’ll undertake our first conversion of an existing NAV classic report into its RDLC counterpart, and begin showing you some of the problems you’ll encounter, as well as how to fix those problems.

An Inevitable Conversion

As Microsoft has already announced, Dynamics NAV 2013 will run only RDLC reports and will discontinue the use of NAV classic reports. This means all customers upgrading to NAV 2013 will have to convert their classic reports to the RDLC format.

Some will undoubtedly dislike this forced conversion, but we believe it’s an opportunity for NAV customers to greatly enhance their reporting capabilities, not only for NAV 2013, but also for NAV 2009, where RDLC reports are optional.

What is RDLC?

RDLC stands for “Report Definition Language Client-side”, an XML markup language used by Microsoft’s Visual Studio to define and store report definitions.

RDLC reports are rendered by a .Net control called Report Viewer, which can be embedded in .Net applications.

The Report Viewer does not play a part in retrieving data; it merely formats and presents the data supplied by its host application. This all happens locally, i.e. on the client, which explains the “Client-side” portion of RDLC’s full name.

Dynamics NAV acts as the host application for the RDLC Report Viewer. It is therefore up to NAV to retrieve the data and supply it to the Report Viewer along with the RDLC report definition.

How does NAV retrieve the reporting data? First, let’s take a look at the existing situation in NAV 2009 R2.

RDLC in NAV 2009 R2

When you run a report from NAV’s classic client, it will be a classic report – no exceptions – which means NAV will process the classic data items and the classic layout in concert to render the report in the classic report viewer.

When you run a report from the RoleTailored Client (RTC), the first thing NAV must do is determine if the report has an RDLC layout. If it does not, NAV will invoke classic client functionality to run the classic version of the report.

If the report does have an RDLC layout, NAV will still use the classic data items, but, in this case, it will retrieve all the data first, flatten it into one dataset, then hand both the flattened dataset and the RDLC layout off to the RDLC Report Viewer for rendering. Note, none of the classic report code beyond the data items will be processed (i.e. none of the code in the report section triggers will fire):

Note, also, that only data item fields placed in one of the sections of the classic report will make its way into the dataset for the RDLC report.

RDLC in NAV 2013

In NAV 2013, there won’t be any classic reports, so NAV will presumably retrieve and process the data using some other mechanism (word is the old classic report object will become strictly a dataset designer, but we’re waiting until we get my hands on the final version of NAV 2013 to verify). And, as mentioned, the only way to render reports will be via the RDLC Report Viewer.

The RDLC in NAV 2013 will upgraded to the 2008 version, which will add even more reporting functionality to its already impressive toolset.

However, Microsoft has announced that customers cannot upgrade directly to NAV 2013. They must go through NAV 2009. So the remaining parts of this article will focus entirely on converting reports to the RDLC in 2009 R2.

RDLC vs RDL

Just to avoid any confusion, we’ll finish today’s article by clarifying the differences between RDLC and RDL.

RDL is the report definition language used by Sequel Server Reporting Services (SSRS), Microsoft’s powerful server-based reporting engine. RDL files are created by SQL Server’s Business Intelligence Studio, which is a specialized implementation of Visual Studio geared toward BI projects.

RDL and RDLC are close cousins. For example, they share the same XML schema. But, as mentioned, RDLC files contain none of the information required to retrieve data. This gives them the flexibility required for use in general applications, where data may sometimes come from a program or other non-standard data source.

Next Post

Now that we’ve gotten the background information out of the way, part 2 of this article will look at the basic process of converting classic reports to RDLC.

Management Reporter 2012 was recently released and integrated with Microsoft Dynamics NAV 2009 R2. Over the next few months, we’ll be writing a number of blogs on Management Reporter 2012 features, including:

• depth of integration with the NAV financial data;

• drill-through capabilities into operational data;

• graphing/charting;

• advanced reports;

• publishing and sharing your reports with others;

• performance;

We’ll also be comparing and contrasting Management Reporter 2012′s capabilities and report-building efficiency with NAV’s classic reporting toolset, RDLC reporting, and full-blown SSRS reporting (i.e. accessing NAV data from SSRS directly through SQL Server or a cube).

In the meantime, as a quick preview, here’s a look at the Management Reporter 2012 Fact Sheet.