Category Archives: programming - Page 2

Open Suggestions to Make Navision RDLC Reporting More Efficient

Working with the new RDLC reporting for a few months now after the NAV2009 release, I thought I would like it as I work with it more. Sad to say, that hasn’t happened yet. It’s like being in a bad relationship and hoping some day that it’ll magically get better. And from the general consensus from NAV forums like mibuso.com and dynamicsuser.net, I’m not alone.

The new RDLC reporting tool in Visual Studio makes creating new reports is a lot longer (and tougher) than if you were to create the same report in the C/side report writer. For NAV, we’re all about efficiency. This RDLC reporting tool is by no means efficient. The report writer should be simple and can be easily picked up by non-developers (i.e. end users), RDLC reporting tool is not.

When I saw the demo for the capabilities of the new reports, I must admit I was drooling. If only I had known at the time that I would have to pull all of my hair out to realize only a portion of those capabilities.

Microsoft said that NAV2009 (Navision 6.0) was going to create new opportunities for partners, I’m not sure who they’re referring to. For companies that create external reporting tools like Jet Reports or Pivotier, I have to say this RDLC reporting tool benefits them the most. They are probably laughing all the way to the bank. But for the rest of the general public, I’m not so sure what kind of opportunties they’re talking about…

So in an attempt to make this relationship better and easiers for partners and end users alike, I would like to make 2 suggestions on how Microsoft can help us improve the relationship we have with the new RDLC reporting tool. Yes, just 2 suggestions.

Suggestion #1:
If Everything Has to be in Table Format, Why Not Just Get Rid of the Layout Designer?

For this suggestion, I’m going to use report 10048 (Customer/Item Statistics). This is one of the more popular reports for customers to analyze who bought what.

Before a standard C/Side report can be converted into the RDLC format, you must first create the sections in the C/side report designer. This is what it looks like on the Section Designer:

The report printed from this is pretty straight forward:

It’s not perfect, but a novice Navision developer or the ned user can easily go in and modify the formating easily and add and remove fields very easily.

Now let’s look at the RDLC layout for this same report:

The output is almost exactly the same. If you save this report to Excel, the formatting would still be messed up. So all the features stayed the same and all of the problems came along with it. Other than the ability to save it as PDF, there’s no benefits that can be seen.

This report is not what the customer signed up for and it’s not what we’ve all see in the demos. I spent a few hours creating the proper layout so the report can take advantage of the features described in COURSE: 80146B – Report Design in Microsoft Dynamics NAV 2009. Here’s what I came up with:

This is the RDLC layout that I had to create in order to generate a report like that:

In order to take full advantage of the capabilities that you saw in the NAV reporting demo, you have to put everything into Table(s). For every standard NAV report, none of the formats created allows you to easily convert it into the format that is needed. Even if you used the Create Layout Suggestion feature in the report designer, it wouldn’t format it properly into what is needed.

The problem is that the reporting tool is still trying to replicate how standard C/side report works. Standard C/side report does not work well in the RDLC environment. It’s what we’ve been told. We get it. But why is the tools built within NAV saying the opposite?

If everything nice and cool in the RDLC requires Table(s) to work, why not just eliminate the RDLC layout designer completely? For list type reports (which is what we’re dealing with), we only use the layout designer to put fields we want to be displayed. We’re not making anything pretty like Sales Order, Sales Invoice, etc. If the user needs list type report to look pretty, or add some wierd format, it’s easy enough to export this report to Excel and manipulate the formatting there.

If that’s the case, why not just allow a table-like report designer and have this designer automatically create the report layouts for us? This designer should allow us to easily group records, create formulas, bold, underline, etc. Allow us to utilize the capability of charting, document mapping, etc with option like interface.

Basically, as I mentioned previously, eliminate the layout designer completely and have the computer AUTOMATE the layout process for us. Create the appropriate tables for us to allow us to take advantage of the new reporting features.

Having this will allow the end users to easily create their own reports within NAV with greater efficiency and would promote the non-IT end users to be more involved with NAV. And we know for a fact that the more involved the user becomes with how the data flows, the better they will trust in the system and the happier the users will be.

The last thing we want NAV to become is a software that only people with high technical ability knows what’s going on.


Suggestion #2:

For form type reports, blow it up!

For form type reports, such as sales order, sales invoice, purchase order, etc. We don’t need nice features like document map, expand/collapse, etc. So why are we fussing with the RDLC layout report writer?

Even when the sales order is properly formatted in the RDLC, the preview of the report will not match what’s actually printed. If you print a sales order right now, the preview will not match what is being pritned on paper.

Microsoft seems to have taken away the WYSIWYG (What You See Is What You Get) functionality in print preview. Any report writer will tell you that having a WYSIWYG preview is very important when we create a delicate form type report with nice graphics, lines, boxes, etc. How can we make quick changes to align everything perfectly if we cannot quickly view them? We have to either print them on paper or print them to PDF.

