The user interface for reporting in Dynamics 365 for Operations (AX7) has changed dramatically, one of the main features being the lovely parameter screen and the standard report header, as shown below:
It did however take me a while to figure out where the parameter/report title derives from and how to change it.
The parameter/report title is based on the Menu Item label which opens the report. This makes perfect sense, although whenever I changed it, it didn’t seem to change when I ran the report. It turns out, after looking into the code, that the report title/caption is stored in the usage data, and this must be cleared for the changes to take effect.
This also means when a change is made to the label on the menu item, all users will have to clear the usage data for this menu item. Not sure how this will work in practice but I guess time will tell.
A few years back, I wrote a similar blog post on developing reports in AX2012. Well, here we are now looking at reports in Dynamics 365 for Operations (AX7), and again I thought I would share my experiences.
I started by trying to replicate a couple of simple reports. I have listed below the things that I think are the good points and the areas which need improvement.
- As all AX development is now done within a fully integrated Visual Studio environment, it was simple to use. I didn’t have to mess around with the configuration, getting Visual Studio to connect to Dynamics AX in the correct layer and model. It was all ready to go.
- Debugging is now completely in Visual Studio which makes development much easier.
- There seemed to be a lot of caching issues in SSRS for Dynamics AX 2012 but these seem to have been eliminated in AX7, speeding up development time and minimising on head scratching time.
- The reports do not necessarily need a title anymore as this is automatically generated from the menu item name.
Areas for Improvement
- There is now no facility to view your report before deploying. This slows down development as you have to deploy the reports and then run the application to see the layout of your report with data.
- If the configuration key is turned off for a particular field that is used in a report, you get a rather vague error message when the report is run along the lines of “please contact your administrator.” It took me a quite bit of debugging to figure out why the report was not working. This could get frustrating and confusing for the end user as the error gives no direct indication what the problem is. For our customers, we may consider extending the class which throws the error to give the user a more meaningful and helpful error message.
- You can drag and drop the report data set onto the design node to create an auto design but this is not supported for a matrix table. This feature has been removed from Dynamics 365 for Operations but is due to return in a future release. We will have to manually create a matrix design until then.
- Elements have to be opened in the designer to allow elements to be dropped into the element to be modified. This slows down development a little but at least it stops modification of object by accidental drag and drops.
- You can no longer deploy just one report (unless you create a separate project for it). When you deploy reports, it deploys all reports for the project you are working in. It feels that this increases the build time slightly and is unnecessary.
Overall, I have really enjoyed the the new version of SSRS in AX7. There seem to be fewer problems and an easier development interface. The areas for improvement may be addressed in future versions of the software. As per every new software release, I’m sure the developer will adjust to the new “features” in time. It is definitely heading in the right direction though with fewer “quirky” features than earlier versions.
I have recently been working on updating the Pick List in Dynamics AX 2012 and thought I would share my experiences.
In Dynamics AX 2012, all reports are now SSRS reports, including things such as pick list, despatch note, sales confirmation etc.
I have developed many reports in previous versions of SSRS but this was the first one using SSRS 2012 integrating with Dynamics AX 2012.
The time needed to develop reports in AX 2012 has definitely increased and here are some of the reasons that I think contribute to this:
- In AX, a specific table is usually created for a report to be used as the data source (although it doesn’t have to). This means if you need a new field, you have to add it to the table or write a method on the table. This requires switching between AX and Visual Studio, which is not ideal.
- When a new field is added in the AOT, the field list in Visual Studio does not refresh. The only way have found to make it appear is to close the report and re-open it.
- There have been a few instances where the changes I have made to a report seem to be ‘Cached’ within AX, even if I redeploy. I then had to clear the caches in AX. If this did not work, I had to delete the report from the server and re-deploy.
- The reports in visual studio can take a while to compile, which wouldn’t necessarily happen in AX.
- The report layouts differ on screen to when they are printed out. Printed out reports seem to maintain white space when the control is hidden, although this does not happen on screen. I spent a lot of time investigating this issue and is still not completely resolved although I have found a suitable alternative solution.
- As far as I am aware, there is no way to access label definitions within visual studio, which makes it more difficult to develop. You have to go to AX to check definitions and get the labels you require.
Overall, the more experience you have of working with reports in AX2012, the easier it will be, although my existing knowledge of SSRS helped immensely. It has quirks which you learn to work around, but there again, don’t all things nowadays