Van Vugt's dynamiXs

For days this issue lingered through my mind as I felt I wanted to write something about report transformation. But what exactly? And in what format? So finally today I decided to just sit down and write.

Love RTC

As I wrote on one of my previous blog posts I had to learn to love RTC. Both from a user and developer perspective. During a bigger part of the development cycle of NAV2009 I had been closely involved with the Form Transformation effort. I had to use it and test it and meanwhile saw it growing and improving. Yes, the transformation process matured and became quite efficient and effective. Sure, I know, some things still remain hard to transform, but these are peanuts compared to where we started from. Probably the whole process of seeing this tool evolve also contributed to my growing love ... and of course the great design decision to have the forms as the base to create pages from. And easily recreate pages from. Any changes and additions to the Classic UI can be automatically ported (through transformation) to the New UI. No need to duplicate manually. You might not know, but the whole NAV build process is based on this. Pages are not stored in MS code repository, only forms and when building a new version of the application pages are created by firing the transformation process.

So what about report transformation?

Yes, what about it? Well, where to start?

By mentioning the huge effort we did put in getting all w1 and local reports transformed?
To me it seemed tremendous compared to form transformation. Not only because of the huge number of local reports, but also the amount of manual work.

By mentioning that some essential standard report functionality could not be achieved on RTC?
Like transfooters and transheaders because of which we could not get some legal compulsory reports work right.

By mentioning the fact that we discovered that a lot of the original processing we had done for NAV2009 had to be redone for NAV2009 SP1?
Changes to the CSIDE part of a report could in general not be integrated straight forward into the RDL part of the report. Merging w1 changes into existing localized reports was a mess. Ouch ...

Or should I have started mentioning the fact that if you do not transform a report you still can run it from RTC?
Yes, indeed, not long before we had to release NAV2009 December 2008 this feature was implemented so that when firing a non transformed report it would launch Classic Client in the background and show the report in it's own window.

OK!

So this leads me back to my question: Should I transform reports on NAV2009?

No ...

... if your Classic reports are working fine and there is no need for change. It will save you a lot of effort in getting it working right.

Yes ...

... for various reasons:

• take advantage of extra features like saving your report to .pdf or Excel easily
• use all kind of extras like having hyperlinks in you report or graphics
• building up expertise on the report transformation and all new possibilities in the new layout
• somewhere in the future CSIDE will be abandoned and get prepared for that

Do you have more thoughts on this?

Now, after my first blog post on reporting bugs, you're in the right mood to start selling your issues. But you might be in the mist on what I mean with to-the-point repro scenario. If so read on; if not ... also read on, don't be afraid to learn.

To-the-point means to me that the repro scenario will lead the engineer straight forward to the bug you are reporting. No need for her to spend too much time to get it reproduced. Just remember: the faster reproduced, the faster - and often better - it get fixed!

So how to lead the engineer in a straight forward manner to the result? By describing:

1. Setup
   the setup you were working on when you encountered the bug
2. Preparations
   the preparatory actions needed before the actual repro actions can be performed
3. Actions
   main action to be performed to show the bug
4. Actual Result
   the actual behavior of the system, i.e. the result you are reporting as the bug
5. Expected Result
   the behavior you had expected

But … it’s not only the wording that does the trick. It’s also how you present them. The better the layout the easier to read and execute upon.

So how would that look like in a real world case? I'll show you one example based on an incident reported to MS (incident 9594805).

Problem description

In NAV 2009 SP1 report Sales Quote (REP204) fails when I execute it from the sales quote window (FOR41) with "Sell-to Customer No." = '' AND "Sell-to Contact No." <> ''
[so "Sell-to Customer No." is empty while "Sell-to Contact No." is populated]
The thing is that when I create a new contact (of type Company) I can create a sales quote for that new contact, but I cannot print it.

The error does not exist on NAV50SP1.

Setup

NAV2009 SP1 RTC (w1, but also on other country versions like NL and DE)

Preparations

Using CRONUS demo database no preparatory actions needed.

Repro Scenario

1. Open Contact: CRONUS International Ltd./Departments/Sales & Marketing/Sales/Contacts
2. Select 'New' to create a new contact
3. Enter following data:

No. = TEST
Type = Company
Name = Luc van Vugt
Address = My Street 41
Post Code = 1234 MS
City = MyCity

4. Country/Region Code = NL
5. Select 'Sales Quotes' to open Sales Quotes list place
6. Select 'New' to create a new sales quote

7. Click 'ENTER' to let system insert a number ('No.') for the quote

Intermediate Result

Following fields will be populated by the system:

Sell-to Contact No. = TEST
Sell-to Customer Name = Luc van Vugt
Sell-to Address = MyStreet 41
Sell-to Post Code = 1234 MS
Sell-to City = MyCity
Order Date = 27-1-2011
Document Date = 27-1-2011

Steps (continued)

