Securing PD Data
Personnel Development (PD) Data is part of the Personnel Planning (PP) Data model used in SAP HCM. The PP Data model is made up distinct HR object types like positions (S), Persons (P), Jobs (C), Tasks (K), etc. The main use of this data is in Personnel Development (PD), Organizational Management (OM) and the Training and Event Management sub-modules of SAP HCM. In contrast to the PA master data which essentially store data for persons, PD data mainly store the attributes of the different PP object types. Also, the allowed PP infotypes depends on the object type and is controlled through configuration settings. PD data is specially relevant for security as it used to define the Organizational Structure of an enterprise and Organizational Structure in turn is used for the position based security assignment and structural authorizations.
PD data is secured by the authorization object, PLOG (Personnel Planing). The fields of this objects are given below.
Authorization Field | Long Text |
PLVAR | Plan Version |
OTYPE | Object Type |
INFOTYP | Infotype |
SUBTYP | Subtype |
ISTAT | Planning Status |
PPFCODE | Function Code |
We can better appreciate the use of this object by looking at one of the basic transactions for maintenance of PD data – PP01.
In the initial screen of PP01, we can easily spot the fields for Plan Version, Object types, Infotypes and Planing Status (the tabs for Active, Planned, Submitted, Approved, Rejected). The buttons highlighted in the toolbar are for different activities on the infotype selected. The permissible activities for the object and infotype combination are contained in the PFCODE field of the authorization object. Among the huge multitude of possible values of PFCODE like INSE (create), disp (display), DEL (delete), CUTI (delimit), LISD (List Display), AEND (Change), LIST (List Display with Change), etc we discuss only the last two.
In the first example we select infotype Object (IT 1000) and click the change button. The infotype change screen allows us to change the name and abbreviation of the object (AEND)
In the second example, we select Relationship (IT 1001) and click the second button from right to get into the Overview Screen which shows all the “relationships” created for the Object. The access being tested is LIST. Also note, that accessing overview screen from a pure display transaction like PP01_disp would have checked for LISD (List display). IT 1001 is also one of the PD infotypes which can be secured at the subtype level. Each relationship record shown on the screen (like A002 – reports, B007 describes) is a separate subtype and is meant to link two different object types. The different relationships between these PP objects is actually used to build the entire Organizational Hierarchy of the enterprise.
In addition to the PLOG object, PP objects can be further secured through Structural Authorizations. I hope to cover a discussion of Structural Authorizations in a future article.
Hello Expert,
Thanks for the article.
I’m new to HR Auth.
I can’t understand when the authorizations for the infotypes restricted via P_ORGIN and P_ORGXX, why we need PLOG object?
Regards
Manoj
PLOG controls access to OM objects and infotypes. P_ORGIN and P_ORGXX control access to PA infotypes.