Issue with HR Security

[Former Member]

Hi All,

Iam facing issue with HR Security currently working in Migration project as part of project requirement created single roles and assign the t-codes and maintained infotypes. Now when they are trying to get list of retired employeess from pa30 t-code its throwing error inconsistency missin authorizations. Whe trying to run su53 screen shot it showed infotype 0040 and 0041 missing but already that infotype is assigned to the role. Please suggest .

Regards,

Parimala

[Colleen]

what did you maintain for P_ORGIN (i.e are other fields limited) and do you have structural authorisations switched on?

[Former Member]

Not structural authorization i maintained all tyhe infotypes necessary to their work

[former_member184635]

Assuming, for the retired staff you are not changing the PA,EG,ESG & Org key and changing only default position. You need to check the structural authorization (if used)  and the switch used for it in T77S0 table.

Regards,

Dadarao.

[Former Member]

here we are not using structural authorization Dadarao so how can i proceed further can i add manually the auth object for s_tabu_dis and assign the table name .

[Colleen]

Hi Parimala

No idea where you are getting S_TABU_DIS from? Even if tables were required, it'd be better to use S_TABU_NAM

How are you trying to obtain the personnel - is it via PA30 matchcode search or are you running report elsewhere. It might be worth showing a screen shot of your error message (blank out any sensitive fields if you see them) and include the STAUTHRACE checks or failed checks

Also, what authorisations have you included already when you say you put all the values in there?

Regards

Colleen

[Former Member]

Hi Parimala,

Please, execute transaction $SYNC and check SU53 again.

Regards,

Salomão

[Colleen]

Why you would you run $SYNC for this scenario?

How to Reset different SAP buffers - Basis Corner - SCN Wiki

Resetting buffers will not fix this issue, is typically restricted to Basis team only and is a last resort to avoid system restart.

I'd hope in a Production environment that S_ADMI_FCD object has been adequately restricted to prevent anyone running this command.

Please do not run this command

Based on re-reading the issue it almost sounds like a PFCG profile generation issue or PFUD user compare problem. Checking SU56 user buffer (not the same as $SYNC) would show if the user is actually getting the P_ORGIN values or similar. IF SU53 is showing as failed for the user but the user has the access then it sounds like mismatch between PFCG and SU01 or the analysis and assumptions are incorrect

Regards

Colleen

[Former Member]

Yep, $SYNC will not help here.

If the buffer is corrupt, then in SU53 via the menu you can reset the buffer. This is the same as report RSUSR405 or SU01 command RSET which sets the flag to rebuild the buffer when you next logon. So just logoff like in the good old days of 46B.

If the PFCG generation is corrupt, then start tcode SUIM_OLD. This will automatically run FM SUSR_SYNC_USER_TABLES and sort out orphaned authorizations and also inconsistencies between the UST and USR tables. Generate the profiles in PFCG afterwards to be on the safe side.

But SVEN is correct. Without providing information about OOAC, this is all guessing as that should come first in the troubleshooting box of tricks.

Cheers,

Julius

[Colleen]

Hey Julius

As soon as Sven wrote his reply I it made sense (pity a few off us all asked the question at the beginning regarding status of structural). But yes, actual screen shots of the configuration or what the error are showing would make root cause analysis easier. It's become another guess the issue with vague details game.

Thanks for detailing my comments further as well

Btw, I thought SUPC and PFUD improvements on cleanups will now resolve the UST* and USR* corruptions. Good to know about SUIM_OLD though as I've discounted most *_OLD transactions as deprecated functionality

Cheers

Colleen

[Former Member]

This sounds a bit like strucht auth not properly switched off. If it's switched on, but no profiles assigned in T77UA and ALL assigned to SAP* in T77PR, then you won't see any effect as long as people are assigned in Orgmgt. But when you have leavers or retirees not assigned in OM it depends on what you have in T77S0 - AUTSW - ORGPD. If it says "always reject, if no position / default position" then it used to reject despite of the ALL profile. This seems. Counter-intuitive, but al least that's what the system did at least many years ago (at least 10, I guess), when I came across the issue.

Do, cutting it short, please check AUTSW - ORGPD in table T77S0 to make sure it's really set to 0 rather than relying on T77UA being empty