AGR and SUIM disagree on Org Levels

[Former Member]

Recently we amended around single 1000 roles due to new company code restrictions in ECC EHP6.

We have found a number of roles where some odd behavious can be observed.

I go to PFCG and look at the Org levels and see $BUKRS 1035

I look at the 3 objects that have field BUKRS and also see 1035

I look in AGR_1252 and $BUKRS shows as 1035

I look in AGR_1251 and field BUKRS shows as $BUKRS

So all as expected and looks correct.

We assign this role to a test user and despite this being the only role assigned the test user can see company code 1000.  CC1000 was the value in the role before we changed it to 1035.

I look in SUIM and see the role is returned in the results when I search for Roles using complex, enter the role name, enter one of the objects with field BUKRS and enter 1000 as the value in BUKRS.  I press the profile assignment button and see the same profile T-D... as I see in PFCG (same name & change date/time).  I expand the profile and see the object and field value for BURKS is indeed showing as 1000.

We trace the user and they get RC=0 for BUKRS 1000.

The only thing I can thing of is that before these changes were made there were many roles that had the values in field BUKRS amended manually by some "bright spark" and we had to run AGR_RESET_ORG_LEVELS and when I look in a copy system I can see this role indeed was one that had been maintained manually.  The AGR_RESET_ORG_LEVELS program corrected the value in AGR tables as expected so why does SUIM disagree and more concerning why does the user somehow get the old values despite being a brand new test user in Q.

Its worth noting when we copy the role with this issue and assign the copy all is fine but I'd like to understand the root cause if at all possible so any ideas out there ?

[Former Member]

Were the updates automated/mass regens performed?  I've seen similar when role updates have been scripted or done through various automated techniques.

It sounds like it could be a case of roles being updated but the profiles not fully generated hence the discrepancy in reporting between 1252 and SUIM.  With the change timestamps being the same I would have expected the roles & profiles being in sync but obviously not in this case.

If the roles were updated manually then that is very strange as I would expect the same behaviour as the copied roles.

[Former Member]

HI Alex

They were performed role by role via an LSMW which called SE38, entered the program, entered the role and executed

[Former Member]

So it seems that after performing the AGR_REST_ORG_LEVELS program it is necessary to run a mass generation via SUPC in oder for the changes the program made are fulled syncronised in AGR tables, and SUIM / user buffers etc

Maybe there is a small improvement opportunity for the program to perform this activity.

[Former Member]

That's good to know, thanks for the update.