Pages

Friday, December 14, 2007

Print report to Excel

I have a client who asked me if it was possible to print a report from AX using Excel as the output media. My first thought was, “Eeeh – no”. But this was something they could do in their old Baan system, so I was really provoked to find a solution.

Actually it turns out that AX has a framework allowing you to integrate your own media as the target for an AX report. This is covered by mainly the ReportOutputUser class hierarchy.

But for some ¤/#&%” reason you can’t really hook this up to the print job settings and get the report engine to use your classes. I hope that will be fixed for 5.0.

In the mean time you’ll have to pull some tricks. In regards to my solution let me just give you this hint; the user should not attempt to make a PDF file with XLS extension of the filename.

Apart from the tricks I had to pull it works really well.

Contact thy:data if you are interested in learning more about the solution.

Record Level Edit Security

I’ve just delivered a solution to a client allowing them to control edit permissions in forms for tables on a record by record base.

The solution is heavily inspired by the existing record level security, hence the title of this post.

The feature is almost totally generic, as it has a hook into the document cursor method on SysSetupFormRun. But to be totally bulletproof (well as bulletproof as things get in the client UI) you must include a single statement in validateWrite and validateDelete on the tables you want covered.

To minimize the negative impact on performance, I interpret the query of the table setup to be covered by this, and if it is a simple query I don’t need to actually run the query to figure out the permissions. If I do need to run the query, I have some code adding everything I need to cover the unique index of the table.

And of course the permissions for each record is cached while the form is open.

Leave a comment if you want more information.