Management Reporter – Unit Security

18 Sunday Sep 2016

Posted by Ludwig Reinhard in Management Reporter

Tags

Data access, Reporting Tree, Restriction, Unit Security

Within this post I would like to present a feature that allows you restricting the access to data included in Management Reporter financial reports. A common business scenario where this feature can be applied are situations where business unit/cost center managers shall only have access to the data of the business unit/cost center they are responsible for.
Let’s have a look at the following Income Statement report that shows the total amounts split up by business units to see how the Management Reporter unit security feature can be applied.

Assume that we want to restrict the report data access for Phyllis, the manager of business unit BU001, in a way that she has Access to the Income Statement data of her business unit only. This restriction can be accomplished by setting up a report with a reporting tree that includes the respective users in the unit security column. Because the report includes all business units next to each other in separate columns, the reporting tree elements need additionally to be linked to the respective columns. This is linkage and the unit security setup is illustrated in the next screen-print.

With this setup in place, Phyllis will see the following report, once she opens it.

Notes:
The security restriction setup does also apply to the Management Reporter drill down functionality in Dynamics AX. That is, if Phyllis wants to see the voucher transaction details that make up a specific amount shown in the report and drills down into the Dynamics AX voucher transactions, she will only see the filtered transactions for her business unit. This system behavior is illustrated in the next screen-print:

A second thing to note here is that the Management Reporter unit restriction does not control whether or not Phyllis can open and access all transaction details through the Dynamics AX client directly. In the example used Phyllis can, for example, log into the Dynamics AX client and access the complete voucher details including the amounts that were recorded for the other business units. Example:

If you have users that can circumvent the Management Reporter unit restriction this way, you have ensure that you also implement the extensible data security framework in Dynamics AX. Otherwise, the unit security feature does not make much sense. Please see the following sites 1 / 2 for additional information on the extensible data security framework.

Report modification 1
Now let’s have a look at some Management Reporter design considerations that you should be aware of when making use of the unit security feature and reporting trees in general. Let’s imagine that the Income Statement report shown previously is modified in a way that also the cost centers that make up a business unit are included in separate report columns. If you follow the same unit restriction setup shown previously also for the sub-elements of the business units …

… users won’t see all details once they open their report. In the example used Phyllis, will see the following data when opening the report:

The data for the cost centers that make up the business unit cannot immediately be identified but rather have to be opened separately by selecting one of the business units. Example:

Report modification 2
Because of the previous data illustration issue, the report is modified once again in a way that the business unit and total columns are now setup as computed columns. (Please see the yellow highlighted section in the next screen-print).

With this setup in place, Phyllis will get the following message once she opens the report.

By selecting one of the cost center elements, she will finally be able to see the data for the selected cost center but not automatically for the other ones without selecting them separately.

Report modification 3
To avoid that the Income Statement report opens with an error message for the business unit / cost center managers, the report design is further modified as follows:

The major difference to the previous setup is that cost center sub-elements that make up the business division are now intended in the reporting tree. This setup finally ensures that Phyllis is able to see all data of the business unit she is responsible for when opening the report.

If Phyllis drills down to the different sub-elements, the report will filter the selected data respectively. Example:

Summary
I hope the different examples gave you an impression what to look out for when designing Management Reporter reports that include reporting trees and make use of the unit security feature. The major take away from this post is that setting up the unit security feature in Management Reporter does not make much sense if users can circumvent those restrictions by extracting the data directly from the AX client. To avoid such scenarios you have to ensure that the extensible data security framework is applied concurrently in the AX client.

Summarize vendor payments to one line for bank reconciliation

04 Sunday Sep 2016

Posted by Ludwig Reinhard in Accounts Payable

≈ 2 Comments

Tags

summarize bank transactions, Vendor payments, voucher

Recently, I came across a requirement where payments were made from a specific bank account. As only one single bank account was used for making the payments, the expectation was that Dynamics AX creates only one single posting on the bank account. Dynamics AX did, however, create numerous bank postings – one for each journal line – as the invoices paid were recorded with different financial dimension combinations. This fact made the bank reconciliation process more difficult because the bank deduced all vendor payments made in one single amount, which had to be matched with the numerous transactions recorded on the Dynamics AX bank account.

Example
The next screenshots exemplify how the payment proposal was created and the vouchers and bank transactions resulting from posting the payment journal.

Example – creation payment proposal

Example – voucher created for the first journal line

Example – bank transactions posted

A) Change journal setup
In order to get the transactions posted on the bank account summarized, a new vendor payment journal was setup with the following (modified) settings:

Note: Previously the parameter ‘new voucher’ was set to ‘in connection with balance’ and the ‘detail’ level was previously set to ‘details’.

The result of this first change in the setup was that Dynamics AX created one single voucher for all lines included in the vendor payment journal. However, there were still a number of postings created on the company’s bank account, as the next screen-print illustrates.

B) Change bank account setup
The underlying reason why Dynamics AX did not summarize the transactions made on the bank account were the different financial dimensions used at the invoice level that got inherited to the bank account. This can be identified from the previous screen-print, which shows that the bank account transactions were posted with the financial dimension ‘cost center’ no. 022, 023 and 024.

In order to avoid this problem, default financial dimension values were setup at the bank account level. For details, please see the following screen-print.

With this setup in place, the expectation was that only one single posting on the bank account is created when posting the vendor payment journal. However, the setup changes made had no influence on the outcome, as the next screenshot proves.

Once again the financial dimension inheritance from the vendor invoice level that was overwriting the default financial dimension setup at the bank account level was the underlying reason that prevented a summary of the bank postings.

C) Change main account setup
To get the posting summary issue resolved, the main account associated to the bank account was finally setup with fixed financial dimension values, as illustrated next.

After creating another vendor payment journal, the following summarized voucher resulted, which shows only one single transaction on the bank account used.

D) Modification 1 – different payment dates
To test the stability and reliability of the setup made, another vendor payment journal was created. This time, different payment dates were used for the lines included in the journal.

The outcome of this modified payment run was that Dynamics AX created several summarized bank postings – one for each day. The next screen-print shows the journal lines and the resulting vouchers.

Note: The major problem with the vouchers generated in the example is that Dynamics AX uses the same voucher number for postings made on different dates. This outcome is likely to result in problems with the company’s auditors, as all accounting standards the author is familiar with, do not allow such kind of postings.

E) Modification 2 – different methods of payments
The next modification made to test the stability of the setup was posting a payment journal with different methods of payments. The result of this second test run was that Dynamics AX still summarized all payments made in one single bank posting. For details, please see the next screen-print.

Summary
Within this post the possible summary of payments made into one single bank posting was illustrated. Please note that what has been shown above does also apply to bridge-payment scenarios where all vendor payments are initially made against a bridging ledger account that is in a second step posted against a bank / cash account.

An important prerequisite of the posting summary illustrated is that the payment account used in the vendor payment journal is setup with fixed financial dimension combinations. Otherwise, the financial dimensions used at the invoice level get inherited to the bank / cash account and result in a large number of bank postings.

In addition, it has been shown that the summary does only work as intended, if one single payment date is used in the payment journal. If this cannot be ensured, Dynamics AX will create vouchers that might be questioned by tax and corporate auditors.