Security how-to: Remove dimension values from Voucher transactions

A recent question on the Dynamics Community triggered me to think about use cases of how to hide ledger accounts and dimension values. When I understand the question correctly, a part was to hide the financial dimension values and show only the main accounts In my reply, I elaborated on the Voucher transactions page where possibly some main accounts should be hidden, but also part of the value of the Ledger account field should be hidden. In this post, I will elaborate on how to make that possible.

Dynamics Community

Almost daily, I spent some spare time on the Dynamics Community trying to help with answering questions. By following and reading the questions, I also learn myself and sometimes get inspiration to write a blog post.

The post that inspired me can be found here: Security on main account + dimension set

When thinking of all places where certain main accounts should be hidden or some dimension visibility on forms and reporting should be limited, then there is quite some work to do to achieve it. Hiding particular main accounts is a typical scenario for eXtensible Data Security (XDS). If there is a security policy developed and enabled for the main accounts, then related tables like voucher transactions and ledger balances can be set as additional constrained tables.

For hiding the financial dimension details there are different variations. On the trial balance you might need to constrain the number of dimension sets to be chosen for the report. This can also be achieved with XDS. Then we also need to take care of the Voucher transactions page as some dimension values are visible in the field Ledger dimension. This is a string field having the Main account and dimension values stored in one field. Security can’t alter the contents of a field.

Hide dimension values on voucher transactions

In this post, I will not focus on constraining access to individual maini accounts. This post will give a walkthrouugh how to hide all dimension values on the Voucher transactions page. Let’s start with a screenshot of the standard view.

In case there is a requirement to not show the dimension values, there is a workaround that touches a bit of security, but it requires a personalization that can be published as organization view. The table containing the accounting entries has another field that stores the main account only. You will find the steps to include the main account in the grid and hide the ledger account below.

1. Right-click on the grid. A popup menu will appear. Choose the option Add fields. Loading the personalization option to include columns takes usually some more seconds. The next dialog will appear.
   

   

2. Mark the Main account record and click the Update button. The field is now the last on the grid, but you can move this to the left.
   Then right click the column Ledger account. In the pop-up menu, choose to hide this field. Now you replaced the Ledger account field with the Main account field which is not displaying the dimensions.
   

   

3. You can now save the view where you can choose to pin this view as default. Click on Standard view*. On the drop down dialog choose Save as…
   On the slider dialog (see screenhot below), you can provide: A Name for the view, Specify if it should become the default view, for which Legal entities the view will be effective. After specifying these details, click on Save.
   

   

4. At this moment it is a personal view. You can go to the Personalization page to publish your view as organization wide view. Go to System administration > Setup > Personalization.
   On this page, go to the tab Personal view and find the view you created for the Voucher transactions form. Then click on Publish which will open a dialog.
   You can review the name and pinning the view as default. Then you can specify one or more security roles. Users being part of these roles will get the view assigned. Then click Publish.
   
   

   

The view is now published as Organizational view.

When logging in as an Accountant, the person will get the new default view. However, by default, the user is still able to switch to the Standard view or use the option Insert columns to include the Ledger account field which is not desired.

Deny permissions on Ledger account

Using personalization is not the same as security. To completely hide this field, you will need to set deny permissions for this field. You can read more about table and field permissions here: Securing a menu item is not enough – table permissions

In case you have a custom role, you can add the deny permissions on that role. In the example below, I will create a new role as I don’t want to change the standard Accountant security role.

The next steps can be used to restrict access to the Ledger account field.

1. On the Security configuration page, you can select an existing role or create a new role.
2. Select Tables in the second grid.
3. Click Add refererence.
4. In the dialog, add the table GeneralJournalAccountEntry and click OK. The permissions can be set to Unset.
5. In the third column, select the table GeneralJournalAccountEntry.
6. Click Add refererence.
7. In the dialog, select the field LedgerAccount and set Deny permissions for both Read and Update. Then click OK.
8. Review the unpublished objects and publish the changes.

When the user will now try to add a column, the Ledger account field is not available for selection anymore. When switching to the Standard view, this field is not visible anymore.

There is more…

The table GeneralJournalAccountEntry also contains a field LedgerDimension. This is a reference field to dimension set value combinations having the same contents as the ledger account field. As I didn’t see the field in the list of avialable fields to insert as a column, I did not add deny permissions on this field.

When you publish a view to the organization, existing users will get the view inherited. In case of new users or users that will get the role assigned later, they will also automatically get the new view.

After adding the security deny permissions, a user can still change to the standard view, but in that case, the Ledger account field is not visible as it was denied via security.

There are options to restrict personalizations for users and specific pages. Restricting personalization for a single form requires a setup per user. For this reason, I think the above described approach will be the most efficient one for this type of requirements.

You can read more tips about how to achieve particular security use cases in my other Security how to blogs.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!

I