Please see the Disclaimer with Part 1: this is an advanced tutorial based upon real-life work and not just demo-ware. I’ve walked into many assignments where beginning, mid-level, and even advanced AX report developers had trouble handling the issue we are about to fix. That being said, the most rewarding and beneficial reports for our companies are often the most complex to transform. Wait to you see some of what we can do for clients in Part 2C! Stay with me because the reward is well worth it.

Note, Part 1 can be found here:

http://instructorbrandon.com/dynamics-ax-reporting-2-advanced-tutorial-getting-that-purchase-order-to-look-the-way-you-want-it-to-look/

So, to recap.. we spent the first part of the series just writing X++. You learned this strange concept called an RDP report, which is really just a report that gets its data from a temp table populated with X++. The x++ class responsible for this is known as surprise… RDP data class! In this section, we update the data.

Okay, so we now open up Visual Studio and we are all ready to see those changes.

Now, according to the Microsoft documentation to see the changes, you simply need to click on these options (not all 3 but just do it to be safe):

TOOLS à CACHES à Refresh dictionary, Refresh data, Refresh Elements. Click on all 3 of them.

From there, open up Visual Studio and bring over the PurchPurchOrder report in a new Dynamics AX Report model Project.

Time for the Undocumented Errors

Following the documentation, you open up the report. Then, you expand the DataSets node. Now, what you want here is for the columns that you added to the temptable in the previous blog post to show up in PurchPurchOrderLine dataset under fields.

Following the documentation, navigate to the PurchPurchOrderLine dataset and click refresh.

SHOOT!!!!

Sigh.. It is never easy. This is a common error that you will see in reports on reports with header-line datasets. You have this strange Parameters is already defined error in Dynamics AX.

So, let’s see how to fix this variant of error, so that we can actually see and use our new columns in our report. Make sure that you do the fix in this EXACT sequence:

Step 1: Rename the bad parameter in Question

Make sure that you choose the parameter node for all the Datasets, not just the dataset that has the parameter!

And now make sure that you rename the parameter.

Now, you have to go to the dataset table that is using the parameter and make sure that it points towards the new parameter.

It should look like this:

Now, go back to the PurchOrderLine dataset and hit “refresh” again. Yaaaay, it works and your new fields show up in the dataset!!!

One last Gotcha to take care of and you are good to go:

You need to go back to the PurchPurchOrderDS dataset and change the IsConfirmationRequestJournal parameter so that it points towards the real isPurchConfirmationRequestJournal instead of isPurchConfirmationRequestJournal_1.

And make sure that you change where it points, so that it looks like this:

Now, last but not least.. You need to delete the bad parameter on the report. Simply, highlight it and click delete.

Finally, build your project and check it into the AOT.

And congrats, you are finally finished with most complicated of the hidden errors. There are a few more that I’ve learned to deal with but only a couple as nasty as this one, also lacking any documentation or hotfixes anywhere, and also on mission critical reports. But that is for another post. Next in Part 2C, the fun begins and we transform an ugly report into a very good-looking one.