Security how-to: A purchasing agent is not allowed to maintain vendor bank details
This post is a new blog in the series about “Security how-to“. In this particular post, the options to segregate duties for maintaining vendor master data and the bank accounts will be explained.
Scenario
In many companies, there is a need to segregate permissions for creating the vendor and the financial details related to a vendor. In the cases where all data can be entered by e.g. a purchasing agent, a company needs to ensure that there is no single person who can perform the full flow from creating vendors, entering invoices and creating the payment journals. This requirement can be achieved in various ways. In this post, I will focus on several options for securing data entry on vendor bank accounts.
The first question, I would like to answer is the next one: “Do we really have to care about securing the vendor bank accounts?” Well, yes and no… it depends. As mentioned, you should prevent having a single person being able to maintain vendor details, bank accounts, create and post invoices. Having a purchasing agent providing the bank details on the vendor master data is not a bad choice when the financial accounts payable department will take care of posting invoices and the actual payments. However, it is also a valid choice to have the purchasing agent create and maintain vendors, but prevent him from maintaining bank accounts. I will elaborate on separating the vendor master details and vendor bank accounts. This is not particularly related to the purchasing agent, but could also be applied to other roles.
Common changes
When you have a closer look at the standard security, you will notice that there is no separate duty for maintaining vendor master details and vendor bank accounts. There are separate privileges for the vendor bank accounts and vendor master. They both are linked to the same duty. The below-mentioned option is valid for both Microsoft Dynamics 365 and AX 2012.

As you can see on the screenshot above, there are multiple roles having included the permissions for the duty Maintain vendor master. You should not change this duty by removing the vendor bank permissions, unless you want to restrict all these roles from editing the vendor bank details.
The correct approach would be duplicating the duty and remove the privilege Maintain vendor bank accounts. When you want to allow read access, you can include the privilege View vendor bank accounts.

Now, you can replace the original duty with the newly created one on the Purchasing agent role or any other role of your preference. Note that I usually prefer to create new security roles as part of an implementation and don’t change those delivered out of the box.
Electronic signature
As alternative, you can setup Electronic signatures. Using this method, a user must provide an additional signature for changing data. It is also an option that the signature will be provided by a supervisor. The result is that all changes are trackable using database logging including details who signed for the change. Using this option, there is a trace who did provide the vendor bank account details. This could be a replacement for the security restriction as mentioned above, but it could also be an additional security check to prevent possible fraud.

Microsoft Dynamics 365
Microsoft Dynamics 365 Finance offers some additional features compared to Dynamics AX 2012. These are:
- Vendor workflow
- Security ‘Deny’ option
Starting with the Vendor workflow, this is not useful to secure vendor bank accounts for the next simple reason. You can only set up approvals for changes in certain fields on the vendor table. It is not an option to track changes on the vendor bank accounts and submit them for approval. So, if you have enabled the vendor workflow, it will not recognize when someone changes the actual bank account number.
The new ‘Deny’ option in the security is a welcome alternative for the duty changes as described above. When you use the deny option on a menu item, it will override all grant permissions across all assigned security roles and have a restriction on the CRUD permissions.

You can create a privilege where only the menu item Vendor bank accounts is used and set deny for ‘Update’, ‘Create’ and ‘Delete’. I would recommend having the ‘Read’ access to unset as you can then give access to read operations via other duties or privileges. The deny privilege can then be assigned to a duty or on a role directly.
There is more…
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!
It this the only option to ensure you the user cannot edit the current bank details?
Hi Hetal,
There are various options provided in this post. What exactly are you referring to when you write “Is this the only option”?