Should org levels be maintained at the object level - pros and cons

[Former Member]

Hi

Reasons not to make Movement Type (BWART) into an ORG level.

Posted: Sep 21, 2010 8:06 PM

Just to check on the original comment please from this thread (didnu2019t want to hijack so started a new thread)

"That way we could manage it for the top level of the role, and then change it at the object level if needed."

Does this answer question 8 in the other thread about fun with interview questions?

😎 Can you have more than one set of org-level values in one role?

And...

I know this is possible to do at the object level and that you can also reverse the entry using SE38 if done by accident but what do you think about the correctness of maintaining org levels at object level?

Pros

It would allow an object or set of objects in a role which support a particular transaction to have unique access to the other transactions in the role

Cons

My own view is that it leads to all sorts of confusion for administrators, I'm not sure how RAR will cope with a variable being fixed if org level reporting is activated either?

Cheers

David

[jurjen_heeck]

> I know this is possible to do at the object level and that you can also reverse the entry using SE38 if done by accident but what do you think about the correctness of maintaining org levels at object level?

I consider everything that deviates too far from SAP standards and which can be broken in the blink of an eye by someone just following everything he or she learned in the SAP ADM* trainings to be a big no no.

Not only is this concept error prone and easy to destroy. Finding and correcting the error afterwards may become a tedious task which you'll have to carry out with lots of angry users and management breathing down your neck.

Just my 2c.

[Former Member]

Has anyone ever promoted s_tcode to an org. level?

It only has one field TCD and few use the other objects so little could go wrong... right?

For KOSTL take a look into RESPOAREA, but do not promote it. Let thwm maintain the hierarchy and your roles will have peace!

Cheers,

Julius

[Former Member]

Hi Julius

Promote S_TCODE eh? very good indeed - I see how this could actually work!

But then you can't leave out all of the other _TCODE objects as you just wouldn't have a consistent security concept.

I raised the thread about over-riding org levels at object level to see what the general feeling about updating these little buggers was. I expected a flame-on (if that is the correct term for an inflamatory post?) but only two people have bitten back but it was a little late in the day

In a system that had been maintained in this way running AGR_RESET_ORG_LEVEL may be a nice little last job before I leave after getting my final timesheet signed. (edited - deleted excerise as I can't spell - edited)

Sorry - second edit - yes the KOSTL on CO-OM really is a pain as cost centres would have been ideal to be promoted bar those.

Cheers

David

Edited by: David Berry on Sep 22, 2010 10:53 PM

Edited by: David Berry on Sep 22, 2010 11:02 PM

[Former Member]

David,

per my understanding, the one maintained at object level have higher priority.

it will override the one maintain in 'og level' tab. Hence always avoid them.

in RAR, org level analysis is handled in very different way, rules are generated at runtime and one job is scheduled to populate table to contain all users and org levels values assign to them.

so in RAR org level anlysis can be done only at uer level

hope this help

regards,

Surpreet

[jurjen_heeck]

> per my understanding, the one maintained at object level have higher priority.

>

> it will override the one maintain in 'og level' tab.

This is incorrect.

Organizational levels only exist within PFCG and are a building aid. Nothing less, nothing more. They do not exist within the generated profile. In the actual profile data all organization variables are replaced by their values whereas manually entered values are left untouched. This happens when the profile is generated.

At the point of the actual AUTHORITY_CHECK, which is done on the profile and not on the role, there is no way to tell the different origins of the values. So there's no prioritizing whatsoever.

[Former Member]

Hi Jurgen

Thanks for that - my reply to Surpreet was going to be "In that case, would the transaction that is being supported by the manually maintained object giving, say plant BR02 also get the plant from the org level entry too, say BR01 or just BR02?"

This is why I don't like org level maintenance carried out at object level - far to messy

[jurjen_heeck]

> This is why I don't like org level maintenance carried out at object level - far to messy

Just keep in mind that org levels do not exist with the actual profiles. The messy part is the ease with which org values maintained on object level in derived roles can be overwritten by the properly entered values with one mouseclick.

[Former Member]

Jurjen Heeck

not sure what you understood from my reply.

i am also refering to PFCG -> auhtorization tab -> here there are two places where you can maintain org values

1. click on 'organization level' button

2. expand auth object and fill value of field say BUKRS

here per my understanding object level have higher priority.

hope i clarified.

regards,

Surpreet

[jurjen_heeck]

> here per my understanding object level have higher priority.

What do you mean by 'priority'? In the profile either one is just a value and will be treated as such.

[Former Member]

i had faced that problem some time back, so that's why i said 'priority'.

pls test with temp role and assign it to user, see if user is able to use both values maintained at different places.

regards,

Surpreet

well forgot to add, it was 46B

Edited by: Surpreet Singh Bal on Sep 23, 2010 5:44 PM

[jurjen_heeck]

Hi Surpreet,

I think we have a terminology mixup here but agree on the technical level.

Yes, the value maintained on object level will end up in the profile regardless of the org level value for that field.

When creating the profile based on a role's authorization data PFCG will only evaluate the org level value if a field holds the corresponding variable, like $PLVAR for Plan Variant. In that case the org level value is written to the profile, instead of the variable name.

If this variable name is overwritten by a value (which you do by maintaining on object level) the entered value is written to the profile. The org level value for this field is ignored since the linking variable has been erased/overwritten.

The term 'priority' may confuse people into thinking the authorizations are treated in a special way if the org field was maintained on object level. That is never the case.

Cheers

Jurjen

[Former Member]

Hi

Just tested this - giving wildcard for Purchase group at org level then maintaining field EKGRP in object M_BEST_EKG to one purchase group only for ME21N.

Test user assigned and logged on cannot raise a PO for * wildcarded org level - just the restricted object value.

Thanks for your time answering this question - much appreciated.

Regards

David

[Former Member]

THANKS Jurjen

for putting it in correct technical term.