Solved: Company Code Restrictions

Former Member · ‎02-07-2007

Hi,

We have multiple company codes as I assume most companies do. I have created a role that is limits access to only 5 of our company codes. I assigned this role to a user that has another role that allows access to all company codes. Now when this user tries to access FB50 (which is included in the new limited role but not the wide open role) it grants them access to all company codes.

Is it possible to have a role that grants access to all co codes for one set of t-codes and another role that grants access to a restricted list of co codes assigned to the same user without giving them full access to all company codes? If so, how would one set this up?

This is confusing me so I'll try to recap:

I created a role that has access to all company codes and assigned it to a user. I create a second role that can only access a few company codes and assign that to the same user. Now when the user uses FB50, which is defined in the second role, they can see all company codes. Why?

Thanks,

Shelby

Former Member · ‎02-07-2007

Dear Shelby,

let me try to explain why this happens:

You probably limited access to transactions (object S_TCODE) and access to posting financial documents in company codes (object F_BKPF_BUK). Maybe more objects can be found in your roles - but let's forget about them for the time being.

So your limited role probably has two authorizations like:

1.1 - S_TCODE limited to FB50

1.2 - F_BKPF_BUK limited to activity *, Company Codes CC01 CC02 CC03 CC04 CC05

The less restricted role maybe looks like

2.1 - S_TCODE limited to FB03

2.2 - F_BKPF_BUK limited to activity *, Company Code * (i.e. not limited at all)

If you assign both roles to one user, all the authorizations in those two roles are added up in one long list:

1.2 - F_BKPF_BUK limited to activity *, Company Codes CC01 CC02 CC03 CC04 CC05

2.2 - F_BKPF_BUK limited to activity *, Company Code * (i.e. not limited at all)

1.1 - S_TCODE limited to FB50

2.1 - S_TCODE limited to FB03

To display this list just log on with the user-id and call transaction SU56 ...

The important message here is: This is a plain list of authorizations - there is no notion anymore of the initial roles / profiles that you used to structure them.

So of course this user can use FB50 (because of authorization 1.1) on all company codes (because of authorization 2.2).

Someone in my company called this the "chemical effect" because the two profiles when added up react with each other and the result is an unpredictably high authorization level for the user.

Of course there is no chemical reaction and nothing is unpredictable here. It is just important to know that roles (/ profiles) are a mere tool to assign authorizations to a user - but that this tool does not create additional structure to these authorizations. Nothing stops a user to make use of the authorizations 1.1 and 2.2 in the same transaction - even though these two authorizations were initially part of different roles.

In other words: If you want to understand the authorization level of a user, you just need to know its SU56 output. The list of authorizations you see there is all there is. It doesn't matter at all which roles have been used to assign the authorizations to him.

So what can be done about it ?

Focus on those objects that allow you to specify several values.

In our example, this would be F_BKPF_BUK as it has two fields: activity and company code. S_TCODE only has one field.

If you limit authorization 2.2:

2.2' - F_BKPF_BUK limited to activity 03, Company Code *

i.e. to display activities - which should be sufficient for transaction FB03 - then you got rid of the "chemical effect".

This may not always be possible - so the general / theoretical answer to your question sounds negative. But usually the situation can be avoided. The few execptions I am aware of typically happen with objects that only have a few (or one) fields - so be careful when using those.

Hoping this clarifies it a bit.

Regards,

Ralf

Former Member · ‎02-07-2007

Dear Shelby,

let me try to explain why this happens:

You probably limited access to transactions (object S_TCODE) and access to posting financial documents in company codes (object F_BKPF_BUK). Maybe more objects can be found in your roles - but let's forget about them for the time being.

So your limited role probably has two authorizations like:

1.1 - S_TCODE limited to FB50

1.2 - F_BKPF_BUK limited to activity *, Company Codes CC01 CC02 CC03 CC04 CC05

The less restricted role maybe looks like

2.1 - S_TCODE limited to FB03

2.2 - F_BKPF_BUK limited to activity *, Company Code * (i.e. not limited at all)

If you assign both roles to one user, all the authorizations in those two roles are added up in one long list:

1.2 - F_BKPF_BUK limited to activity *, Company Codes CC01 CC02 CC03 CC04 CC05

2.2 - F_BKPF_BUK limited to activity *, Company Code * (i.e. not limited at all)

1.1 - S_TCODE limited to FB50

2.1 - S_TCODE limited to FB03

To display this list just log on with the user-id and call transaction SU56 ...

The important message here is: This is a plain list of authorizations - there is no notion anymore of the initial roles / profiles that you used to structure them.

So of course this user can use FB50 (because of authorization 1.1) on all company codes (because of authorization 2.2).

Someone in my company called this the "chemical effect" because the two profiles when added up react with each other and the result is an unpredictably high authorization level for the user.

Of course there is no chemical reaction and nothing is unpredictable here. It is just important to know that roles (/ profiles) are a mere tool to assign authorizations to a user - but that this tool does not create additional structure to these authorizations. Nothing stops a user to make use of the authorizations 1.1 and 2.2 in the same transaction - even though these two authorizations were initially part of different roles.

In other words: If you want to understand the authorization level of a user, you just need to know its SU56 output. The list of authorizations you see there is all there is. It doesn't matter at all which roles have been used to assign the authorizations to him.

So what can be done about it ?

Focus on those objects that allow you to specify several values.

In our example, this would be F_BKPF_BUK as it has two fields: activity and company code. S_TCODE only has one field.

If you limit authorization 2.2:

2.2' - F_BKPF_BUK limited to activity 03, Company Code *

i.e. to display activities - which should be sufficient for transaction FB03 - then you got rid of the "chemical effect".

This may not always be possible - so the general / theoretical answer to your question sounds negative. But usually the situation can be avoided. The few execptions I am aware of typically happen with objects that only have a few (or one) fields - so be careful when using those.

Hoping this clarifies it a bit.

Regards,

Ralf

Former Member · ‎02-08-2007

Ralf,

Thank you for the great explanation. That helps me very much.

Shelby

Former Member · ‎02-08-2007

Hi Shelby,

happy to hear that my answer was helpful for you.

Would you mind assigning some points ?

Thanks and regards,

Ralf

Former Member · ‎02-09-2007

I would gladly assign points, but I don't see the radio buttons anymore. Not sure why. Sorry - If they magically come back, I'll assign them for sure.

Former Member · ‎02-10-2007

Hi Ralf and Shelby,

FYI: There are some threads in the Comments & Suggestions forum about the disappearance of the points radio buttons, which say that the sdn development department is also looking into it already.

Cheers,

Julius