Org Level, fund center/cost center level restriction for tcodes????

[Former Member]

I am looking to see whether org level restriction and cost center/fund center level restriction is possible for certain set of transactions.

I am using USOBX table for this analysis. This table has a check flag field ( same as in SU24) which says whether the Tcode (program) does the authority check for certain auth objects. Example- X (checked but not maintained in USOBT). This table pulls up several authorization objects under the 'X' category. However, when I do the System trace for the same tcode, all the objects (marked as X) are not captured. Instead only a few are captured.

Can we rely on the USOBX data or should we do system Trace for every tcode. I am just pulling a report and not creating roles at this point. So trace is time consuming. But data reliability is equally important.

My objective is to verify whether org level and cost center/fund center level restriction is possible or not for some tcodes.

Do you have any suggestion to achieve this faster (through USOBX or any other means)?

Thanks in advance

Kee

[Former Member]

Auth objects with a Y in OKFLAG field are usually (not 100% accurate) checked when a transaction is executed. Depending on the scenario other objects with an X in OKFLAG field for that transaction may are may not be checked. There is no easy & fool proof way to determine all authorization objects checked for each transaction.

For initial assessment it is a common practice to only take into account the default authorization checks (the authorization objects with a Y)

[Former Member]

I would suggest you to check USOBX_C and USOBT_C instead of USOBX and USOBT as it will have your customization as well and not just the standard ones given by SAP.

Also when check field is X ...it means the object is checked but not maintained for the t-code as you already said but I am not sure how much it will help you as the they will not be pulled by PFCG when you are creating the role until you change the object to Check / maintain . When you do that the check field will be Y and not X. So basically it is the Y one which you need to see.

Going for trace is time consuming for every t-code and I am not sure if it really needed. When your roles are in testing phase and are tested by the functional team or the team which needs it and if they are missing some object, you can run a trace and find the missing object....

I am not sure on what basis you want to change some field to Org level ...but typically it is done if you want to do segregation of roles based on these org level. There could be various other reasons and it is better to talk to your functional counterparts before changing a field to Org level.

for ex : If you want to segregate on company code, you will create co. code as Org level and create roles for different company code.

[Former Member]

My requirement for the org level is for the segregation of roles (similar to your example). In my case, we need to restrict by fund center/cost center. So planning to turn on fund center and the authorization groups for fund centers to org level for easy maintenance.

We are doing a fresh implementation and we dont maintain any custom values in the USOBT_C tables for now.

Also my current check is to find out whether org level restriction is first possible. But it turns out that there is no fool proof way to find that.

Thanks

Kee

[Former Member]

That is true ..there can be more than 1 way ....but if you have t-codes which pulls authorization object with fields for fund centre and cost centre....you could change them to Org fields using PFCG_ORGFIELD_CREATE and then segregate by roles. Talk to your functional team to see if it advisable and feasible to do so. there should be some functional and technical specs right for the fields that should be considered as Organizational level.