P_PERNR — P_PERNR Authorization Object for Own HR Data

P_PERNR restricts what a user can do with the personnel number attached to their own employment record, typically infotype read or maintenance in ESS-type scenarios, self-service infotype changes, or PA20/PA30 access limited to 'my own data'. It sits alongside P_ORGIN, which restricts data by org structure attributes such as personnel area, employee group and subgroup. The structural fact that explains almost every confusion around this object: P_PERNR is only evaluated if the HR authorization main switch AUTSW PERNR in table T77S0 is turned on. With the switch off, the object is completely inert, the role can contain any value, correct or wrong, and it will have zero effect on the check outcome. Consultants who add or fix P_PERNR values in a role while the switch is off will see no change in behaviour and wrongly conclude the fix did not work.

The check fires inside the standard HR authorization check routine used by the infotype framework, immediately after the P_ORGIN check, whenever the AUTSW PERNR switch is active. This means it is evaluated on every infotype read or write triggered through PA20, PA30, PA40 personnel actions, and any custom or standard program that reads personnel data through the logical database PNP or the HR infotype API function modules. ESS and MSS scenarios that route through these same infotype operations inherit the same check, so a self-service tile failing to show a record is frequently a P_PERNR issue rather than a Fiori catalog or role assignment issue. In hybrid or side-by-side landscapes where core HR stays on-premise and SuccessFactors handles employee-facing processes, this check still applies on the on-premise system whenever a process falls back to PA20/PA30 or a report against infotype data, so it remains relevant even in a SuccessFactors-led landscape.

Start with SU53 run immediately after the failed action, since HR checks can be overwritten by a later unrelated check if the user tries something else first. If SU53 shows P_ORGIN failing, check that first; if it shows P_PERNR failing, note the exact PERNR and AUTHC values shown as required versus the values in the user's role. Before escalating, check table T77S0 for the AUTSW PERNR switch value, since a P_PERNR failure with the switch turned off is impossible and points to stale SU53 data or a different object misread. If SU53 is inconclusive, run an authorization trace (ST01 or the newer trace transaction) for the exact user, transaction and personnel number involved, then filter for object P_PERNR. Hand security the transaction code, the personnel number that failed, the infotype and subtype if known, and the AUTHC value required, not just a screenshot of the error message.

This sits between functional HR and security. Functional confirms which infotype, transaction and personnel number are involved and whether the AUTSW PERNR switch should be active for this client. Security confirms the role's PERNR field derivation and AUTHC value. A good ticket includes the user ID, transaction, infotype/subtype, the personnel number expected, and the SU53 or trace extract, not a general 'no access' description.

Most P_PERNR failures are diagnosed as role problems when the real cause is the T77S0 switch, or vice versa, and the two get fixed in the wrong order. A role that looks fully correct on paper still fails if the PERNR field was populated with a static personnel number captured during role build rather than a dynamic reference to the current user, which breaks the moment that user's own record changes or a new hire is onboarded into a copied role. Activating the AUTSW PERNR switch for the first time without auditing existing roles locks out large groups of users overnight, because roles built when the switch was off never needed a PERNR value and now fail by default. Consultants sometimes assume P_ORGIN alone should be sufficient and add restrictive org values there, without realising P_PERNR runs independently and can block access even when P_ORGIN is wide open. Confusing P_PERNR with structural authorizations for org-structure-based access is another common error; they solve different problems and neither substitutes for the other.