Permission on purchase or sales prices

(0) Share

Report

Posted on by Community Member

Dear community,

I have an issue when setting up a user role in AX2012 for a purchasing user. Have you found out how to restrict access to purchase prices (and not create sales prices)?

In general, prices can be entered in a journal (e.g. in Procurement and sourcing/Common/Purchase orders/All purchase orders/tab general/button trade agreement/view purchase prices, button edit select lines OR Procurement and sourcing/Journals/Price discount agreement journals). But when creating a new line within a journal, the "price (sales)" can be selected. So a purchase guy will be able to change sales prices. That is not allowed in our company. How can this be prevented?

I checked a couple of MS standard roles and found "purchasing manager". But also this role can change purchase AND sales prices.

Any help is appreciated.

Thanks and kind regards,

Katja Schebler

*This post is locked for comments

I have the same question (0)

All responses (5)

Answers (0)

Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

This is typically a task which requires an AX developer familiar with the Security framework and needs to do customization, if the out-of-the-box roles and duties do not cover your requirements.

You would either exclude those specific access (or lower access to Read only) from the roles where creating/editing/deleting is not allowed, or you would create new roles to use that instead of the standard ones for those users with the required access restrictions on the privileges and tables.

Unfortunately AX works in a way that the strongest access wins, so you cannot just specifically block out that functionality.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Crispin,

thank you for your answer! I followed the link. But will that code have an affect for all users or only for the purchase users?

How can I have that code only for the users of my purchase role?

Kind regards

Katja

Was this reply helpful? Yes No
Community Member on at

Like (1)

Report

Hello Vilmos,

thank you for your answer.

I have created my own user roles (from scratch). This user role should have full access to the purchase prices. So I included the menu item (and permissions to use it). But I was not able to prevent them to create journal lines with relation "Price (sales)" and only provide them access to "Price (purch.)". Then I checked the standard Microsoft roles how they solved this issue. But the standard roles also have this issue. Do you know how I can allow them to create purchase prices but no sales prices?

Kind regards,

Katja

Was this reply helpful? Yes No
Suggested answer

guk1964 10,888 on at

Like (0)

Report

I am not clear whether you are trying to prevent access to the trade agreement orto the order line

If purchasing are not given access to the sales order screen, then how will they change the SO prices?

If you are concerned about the trade agreement price maintenance then use XDS.

Why would purchase want to change a sales price anyway?

You can perhaps set an alert for whenever a default price is changed, or run a daily exception report so that any such transactions are identified and remedied quickly.

In the extreme you could also require workflow approval, or digital signature to change a price, but the simplest seems to be to restrict Purchasing to view only rights on sales order screen.

With retail call centre enabled you can also set a margin alert.

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

I cannot give guidance for your specific scenario regarding the prices, but the general approach is if the AX security framework is not granular enough for you to set it up as per your requirements, you could always rely on X++ coding to make it more granular.

I.e. in the init() method of the form you could put your own code to check the current user's security roles, and if they belong or do not belong to specific ones, enable/disable specific form controls, or even a form datasource entirely as per your requirements. The only pitfall of this is that if the same functionality can be reached in multiple places, you need to implement this on many forms then. Cross-references could be used to find those forms related to your price table.

I would avoid using XDS since that has a huge negative performance impact on your application. It is fine to use for more static data with lower volume, but prices are typically not like that.

Was this reply helpful? Yes No