Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

Field values for Authorization object assignment

Dear Experts,

I am trying to understand how SAP behaves when there are conflicting field values are provided when accessing a T.Code.

For instance, i am trying to evaluate users having access to T.Code VA01 (Create Sales order).

As i understand, BOTH the below authorization objects are required to access VA01.

a) V_VBAK_AAT - Sales Document: Authorization for Sales Document Types

b) V_VBAK_VKO - Sales Document: Authorization for Sales Areas

I have a scenario, where the first aurhorization object (V_VBAK_AAT) has been given ACTVT value of 01 (Create), but the second authorization object V_VBAK_VKO has been given ACTVT value of 03 (Display)

In the above scenario, would be user be able to create sales order through VA01 ? 

My understanding is, since the user has "Create" access to Sales document type, but only "Display" access to sales area, the user would NOT be able to create a sales order.

Kindly advise.

Thanks !

Uday

Tags:
Former Member
Former Member replied

You should get yourself a sandbox then to make tests in, as this is just a matter of testing, or reading  the code. Additionally you should verify the answers you get in the internet...  :-)

Sometimes the combination of multiple objects is needed, sometimes 1 stronger object can override a weaker one and in most cases config (SU24) can control the behaviour.

Where you are correct in this case is that the role has a conflict as both are required to complete the document. This means that another (probably bolt-on-role) is needed for the sales area authorization. This means you are dealing with a very unfortunate design of the roles (enabler concept) and will have to evaluate the access at a user level and not a role level as the role appears to be disfunctional.

The concept in such a case is not disfunctional, it is just rubbish. Often the cause of it is that roles must be free of being functionally capable of doing anything critical (or anything at all) so that the role concept "looks" fine, but trying to put it together at user assignment level is a nightmare.

You should not break the role concept and make it unmanageable just so that the roles look "nice" from an SOD analysis perspective, when in actual fact it is a mess and the buck is just being passed on to the assignments.

That is what you should right into your audit report as a bigger risk than the ability to create customer orders combined with anything else...

Cheers,

Julius

0 View this answer in context

Helpful Answer

by
Not what you were looking for? View more on this topic or Ask a question