How to restrict the transaction OB52 ?

[Former Member]

Hi guys.

I need to restrict the transaction OB52 for Company Code. By default the transaction OB52 has no authority object to restrict it to the company code. Try it by adding the SU24 transaction object F_BKPF_BUK (check / maintain). When I create the security role by adding the transaction OB52, lifts my perfectly F_BKPF_BUK authorization object, added the company you will have the authorization, but does not work when I assign the Role to the user. The user will still leave change all companies and not the company you want to restrict.

Thanks guys for the help.

Desirée.

[Former Member]

this has been answere quite a few times on the forum, if you searched for it i am sure you would have found it.

Anyway, you would need to make restrictions based on the posting period variants F_BKPF_BUP

.............search the forum for more details

[Former Member]

Thanks Shekar for the replay.

Now I already have this restriction in order to permit F_BKPF_BUP. But I need to add authorization for company code?

I will seek the post.

Thank you.

[Former Member]

Hi Desiree,

You need to sit with the developer and check if at all there is an authority check on the company code inside the program assosiated with Tcode OB52.

Simply adding an object to SU24 w.r.t Tcode does not actually restrict that tcode, unless that object is used as an authority check in the code assosiated with that tcode.

You can create a customized tcode if you want some additional checks to be places in the code.

Regards,

Akshay

[arpan_paik]

Hi,

Take the below into consideration for restricting table views for transaction like OB51, OB52 etc.... For your particular case I guess when user is running OB52 then it is providing data from table V_T001B

First level authorization check will be S_TABU_DIS for access to table. Auth group will be FC31

Now to drill down further restriction on line level for above table you need to use objects S_TABU_LIN. To use this object consider have look into the documentation for this object and 2nd step to read documentation in following path.

 SPRO --> Display IMG --> SAP Web Application Server --> System Administration --> Line-oriented Authorizations --> Define organizational criteria/Active organizational criteria 

Now in SPRO when you will create organization criteria then create it for field Posting Period Variant (BUKRS). This is one of the field for table V_T001B.

Now activate it for table views V_T001B

Now run OB52 again and it will ask for additional authorization for object S_TABU_LIN. In ORG_CRIT put the name of organization criteria you have created and in ORG_FIELD1 maintain value for relevent company code.

This way will see only those lines where value for BUKRS will match with his/her user master for S_TABU_LIN

This is quite big post. Will suggest you to go through documentation thoroughly rest are self explanatory.

Arpan

Edited by: Julius Bussche on Mar 28, 2010 10:22 AM

Formatting fixed - please use "quote" tags and not "code" tags.

[Former Member]

> Thanks Shekar for the replay.
> 
> Now I already have this restriction in order to permit F_BKPF_BUP. But I need to add authorization for company code?
> 
> I will seek the post.
> 
> Thank you.

Hi Desir'ee,

you need not specifically give authorizations on the company code. I am sure the functional consutlants at your end would have assigned the posting period variant to the company code. (IMG, FInancial Accounting=>Global settings=>Document=>Posting Periods=>Assign Variants to company Codes)

But doing just this might not solve the problem. When you give access to a user on a particualr posting period variant, there is no inherent check on the table (V_T001B) to restrict the display to the particular variant. If you look at the tabel carefully, there are 3 things that matter (1) Posting Period variant (2) the Account type (3) Account number (and obviously the year)

we created a new transaction ZSM31 for a host of other tables that needed to be restricted, and in the program for ZSM31, we have a screen developed for V_T001B that has the above mentioned 3 items as the primary selection criteria. A user can enter the posting period varaint only that he is entitled to and since it is linked the company code, i dont make specific restrcitions on the company code itself.

[Former Member]

What happens when the user, once in the restricted view of the current variants he is authorized for, adds a new entry with a company code he is not meant to be authorized for?

The correct and more secure approach is S_TABU_LIN, which is checked again.

Cheers,

Julius

[Former Member]

Hi Julius,

I am not against using S_TABU_LIN, i was explaing what we have

A mistake in my post is: i mentioned the maintenance via ZSM31 on V_T001B, Infact we have the table maintenance on T001B, and there is no company code value in the table. we never had problems with the approach since all the 21 company codes have 21 distinct posting period variants and since it is a one to one assignment, a user cannot enter the vaule for a differnt entity than what he is authorized to.

[Former Member]

The downside of it that is the standard view is still there and wont check it.

There are some other transactions and view maintenance calls with use the standard view.

Cheers,

Julius

[Former Member]

>

> The downside of it that is the standard view is still there and wont check it.
> 
> There are some other transactions and view maintenance calls with use the standard view.
> 
> Cheers,
> Julius

Julius,

I didnt understand what you mean.

users are not given access on SM30, S_TABU_DIS: FC31 , who ever needs to change it does it via ZSM31. so why should it be a problem if the view V_T001B exists???

I would also be interested to know which other transactions use this maintenance view, could you help us with this?

[Former Member]

F-60

GCP1

GCP5

OBVU

SE16

SA38

SM37

SUB%

etc...

etc

Cheers,

Julius

[Former Member]

ok, i buy your point that there are other transactions that use the view. but how does it dilute the security aspect if users are given access to ZSM31 with the posting period restriction for T001B and not to SM30 maintenance on FC31 authorization group?

[Former Member]

by the way, i just found out that the selction criteria we have for posting period maintenance via the custom transaction is similar to what you get when you go to SM30 and table V_T001B_PS_PER

[Former Member]

In that case they might be able to create new entries in or from other clients as well?

S_TABU_LIN is a safer bet and no redundant coding in need of maintenance is involved. SAP does it for you.

Cheers,

Julius

[sdipanjan]

To be frank, I am not quite sure on the feasibility of the method I am describing. You need to check with ABAP team on this.

Try to include a enhancement to check the BUKRS in T001W and take the provided value from the user buffer provided by admin in the roles as a variable and pass this value dynamically to the user's authorization while. May be S_TABU_LIN can be leveraged for this while accessing the structure getting populated during runtime for this value pass by variable.

Regards,

Dipanjan

(i hope Julius or Barnhard will comment on this based on the possibility for this if they see my post. check their post).

[Former Member]

hello guys here in my country we holidays. I'll take all the recommendations I listed in the answers to restrict the transaction OB52. I really like the idea of creating a new transaction based on it and restrict it to be, but as I discuss with my team what we do best.

I appreciate the interest in helping.

Thank you.

Desiré