How do we restrict the user access for a particular G/L account

[Former Member]

Dear Experts,

At our customer site, we follow master / derived role concept for authorisations.

We have a requirement to restrictict user at G/l account authorisation level.

I am aware that every g/l account account has a authorisaition group. But g/l account authorisation is a non-org value for which the present value is * for brgru, we cannot restrict by user/org. At our customer site the authorisations are provided at master role level for a designation and derived role is restricted for a plant, BA etc..

Is there is any user parameter level restriction which can handle this requirement, i mean user parameter for specific g/l account, as we do LIF pid to restrict vendor level access.

Appreciate your suggestions ASAP.

Best regards,

M.Kumaran

[Private_Member_119218]

Depends.

What are you trying to protect? GL account masterdata (FS00) or FI document creation for specific GL accounts?

Without knowing more about the design principles behind your roles, your release or other restrictions, I would suggest:

(1) grouping off the GL accounts you want to protect in authorization groups (maintained via FS00);

(2) deactivating either object F_BKPF_BES (if your trying to restrict FI document creation) or object F_SKA1_BES (if your trying to restrict access to GL account masterdata) or both in master/derived role;

(3) create several separate roles that would contain only the aforementioned objects with access to specific GL account groups;

(4) assign the roles from step 3 to users as required.

Hope this helps.

[Former Member]

Hi,

i dont think there is a parameter that controls the G/L account authorization. A parameter value can only default what you get to see, you can easily change the deafaulted value isnt it?

Have a discussion with the stake holders in your project and if they agree you can follow the approach of maintaining a dummy value '' in the master role - derive the role so that all inherited roles have dummy values in them.

create seperate roles for the G/L acccount groups created (you can have only the authorization object and not all the transactions in this role).

The advantge in this is: you still have your master and inherited roles in tact (particularly useful when they are very big) and the smaller roles you would create for individual G/L account groups can be assigned in a controlled and need based manner

[bashayreh]

Hi All

I reached here because I have the following scenario:

1) we prevented changes and customization to our production client.

2) some of our finance users requires access to OB58 and FSE2 but they start getting:

client x has status 'not modifiable'

3) I unlocked both TCODES and disabled the error message 146.

4) I created a role to grant access for both TCOdes, and assigned that Role to some users.

5) the problem: I noticed all finance users got the access to these TCODES

what to do ... please advise