The suggestion here is simple, again, eliminate the RDLC layout designer and create a new report designer for forms that allows NON-TECHNICAL to create nice and professional forms.

Conclusion:
I will repeat this over and over again. The best customers we have are the customers that actively tries to learn the system. Most of these users are non-technical.

I understand the desire to move to a more general report writing tool like Visual Studio, I understand the need to move into a language that are more generally accepted. However, I can easily teach someone how to create and modify reports in C/side environment to a non-IT person. I cannot say the same with RDLC reporting tool and Visual Studio.

As I mentioned in the previous article, NAV is a business software, NOT an IT software. As such, everything in NAV must be designed so a business person can easily utilize its full potential. The ease of use should not stop at the front end, it should extend to the back end as well. Including development.

How to Define SetData and GetData in RTC Reports in Dynamics NAV Navision

For some reason unfamiliar to me, Microsoft likes to write tutorials that does not easily teach you what you need to do to get the job done.

For basic List type reports, yes, it’s quick and simple, however, when it comes to reports involving forms (i.e. sales order, sales invoice, etc), I cannot find a good tutorial on how to get it done.

Forget about the Create Layout Suggestion feature on the form type reports. It sucks. You’d save a lot more time by re-creating your layouts in the standard NAV RDLC report.

One of the most important aspects of the Form type report when you’re trying to edit the standard report is 2 functions: SetData and GetData.

In this example, I’m modifying report 5703 (Transfer Order) report. I’m going to add the Shipment Date and the Shipment Method Code to the report in the report.

Here’s what you need to do, step by step:

1. Create the fields in the classic report and point to the proper field. It doesn’t matter where you put it as we’re not displaying the classic report.
Pic1

2. Click on View –> Layout. This is to modify the report when running the report in the RTC environment. Note that you’ll need Visual Studio 2005 and above to do this.
Pic2

3. You want to add 4 additional text boxes. Two for the caption box and 2 for the text box. I just copy and paste from the existing text boxes above. Number your GetData function 21 to 24 as shown in the example.

Background and the reason for this, if you’re not interested, skip to #4:
Now you need to do a little detective work to find where the SetData and the GetData is. If you notice on the upper left corner, there’s a small hidden field in red. If you highlight the field, the code reads:
Pic3

What’s the reason behind using SetData and GetData? The reason is because you cannot add field text boxes in the report header. The argument here is performance. If you like to read, there’s a section in the 80146B manual that you can download from Customersource or Partnersource. So most of the coding is done on the lines area.

Now, back to the tutorial, where to set the SetData and GetData? Here’s where you need to play a little detective.

4. On the lower right corner, there are some additional hidden boxes in red. Highlight each one of them until you find this one (Note the HeaderInfo. It corresponds to the SetData).
Pic4

5. Highlight the text box and go to the Value property. Click on the Property Page icon to display the property of the Value:�
Pic5

6. Go to the General tab and click on the fx button next to the Value
Pic6

7. Type in the 4 additional fields you’ve set from row 21-24.
Pic7

8. Click OK and close and save the report

9. Go back to the RTC and run the Transfer Order report:
Pic8

There you have it. Seems like an awful lot of steps for something so simple… But this is supposed to make our life easier so we’ll walk along and wait for the benefits to come.

How to Create Drilldown page to a custom table in RTC – NAV2009 SP1

This is so someone does not pull their hair out like I just did. I cannot find anywhere in the documentation where this is explained so here it is:

1. Create your custom table
2. Create the drilldown page with SourceTable to your custom table
3. Save the page and REMEMBER THE ID
4. Go to the table property on the table you created in step 1
5. TYPE IN the Page ID in the DrillDownFormID property in step 4
6. Save and test your work.

In the table designer, there’s no place to specify the Drilldown Page. So you will need to use the DrillDownFormID property on the table even though there’s no forms created. 

<Posted edited, thanks to a3arn for confirm that you do not need to create a form>

If you look through the standard objects, you’ll notice that the drilldown FORMS have the same ID as the drilldown PAGES. Tricky….

How to Calculate the Current Fiscal Year

In Navision, there’s no function that will give you the fiscal year according to what you’ve setup on the Accounting Period table. Here’s a code that will get the current fiscal year based on the accounting period:

AccountingPeriod is a record variable  to table 50
Date1 and Date2 are date variables

AccountingPeriod.RESET;
AccountingPeriod.SETRANGE(“New Fiscal Year”,TRUE);
AccountingPeriod.”Starting Date” := WORKDATE;
AccountingPeriod.FIND(‘=<‘);
Date1 := AccountingPeriod.”Starting Date”;
IF AccountingPeriod.NEXT = 0 THEN
  Date2 := 12319999D
ELSE
  Date2 := AccountingPeriod.”Starting Date” – 1;