8. Enter: Sell-to Customer Template Code = GB-SMALL
9. Enter (on Lines)

Type = Item
No. = 1000
Quantity = 2

10. Select 'Print' and Request Page of report Sales - Quote appears
11. Click 'Preview'

Actual Result

Error message: Customer No. '' does not exist.

Expected Result

Report will run and show preview of sales quote for contact TEST with right details (as entered on quote as above).

You're sitting in front of your computer doing one of your daily tasks in, let's say NAV. But @*^%$#@$$!!!!, the darn system does not do what you expect it to. Just one of these days? Might be, but it seems to you the system is not just doing something different than you expected, it clearly errs. A fix is needed to enable you to finish your task. Pffff ... no time; a busy day, but no other way than to contact the help desk at your Dynamics NAV partner and tell them a fix is need right away! Unfortunately as always you're asked to register the bug by means of a comprehensive bug report.

"What the .... (beep), I am sitting here in front of NAV in it says .... It's clear it's a bug and we need a fix ... now!"

Don't we all find ourselves in a similar kind of situation once in a while? We're under pressure because of what we are doing and are blocked on the way doing it. And then we are urged to provide a bug report. As no other way seems possible to get a fix, you do what is asked and create the report (by whatever means, in whatever system your partner is using). But the water is still boiling as you think: "@*^%$#@$$!!!! "; "Not your fault the system errs"; "Now I am punished for something I have no part in"; ... Not the best mood for writing a comprehensive bug report. You might ask yourself:

Is this the way I am going to get it fixed asap?

Most probably we agree and will answer this question with: no.

Sell the issue

If you really want to get your issue solved: sell it! Not by just saying it's an issue and it is a high severity one, but indeed by providing:

• a comprehensive report with
• a sticky title and
• to-the-point repro scenario and if possible
• your thoughts on the solution

Do your utmost best to get the developer in the good position to fix your bug. That he loves to solve your issue(s).

A big thanx ...

... to Tracey Montieth at MS for having learned me to change my attitude toward bug reporting.

It must have been somewhere in 2006 that we started testing the Role Tailored Client (RTC) and I must confess it was very hard to love RTC. But they said it was going to be a great product and it was my job at MS to test. So I simply needed a way to learn to love it. "Always look at the bright side of life, pal", I said to myself. "Look at the RTC features not available on the Classic Client." Here is one.

At that time our team was mainly relying on manual testing based on written test cases. An eternally recurring part of writing test cases was defining the path where the test executer needed to open or activate a NAV object like a page, a report, etc. Something like this:

Open the Chart of Accounts from Departments > Financial Management > General Ledger > Chart of Accounts (under Lists)

A tedious and slightly boring task so anything that would help me do this more efficient would make my life even brighter.

Having read my two preceding chapters and gotten this far in this chapter you probably will exclaim: "C&P!" Yes, indeed. The Explorer address bar was one of the things that helped me start loving the RTC. Having activated the Chart of Accounts like instructed above I can simply copy the path and paste it to my test case. In this way the above instruction would become: 

Open the Chart of Accounts from CRONUS International Ltd./Departments/Financial Management/General Ledger

And not only this made my life easier writing the test case, it also made it easier for the executer. Simply copying the path from the test instruction and paste it into the RTC address bar would directly bring her to the right page. HOORAY! I love RTC!

And that brings me to chapter 2. Maybe less exciting, but for sure even more fun than the preceding chapter if you didn't know about it yet. Saves you a lot of time.

One of the things I have always liked about NAV is the open source character of it. OK, you need the right license, but as soon as you have it you can look at any part of the code. And one of the things I probably did stress most when teaching Solution Developer classes was: if possible reuse existing code. Your customer does not want a state of the art unique piece of code, your customer wants a reliable solution! So C&P. C&P code snippets. C&P functions; C&P whole objects.

C&P functions? Yes, here we go.

Let's say you would like to implement the same AssistEdit functionality as can be found on the Customer Card (21): the button in the No. field.
Digging a bit into the code you did find that a AssistEdit function has been defined on the Customer table (18). Now you would like to reuse that code. You know how to create functions in any object; you know how to provide it with the right parameters, return value settings and local variables. So you could do that and C&P the code lines from the AssistEdit function on the Customer table to your object. Maybe you have done that dozens of times before and found every now and then that you had overlooked some local variable or parameter. Indeed we're no machines and our actions are error prone. So let C&P be your friend!

1. On table 18 (Customer) in design mode open the C/AL Globals window and select the Functions tab:
   
   
2. Select the AssistEdit line (record!)
3. Ctrl+C (Copy)
4. Go to your object that you are designing
5. Open the  C/AL Globals window
6. Create an new line and ...
7. ... Ctrl+V (Paste)

Your object is now the happy owner of an AssistEdit function, including parameters, return value settings and local variables. Congratulations!

Note

As your context might be a bit different from the one on the Customer you probably need to do some updating on the code.