Hi Everyone,

Recently I was asked by a customer to look into a security
issue around one of their reports in Dynamics AX 2012 R2.  Users were reporting that some people within
the customer organization had access to the accrued purchases report and some
did not.

After reviewing the security we found that the user that had
access to the report was looking at a US legal entity localization in a TEST
environment while the other user who could NOT
view the report was looking at their UK localization legal entity in their PROD
environment.  Once we were comparing
apples to apples we found that the accrued purchases report was not available
in any of their UK localizations. 

After further research this was found to be “by-design” in
Dynamics AX 2012 R2.  As stated in a
TechNet article, the link is below, the accrued purchases report is only
available in localizations for the United States and Canada. 

http://technet.microsoft.com/en-us/library/aa598272.aspx

 

This did not change the fact that the customer still needed
a report to reconcile their UK received not invoiced account at month and
year-end.

After speaking with some collogues on the possible risk of
deploying a report not made for a particular localization I decided to attempt
this in a TEST environment. 

The only risk that you run when deploying a report this way
is that the report may not work.  A
reports could require data from fields that may not exist in a different
localization causing the report query to fail.

In short, the deployment and testing of the accrued
purchases report in my TEST environment was successful for multiple users in
the UK legal entity!  Also, attached to
this blog entry is a generic document for how to deploy the accrued purchases
report to a UK localization.

It should also be noted that this is not a process that is
unique to this report.  This process
could be used to deploy any report to any legal entity where it does not
originally exist, however, this does not mean the report will work in that
localization.  This should be tested
before a deployment to PROD is attempted with any report.

As always, please test, test, test. 
Although this solution worked for me it should still be thoroughly vetted in your TEST
environments before the deployment is attempted in any production (PROD) environment.

When I was researching this issue I found very little
information on this topic so I hope this helps if this is ever an issue for any
of you!