Authorization for VAP2 in conflict with VD02 for F_KNA1_GRP

[suzy_bijnens]

Hi experts,

Our sales people need create, change and display access for contact persons (VAP1-2-3) of all customer account groups (F_KNA1_GRP). Meanwhile they also need to be able to create, change and display prospects (account group 0005). For changing prospects, you need access to S_TCODE VD02, but the users should not have access to other customer account groups (eg sold-to or ship-to parties) while using VD02. Can this be done?

Regards,

Suzy

[sdipanjan]

Hi Suzy,

First of all, Create and Change should not be assigned to same employee. Also, change option should be restricted and should not be given for all account group to an employee.

Now coming to your point, this can be done. For easy administration and clear authorization monitoring, you need to divide this into two different roles.

1 role should contain VAP1, VAP3 and the value to field KTOKD (Account Group) can be given as *.

Next role should contain VD01,VD03 and restrict the KTOKD field as 0005.

Put these two roles in the a Composite role which you can assign to the user.

Other set of roles can be created in the same fashion: 1 for VAP2,VAP3 (optional) and 1 for VD02, VD03 (optional).

Regards,

Dipanjan

[Former Member]

> Put these two roles in the a Composite role which you can assign to the user.

You dont need composite roles to achieve that. Combining two "tasks" in single roles into a composite "job" is suboptimal because the "singles" (I prefer the term "real" roles...) will bring in all other access as well...

You end up shooting yourself in the foot because it is not scalable...

If there is a navigation option to the second task, your next best option is to maintain SE97 for the tcode "couples".

Trick is to find the most suitable tcode (if not the original one) which will allow you to do this.

Some tcodes will allow you to access them, but not use them.

But I think the answer to this is using account groups and a carefull choice of transactions which the user can enter with. If the transaction does not check granular authority (such as some "Enjoy" transactions are designed to do) then this requirement cannot be fullfulled by it.

Sometimes you need to forefeight usability... (might also include using older transactions or creating your own for the standard scenario without the tcode context using BAPI's).

See transaction BAPI.

Cheers,

Julius

Edited by: Julius Bussche on May 9, 2009 10:48 PM

[suzy_bijnens]

Hi Dipanjan,

Thank you so much for your advice. I've tested and created a role with change authorisation for account group 0005.

F_KNA1_APP, ACTVT=02, APPKZ=V

F_KNA1_GEN: ACTVT=02,

F_KNA1_GRP: ACTVT=02, KTOKD=0005 (prospects)

This role was assigned to a test user with no other authorisation roles.

Changing customers (trc VD02) of account group 0005 was possible with that user and changing customers of other account groups was not possible.

I created a second role with VAP2 as S_TCODE

F_KNA1_GRP: ACTVT 02, KTOKD=*

After that I put both roles into 1 composite role and assigned that to the test user again. Using transaction VD02 now ends up in being able to change customers of all account groups.

What am I doing wrong?

Rgds,

Suzy

[suzy_bijnens]

Hi Julius,

Thank you for your advice. Actually yes, there is a navigation option from VD02 to VAP1-2-3. I'm not familiar with SE97, but if my understanding is correct, I cannot use SE97 in this case because the user needs to be able to access the customer first in order to change contact persons.

If the user only has change (or display) access for customer account group 0005, it is impossible to access the contact persons tab for customers of other account groups.

I suppose the navigation start transaction needs to have a wider authorisation range than the transaction you navigate to to be able to use SE97.

Is that correct?

Rgds,

Suzy

[Former Member]

> I created a second role with VAP2 as S_TCODE

> F_KNA1_GRP: ACTVT 02, KTOKD=*

The calling transaction takes care of what can be navigated in the called transaction's context, if it cannot be accessed directly.

What you could also try is a combination of F_KNA1_AEN (optional authorization to change fields of the groups, as a protective mechanism), then disable VD02 for the VAP2 in SE97 and disable F_KNA1_AEN in SU24 for VAP2.

Might work... (just a brain-storm...

Cheers,

Julius

[suzy_bijnens]

Hi Julius,

I'v tried your suggestions, but unfortunately I could not make them work. However I was inspired by this. In SU24, for trc VAP2, I removed the check for F_KNA1_GRP and this solved my problem.

I really learned a lot today!

Thanks,

Suzy

[Former Member]

Yeps, that sounds like an even simpler way of achieving what I was attempting to do..

Remember that deactivating an authority-check means that you no longer can use that object at all for that transaction context. This means that all users have full authority for F_KNA1_GRP in VAP2, so you need the other objects it checks to still protect the correct use if the transaction.

Cheers,

JUlius