Problem in Optimising the use of K_PCA for Profit Center Restriction

[Former Member]

HI,

We are currently working on ECC EHP6. I have started working on the security part recently and therefore need help.

We have a scenario where for a transaction/set of transactions a user should be restricted to one profit center and for another transaction/set of transaction he should be allowed for multiple profit center, including the profit center used in first case.

The set of transaction in both the scenarios will not contain any common t-codes.

For testing purpose, I created a role, say R1, assigned t-code F-02 and under K_PCA object assigned P1 as the allowed profit center. Then I created a role R2, assigned t-code FB50 and under K_PCA object assigned P2 & P3 as the allowed profit center. Now I assigned both these roles to a user  TEST1.

The problem arises when I login as user TEST1 and execute transaction F-02, it allows me to work upon all the 3 profit centers P1, P2 & P3. Same is the case when I use the transaction FB50.

As I am not finding a way out to implement the restriction as mentioned above, I am not not able to implement the bigger picture mentioned in the 2nd paragraph.

Regards,

Hrishav

[Former Member]

Hi Harsha,

This is common and a very important step when designing Security on transactions.

In your scenarion it looks like t-code F-02 is talking to FB50 t-code in the backround due to which it takes the auth data for object K_PCA and is providing access to all the 3 PC.

You first need to check and break the ralationship between these 2 t-codes in TCDCOUPLES table so that F-02 does not talk and fetch the auth data for that object in the backround.

You can run a trace on on test id and see what authorization are getting checked and maintain the security accordingly.

Thanks

Uttam

[Former Member]

Hi, this is standard behaviour.  The transactions share K_PCA so the auths will be available to any transaction that requires them.

If you need to segregate them (and arguably if you are performing posting activities to both restriction sets then why bother) then you'll need to perform some customisation to achieve that (e.g. use an enhancement point to add in additional checks/logic that are linked to the context of the posting).