Authorizations in HCM 1

7/13/2021
Human Resources
Generated on: 2021-07-13 17:28:27 GMT+0000
HR Renewal | 2.0, Feature Pack 5 SP 90
PUBLIC
Original content: https://help.sap.com/viewer/4946a4f5c2d7427c96d89242e1ff2d9a/2.5.90/en-US
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/viewer/disclaimer.
This is custom documentation. For more information, please visit the SAP Help Portal 1
7/13/2021
Authorizations for Human Resources
Purpose
Authorizations control system users’ access to system data and are therefore a fundamental prerequisite for the
implementation of business software.
In Human Resources, authorizations play a signi cant role since access to HR data must be strictly controlled. There are two
main ways to set up authorizations for SAP Human Resources:
You can set up general authorizations that are based on the SAP-wide authorization concept or you can set up HR-speci c
structural authorizations that check by organizational assignment if a user is authorized to perform an activity.
 Note
All information refers to the SAP Standard Release 4.70 unless otherwise stated.
Implementation Considerations
To decide how best to set up your authorization requirements, see Technical Aspects for all relevant technical information about
both authorization types.
Integration
You can set up both authorization types (general access authorizations and structural authorizations) simultaneously. This can
lead to a complex interaction of authorizations. For more information, see Interaction of General and Structural Authorizations .
Features
This documentation explains which values to select and how to use them to set up authorizations for each authorization type.
For more information about the authorization types, see General Authorization Check and Structural Authorization Check .
For more information about the customer enhancements available for HR Authorizations, see also Customer Enhancements .
For help with setting up authorizations and information about important help and tool reports for authorizations, see Additional
Functions for Authorization Checks .
Constraints
For information about the known problems and suggestions for solving problems, see Constraints .
Example
Simple examples demonstrate how you can accommodate different authorization requirements.
General Authorization Check
Use
The general authorization check for mySAP HR controls access to Human Resources infotypes .
7/13/2021
Integration
This authorization type applies to the general SAP authorization check, which is set up using the transaction PFCG. The
authorization objects that are used only in mySAP HR are HR-speci c authorization objects.
Features
Authorizations are de ned by authorization objects . An authorization object speci es the elds that occur in an authorization.
The system checks if a user has the corresponding authorization for certain eld speci cations in the user master record.
Authorizations are grouped together in authorization pro les .
A user’s authorizations for the different authorization objects in the system are determined from the authorization pro les
assigned to the user in the master data record.
There are a number of authorization objects you can use to de ne authorizations for mySAP HR . You can call up these
authorization objects using transaction SU21 (HR object class) in the SAP system. For more information, see Authorization
Objects .
The authorization main switch controls the use of authorization objects. For more information about the authorization main
switches, see HR: Authorization Main Switches .
In addition to the authorization objects and the main authorization switches, the following technical aspects are important for
general authorizations in mySAP HR:
Authorization Level ( AUTHC eld) – this eld controls the access mode (read, write, ...) in HR authorization objects. It
can have different speci cations according to the authorization object.
Organizational Key ( VDSK1 eld) – this eld is only contained in the P_ORGIN authorization object. You can use this
object to carry out a differentiated authorization check by organizational assignment.
Time Logic
Periods of Responsibility
Control Mechanisms (Double Veri cation Principle, Test Procedures, etc.)
For a description of the process of general authorization checks in mySAP HR (and of all relevant substeps in this process), see
Processes and Flowcharts of the Authorization Check .
Activities
For general information about setting up authorizations for SAP applications, see Setting up General Authorization Checks .
Example
The following examples demonstrate how you can accommodate simple authorization requirements for the general
authorization check:
Employee Self-Service
Administrator Should Not Be Allowed to Edit Own Data
Administrator Should Not Be Allowed to Enter Data Alone
Decentral Time Recording
7/13/2021
Telephone Lists
Payroll
Transaction-Dependent Authorizations
Setting Up General Authorization Checks
Use
You set up authorizations in the form of roles using role maintenance (transaction PFCG). Roles provide a business perspective
by representing the tasks and activities that a user is authorized to perform in the system. Authorizations are parts of roles and
are stored as an authorization pro le for the role. Role maintenance generates one part of the authorization pro le (functional
part) automatically; you must de ne the part of the pro le that controls which data a user has access to manually. You can
generate several authorization pro les for each role. When you generate roles, you also de ne the authorization objects with
the necessary eld speci cations.
User menus provide access to the transactions, reports or web-based applications contained in the roles. A user menu should
therefore contain only the functions that are required by a speci c user with a speci c task pro le for daily work.
 Note
Authorizations were set up using the transactions SU01 and SU03 up to release 4.6A. Up until then, the common term used
to describe roles was activity groups.
Procedure
To create roles and to generate authorization pro les, proceed as follows:
1. To create or change a role, choose Role Maintenance using transaction PFCG. If you want to create your own user roles,
make sure you do not use the SAP namespace (all roles delivered by SAP have the pre x SAP_).
2. In the Menu tab page, assign transactions, reports, and/or web addresses to the role. By doing this, you set the user
menu that is automatically called up when the user assigned to this role logs on to the SAP system. When you assign
transactions and so on, the user’s role or task pro le is de ned. The transactions de ned in Menu tab page are are then
used by the system to create authorizations automatically.
3. You can change the authorizations that were automatically created by the system if you need to by setting the menu in
the Authorizations tab page. To do so, choose the Expert Mode option under Maintain Authorization Data and Generate
Pro le in this tab page.
4. You can create additional authorizations when you change the authorizations that you have already created by choosing
additional authorization objects and so on, for example.
5. In the Authorizations tab page , also generate the authorization pro le belonging to the role when you have nished any
post-processing work on the automatically created authorizations.
6. In the User tab page , assign users to the newly generated role.
 Note
You can also assign users to roles by user groups and by objects (for example, job) in Organizational Management . You
cannot use the pro le generator for this type of assignment; you must use transaction SU10 ( User Maintenance: Mass
Changes ) in Organizational Management .
7/13/2021
The generated pro le is only entered in the user master record once a user comparison has taken place. A comparison is
also required if changes are made to the users assigned to the role and if an authorization pro le is generated.
For more information about setting up authorization pro les, see the Implementation Guide (IMG) for Personnel Administration
under Tools Authorization Management Maintain Pro les .
In addition, you can nd all relevant and non-HR-speci c information on authorization maintenance (Role Maintenance) in the
SAP Library under Basis Computing Center Management System (BC-CCM) Users and Roles (BC-CCM-USR) .
Structural Authorization Check
Use
Structural authorizations perform exactly the same function, from a business point of view, as general authorizations in mySAP
HR and in other SAP components. They control access speci cally to data that is stored in time-dependent structures
(organizational structures, business event hierarchies, quali cations catalog, and so on).
Integration
You can integrate the structural authorization check with the general authorization check. Note that if you do so, the
authorizations entered for each authorization type may in uence one another. For more information, see Interaction of General
and Structural Authorizations.
Prerequisites
The data that you want to protect must be stored in a hierarchical structure of one of the Personnel Development components
(Organizational Management, Personnel Development, Training and Event Management, and so on).
Features
You can grant authorizations for objects that are stored in a hierarchical structure using the structural authorization check. If
you specify a root object, you can determine that all objects in the hierarchy under this speci ed object may also be changed, for
example.
This concept guarantees that the maintenance of structural authorizations is kept to a minimum, even if a change is made
within the structure, and at the same time that users still only have access to objects for which they are responsible.
This exibility is achieved in two steps. First by using the (initial) structure built in Organizational Management to de ne the
authorization pro les. And second by using a concept to store authorization pro les that reacts automatically/dynamically to
changes in the organizational structure, or in other words a concept that automatically adjusts to the different pro les.
Furthermore, structural pro les can be created speci cally to exclude certain branches of structures from authorizations by
setting the Exclusion indicator for these pro les during pro le assignment in Customizing. During the authorization check, it is
rst checked whether an object is included in the exclusion set, meaning within the excluded substructure. If this is the case, the
user does not receive authorization for this object, even if the object appears again without exclusion in the pro le.
If a user is to receive extensive authorizations, the exclusion of substructures can also improve the performance of structural
authorizations.
For more information about the structural authorization check concept, see Structural Pro les.
7/13/2021
Activities
For information on how to set up structural authorizations, see De nition of Structural Authorizations.
Example
The following example illustrates the advantages of structural authorizations for access to data in time-dependent structures:
An organizational structure divides into three subtrees (organizational units O2, O3, and O4) on the second level, for example.
The authorizations of the persons responsible for each organizational unit are also divided up accordingly for each subtree. A
user needs three pro les for this organizational structure that allow him or her to read/change data in O1, O2, or O3 AND in all
lower level organizational units.
If you were to use the general authorization concept (values in elds) here, you would have to enter all objects under the initial
object in every authorization pro le.
For the O2 pro le and lower level objects, for example, you would have to enter the following objects in the pro le:
O2
O5
O6
In other words, you would have to enter ALL objects under O2 in the pro le.
7/13/2021
You would have to follow the same procedure for all other pro les, which would involve considerable maintenance work for the
initial pro le and for the organizational structure if changes were made to it.
If the organizational structure were expanded to include the organizational units O11 and O12, for example, you would have to
add the O2 and lower level objects pro le to include 011 and 012 manually.
Structural pro les, on the other hand, allow you to copy pro les, such as the O2 and lower level objects pro le, by entering a
start object (in this case, O1) and an evaluation path. This requires minimal time and effort.
For more examples of structural authorizations, see Example:Structural Authorization Pro les.
Structural Pro les
Structure
Structural pro les use the data model of the Personnel Management components Organizational Management, Personnel
Development and Training and Event Management to build hierarchies using objects and relationships. Different types of
objects (Object Types) and different types of relationships are used in this process. The organizational structure of a company is
illustrated in the following way:
The central elements of this data model are used to manage the authorizations for the model effectively:
Objects (such as O (Organizational Unit), S (Position), P (Person))
Relationships (such as A003 (belongs to))
Evaluation Paths (such as O-S-P)
Evaluation paths "collect" objects from a start object in an existing structure according to their de nition: The de nition of an
evaluation path determines the start object and which object types using which relationships are selected.
7/13/2021
 Example
The evaluation path O-S-P (Staffing Assignments along Organizational Structure) is an example of an evaluation path (and
also a standard evaluation path that plays a central role in Authorizations) that is de ned as follows:
Object Type Relationship Relationship Name Related Object Type
O B002 is line supervisor of O
O B003 incorporates S
S A008 Holder P
This evaluation path starts selection from an organizational unit (O) that is used as the start object (the organizational unit O1
from graphic 1 is used in the following example). The evaluation path rst selects all organizational units from row 1 of the
de nition (O B002 O).
The following organizational units are selected for the structure in the above example:
O1, O4, O5
Second, the evaluation paths starts selection from the selected organizational units according to row 2 of the de nition (O
B003 S) and selects the following positions:
S1, S2, S3
Last, the evaluation path starts selection from the selected positions according to row 3 of the de nition (S A008 P) and
selects all persons:
P1, P2, P3
In total, the following objects are selected using the O-S-P evaluation path and the start object O1:
O1, O4, O5, S1, S2, S3, P1, P2, P3
A combination of start object and evaluation path returns a speci c number of objects from an existing structure. This exact
combination or the objects returned by this combination, represents a user’s structural pro le. Note that neither the number of
objects nor the speci c objects that are returned by a structural pro le are constant, nor is this desirable. The concrete objects
that are returned by a structural pro le change as the organizational structure (under the start object) changes.
See also:
Example in Structural Authorization Check
There are several elds besides the central elds Start Object and Evaluation Path that can be used to de ne structural
pro les. These elds simply allow you to add more detail about frequently occurring standard cases, but use the basic principle
of "start object plus evaluation path". See De nition of Structural Authorizations for more information on these elds and how
to create structural pro les.
 Note
Not all aspects of the structural authorization check can be discussed in one section. See the following for more detailed
information on the different aspects:
PLOG (Personnel Planning) : Importance of the PLOG authorization object for the structural authorization check
7/13/2021
AUTSW ORGPD (HR: Structural Authorization Check) : Importance of the ORGPD authorization main switch
Flowchart: Example of Period of Responsibility According to Structural Authorization Check
Interaction of General and Structural Authorizations
Example: Structural Authorization Pro les
HRBAS00_STRUAUTH (BAdI: Structural Authorization)
Performance Aspects
Redundant Read of Objects
Evaluation Paths with Non-Speci ed Target Object Type
Context Problems in HR Authorizations
De nition of Structural Authorizations
Use
You can use this function to de ne structural authorizations. You de ne structural authorizations using table T77PR (De nition
of Authorization Pro les).
The system distinguishes between two different uses of structural authorizations:
Structural authorizations for the components Organizational Management, Personnel Development, and Training and
Event Management - this focus on structural authorizations is covered in this section.
Structural authorizations that are to be used for a more detailed authorization check (based on the organizational
structure) during the processing of HR master data. This focus is covered in Interaction of General and Structural
Authorizations.
Integration
You assign the pro les using table T77UA (User Authorizations = assignment of pro le to users). For more information, see
Assignment of Structural Authorizations.
Prerequisites
Knowledge of the data model for the Personnel Development components (Organizational Management, Personnel
Development, Training and Event Management, and so on) is a basic requirement for understanding and setting up structural
authorizations. For more information, see Structural Pro les.
Features
In table T77PR (De nition of Authorization Pro les), you can use the following elds to de ne authorizations for HR objects (the
elds are mentioned in line with their sequence in the maintenance view; the sequence does not represent prioritization!):
Plan Version
In this eld you can specify for which plan version the de ned pro le is valid. In the integrated scenario, note that plan
version 01 is usually the integrated plan version.
Object Type
7/13/2021
In this eld you can specify for which object types the pro le is valid. Note that only object types that have a key with the
format NUMC (8) can be speci ed. For external object types with another key (for example, cost centers), structural
authorization checks are not generally performed. From a technical perspective, this is all object types that have an
entry in table T77EO (External Object Types), but no inverse relationship (INREL = < Blank >). For external object
types without an inverse relationship, you can use the general authorization checks for the respective application.
Object ID
In this eld, you can de ne the start object when using evaluation paths.
Maintenance (processing type)
In this eld, you can control whether display or change authorization for the corresponding object set is to be granted.
This eld in table T77PR (De nition of Authorization Pro les ) corresponds to the eld MAINT in table T77FC (PD
Function Codes). All function codes that are coded with X in this eld can be edited.
Evaluation Path
In this eld you can enter a speci c evaluation path to specify that the user can access only objects on this evaluation
path.
When using an evaluation path, a root object must be speci ed for the structure. This root object can either be speci ed
directly in the corresponding eld of table T77PR (De nition of Authorization Pro les) or determined dynamically using a
suitable function module.
The selection of the evaluation paths has a signi cant impact on the overall system performance. Also note the
information on avoiding performance problems under Performance Aspects.
Status Vector
In this eld you can specify which relationships are to be taken into account when setting up the structure. For example,
if you de ne 12 for the status vector, all relationships are evaluated that are active or planned. The choice of the status
vector does not affect the status of the objects. It refers simply to the status of the relationships. The status de ned for
mySAP HR is in table T778S (Plan Status).
Depth (display depth)
In this eld you can specify up to which hierarchy level the user may access a structure.
If you enter the value 0 for the display depth, the corresponding tree is set up completely, meaning that there is no
restriction.
+/- Sign
7/13/2021
In this eld, you can enter the sign - to determine that structural authorization pro les are to be created, which process
the structure "from bottom to top".
If you do not make an entry (default value < Blank > ) or enter the sign +, the structure is processed from top to
bottom as standard.
Period
In this eld you can specify the pro le depending on the validity period of the structure. The options key date, all, and
various periods (current year, current month, and so on) are available.
If, for example, you choose the entry D (current day), the structural authorization extends only to the structures valid on
the respective current day.
If, for example, you de ne a structural authorization for a manager with period D, the manager has access to all persons
currently in their group.
If you do not make an entry (default value < Blank >), there is no restriction other than the validity period of the
structures. If you de ne the period as < Blank > for the pro le, in addition to the access above, the manager also has
authorization for former and future employees.
The eld Period has no in uence on the period for which a user has authorization for a given object, meaning that unlike
for the general authorization check, periods of responsibility are not returned, only the statement whether the user has
authorization for a speci c object.
 Note
The eld Period in the de nition of the structural authorization check has no impact on the time logic of the general
authorization check described under Time Logic. Within the structural authorization, the eld Period is used
exclusively to determine the object set for which authorization is granted or the object set that is transferred to the
general authorization check for further processing. The period of responsibility for the general authorization check is
then determined as described under Flowchart: Example of Period of Responsibility According to Structural
Authorization Check.
For the data in the graphic above, the user has access to different object sets as a result of different values in the eld
Period.
 Example
For the following two examples that refer to graphic 3, it is assumed that the system date is 02/06/2001.
Example 1:
Period: D (= key date)
If the value D is used, the user has access to P2 only, since they only have access to objects in the structure valid on
February 6, 2001 and the relationship between S1 and P1 ends before February 6, 2001.
Example 2:
Period: <BLANK> (= all)
If the value <BLANK> (= all) is used, the user has access to P1 and P2.
Function Module
In this eld you can de ne a function module that determines the root object dynamically at runtime. In this case, no
entry may be made in the eld Object ID. However, the elds Plan Version and Object Type must be speci ed.
The advantage of using the function modules is that de ning a single authorization pro le through the dynamic
determination of the root object at runtime generates a user-speci c pro le.
7/13/2021
If, for example, a manager switches department, the corresponding pro le in table T77PR (De nition of Authorization
Pro les) does not need to be changed. Furthermore, the number of entries in table T77PR can be reduced signi cantly
by using function modules.
In the standard system, 2 function modules are provided:
RH_GET_MANAGER_ASSIGNMENT (Determine Organizational Units for Managers)
If you use this function module, the organizational unit to which the user is assigned as manager via the position
and the relationship A012 ("is manager of") is determined as the root object.
This function module works based on key date, meaning that for a user, only the organizational units to which the
user is assigned as manager on the current system date are determined as the root object
RH_GET_ORG_ASSIGNMENT (Organizational Assignment)
If you use this function module, the organizational unit to which the user is assigned from an organizational
perspective is determined as the root object.
7/13/2021
Assignment of Structural Authorizations
Use
You can use this function to assign structural pro les to users using table T77UA.
Integration
In contrast to general authorization pro les, which are assigned using the Pro le Generator (PFCG transaction), you use table
T77UA ( User Authorizations = Assignment of Pro le to User ) to assign structural pro les.
 Note
You can edit this table in the Implementation Guide (IMG) for Organizational Management under Basic
Settings Authorization Management Structural Authorization Assign Structural Authorization .
Alternatively, you can use the HRBAS00_GET_PROFL Business Add-In (BAdI). This BAdI enables you to implement an alternative
determination of structural pro les.
Activities
You can assign users to structural pro les using table T77UA or transaction OOSB.
The system rst searches for entries for the current user in the T77UA table ( User Assignments ). If one or more entries exist,
the set of objects is mapped according to the pro le de nition. The set of objects is then checked against the concrete object
and the action ( Display or Edit ). The authorization is granted only if the object to be checked exists with the necessary
processing indicator in the set of objects.
 Note
If there is no entry in the T77UA table ( User Authorizations ) for the current user, the above check takes place within the
T77UA table for the entry SAP*. If still no entry exists, the authorization is denied. In the standard system, there is an entry
for user SAP* with the pro le ALL. This means that when you rst implement mySAP HR , all users have complete
authorization as far as structural authorization is concerned
7/13/2021
See also:
HRBAS00_GET_PROFL (BAdI: Determine Assigned Structural Pro les)
Technical Aspects
The following paragraphs explain how you set up general and structural authorizations and provide you with an outline of the
technical aspects of authorizations, in other words, of all the technical objects, checks, and additional setting options that play a
part in setting up these authorization types.
See also:
Authorization Objects
HR: Main Authorization Switch
AUTHC (Authorization Level)
VDSK1 (Organizational Key)
Time Logic
Control Mechanisms (Double Veri cation Principles, Test Procedures, etc.)
Authorization Objects
In certain contexts, you may need several authorizations to perform an operation in theSAPsystem. The resulting contexts can
be very complex. TheSAPauthorization concept has been realized on the basis of authorization objects to provide an
understandable and easy-to-follow procedure. Several system elements that are to be protected form an authorization object.
Authorization objects enable complex checks with multiple conditions for an authorization that allows the user to perform an
action. An authorization object groups up to ten authorization elds that are checked in anANDrelationship.
For an authorization check to be successful, all eld values of the authorization object must be maintained in the user master
data.
Authorization objects are assigned to object classes for purposes of clarity. The authorization objects for mySAP HR belong to
the HR (Human Resources) object class.
You can display or edit the authorization objects and their elds using transaction SU21. You can also use this transaction to
create new object classes and authorization objects.
The authorization objects of the HR (Human Resources) object class have, as with allSAPauthorization objects, up to ten elds
that are read by the system during an authorization check.
The P_ORGIN object ( HR: Master Data ) used in the standardSAPsystem consists of the following elds:
Authorization Field Long Text
7/13/2021
INFTY Infotype
SUBTY Subtype
AUTHC Authorization level
PERSA Personnel area
PERSG Employee group
PERSK Employee subgroup
VDSK 1 Organizational key
INFTY:Infotype number
SUBTY:Subtype number
AUTHC:Authorization level
WERKS:Personnel area
PERSG:Employee group
PERSK:Employee subgroup
VDSK1:Organizational key
You can therefore assign authorizations for HR data in Human Resources at infotype/subtype level according to the employee's
personnel area, employee group, employee subgroup, and organizational key .
The following sections describe the authorization objects for the HR (Human Resources) object class and selected
authorization objects from the BC_A (Basis - Administration) object class that also play an important part inSAPHuman
Resources.
In most cases, the individual elds of the authorization objects are described by means of examples. An exception to this is the
eld that contains the access authorization for an authorization object (normally AUTHC orACTVT). This eld or elds that are
based on a special logic are described in more detail for each authorization object.
Authorization objects for the HR object class:
P_ABAP (HR: Reporting)
P_APPL (HR: Applicants)
P_BEN (HR: Bene t Area)
P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check)
P_CERTIF (HR: Statements)
P_CH_PK (HR-CH: Pension Fund: Account Access)
7/13/2021
P_DBAU_SKV (HR: DBAU: Construction Pay Germany - Social Fund Procedure)
P_DE_BW (HR-DE: Statements SAPScript)
P_DEL_PERN (Deletion of Personnel Numbers in Live Systems)
P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company)
P_HAP_DOC (Appraisal Systems: Appraisal)
P_HRF_INFO (HR: Authorization Check InfoData Maintenance for HR Forms)
P_HRF_META (HR: Authorization Check Master Data Maintenance for HR Forms)
P_NNNNN (HR: Master Data: Customer-Speci c Authorization Object)
P_NNNNNCON (HR: Master Data: Customer-Speci c Authorization Object with Context)
P_OCWBENCH (HR: Activities in the Off-Cycle Workbench)
P_ORGIN (HR: Master Data)
P_ORGINCON (HR: Master Data with Context)
P_ORGXX (HR: Master Data - Extended Check)
P_ORGXXCON (HR: Extended Check with Context)
P_PCLX (HR: Clusters)
P_PCR (HR: Payroll Control Record)
P_PE01 (HR: Authorization for Personnel Calculation Schemas)
P_PE02 (HR: Authorization for Personnel Calculation Rule)
P_PERNR (HR: Master Data - Personnel Number Check)
P_PYEVDOC (HR: Posting Document)
P_PYEVRUN (HR: Posting Run)
P_TCODE (HR Transaction Code)
P_USTR (HR: US Tax Reporter)
PLOG (Personnel Planning)
S_MWB_FCOD (BC-BMT-OM: Allowed Function Codes for Manager's Desktop)
The following authorization objects are also important forSAPHuman Resources:
S_TABU_CLI (Table Maintenance of Cross-Client Tables)
S_TABU_DIS (Table Maintenance (Using Standard Tools Such as SM30))
7/13/2021
S_TABU_LIN (Authorization for Organizational Unit)
S_TMS_ACT (TemSe: Actions on TemSe Objects)
P_ABAP (HR: Reporting)
De nition
Authorization object that is used during the authorization check for HR Reports.
Use
This authorization object is used to:
Run reports in HR Reporting (with reports that are based on the logical databases SAPDBPNP or SAPDBPAP)
Evaluate logged changes in infotype data
Process person-related data using payment medium programs from Accounting
Structure
The P_ABAP authorization object contains the following elds, which are tested during an authorization check:
COARS Degree of Simpli cation of the Authorization Check
REPID ABAP Report Name
More Information About the Fields
Using P_ABAP in HR Reporting:
You can use the relevant authorizations for this object to control how the objects P_ORGIN, P_ORGXX, and the customer-
speci c authorization object P_NNNNN are used in the speci ed reports to check the authorization of HR infotypes. You can
also use reports to control the infotype authorization check. This can be useful for functional reasons or to improve
performance at runtime of the corresponding reports.
For this object, enter the report name(s) in the REPID eld and the degree of simpli cation to be used for the authorization
check in the COARS eld.
The following degrees of simpli cation are possible:
Authorization using COARS = <BLANK> or no authorization. The authorization checks are to be processed as in
Authorization using COARS = 1 . The authorization checks for the infotype/subtype combination and for organizational
assignment are to be checked separately. This means that a user is authorized to read a personnel number when he or
she has a read authorization for all the infotypes (subtypes) requested by the program and that the user has a read
authorization for the organizational assignment of the personnel number.
Authorization using COARS = 2. The authorization check is inactive.
 Note
7/13/2021
Note that an ABAP authorization for report SAPDBPNP with COARS = 2 means that all HR reports based on the logical
databases PNP or PAP (nearly all reports) cannot perform any more authorization checks. In general, you will only want to
deactivate the authorization checks for a very small number of Reports. In case of doubt, do not assign your users
authorizations for the P_ABAP object.
Furthermore, note that this authorization object differs from the object S_PROGRAM ( ABAP: Program Run Checks ). The
latter is used for general program authorization checks. In HR reports, these checks are carried out in addition to the HR
infotype authorization check. HR Reporting, however, overrides the HR infotype authorization check for selected reports,
with the result that the authorization checks are weakened or completely switched off.
Examples:
In your company, the authorization for infotypes is set up independently of the authorization for speci c organizational
units. For example, an administrator is authorized to access address, personal, and education data and is responsible
only for personnel area 0101 . This does mean that the administrator would be authorized to access addresses in
personnel area 0101 and persona data in personnel area 0102 . If you enter 1 in the COARS ( Degree of Simpli cation )
eld, the authorization check takes account of how the authorization has been set up by reading the Reports entered in
the REPID ( Report Name ) eld, and the authorization check for a user with this authorization runs more quickly.
If certain HR reports are not critical (telephone lists and so on) and authorization protection is not required, enter the
report name and * in the Degree of Simpli cation eld. The system then checks the speci ed reports to see whether the
user is authorized to start the report (S_PROGRAM ( ABAP: Program Run Checks ) authorization object), but perform
no other authorization checks.
In your company, one user has access to all HR infotype data. Assign this user an additional authorization for the existing
object by entering* in the REPID and COARS elds Consequently, the system only checks if this user is authorized to
start the report. It does not check whether this user is authorized to display the requested HR infotype data. The fact
that the user has unlimited authorization does not change the results of the authorization check, but does affect the
runtime required to produce the result is authorized to . The reports are processed more quickly.
A time administrator carries out time evaluations using the RPTIME00 report ( HR: Time - Time Evaluation ) for
employees assigned the organizational key 0001TIMEXXX . To obtain certain additional information that is required
internally and that the program user cannot see or can see only partially, the system must read the Basic Pay (0008)
infotype, amongst others, during time evaluation. To be able to carry out time evaluation, the time administrator must
have a display authorization for the Basic Pay (0008) infotype. On the other hand, the user should not have general
display authorization for the Basic Pay (0008) infotype. To restrict the read authorization for the Basic Pay (0008)
infotype for employees with the 0001TIMEXXX organizational key in the RPTIME00 report, use the following
authorizations:
P_ORGIN ( HR: Master Data ) – two authorizations:
INFTY = 0008
SUBTY = *
AUTHC = R
VDSK1 = <Blank>
INFTY = <Blank>
SUBTY = <Blank>
AUTHC = <Blank>
VDSK1 = 0001TIMEXXX
7/13/2021
P_ABAP ( HR: Reporting ):
REPID = RPTIME00
COARS = 1
A simple check is carried out for the infotype authorization check in conjunction with the RPTIME00 report ( HR: Time – Time
Evaluation ): The system independently checks infotype, subtype, and level on the one hand, and organizational assignment (in
the example, the VDSK1 eld ( Organizational Key )) according to degree of simpli cation 1 . The Basic Pay (0008) infotype can
also be read in the RPTIME00 report ( HR: Time – Time Evaluation ).
However, if the check is not in conjunction with the RPTIME00 report ( HR: Time – Time Evaluation ), all elds of the object
P_ORGIN ( HR: Master Data ) are checked together. This check does not result in read authorization for the Basic Pay (0008)
infotype.
Using P_ABAP to evaluate logged changes in infotype data:
Evaluations of the logged changes in infotype data are subject to infotype authorization checks. The person who starts this kind
of evaluation normally has extensive infotype authorizations. In this case, it makes more sense to assign the user a global
authorization using the RPUAUD00 report ( Logged Changes to Information Types Data ) rather than to check individual data.
To do so, use an authorization for the existing object that has the value RPUAUD00 in the REPID eld ( ABAP – Report Names )
and the value 2 in the COARS eld ( Degree of Simpli cation ).
Using P_ABAP to process personal data using payment medium programs in Accounting:
The payment medium programs in Accounting speci cally process extremely sensitive personal data. As an additional security
measure, the system checks whether the user has a corresponding authorization for the existing object and checks whether the
user is authorized to start the program. You must enter the name of the payment medium program in the REPID eld ( ABAP –
Report Names ) and the value 2 (or * ) in the COARS eld ( Degree of Simpli cation ).
P_APPL (HR: Applicants)
De nition
Authorization object that is used during the authorization check of Recruitment infotypes. The checks take place when applicant
infotypes are edited or read.
Structure
The P_APPL authorization object contains the following elds, which are tested during an authorization check:
INFTY Infotype
SUBTY Subtype
AUTHC Authorization Level
PERSA Personnel Area
APGRP Applicant Group
APTYP Applicant Range
VDSK1 Organizational Key
7/13/2021
RESRF Responsible Personnel Officer
The AUTHC eld contains the access mode for the authorization (for example, R = Read). See Authorization Level for a
detailed description of the possible speci cations ( M , R , S , E , D , W , * ) for this eld.
The PERSA , APGRP, APTYP, VDSK1 and RESRF elds are lled from the Organizational Assignment infotype (0001).
Since this infotype has time-dependent speci cations, an authorization may only exist for certain time intervals
depending on the user’s authorization. A user’s period of responsibility is represented by all the time intervals for which
he or she has P_APPL authorizations (see also Example of the Period of Responsibility Using P_ORGIN ).
 Note
Unlike the P_ORGIN and P_ORGXX authorization objects, the check on this authorization object cannot, in principle, be
deactivated (that is, there is no corresponding authorization main switch ).
P_BEN (HR: Bene t Area)
De nition
Authorization object that is used during the authorization check for bene ts. This check takes place when bene t tables are
edited or read.
Structure
The P_BEN authorization object contains the following elds, which are tested during an authorization check:
PBEN_AREA Bene t Area
ACTVT Activity
The ACTVT eld contains the activities for bene ts that are possible as part of the authorization check. The eld can have the
following values:
02: : Change
03: : Display
P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check)
De nition
Authorization object that is used during the authorization check for task type and task level in the Time Sheet for Service
Providers.
Use
The P_CATSXT authorization object is used for the following checks in the CATSXT and CATSXT_ADMIN transactions:
7/13/2021
Fill the Drop Down F4 Help for task type and level
Request data records from the history for editing, copying or deleting
Save and check new/changed data records
You can use this object to restrict the task types and levels that employees can use in time recording according to different
organizational perspectives.
Structure
The P_CATSXT authorization object contains the following elds, which are tested during an authorization check:
CATS_AUTHP Personnel Number Check
TASKLEVEL Task Level
TASKTYPE Task Type
BUKRS Company Code
KOSTL Cost Center
PERSG Employee Group
PERSK Employee Subgroup
ORGEH Organizational Unit
ACTVT Activity
The CATS_AUTHP eld contains the processing mode that is permitted for the authorization check. The following values
are possible:
E: : Processing your own personnel ID
O: : Processing a different personnel ID
 Note
To determine your own personnel ID, infotype 105 must be de ned in the system.
The ACTVT eld contains the permitted activities. The following values are possible:
01: : Add (currently not used)
02: : Change (edit or copy data from the history)
03: : Display (currently not used)
06: : Delete (delete data from history)
7/13/2021
71: : Evaluate (currently not used)
P_CERTIF (HR: Statements)
De nition
Authorization object that is used in Statements to check which tasks an administrator is authorized to perform.
Use
This object is used only in Statements. Only edit this authorization object if you have rst set up statements without SAPScript.
If you use statements with SAPScript, you must use the P_DE_BW authorization object. This object is used in screen control and
in report creation.
In screen control, this object determines whether an administrator is authorized to perform a certain task.
In report creation, this object determines whether an administrator is authorized to make changes when displaying statements
that have already been created (this corresponds to individual creation).
Structure
The P_CERTIF authorization object contains the following elds, which are tested during an authorization check:
MOLGA Country Grouping
BESNR Statement Number
The MOLGA eld de nes the countries for which an administrator is authorized to process statements. The countries
must correspond to the country modi er.
The BESNR eld de nes which statements an administrator is authorized to access using a number interval. The
speci ed numbers must correspond to the existing statements.
The AUTHC eld contains the access mode for the authorization (for example, Display). The following values are
possible:
E: : Create statements using the Single Record Entry option
S: : Create statements using the Fast Entry option
A: : Display statements using the Print Statement option
D: : Print statements using the Print Statement option
L: : Delete statements using the Print Statement option
F: : Release statements using the Print Statement option
Example
7/13/2021
You want to assign an administrator the following authorizations:
Create all German statements
Delete all German statements between 1 and 10
Display and print all Austrian statements
De ne three authorizations and group these into one pro le. Assign this pro le to the administrator by user assignment.
Authorization Country Grouping Statement Number Authorization Level
P_CRF_ALD 01 * ES
P_CRF_TENLD 01 01-10 L
P_CRF_DRUA 03 * AD
P_CH_PK (HR-CH: Pension Fund: Account Access)
De nition
Authorization object that is used during the authorization check for access to pension fund accounts (PF Accounts). This check
takes place in transactions or reports that process account data.
Structure
The P_CH_PK authorization object contains the following elds which, are tested during an authorization check:
KONNR Number of Individual PF Account
AUTGR HR-CH: Authorization for PF Accounts
PKKLV HR-CH: Pension Fund: Authorization Level for Account Access
The KONNR eld speci es which pension fund accounts an administrator is authorized to access.
The AUTGR eld speci es the permissible authorization groups for the authorization check.
The PKKLV eld speci es which operations (authorization level) the user is authorized to perform in pension fund
accounts. The following values are possible:
-: : No Access
R: : Read authorization
W: : Write authorization
X: : Extended authorization (for example, offsetting entries for postings or changing the lock date)
P_DBAU_SKV (HR: DBAU: Construction Pay Germany – Social Fund Procedure)
7/13/2021
De nition
Authorization object that is used exclusively in Construction Pay Germany for reports on the Social Fund Procedure.
Use
This authorization object determines which reports with which parameters or which processing steps an administrator is
allowed to run or carry out.
The RPCBLFD0 report ( Construction Pay: Evaluations of the Social Fund Procedure ) de nes which activities an administrator
is allowed to perform:
Display posting runs already created
Create new posting runs
Delete the last posting run to be carried out
Structure
The P_DBAU_SKV authorization object contains the following elds, which are tested during an authorization check:
REPID ABAP Report Name
ZVKAS Social Fund
RZNUM Data Processing Center Number for Constr.Ind.SI Fund
ACTVT Activity
The REPID eld contains the name of a report that is used to check an authorization object, for example the evaluation
report for the social fund procedure. A granted authorization refers, however, only to this report.
The ZVKAS eld speci es the social funds for which a granted authorization should be valid.
The RZNUM eld speci es the data processing center number that a granted authorization should refer to.
The AUTHC eld contains the activity for the authorization (for example, Display). The following values are possible:
01: : Add or Create
03: : Display
06: : Delete
Example
An administrator should have the following authorizations regarding the evaluation report for the social fund procedure:
Display posting runs already created
Create all posting runs for social fund 02
7/13/2021
Delete a posting run of the 02 social fund for the data processing center number 12345678 (providing the posting run is
the last posting run to have been created).
De ne three authorizations and group these into one pro le. Assign this pro le to the administrator by user assignment:
Authorization Report Name Social Fund Data Center Activity
P_DBAU_SKV_A RPCBLFD0 * * 03
P_DBAU_SKV_E RPCBLFD0 02 * 01
P_DBAU_SKV_L RPCBLFD0 02 12345678 06
P_DE_BW (HR-DE: Statements SAPScript)
De nition
Authorization object that enables you to determine the authorization check within statements (with SAPScript) for Payroll
Germany.
Use
Only edit this authorization object if you have rst set up statements with SAPScript. You can do this as of Release 4.6B.
If you use statements without SAPScript, you must use the P_CERTIF (HR: Statements) authorization object.
Structure
The P_DE_BW authorization object contains the following elds, which are tested during an authorization check:
BEWID Statement Identi er
BSUBJ InfoSet Identi cation for Statements
BACT Activities for Statements in Authorization Check
The BEWID eld contains the statement identi er for statements in Payroll Germany that should be tested during an
authorization check.
The BSUBJ eld contains the functional area identi cation (ID) for statements. The functional area represents a logical
breakdown of the statements according to individual subject areas. Note that you can de ne the access using the
parameter ID (PID or user parameter) BSUBJ . By prede ning the values for a function area, the correct authorization is
used when you call up the application for the rst time.
 Example
The administrator only has authorization for functional areas 03 and 04. In this case, the BSUBJ user parameter must be set
as one of the two values. The administrator is therefore only authorized to navigate within these two functional areas.
7/13/2021
If an administrator has authorization for all functional areas, the user parameters can only be used to simplify coordination
since the initial access branches directly to this functional area.
You can con gure up to 30 functional areas.
The BACT eld contains the activities for statements that are valid as part of the authorization check. The following
values are possible:
E: : Creation of statements
A: : Asynchronous archiving
S: : Fast entry/Ad Hoc Query
V: : Administration of archived statements
P_DEL_PERN (Deletion of Personnel Numbers in Live Systems)
De nition
Authorization objectfor the complete deletion of personnel numbers in live systems. As this should occur only in exceptional
cases, a double veri cation principle is implemented for this special authorization.
The authorization object is used by two roles: one that requests the deletion of the data and one that performs the actual
deletion of the data. These roles must be assigned to two different users.
Use
The authorization object is used in the RPUDELPP report.
Structure
The authorization object contains the eld PAYDELROLE . The two roles are de ned using the domain
HRPAD_DELETE_PERNR_ROLE (associated data element HRPAD_DELETE_PERNR_ROLE ).
01 : Request to Delete Personnel Numbers
02 : Execution of Permanent Deletion of Personnel Numbers
P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company)
De nition
Authorization object that is used during authorization checks for PBS companies.
Structure
The P_DK_PBS authorization object contains the following eld which is tested during an authorization check:
PBSFIRMA HR_DK: Company Used for PBS
7/13/2021
P_HAP_DOC (Appraisal Systems: Appraisal)
De nition
Authorization object that controls users’ access to forms.
Use
In addition to assigning authorization for forms, you can also use this authorization object to restrict the structural
authorizations, which control authorization access within the organizational structure. You do so by de ning for which part of
the organizational structure the user should only have read authorization and for which part he or she should also have write
authorization. This enables you, for example, to de ne that the person responsible for the personnel area Recruiting can
change the appraisals of his or her own employees but only display those of the employees in the other personnel area.
Structure
The P_HAP_DOC authorization object contains the following elds, which are tested during an authorization check:
ACTVT Activity
PLVAR Plan Version
HAP_CAT_G Appraisal Category Group ID
HAP_CAT Appraisal Category ID
HAP_TEMPL Appraisal Form
PROFL Authorization Pro le
TheACTVT eld speci es the activities for which a user has authorization. The following values are possible:
02:Change
03:Display
06:Delete
ThePLVAR eld speci es which plan version(s) the user is authorized to access.
TheHAP_CAT_G eld speci es that the user is only authorized to access forms of the category group(s) entered here.
TheHAP_CAT eld speci es that the user is only authorized to access forms of the category(ies) entered here.
TheHAP_TEMPL eld speci es that the user is only authorized to access the form(s) entered here.
ThePROFL eld speci es which target object(s) a user has access to by entering a structural pro le. This enables you to
determine, for example, that a user has change authorization for the forms of all employees in his or her department and
display authorization for the forms of all other employees.
Integration
7/13/2021
Note that you can only enter structural pro les that are assigned to the user in table T77UA ( User Authorizations =
Assignment of Pro le to User ) in thePROFL eld.
If you use the HRBAS00_GET_PROFL (BAdI: De ne Assigned Structural Pro les) Business Add-In (BAdI), you do not have to
maintain the entries in table T77UA. This BAdI enables you to implement an alternative determination of structural pro les.
See also:
P_HRF_INFO (HR: Authorization Check InfoData Maintenance for HR Forms)
De nition
Authorization object that is used during the authorization check for the processing of infotypes for HR Forms .
Structure
The P_HRF_INFO authorization object contains the following elds, which are tested during an authorization check:
P_HRF_INET HR Forms: InfoNet
ACTVT Activity
The ACTVT eld contains the activities for the InfoData maintenance of HR Forms that are possible as part of the authorization
check. This eld can have the following values:
02: : Change
03: : Display
P_HRF_META (HR: Authorization Check Master Data Maintenance for HR Forms)
De nition
Authorization object that is used during the authorization check for HR Forms .
You can carry out different actions in the HR Forms application. You can use this authorization object to restrict the actions a
user can carry out.
Structure
The P_HRF_META authorization object contains the following elds, which are tested during an authorization check:
7/13/2021
P_HRF_TYP HR Forms: Object Type
P_HRF_MOBJ HR Forms: MetaData Object
ACTVT Activity
The ACTVT eld contains the activities for the MetaData maintenance of HR Forms that are possible as part of the
authorization check. This eld can have the following values:
02: : Change
03: : Display
De nition
Authorization object that does not yet exist in the system and that is created by you.
Use
If you have requirements that cannot be met using the P_ORGIN and P_ORGXX authorization objects (for example, because you
want to build your authorization checks on additional elds of the Organizational Assignment infotype (0001) that are
customer-speci c), you can include an authorization object in the authorization checks yourself.
Structure
A customer-speci c authorization object must contain the following elds:
INFTY Infotype
SUBTY Subtype
You can use any of the elds in the Organizational Assignment infotype (0001) or in the PA0001 structure. You can also use
customer-speci c additional elds as long as they are CHAR or NUMC type elds.
In addition, you can use the following elds:
TCD : This eld is always lled with the current transaction code ( SY-TCODE ). Note that when you use this authorization
object in reports, the TCD eld is lled with the name of the transaction that calls up the report and not with the report
name.
INFSU : This eld is 8 characters long. The rst 4 characters contain the infotype, the last 4 characters the subtype.
 Note
7/13/2021
The system determines the period of responsibility for this object analogously to the P_ORGIN and P_ORGXX objects.
For more information, see Example of Period Determination Using P_ORGIN .
See also:
Creating a Customer-Speci c Authorization Object

Procedure
1. To create the authorization object, choose the SU21 transaction.
2. First double-click an object class to select it, for example HR ( Human Resources ).
3. Then choose Create on the following screen (F5). To be able to use the new authorization object you have created in the
master data authorization check, the object must contain the following elds:
INFTY: Infotype
SUBTY: Subtype
AUTHC: Authorization Level
If you want to use the authorization object for the context authorization check , it must also contain the PROFL
eld, which de nes the structural pro les a user is authorized to access.
You can use any of the elds in the Organizational Assignment infotype (0001) or in the PA0001 structure for the
rest of the elds. You can also use customer-speci c additional elds provided they are CHAR or NUMC type
elds.
TCD: This eld is always lled with the current transaction code ( SY-TCODE ). Note that when you use this
authorization object in reports, the TCD eld is lled with the name of the transaction that calls the report and
not with the report name.
INFSU: This eld is 8 characters long. The rst 4 characters contain the infotype, the last 4 characters the
subtype.
4. After you have created the authorization object, start the RPUACG00 report. This report overwrites the MPPAUTZZ
standard include with the code that is needed to evaluate the authorization object you created. Note: Technically
speaking, this involves a modi cation. However, SAP fully supports this procedure. And you should not have more
maintenance work as a result of this modi cation. To ensure that the report actually writes the program code, deselect
the Test eld. Enter your user as the password.
5. Activate your checks by switching the appropriate authorization main switch, NNNNN or NNCON to 1 .
See also:
P_NNNNNCON (HR Master Data: Customer-Speci c Authorization Object with Context)
P_NNNNNCON (HR Master Data: Customer-Speci c Authorization Object with

Context)
7/13/2021
Use
If you have requirements that cannot be mapped using the P_ORGINCON and P_ORGXXCON authorization objects (for example,
because you want to build your authorization checks on additional elds of the Organizational Assignment infotype (0001) that
are customer-speci c) and if you want to implement the context solution , you can include an authorization object in the
authorization checks yourself.
In the standard system, the check of this object is not active. You can use the AUTSW NNCON authorization main switch to
control the use of the customer-speci c authorization object.
Structure
A customer-speci c authorization object for the context solution must contain the following elds:
INFT Y Infotype
SUBT Y Subtype
AUTH C Authorization Level
PROF L Authorization Pro le
The PROFL eld is used to determine which structural pro les the user is authorized to access. Note that you can only enter
structural pro les that are assigned to the user in table T77UA ( User Authorizations = Assignment of Pro le to User ) in this
eld.
 Note
If you use the HRBAS00_GET_PROFL (BAdI: De ne Assigned Structural Pro les) Business Add-In (BAdI), you do not have to
maintain the entries in table T77UA. This BAdI enables you to implement an alternative determination of structural pro les.
You can use any of the elds in the Organizational Assignment infotype (0001) or in the PA0001 structure for the rest of the
elds. You can also use customer-speci c additional elds as long as they are CHAR or NUMC type elds.
TCD : This eld is always lled with the current transaction code ( SY-TCODE ). Note that when you use this
authorization object in reports, the TCD eld is lled with the name of the transaction that calls the report and not with
the report name.
INFSU : This eld is 8 characters long. The rst 4 characters contain the infotype, the last 4 characters the subtype.
To create a customer-speci c authorization object, you can use the RPUACG00 report.
 Note
Note that if you use customer-speci c authorization objects, you must maintain these objects in transaction SU24 in the
same way as you maintain the authorization objects P_ORGIN ( HR: Master Data ), P_ORGXX ( HR: Master Data – Extended
Check ), and P_PERNR ( HR: Master Data – Check by Personnel Number ).
See also:
7/13/2021
Context Authorization Check
P_OCWBENCH (HR: Activities in the Off-Cycle Workbench)
De nition
Authorization object that is used during the authorization check for the off-cycle workbench. The P_OCWBENCH authorization
object ensures that each administrator sees only the off-cycle activities that he or she is authorized to perform.
Structure
The P_OCWBENCH authorization object contains the following eld which is tested during an authorization check:
P_OCTYP Type of Off-Cycle Activity
The P_OCTYP eld contains the activities for the off-cycle workbench that are possible as part of the authorization check. The
eld can have the following values:
OC: : Run Off-Cycle Payroll
HI: : Display History
PR: : Replace Payment
AC: : Assign Check Number
PV: : Reverse Payment
De nition
Authorization object that is used during the authorization check for HR infotypes. The check takes place when HR infotypes are
edited or read.
Structure
P_ORGIN contains the following elds, which are tested during an authorization check:
INFTY Infotype
SUBTY Subtype
7/13/2021
VDSK1 Organizational Key
The AUTHC eld contains the access mode for the authorization (for example, R = Read). See AUTHC (Authorization
Level) for a detailed description of the different authorization levels possible ( M , R , S , E , D , W , * ).
The VDSK1 eld is used in several authorization objects and is therefore described in detail in VDSK1 (Organizational
Key) .
The PERSA , PERSG , PERSK, and VDSK1 elds are lled from the Organizational Assignment infotype (0001). Since this
infotype has time-dependent speci cations, an authorization may only exist for certain time intervals depending on the
user’s authorization.
 Note
The time dependency of infotypes is stored in table T582A ( Infotypes – Customer-Speci c Settings ) in the VALDT eld.
A user’s period of responsibility is represented by all the time intervals for which he or she has P_ORGIN authorizations.
See also:
Example of Period Determination Using P_ORGIN
Authorization check using P_ORGIN for:
INFTY = 0014
SUBTY = M120
AUTHC = R
The data available in the Organizational Data infotype (0001):
01.01.2000 – 12.31.2000: 01.01.2001 – 12.31.2001: 01.01.2002 – 12.31.9999:
PERSA = DE01 PERSA = US01 PERSA = DE01
PERSG = 1 PERSG = 1 PERSG = 1
PERSK = DA PERSK = DA PERSK = DB
VDSK1 = 42 VDSK1 = 42 VDSK1 = 42
The user’s authorizations available in the user master record:
INFTY = 0014
SUBTY = M120
AUTHC = R
7/13/2021
PERSA = DE01
PERSG = 1
PERSK = *
VDSK1 = *
as well as
INFTY = 0015
SUBTY = *
AUTHC = *
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
The following authorization checks are performed by the system:
For the period January 1, 2000 – December 31, 2000:
INFTY = 0014
SUBTY = M120
AUTHC = R
PERSA = DE01
PERSG = 1
PERSK = DA
VDSK1 = 42
Due to the rst authorization in the user master record, the authorization check is successful. The period belongs to the period
of responsibility.
INFTY = 0014
SUBTY = M120
AUTHC = R
PERSA = US01
PERSG = 1
7/13/2021
PERSK = DA
VDSK1 = 42
The rst authorization in the user master record denies access to PERSA = US01 , the second denies access to INFTY = 0014 .
The authorization check is unsuccessful and the period does not belong to the period of responsibility.
INFTY = 0014
SUBTY = M120
AUTHC = R
PERSA = DE01
PERSG = 1
PERSK = DB
VDSK1 = 42
Due to the rst authorization in the user master record, the authorization check is successful. The period belongs to the period
of responsibility.
Result
In this example, the period of responsibility consists of the periods January 1, 2000 – December 31, 2000 and January 1, 2002 –
December 31, 9999 .
P_ORGINCON (HR: Master Data with Context)
De nition
Authorization objectthat is used during the authorization check for HR data. This check takes place when HR infotypes are
edited or read.
Use
You can map user-speci c contexts in HR Master Data using P_ORGINCON.
In the standard system, the check of this object is not active. You can use the AUTSW INCON authorization main switch to
control the use of P_ORGXXCON.
Structure
The P_ORGINCON authorization object consists of the same elds as P_ORGIN and also contains the PROFL eld:
INFTY Infotype
SUBTY Subtype
7/13/2021
VDSK 1 Organizational Key
The VDSK1 (Organizational Key) eld enables you to run diverse authorization checks by organizational assignment
(using theP_ORGINCON authorization object). The content of the organizational key is either derived by the system from
the elds of the Organizational Assignment infotype (0001) or entered manually by the user.
The PERSA , PERSG , PERSK, and VDSK1 elds are lled from the Organizational Assignment infotype (0001). Since this
infotype has time-dependent speci cations, an authorization may only exist for certain time intervals depending on the
user’s authorization.
 Note
The time dependency of infotypes is stored in table T582A ( Infotypes – Customer-Speci c Settings ) in the
VALDT field.
All the time intervals for which a user has P_ORGINCON authorizations constitute a user’s period of responsibility.
The PROFL eld is used to determine which structural pro les the user is authorized to access. Note that you can only
enter structural pro les that are assigned to the user in table T77UA ( User Authorizations = Assignment of Pro le to
User ) in this eld.
 Note
If you use the HRBAS00_GET_PROFL (BAdI: De ne Assigned Structural Pro les) Business Add-In (BAdI), you do not
have to maintain the entries in table T77UA. This BAdI enables you to implement an alternative determination of
structural pro les.
See also:
Context Solution
P_ORGXX (HR: Master Data – Extended Check)
De nition
Authorization object that is used during the authorization check for HR infotypes. The check takes place when HR infotypes are
edited or read.
Structure
P_ORGXX contains the following elds, which are tested during an authorization check:
7/13/2021
INFTY Infotype
SUBTY Subtype
SACHA Payroll Administrator
SACHP Master Data Administrator
SACHZ Time Recording Administrator
SBMOD Administrator Group
The SACHA , SACHP , SACHZ , and SBMOD elds are lled from the Organizational Assignment infotype (0001). Since
this infotype has time-dependent speci cations, an authorization may only exist for certain time intervals depending on
the user’s authorization. A user’s period of responsibility is represented by all the time intervals for which he or she has
P_ORGXX authorizations.
See also:
P_ORGXXCON (HR: Extended Check with Context)
De nition
Authorization objectthat is used during the authorization check for HR infotypes. The check takes place when HR infotypes are
edited or read.
Use
You can map user-speci c contexts in HR Master Data using P_ORGXXCON.
In the standard system, the check of this object is not active. You can use the AUTSW XXCON authorization main switch to
control the use of P_ORGXXCON.
Structure
The P_ORGXXCON authorization object consists of the same elds as P_ORGXX and also contains the PROFL eld:
INFTY Infotype
SUBTY Subtype
SACHA Payroll Administrator
7/13/2021
SACHP Master Data Administrator
SACHZ Time Recording Administrator
SBMOD Administrator Group
The SACHA , SACHP , SACHZ , and SBMOD elds are lled from the Organizational Assignment infotype (0001). Since
this infotype has time-dependent speci cations, an authorization may only exist for certain time intervals depending on
the user’s authorization. All the time intervals for which a user has P_ORGXXCON authorizations constitute a user’s
period of responsibility.
The PROFL eld is used to determine which structural pro les the user is authorized to access. Note that you can only
enter structural pro les that are assigned to the user in table T77UA ( User Authorizations = Assignment of Pro le to
User ) in this eld.
 Note
If you use the HRBAS00_GET_PROFL (BAdI: De ne Assigned Structural Pro les) Business Add-In (BAdI), you do not
have to maintain the entries in table T77UA. This BAdI enables you to implement an alternative determination of
structural pro les.
See also:
Context Solution
De nition
Authorization object that is used during the authorization check when thePCLx HR les (x = 1, 2, 3, 4) are accessed using the
PCLx buffer (interface supported by HR).
Structure
The P_PCLX authorization object contains the following elds, which are tested during an authorization check:
RELID Area Identi er for Clusters in Tables
The possible values for the eld RELID are stored in the value table T52RELID ( HR: Description of Clusters in PCLx
Tables ) for the domain RELID_PCL .
7/13/2021
The AUTHC eld contains the activity for the authorization but uses a different logic for P_PCLX than for other
authorization objects. The following values are possible:
R : Read
U : Write (update) - this includes the authorizations of authorization level S but not authorization level R
S : Write data to internal buffer but not to database (simulation)
P_PCR (HR: Payroll Control Record)
De nition
Authorization object that is used during the authorization check for payroll control record.
Use
This check takes place when the control record is displayed using transaction PA03, or when the control record is maintained.
The check also takes place during maintenance using the payroll menu.
Structure
The P_PCR authorization object contains the following elds, which are tested during an authorization check:
ABRKS Payroll Area
ACTVT Activity
01: : Add or Create
02: : Change
03: : Display
06: : Delete
P_PE01 (HR: Authorization for Personnel Calculation Schemas)
De nition
Authorization object that is used during the authorization check for personnel calculation schemas.
Structure
The P_PE01 authorization object contains the following eld, which is tested during an authorization check:
7/13/2021
P_AUTHPE01 HR Schema: Authorization
P_PE02 (HR: Authorization for Personnel Calculation Rule)
De nition
Authorization object that is used during the authorization check for personnel calculation rules.
Structure
The P_PE02 authorization object contains the following eld, which is tested during an authorization check:
P_AUTHPE02 Personnel Calculation Rule: Authorization
P_PERNR (HR: Master Data – Personnel Number Check)
De nition
Authorization object that is used to assign users different authorizations for accessing their own personnel number. These
authorizations differ from those de ned in users’ P_ORGIN pro les. If this check is active and the user has been assigned a
personnel number in the system, it can directly override all other checks with the exception of the test procedures. This check
does not take place if the user has not been assigned a personnel number, or if the user accesses a personnel number other
than his or her own.
 Note
You can assign a user a personnel number using infotype 0105, subtype 0001 (in earlier releases using the V_T513A view).
Structure
The P_PERNR authorization object contains the following elds, which are tested during an authorization check:
PSIGN Interpretation of Assigned Authorization
INFTY Infotype
SUBTY Subtype
The PSIGN eld ( Interpretation of Assigned Authorization ) can have the following values:
I: : include (for additional authorizations)
E: : exclude (for authorizations that are to be removed)
7/13/2021
Example
The authorization checks for P_ORGIN and P_PERNR are activated in the system. In addition, there are user assignments for
some personnel numbers.
The user in our example is assigned a personnel number and is administrator responsible for the Basic Pay infotype (0008) of a
personnel area (that is, the user has the corresponding P_ORGIN authorization). The employee should also be able to display
his or her own data but not change his or her basic pay, irrespective of the personnel area for which the employee is responsible.
The corresponding authorizations for the P_PERNR authorization object must be set up as follows:
AUTHC = R , M
PSIGN = I
INFTY = *
SUBTY = *
AUTHC = W , S , D , E
PSIGN = E
INFTY = 0008
SUBTY = *
The rst authorization grants the employee read authorization for all infotypes that are stored under the employee’s personnel
number. The second authorization denies write authorization for all data records of the Basic Pay infotype (0008) stored under
the employee’s personnel number.
The authorization checks for all other personnel numbers and for write authorizations for all infotypes (except Basic Pay
(0008)) run according to P_ORGIN.
 Caution
As the following examples illustrate, inconsistent authorizations can be granted.
Example 1:
AUTHC = *
PSIGN = I
INFTY = 0014
SUBTY = M*
AUTHC = W , S , D , E
PSIGN = E
INFTY = 0014
SUBTY = *
7/13/2021
The rst authorization grants the employee read authorization ( AUTHC = R ) for the Recurrent Payments/Deductions
infotype (0014), subtype M120 , which allows the employee to access the data stored under his or her personnel number. In
this case, the second authorization is irrelevant.
The rst authorization grants the employee write authorization ( AUTHC = W ) for the Recurrent Payments/Deductions
infotype (0014), subtype B030 , which denies the employee access to the data stored under his or her personnel number. In
this case, the rst authorization is irrelevant.
The rst authorization grants the employee write authorization for the Recurrent Payments/Deductions infotype (0014),
subtype M120 , the second authorization denies the employee this authorization. The desired system response is unclear
from this example. According to the documentation, the system response is unde ned in such situations. In reality, the
authorization check always denies authorization in unclear situations, that is E is stronger than I and therefore the
authorization is not granted.
Example 2:
AUTHC = *
PSIGN = *
INFTY = *
SUBTY = *
This type of authorization is required by superusers with unlimited access, for example. The above authorization is
appropriate if an employee wants to access an infotype. However, since PSIGN = * and * can be substituted for any value,
PSIGN and E can also be interpreted as I . This can also lead to an unde ned situation. In earlier releases, the authorization
was denied on the basis of the rule E is stronger than I . This meant that superusers with assigned personnel numbers were
not able to access their own personnel number. The programs have since been changed and now * is interpreted as I and is
stronger than E . In other words, * is stronger than E and E is stronger than I , whereby * is interpreted as I .
As already indicated in Example 1, the combination of different authorizations can produce a complicated result. We
therefore recommend that you avoid combinations where P_PERNR authorizations can be interpreted differently for the
same combination of AUTHC ( Authorization Level), INFTY ( Infotype) and SUBTY ( Subtype ).
Misunderstandings arising from the complex situations described above are not the most frequent causes of customer
inquiries, however. The most frequent cause is the incorrect assumption that authorizations by personnel number affect
authorizations for non-assigned personnel numbers. This is not the case at all.
If you use authorizations by personnel number, you should always rst set up all non-personnel number-related
authorizations. As soon as you have done this, you should create different access authorizations for the personnel numbers
that are assigned to users using appropriate P_PERNR authorizations. This is always possible since the P_PERNR
authorizations override all other authorizations directly (except Test Procedures ).
P_PERNR authorization checks cannot bypass test procedures directly. For instance, a test procedure is only carried out on
the Recurring Payments/Deductions infotype (0014) if a corresponding P_PERNR authorization (with PSIGN = I ) exists. If
an appropriate authorization for the corresponding subtype of the infotype 0130 exists, it can be used effectively to carry out
the test procedures.
P_PYEVDOC (HR: Posting Document)
De nition
7/13/2021
Authorization object that is used to protect actions on posting documents.
Structure
The P_PYEVDOC authorization object contains the following elds, which are tested during an authorization check:
BUKRS Company Code
ACTVT Activity
The ACTVT eld contains the activities for posting documents that are possible as part of the authorization check. The ACTVT
eld can have the following values:
03: : Display
10: : Post
28: : Display Line Item
43: : Release
P_PYEVRUN (HR: Posting Run)
De nition
Authorization object that is used during the authorization check for posting runs.
Structure
The P_PYEVRUN authorization object contains the following elds, which are tested during an authorization check:
P_EVTYP Run Type
P_EVSIMU Posting Run: Simulation Indicator
ACTVT Activity
The P_EVTYP eld contains the run type that is to be tested during the authorization check. The following values are
possible:
PP: : Payroll Posting
TP: : Posting Third-Party Remittance
AP: : Posting Tax/SI Austria
The P_EVSIMU eld speci es whether the authorization check should be carried out for simulation or live runs.
7/13/2021
01: : Add or Create
03: : Display
06: : Delete
10: : Post
85: : Reverse
P_TCODE (HR: Transaction Code)
De nition
Authorization object that is used to check whether a user is authorized to start the different HR transactions. The transaction
code is checked.
Use
The P_TCODE authorization object is not used in all HR transactions. We distinguish between:
HR transactions with natural (own) authorization objects, such as persons (employees, applicants), statements, or
similar.
In transactions of this type, these natural authorization objects ( HR: Master Data, HR: Applicants, and HR: Statements ) are
used for the check. When a user starts a transaction, the system uses the same object to check minimum authorizations. For
example, a user must have at least a read authorization to be able to edit employee data, that is R in the Authorization Level
eld of the HR: Master Data object.
HR transactions without natural authorization objects, such as processing system settings (cycles, features) and
personnel control records, and so on.
In transactions of this type, differentiated authorization checks do not take place: The system only checks whether or not the
user is authorized to start the transaction. These HR transactions are protected by the HR: Transaction Codes check object.
You can nd a list of these transactions as follows:
1. Choose Tools ABAP Workbench Development Other Tools Transactions .
2. Then choose Utilities Find and nally Edit All Selections .
3. Enter P* as the transaction code in the Transaction eld.
4. Enter the authorization object P_TCODE in the Test Object eld.
5. Choose Program Execute .
Structure
The P_TCODE authorization object contains the following eld, which is tested during an authorization check:
TCD Transaction Code
7/13/2021
Integration
You can also use authorizations for the S_TCODE authorization object ( Check Transaction Code at Start of Transaction ) to
protect the HR transactions. In this context, note that the P_TCODE authorization object was implemented before the S_TCODE
authorization object. The P_TCODE authorization object was maintained as an additional protection measure given the
increased need for the protection of person-related data.
P_USTR (HR: US Tax Reporter)
De nition
Authorization object that is used during the authorization check for simulation and update runs of the US Tax Reporter
(Transaction PU19).
Use
To carry out simulation or update runs of the US Tax Reporter , you must enter the authorization to add or create ...(value 01 –
see below) using the P_USTR authorization object.
Structure
The P_USTR authorization object contains the following elds, which are tested during an authorization check:
ACTVT Activity
BTRTL Personnel Subarea
You specify the tax company that you want to perform the authorization check of the US Tax Reporter for using the elds
PERSA and BTRTL .
Enter the activities that you want to assign authorizations for using the ACTVT eld. The following values are possible:
01: : Add or Create
03: : Display
06: : Delete
PLOG (Personnel Planning)
De nition
Authorization object that is used to check the authorization for speci c elds in the Personnel Management components (
Organizational Management, Personnel Development, Training and Event Management , ...).
Structure
The PLOG authorization object contains the following elds, which are tested during an authorization check:
7/13/2021
PLVAR Plan Version
OTYPE Object Type
INFOTYP Infotype
SUBTYP Subtype
ISTAT Planning Status
PPFCODE Function Code
The PLVAR eld speci es which plan version(s) the user is authorized to access.
The OTYPE eld speci es which object types the user is authorized to access.
The INFOTYP eld speci es which infotypes the user is authorized to access.
The SUBTYP eld speci es which subtypes of given infotypes the user is authorized to access.
The ISTAT eld speci es the planning status in which the user is authorized to access information.
The PPFCODE eld speci es the processing mode for which the user has authorization (Display, Change and so on).
Integration
If you use the PLOG authorization object, you must also set up a structural authorization pro le for the user. Users of the
Personnel Management components ( Organizational Management, Personnel Development, Training and Event Management ,
...) can access data only if they have a pro le for the PLOG authorization object and a structural authorization pro le.
A structural authorization pro le is also necessary if you do not want to limit users’ access authorization by the structural
authorization check. If this is the case, you must assign the user a structural pro le that grants the user access to the whole
structure.
For more information, see De nition of Structural Authorizations .
S_MWB_FCOD (BC-BMT-OM: Allowed Function Codes for Manager’s Desktop)
De nition
Authorization Object that is used to restrict the actions a user can carry out in the Manager’s Desktop application.
Structure
The S_MWB_FCOD authorization object contains the following eld, which is tested during an authorization check:
MWBFCODE Function Code
The MWBFCODE check eld refers to table T77MWBFCD ( Function Codes for Manager’s Desktop ).
7/13/2021
Cross-Application Authorization Objects

See the following for a description of additional authorization objects that are also important for SAP Human Resources:
De nition
Authorization objectthat is used to assign authorization for the maintenance of cross-client tables.
Use
This authorization object enables you to protect cross-client tables from unintentional accesses. Therefore, you can also use
this authorization object to enhance the general table maintenance authorization using S_TABU_DIS .
Structure
The object consists of the following eld:
CLIIDMAINT Indicator for cross-client maintenance
The CLIIDMAINT eld can take on the value X to grant a user authorization to maintain cross-client tables in general.
De nition
Authorization object that is used to check the authorization for displaying and maintaining table contents. This object controls
users’ access to data only if they access the data using Standard Table Maintenance (transaction SM31), Extended Table
Maintenance (SM30), the Data Browser or through Customizing.
Use
You can use this authorization object to limit users’ access authorization so that, for example, users with authorization for the
se16 transaction (that is, for all Data Dictionary objects) can only access data of the table entries de ned using this
authorization object. You can also deny system administrators speci c access to application data, for example. As soon as you
have set up this authorization object, you can edit or change only the table entries for which corresponding authorization has
been granted explicitly by S_TABU_DIS.
Structure
7/13/2021
The object consists of the following elds:
DICBERCLS Authorization Group
ACTVT Activity
TheDICBERCLS eld contains the authorization for tables by authorization class according to table TDDAT. Specify the names of
the permitted classes in this eld. Table classes are de ned in the TBRG table.
TheACTVT eld contains the permitted operations. The following values are possible:
02:Change (add, change or delete table entries)
03:Display table contents
Integration
You can enhance the general table maintenance authorization using S_TABU_DIS and the S_TABU_CLI authorization object.
This protects cross-client tables.
If you have to make a stronger distinction between the general table maintenance authorization (for example because you need
to protect country-speci c data records in cross-country tables such as T510A), you can use the S_TABU_LIN authorization
object.
De nition
Authorization object that can be used to restrict access to tables on the basis of organizational criteria. Organizational criteria
stand for business work areas (for example, country, plant, company code) and represent a connection between key elds of
tables and the authorization elds of S_TABU_LIN.
Use
This authorization object enables you to set up access authorization to speci c rows of a table for a user. In addition, you can
use an organizational criterion in one client for all tables to de ne that a user is only authorized to display and change the table
contents of a speci c business work area (for example, of a country).
Prerequisites
The existence of organizational criteria is a prerequisite for the use of this authorization object. You de ne organizational
criteria in Customizing under SAP Web Application Server → System Administration → Users and Authorizations → Line-
Oriented Authorizations → De ne Organizational Criteria
7/13/2021
Prede ned organizational criteria already exist in the standard system. You can, however, de ne your own organizational
criteria if required. SAP recommends that you refer to the prede ned organizational criteria when you de ne your own
organizational criteria.
Authorization at row level only has an effect if the associated organizational criterion is activated in the current client. Since
organizational criteria are indeed de ned on a cross-client basis but work on a client-speci c basis, you must activate them for
each client required. To activate organizational criteria in the current client, choose SAP Web Application Server → System
Administration → Users and Authorizations → Line-Oriented Authorizations → Activate Organizational Criteria
Structure
The object consists of the following elds:
ORGKRIT Organizational criterion for key-speci c authorizations
ACTVT Activity
ORG_FIELD1 1. Attribute for organizational criterion
TheORGKRIT eld establishes the relationship to the key elds of the tables to which the line authorization refers. Possible
values: all organizational criteria de ned in Customizing and activated for the current client (see above). These values are
displayed using the F4 help.
TheACTVT eld contains the permitted operations. The following values are possible:
02:Change (add, change, or delete table entries)
03:Display table contents
FieldsORG_FIELD1-8can however each contain a certain key eld of a table. You can only enter values for as many attributes as
are de ned in the organizational criterion (at least one).
Possible values: eld values for the key eld of the table. You can enter several individual values and/or intervals.
Integration
The S_TABU_LIN authorization object enhances the S_TABU_DIS and S_TABU_CLI authorization objects. Whereas S_TABU_DIS
has an effect on complete Customizing tables or maintenance views, you can use S_TABU_LIN to control access to individual
table rows.
7/13/2021
In this process, the authorization check of the maintenance transaction rst checks the S_TABU_CLI and S_TABU_DIS
authorization objects. If this is successful, the authorization check then checks whether organizational criteria were de ned for
the key elds of the tables. If this is the case, the authorization check checks whether authorization exists for values, that is
value ranges, of the elds in question. Only those elds for which the complete authorization check has run successfully are
displayed as the result.
Example
Examples of the authorization check using S_TABU_LIN on the basis of the following organizational criteria:
Organizational Criterion Cross-Table Attribute Field
OC_COUNTRY X COUNTRY Table1-COUNTRY
OC_EMP_SUB EMP.SUBGR. Table2-EMP_SUBGR
OC_FOR_TAB_3_ONLY COUNTRY Table3-COUNTRY
AREA Table3-AREA
PAY SCALE Table3-PAY_SC_TYPE
OC_WAGE_TYPE X WAGE TYPE Table4-WAGE_TYPE
or X COUNTRY Table1-COUNTRY
OC_WAGE_TYPE_COUNTRY WAGE TYPE Table4-WAGE_TYPE
To de ne line authorization for certain countries, you simply require authorization for S_TABU_LIN withORGKRIT=OC_COUNTRY.
Since the organizational criterion in this example is de ned as cross-table (that is, not for table 1), it controls user access to
each table that hasCOUNTRYde ned as the key eld.
If you use the organizational criterionOC_EMP_SUBin addition toOC_COUNTRY, the authorization is also checked for this
organizational criterion if a user accesses table 2. This check takes place exclusively for table 2, sinceOC_EMP_SUBis not
de ned as cross-table.
If in addition toOC_COUNTRY,you use the organizational criterionOC_FOR_TAB_3_ONLY, you can thus de ne an exception for
access to table 3: In this case,OC_COUNTRYis not checked, as an authorization check for eldCOUNTRYis already speci cally
de ned for table 3 viaOC_FOR_TAB_3_ONLY
If you use the organizational criterionOC_WAGE_TYPEin addition toOC_COUNTRY, an authorization check is performed for this
organizational criterion for all tables that have theWAGE_TYPE eld de ned as the key eld. If a user accesses table 4, the
authorization forOC_COUNTRYis also checked.
If you use the organizational criterionOC_WAGE_TYPE_COUNTRYinstead ofOC_WAGE_TYPEin addition toOC_COUNTRY, an

authorization check is performed for this organizational criterion for those tables only that
haveWAGE_TYPEandCOUNTRYde ned as key elds. The authorization check forOC_WAGE_TYPE_COUNTRYis, for example, not
performed for table 2 since table 2 does not contain the elds de ned for it.
De nition
Authorization Object that is used to determine who is authorized to perform which operations on which TemSe Objects (objects
with tem porary se quential data).
Use
7/13/2021
Authorizations using S_TMS_ACT only control direct access. TemSe les are protected from applications that access their data
indirectly, such as the spooler or background request management, by their own authorization checks.
Structure
The S_TMS_ACT authorization object contains the following elds, which are tested during an authorization check:
STMSACTION TemSe: Action ID for Authorizations
STMSOWNER TemSe: Owner Group for Authorizations
STMSOBJECT TemSe: Generic Object Name for Authorizations
The STMSACTION eld is used to de ne the permitted operations. The following values are possible:
CRE: Create TemSe object
REA: Read TemSe object
DEL: Delete TemSe object
APP: Append TemSe object
MOD: Modify TemSe object This currently applies only to attributes as the data of the TemSe objects cannot be changed in the
current version.
The STMSOWNER eld is used to de ne the objects for which a user has authorization. The following values are possible:
OWN: Own TemSe objects
GRP: External TemSe objects in own client
OCL: TemSe objects in external clients
The STMSOBJECT eld is used to specify the names of the TemSe objects that are to be tested during the authorization
check.
 Note
TemSe objects have names. The name is speci ed partly generically (that is with a ( * ) at the end).
TemSe objects can have any names. However, naming conventions are used, which are de ned in the TST07 table ( Naming
Conventions for TemSe Objects ). The spooler, for example, currently uses SPOOLnnnnn, where nnnnn is the spool request
number.
HR: Authorization Main Switches

You can use the authorization main switches stored in table T77S0 ( System Table ) under the group name AUTSW to tailor the
behavior of the authorization check on HR infotypes to your requirements. Up to Release 4.5B the switches were stored in the
MPPAUTSW include. Storing the authorization main switches in the T77S0 table is advantageous because the switches can be
de ned differently at client level.
7/13/2021
 Note
For more information on the authorization main switches, see the Implementation Guide (IMG) for Personnel Administration
under Tools Authorization Management Maintain Pro les .
See also:
AUTSW ORGIN (HR: Master Data)
AUTSW ORGXX (HR: Master Data – Extended Check)
AUTSW NNNNN (HR: Customer-Speci c Authorization Check)
AUTSW ADAYS (Tolerance Time for Authorization Check)
AUTSW PERNR (HR: Master Data – Personnel Number Check)
AUTSW APPRO (HR: Test Procedures)
AUTSW ORGPD (HR: Structural Authorization Check)
AUTSW INCON (HR Master Data (Context))
AUTSW XXCON (HR Master Data: Extended Check (Context))
AUTSW NNCON (Customer-Speci c Authorization Object (Context))
AUTSW DFCON (Authorization Check for a Person with Default Position)
AUTSW ORGIN (HR: Master Data)
De nition
Authorization main switch that controls whether the P_ORGIN authorization object should be used in the authorization check.
Values
In the standard system, this switch is set to 1 . If you want to activate the authorization check, set the switch to 0 .
AUTSW ORGXX (HR: Master Data – Extended Check)
De nition
Authorization main switch that controls whether the P_ORGXX authorization object should be used in the authorization check.
Values
AUTSW NNNNN (HR: Customer-Speci c Authorization Check)
De nition
7/13/2021
Authorization main switch that controls whether a customer-speci c authorization object should be used in the authorization
check.
Values
 Caution
Carry out the steps described in Creating a Customer-Speci c Authorization Object before you activate this check. If you fail
to do this, the response of the authorization check is unde ned.
AUTSW ADAYS (Tolerance Time for Authorization Check)
De nition
Authorization main switch that is used to specify the tolerance time of the authorization check in the event of an organizational
change. You can use this switch to set up how long an administrator has access to the data he or she has created as long as this
employee already has an organizational assignment outside his or her own authorization.
Values
Enter the tolerance time of time logic for master data infotypes in calendar days. In the standard system, this switch is set to 15
(= 15 calendar days). If this switch is active, that is if it contains a value greater than zero, the organizational changes that
cause users to lose authorization are delayed signi cantly by the tolerance time.
Example
ADAYS is set to 15 . Only checks using P_ORGIN are activated in the system. Administrator A has write and read authorization
for data in personnel area A; administrator B has the same authorizations for personnel area B. In addition, it is assumed that
the time dependency of the authorization check (T582A- VALDT switch) is activated for all infotypes.
A personnel number was assigned to personnel area A until the December 31, 1999. From January 1, 2000, it is assigned to
personnel area B. Administrator A’s period of responsibility nishes on December 31, 1999 but she has unlimited write and read
authorization until January 15, 2000 (up to and including) because of the tolerance time. From January 16, 2000, administrator
A loses write authorization. She is, however, still authorized to display all the data records that have a validity date (begin date)
before December 31, 1999.
AUTSW PERNR (HR: Master Data – Personnel Number Check)
De nition
Authorization main switch that controls whether the P_PERNR authorization object should be used in the authorization check.
Values
In the standard system, this switch is set to 1 . If you want to deactivate the authorization checks on the personnel number
assigned to a user, set the switch to 0 .
AUTSW APPRO (HR: Test Procedures)
7/13/2021
De nition
Authorization main switch that controls whether test procedures should be used.
Test procedures can be used if certain entries are to be checked centrally and should not be changeable after the check without
further action.
Values
In the standard system, this switch is set to 0 . If you want to activate the test procedures, set the switch to 1 .
AUTSW ORGPD (HR: Structural Authorization Check)
De nition
Authorization main switch that controls whether the organizational structure should also be included in the authorization check
in Personnel Administration .
Values
In the standard system, the switch is set to 0 .If you want to activate the structural authorization check, set the switch to 1 , 2 , 3
or 4 . The different switch settings specify how the system should react to personnel numbers that are not linked to the
organizational structure (in other words, personnel numbers that have position entered as the default position in the
Organizational Assignment infotype (0001)).
For these personnel numbers, you may want to refer to the organizational unit stored in the Organizational Assignment
infotype (0001) for the authorization check (if the organizational unit exists). If you want to do so, you must set the main switch
to 1 or 3 , otherwise to 2 or 4 .
If the person is assigned the default position and no organizational unit is speci ed in the Organizational Assignment infotype
(0001) (or should not be evaluated), no authorization check by organizational assignment can take place. In this case, you can
specify whether the system should grant or deny the authorization by default. If you want to deny the authorization by default,
set the main switch to 1 or 2 , otherwise to 3 or 4 . The following combinations are possible for the switch settings:
Evaluate Organizational Unit (if available) Never Evaluate Organizational Unit
Deny Authorization by Default 1 2
Grant Authorization by Default 3 4
AUTSW INCON (HR Master Data (Context))
De nition
Authorization main switch that controls whether the P_ORGINCON authorization object should be used in the authorization
check.
Values
In the standard system, this switch is set to 0 . If you want to activate the authorization check for P_ORGINCON, set the switch
to 1 .
See also:
7/13/2021
Example Implementation of the Authorization Main Switches
AUTSW XXCON (HR Master Data: Extended Check (Context))
De nition
Authorization main switch that controls whether the P_ORGXXCON authorization object should be used in the authorization
check.
Values
In the standard system, this switch is set to 0 . If you want to activate the authorization check for P_ORGXXCON, set the switch
to 1 .
See also:
AUTSW NNCON (Customer Authorization Object (Context))
De nition
Authorization main switch that controls whether the customer-speci c authorization object P_NNNNNCON should be used in
the authorization check.
Values
In the standard system, this switch is set to 0 . If you want to activate the authorization check for P_NNNNNCON, set the switch
to 1 .
See also:
AUTSW DFCON (Authorization Check for a Person with Default Position)
De nition
Authorization main switchthat controls how the system should react, if the context solution is set up, to personnel numbers
that are not linked to the organizational structure (in other words, personnel numbers that have position entered as the default
position in the Organizational Assignment infotype (0001)).
Values
In the standard system, this switch is set to 1 . You can set the switch to 1 , 2 , 3 or 4 . The different switch settings specify how
the system should react to personnel numbers that are not linked to the organizational structure (in other words, personnel
numbers that have position entered as the default position in the Organizational Assignment infotype (0001)).
For these personnel numbers, you may want to refer to the organizational unit stored in the Organizational Assignment
infotype (0001) for the authorization check (if the organizational unit exists). If you want to do so, you must set the main switch
to 1 or 3 , otherwise to 2 or 4 .
7/13/2021
If the person is assigned the default position and no organizational unit is speci ed in the Organizational Assignment infotype
(0001) (or should not be evaluated), no authorization check by organizational assignment can take place. In this case, you can
specify whether the system should grant or deny the authorization by default. If you want to deny the authorization by default,
set the main switch to 1 or 2 , otherwise to 3 or 4 . The following combinations are possible for the switch settings:
Evaluate Organizational Unit (if available) Never Evaluate Organizational Unit
Deny Authorization by Default 1 2
Grant Authorization by Default 3 4
 Note
You can make this setting for non-context authorization objects using the AUTSW ORGPD switch.
AUTHC (Authorization Level)
De nition
Field in authorization objects, which de nes a user’s access mode (activity).
Use
The AUTHC eld is used in the following authorization objects:
P_ORGXX (HR: Master Data – Extended Check)
P_PERNR (HR: Master Data – Check by Personnel Number)
Values
Authorization Level for Accessing Master Data:
The following authorization levels are possible for the P_ORGIN, P_ORGXX, and P_PERNR authorization objects and for the
customer-speci c authorization object, P_NNNNN:
R (Read) for read access
M (Matchcode) for read access to entry helps
W (Write) for write access
E (Enqueue) for write access using the Asymmetrical Double Veri cation Principle. E also enables you to create and
change locked records
D (Dequeue) for write access using the Asymmetrical Double Veri cation Principle. D also enables you to change the lock
indicator.
S (Symmetric) for write access using the Symmetric Double Veri cation Principle
7/13/2021
* (all operations). * includes all authorization levels simultaneously, that is it has the same meaning as R , M , W , E , D
and S .
Problems can arise in some programs when write authorizations exist but no read authorizations. To avoid this, you should
always specify R along with the authorization levels W , E , D , and S .
This applies for authorizations with PSIGN = I in the P_PERNR authorization object. In certain cases, it is appropriate not to
enter read authorizations for authorizations with PSIGN = E . This is not an exception to the rule. PSIGN = E can be used to
deny authorizations, which is, of course, allowed. This can occur, for example, if you have speci ed an authorization using
P_ORGIN and authorization level * , and then use P_PERNR to determine that the user should be authorized to display his or her
own data but not change the data. In this case, you would specify an authorization for P_PERNR with AUTHC = W , E , D , S and
PSIGN = E .
Authorization Level for Accessing Clusters:
The following authorization level speci cations are possible for the P_PCLX (HR: Clusters) authorization object:
R (Read) for read access
U (Update) for write access. This includes the authorizations of authorization level S but not authorization level R
S (Simulation) to write data to internal buffer but not to database
Integration
You are probably familiar with the ACTVT ( Activity ) eld from other components of the SAP system, not with the authorization
level and wonder why ACTVT is not used in mySAP HR . The eld is not used in mySAP HR because the authorization objects
that contain the AUTHC eld ( Authorization Level ) were already in use before it was decided to switch to the ACTVT eld.The
decision up until now has been to continue to use the AUTH eld to ensure existing customers remain compatible in this area
and to avoid the adjustment and corresponding implementation that a switch would involve.
VDSK1 (Organizational Key)
De nition
Field in authorization objects that is used to run diverse authorization checks by organizational assignment (using the P_ORGIN
authorization object). The content of the organizational key is either derived by the system from the elds of the Organizational
Assignment infotype (0001) or entered manually by the user.
Structure
Controlling the Creation and Validation of the Organizational Key
The VDSK1 feature ( Organizational Key ) and the T527 ( Organizational Key: Control ), T527A ( Organizational Key: Rules for
Creating Organizational Keys ), and T527O ( Organizational Key: Validation ) tables control the creation and validation of the
organizational key.
A variable key, VARKY , is determined for this purpose using the VDSK1 feature. This key is used according to the T527 table to
determine how the VDSK1 ( Organizational Key ) should be created or validated. The OFLAG ( Default/Validation) and RULID (
Rule for Creating Organizational Keys) elds are evaluated for this. The OFLAG ( Default/Validation) eld can have the following
speci cations:
1: optional entry without validation
7/13/2021
2: optional entry with validation
3: required entry with validation
4: default that cannot be overwritten without validation
5: default that can be overwritten without validation
6: default that can be overwritten with validation
7: default that cannot be overwritten with validation
If you make an entry in the OFLAG eld ( Default/Validation) which causes a default value to be created (speci cations 4 , 5 , 6
or 7 ), you must also maintain the RULID eld ( Rule for Creating Organizational Key). This entry is then used to determine the
corresponding rule for the organizational key in the T527A table ( Organizational Key: Rule for Creating Organizational Key ).
If you make an entry in the OFLAG eld ( Default/Validation) which causes the organizational key to be validated, you must
enter the values that should be recognized by the system as permitted in the T527O table ( Organizational Key Validation ).
 Note
If an entry for OFLAG ( Default/Validation) is not permitted (that is, the number is not between 1-7 ), the system always
responds as if 1 had been entered in the eld.
Example of an entry in table T527:
VARKY OFLAG RULID
TEST 6 XY
If the VDSK1 feature returns the TEST key, the organizational key is created according to the entries in table T527A that belong
to XY . In addition, the organizational key is validated against the entries in table T527O.
Creating the Organizational Key
The T527A table ( Organizational Key: Rule for Creating Organizational Keys) controls the creation of the organizational key.
You can create one or several rows for each rule. The rows are always sorted according to SEQNO ( sequence number ). SNAME
( Field Name ) speci es the eld of the Organizational Assignment infotype (0001) from which data should be included in the
organizational key. Using the LNGTH ( Length) and OFFST ( Offset) elds, you can also specify that only data from certain
places in the speci ed elds should be transported. OFFST de nes the number of places that should be skipped (from the left).
LNGTH speci es the number of places that should be included. The elds, or parts of elds, that have been determined for
each row are placed after each other in the organizational key.
 Example
Example of entries in table T527A:
RULID SEQNO SNAME LNGTH OFFST
01 10 P0001-KOSTL 5 0
7/13/2021
XY 01 P0001-KOSTL 1 0
XY 04 P0001-PERNR 2 3
XY 05 P0001-KOSTL 1 9
ZZ 01 P0001-KOSTL 5 5
If the organizational key should be created according to RULID ( Rule ) 01 , the rst 5 places of the cost center are always
entered in the organizational key, for example, 12345 is entered in the organizational key for cost center 1234567890 .
If the organizational key should be created according to RULID ( Rule ) XY , the rst place is the rst number of the cost center,
the fourth and fth places are the fourth and fth numbers of the personnel number, and the tenth place is the tenth number of
the cost center. For example, 1450 is entered in the organizational key for cost center 1234567890 and personnel number
12345678 .
If the organizational key should be created according to RULID ( Rule ) ZZ , the last ve places of the cost center are entered in
the organizational key. For example, 67890 is entered in the organizational key for the cost center 1234567890 .
Validating the Organizational Key
The T527O table ( Organizational Key: Validation ) contains a list of the permitted entries for the VDSK1 eld ( Organizational
Key ). Only entries with HIRAR ( Hierarchy ) = 1 are relevant for validations. All other entries are ignored when validating the
organizational key.
The ORGKY column ( Organizational Key) contains the organizational key that should be permitted during the validation. All
other columns are irrelevant for the validation.
In the TEXT1 ( Short Name ) and TEXT2 ( Name ) columns, you can store a short text or a description for each organizational
key. The texts appear when you press the input help for the Organizational Key eld. The texts are irrelevant for the actual
validations.
The NODTY column ( Organizational Element) is no longer of signi cance. The column is still included in the T527O table for
reasons of downward compatibility but is no longer displayed in the table view.
 Example
Example of entries in table T527O:
HIRAR ORGKY NODTY TEXT1 TEXT2
1 ADM Adm. Administration
1 PRO Prod. Production
2 PRO TEST Test
2 TEST Test Test
The organizational keys PRO and ADM are permitted organizational keys due to the rst two rows of the table. The entries with
the text Test are all irrelevant because they have an entry unequal to 1 in the HIRAR eld. If there are no more entries in the
T527O table, TEST , in particular, is not a permitted organizational key.
Time Logic
Use
7/13/2021
Time Logic is a principle that checks whether access authorizations already exist for a user using his or her period of
responsibility, the validity period of a data record, and the desired access mode (read or write).
Example
The exact process of the time logic is described in Process of the Time Logic .
Use
Checking the period for which an employee has authorizations for an infotype or for a combination of infotype and subtype is an
important element in the authorization check.
Features
Periods of responsibility can be determined:
according to structural authorization pro les and position or organizational unit
according to the structural authorization check
according to organizational assignment
See also:
Process of Determining the Period of Responsibility
Control Mechanisms (Double Veri cation Principle, Test Procedures, etc.)

The following are additional methods you can use to protect especially critical data when you create or change data.
Asymmetrical Double Veri cation Principle
Symmetrical Double Veri cation Principle
Test Procedures
Change Document
 Note
Note that you can combine the symmetrical and asymmetrical double veri cation principles as long as they are used for
different infotypes (or different subtypes of an infotype). It is not advisable to combine the asymmetrical and symmetrical
double veri cation principles for the same infotype/subtype because the system response is unde ned for this type of
combination.
The test procedures and the change document are, in comparison, independent mechanisms. You can, therefore, use any
combination of these mechanisms and in conjunction with the double veri cation principle.
Asymmetrical Double Veri cation Principle
Use
7/13/2021
This process controls access to infotypes by stipulating that two users are always required to create or change infotype data.
The users do not have the same authorizations, which is why the process is called asymmetrical.
Features
The process proceeds as follows:
User A is granted authorizations with the authorization level E (enqueue), R (read) and M (matchcode) for the P_ORGIN
(or P_ORGXX) authorization object instead of complete write authorizations ( authorization level W or * ). These
authorizations allow user B to create, change or delete locked records only.
User B is granted authorizations with the authorization level D (dequeue), R and M for the authorization object P_ORGIN
(or P_ORGXX) instead of complete write authorizations. These authorizations allow user B to unlock locked records (or
lock unlocked records) only.
Activities
User A enters new data and user B unlocks the new data.
Existing data can be changed in two ways:
User B locks the data, user A changes the data, and user B unlocks the data.
Alternatively, user A creates a locked copy from the unlocked data and changes this copy. User B then unlocks the data.
To delete unlocked data, user B locks the data which is then deleted by user A
In this process, user A is always responsible for entering and changing data and user B for approving the changes.
Symmetrical Double Veri cation Principle
Use
This process controls access to infotypes by stipulating that two users are always required to create or change infotype data.
The users have the same authorizations, which is why the process is called symmetrical.
Features
The process functions as follows:
Both users are granted authorizations with the authorization level S (symmetric), R (read) and M (matchcode) for the
P_ORGIN (or P_ORGXX) authorization object instead of complete write authorizations ( authorization level W or * ).
These authorizations allow each user to create locked data records, change locked data records, and relock unlocked
data records.
In addition, each user can unlock data as long as he or she is not the last person to have changed the locked data.
Neither user can delete data.
Activities
User A (or user B) creates new data and user B (or user A) unlocks the new data.
To change existing data, user A (or user B) locks and changes the data and user B (or user A) unlocks the data.
7/13/2021
Another user must be consulted to delete existing data.
Test Procedures
Use
You can use the test procedures to create test data for speci ed infotypes.
Integration
The test procedures are similar to the asymmetrical double veri cation principle. The difference is that the entered data is
payroll-relevant even if it has not yet been checked. It can, however, only be changed after a successful authorization check by a
user with special authorization.
Features
This control mechanism functions as follows: You can specify a test procedure for the given infotype (or subtype) in the T584A
and V_T584A tables ( Test Procedures – Infotype Assignment ). For infotypes without subtypes, always specify < BLANK > as
the subtype. For infotypes that support subtypes, you must explicitly specify each subtype to be checked.
When you have made this entry, you can create a data record of the Test Procedures infotype (0130). The subtype of this data
record is the test procedure speci ed in T584A. This data record contains the check date amongst other things. As soon as this
check date has been entered in the data record, a user, who is not authorized to change the check date (that is the subtype of
the 0130 infotype), cannot make any changes that are before the check date to the infotype to be checked.
Example
In the framework of decentralized time recording, the time administrator records certain absences. An inspector should check
the entered data. Time administrators should not be able to change the data once it has been checked.
You can set up a test procedure for the attendances and absences that are to be checked in table T584A. If you want to check all
attendances and absences together, it is sufficient to set up one test procedure that can be used for all subtypes of the
Attendances infotype (2002) to be checked. If you want to check the attendances and absences separately, you need to set up
various test procedures.
At rst, the time administrators can create and change any data within the scope of their authorizations. If a tester checks the
entered data at a later date, he or she sets the check date for each personnel number checked in the corresponding subtype of
the Test Procedures infotype (0130) to the date on which he or she nished the checks. This date is normally in the past but it
can also be the current date. It would also be technically possible to have a date in the future but this makes little business
sense.
As soon as the tester has set a check date, the time administrators can only enter data that is after the check date and within
their scope of authorizations. Only time administrators who also have authorization to change the check date (that is, to
change the corresponding subtype of the Test Procedures infotype), can still change data that is before the check date.
If the tester does not have write authorization for the data to be checked and the time administrator does not have
authorization for the test procedures, data checks and data entry take place completely separately from each other.
Creation of Infotype Log
Use
7/13/2021
If you want or need to protect especially critical data, it may be advisable to activate the change document for this data. This
function logs changes made to infotype records.
Integration
The change document has nothing to do with the authorization check. It does not prevent unauthorized users from accessing
data. Rather it logs attempts made by unauthorized users to access data. You can evaluate the changes using the RPUAUD00
report ( Logged Changes in Infotype Data ).
 Note
You can activate the change document in the Implementation Guide (IMG) for Personnel Management under Personnel
Administration Tools Revision Set up change document . For more information about the change document, see the
documentation on this IMG activity.
Processes and Flowcharts of the Authorization Check
This section provides you with an overview of the complete process of an authorization check (see Process of the General
Authorization Check ) and describes the (possible) individual steps in an authorization check. Each process is also represented
graphically.
See also:
Process of the Authorization Check by Personnel Number
Process of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN
Process of the Time Logic
Process of the Test Procedures
Process of Determining the Date After Which Changes Are Permitted for Test Procedures
Process of the General Authorization Check
Purpose
In this process, the system checks authorizations within the General Authorization Check.
Call Parameters
As a result, the authorization check is called using the following parameters:
LEVEL Authorization level
TCLAS Transaction Class = Difference Personnel Number/Applicant

Number (A = Employee, B = Applicant)
PERNR Personnel Number (or Applicant Number)
INFTY Infotype
7/13/2021
SUBTY Subtype
BEGDA Start Date
ENDDA End Date
 Note
Note that BEGDA and ENDDA always indicate the start or end date of a data record for which the authorization should be
checked. The start and/or end date of a period for which the authorization should be checked is never transferred. This
ensures that the users who call up the authorization check do not have to decide which authorization to give the
administrator who has access authorization only for a part of the validity period of a data record. Instead, this is determined
by the time logic of the authorization check.
Process Flow
1. First the authorization check by personnel number (for LEVEL , TCLAS , PERNR , INFTY , SUBTY ) is processed (see also
Flowchart 2). If this check returns the result “not authorized”, the authorization is immediately denied. If, however, the
check returns the result “authorized”, all further steps in the authorization check, with the exception of test procedures,
are skipped.
2. If you use the structural authorization check, the user’s period of responsibility is determined from the organizational
structure (see also Flowchart 3). If the de ned period of responsibility is empty, the authorization is denied immediately.
3. The user’s period of responsibility is determined according to the PA authorization objects (P_ORGIN, P_ORGXX,
customer-speci c authorization object) using organizational assignments (Organizational Assignment infotype (0001))
(see also Flowchart 4). If the de ned period of responsibility is empty, the authorization is denied immediately.
4. The intersection of both periods of responsibility is determined and the time logic is transferred as the period of
responsibility (see following graphic, Graphic 1):
5. The time logic compares the de ned period of responsibility with the validity period of BEGDA to ENDDA (see also
Flowchart 6). If the time logic returns the result “not authorized”, the authorization is denied immediately.
6. The check establishes whether a test procedure exists that prevents the data record from being changed (see also
Flowchart 7). If this is the case, the authorization is denied. Otherwise, the user is authorized to access the data record.
See also:
Flowchart of the General Authorization Check
The individual steps of an authorization check are described one by one and presented graphically in the following:
Process of the Authorization Check – Personnel Number Check
7/13/2021
Process of the Time Logic
Flowchart of the General Authorization Check
7/13/2021
Process of the Authorization Check by Personnel Number
Call Parameters
A user attempts to call an employee’s infotype record. As a result, the authorization check is called using the following
parameters:
LEVEL Authorization Level

Number
INFTY Infotype
SUBTY Subtype
The BEGDA and ENDDA parameters are not needed as the user’s current assignment to a personnel number is always
evaluated. As soon as the system recognizes that a personnel number belongs to a user, the data is differentiated using only
the infotype/subtype parameter. A differentiation based on time does not take place.
Process Flow
The system performs all the following steps of the authorization check.
1. The transaction class is evaluated. If the check is on an applicant number, the check is ended with the result undecided .
2. The PERNR authorization main switch is evaluated. If the switch is deactivated, the check is ended with the result
undecided .
3. The personnel number belonging to the user is determined (in the standard system from the 0105 infotype, subtype
0001, in earlier releases from the T513A table User Values ).
4. If the personnel number does not concur with the personnel number to be checked or if no personnel number is found,
the check is ended with the result undecided . (This is why authorization settings for the P_PERNR authorization object
can never affect the authorization check by personnel number on personnel numbers that are not assigned to the user.)
5. An authorization check is performed for the P_PERNR authorization object:
6. AUTHORITY-CHECK OBJECT 'P_PERNR'
ID 'AUTHC' FIELD LEVEL
7/13/2021
ID 'PSIGN' FIELD '*'
ID 'INFTY' FIELD INFTY
ID 'SUBTY' FIELD SUBTY.
7. If this check is successful ( SY-SUBRC = 0 ), the outcome is authorized .
8. A second authorization check is performed for the P_PERNR authorization object:
ID 'PSIGN' FIELD 'E'
10. If this check is successful ( SY-SUBRC = 0 ), the outcome is not authorized .
11. A third authorization check is performed for the P_PERNR authorization object:
ID 'PSIGN' FIELD 'I'
14. If none of the checks performed were successful, the outcome is undecided .
 Note
The check using P_PERNR with PSIGN = * was not carried out in earlier releases. A user with * authorization for P_PERNR in
the PSIGN eld is was always denied access for this reason. This meant, amongst other things, that users with full
authorizations were unable to access their own personnel number during active authorization checks by personnel number.
Why not, therefore, simply switch the check to PSIGN E or I? ? A user with E and I authorization should be able to access and
unable to access his or her own personnel number. Since the system cannot interpret this in a meaningful way, it should deny
the authorization according to the strategy "when in doubt, no authorization". This immediately rules out switching the E and
I checks. The additional PSIGN = * checks were introduced to ensure that users with SAP_ALL authorization always have the
authorization to access their own personnel numbers.
See also:
Flowchart of the Authorization Check by Personnel Number
Flowchart of the Authorization Check by Personnel Number
7/13/2021
Process of Determining the Periods of Responsibility
7/13/2021
In this process, the periods of responsibility for the general authorization check are determined.
This process includes the following subprocesses:
Process of Determining the Period of Responsibility According to Organizational Structure
Process of Determining the Period of Responsibility According to Structural Authorization Check
Process of Determining the Period of Responsibility According to Organizational Assignment
The authorization check determines an intersection from the periods of responsibility returned by this process. This intersection
is transferred to time logic as the period of responsibility.
See also:
Time Logic
Process of Determining the Period of Responsibility According to Organizational

Structure
Call Parameters
The determination of the period of responsibility is called up using the following parameters:

Number
INFTY Infotype
SUBTY Subtype
Process Flow
The system performs all the following steps of this process.
1. The ORGPD authorization main switch is evaluated. If the switch is deactivated, January 1, 1800 to December 31, 9999 is
returned as the period of responsibility and the check is ended.
2. If the current access check is for write access to the Reference Personnel Numbers infotype (0031), January 1, 1800 to
December 31, 9999 is set as the period of responsibility and the check is ended prematurely. (This situation never occurs
for applicant numbers.)
3. The period of responsibility is determined according to the structural authorization pro les (the T77UA table – User
Authorizations and the T77PR table - De nition of Authorization Pro les ).
4. The default position is determined (T77SO table – System Tables , PLOGI PRELI entry). If the default position cannot be
determined (for example, because no entry was found in the T77S0 table), it is not possible to perform the comparisons
of position and default position listed below. In this case, the comparisons always return the result is unequal .
5. The organizational assignments of the personnel number are imported (data records of the Organizational Assignment
infotype – 0001).
The following steps are carried out for each organizational assignment (data record of infotype 0001):
7/13/2021
If the position and default position do not concur, the organizational assignment is not evaluated further and the system
moves to the next organizational assignment.
If the position and default position concur, the organizational assignment is further evaluated.
If an organizational unit can be determined from the organizational assignment and if the evaluation of the
organizational unit is desirable (speci cation 1 or 3 of the ORGPD authorization main switch), the system checks
whether the user is authorized to access the organizational unit for the validity period of the organizational assignment
according to the structural authorization pro les:
1. If the user is not authorized to access the organizational unit, the organizational assignment is not evaluated further and
the system moves to the next organizational assignment.
2. If the user is authorized to access the organizational unit, the validity period of the organizational assignment is added
to the period of responsibility.
If no organizational unit can be determined from the organizational assignment or if the evaluation of the organizational
unit is not desirable (speci cation 2 or 4 of the ORGPD authorization main switch), the default case occurs:
1. If the authorization should be denied in the default case (speci cation 1 or 2 of the ORGPD authorization main switch),
the organizational assignment is not evaluated further and the system moves on to the next organizational assignment.
2. If the authorization should be granted in the default case (speci cation 3 or 4 of the ORGPD authorization main switch),
the validity period of the organizational assignment is added to the period of responsibility.
1. When all the organizational assignments of the personnel number have been evaluated, the period of responsibility is
returned.
2. If the period of responsibility is empty, not authorized is returned as the result of the check. Otherwise, the result is
authorized .
 Note
The speci cations 1 or 2 of the ORGPD authorization main switch always deny access authorization in the default case, that
is if the structural assignment of the authorization check is impossible. Consequently, a user can no longer access the
personnel numbers affected in this case. Since the organizational structure for users with unrestricted structural
authorization for personnel numbers is not evaluated, these users can access all personnel numbers. This is due to the fact
that the period of responsibility of these users already had the maximum possible length before the subsequent evaluation
of the organizational assignment.
See also:
Flowchart of Determining the Period of Responsibility According to Organizational Structure
Flowchart of Determining the Period of Responsibility According to Organizational

Structure
7/13/2021
Process of Determining the Period of Responsibility According to the Structural

Authorization Check
In this process, the system determines the period of responsibility according to the structural authorization check. This process
is described by means of examples.
7/13/2021
See Structural Pro les for detailed information about the structural authorization check.
 Note
If you use a combination of general and structural authorization check, an intersection of the periods of responsibility from
the structural authorization check and the organizational assignment (evaluation of the data from the Organizational
Assignment infotype for the P_ORGIN, P_ORGXX and P_NNNNN authorization objects) is transferred to the time logic of the
general authorization check.
Call Parameters
Assume for all examples that the user has been assigned a structural authorization pro le with the following characteristics
using table T77UA ( User Authorizations ) and table T77PR ( De nition of Authorization Pro les ):
The Plan Version eld is speci ed with the active plan version.
The Object Type eld is always speci ed with the ID of the current root object from the current example.
The Object ID eld is speci ed as 1 .
The Evaluation Path eld is speci ed as O-S-P .
The Status Vector eld is speci ed as 12345 , which means that all relationships should be taken into account.
The Depth eld is speci ed as 0 , which means that all levels of the structure should always be evaluated.
The Sign eld is not speci ed, which means that the structure should always be evaluated from top to bottom.
The Period eld is speci ed (the period is varied in the examples).
The Function Module eld is not speci ed.
Process Flow
The following three examples illustrate the process of period determination in the structural authorization check:
Example 1: The personnel number is located as follows in an organizational structure:
7/13/2021
Assume today’s date is February 6, 2001.
Example 1a: < BLANK > ( = All) is entered as the period. When evaluating the structure, the system rst follows the
relationships and forms intersections. The system starts with the period January 1, 1900 – December 31, 9999. After the rst
relationship (O1 O2) has been evaluated, January 1, 2000 – December 31, 9999 is initially returned as the period of
responsibility. The second relationship (O2 S) returns January 1, 2000 – December 31, 2002 as the period. The last
relationship (S P) covers this period and January 1, .2000 – December 31, 2002 remains the period of responsibility. In other
words, the system "arrives" at the personnel number with a full period of responsibility. Once this has been successfully
checked, the validity period of the last relationship is always used as the period of responsibility, which would be the period
January 1, 1995 – December 31, 2005 in this example.
Example 1b: Y ( = current year) is entered as the period. In contrast to example 1a, the system starts with the period January 1,
2001 – December 31, 2001 to determine the period of responsibility. Since all of the relationships affected cover this period, the
period January 1, 2001 – December 31, 2001 is still the intersection for personnel number P. The period of responsibility is then
determined, as in example 1a, from the period of responsibility of the last relationship, which is the period January 1, 1995 –
December 31, 2005.
Example 2: The personnel number is located as follows in the organizational structure:
7/13/2021
D ( = key date) is entered as the period. The system starts with February 6, 2001 and cannot, therefore, move from O1 to O2.
However, the system can reach P from O1 via S3. Therefore, the period of the last relationship (S3 P) is used as the period of
responsibility, which is January 1, 2001 – December 31, 2010 in this example.
Example 3 : The personnel number is located as follows in the organizational structure:
7/13/2021
The following periods of responsibility are determined depending on the settings of the period:
Period Setting Period of Responsibility
<BLANK> (= all) 01.01.1999 – 12.31.1999 and 01.01.2002 – 12.31.2002
D (= key date) no period
M ( = current month): no period
Y ( = current year): no period
P ( = past): 01.01.1999 – 12.31.1999
F ( = future): 01.01.2002 – 12.31.2002
Process of Determining the Period of Responsibility According to Organizational

Assignment
Call Parameters

Number
INFTY Infotype
SUBTY Subtype
Process Flow
1. The organizational assignments of the personnel number are determined (data records of the Organizational
Assignment infotype (0001)).
2. The following steps are carried out for each organizational assignment (data record of infotype 0001):
An authorization check for P_ORGIN is performed: If there is no authorization, the validity period of the organizational
assignment does not belong to the user’s period of responsibility.
An authorization check for P_ORGXX is performed: If there is no authorization, the validity period of the organizational
assignment does not belong to the user’s period of responsibility.
An authorization check for the customer-speci c authorization object, P_NNNNN , is performed: If there is no
authorization, the validity period of the organizational assignment does not belong to the user’s period of responsibility.
1. If all the authorization checks run successfully, the validity period of the organizational assignment is added to the user’s
period of responsibility.
2. When all the organizational assignments of the personnel number have been evaluated, the period of responsibility is
returned.
3. If the period of responsibility is empty, not authorized is returned as the result. Otherwise, the result is authorized .
7/13/2021
 Note
For applicant numbers ( TCLAS = B ), P_APPL is checked instead of P_ORGIN, P_ORGXX, and the customer-speci c
authorization object P_NNNNN.
See also:
Flowchart of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN
Flowchart of Determining the Period of Responsibility According to Organizational

Assignment
7/13/2021
Call Parameters
A user attempts to call an employee’s infotype record. As a result, the authorization check is called using the following
parameters:
P0001 Data Record of the Organizational Assignment Infotype (0001)
INFTY Infotype
SUBTY Subtype
Process Flow
The system performs all the following steps of the authorization check.
1. The ORGIN authorization main switch is evaluated.
2. If the main switch is not activated, the authorization check returns authorized immediately.
3. An authorization check takes place on the P_ORGIN authorization object:
AUTHORITY-CHECK OBJECT 'P_ORGIN'
ID 'SUBTY' FIELD SUBTY
ID 'PERSA' FIELD P0001-WERKS
ID 'PERSG' FIELD P0001-PERSG
ID 'PERSK' FIELD P0001-PERSK
ID 'VDSK1' FIELD P0001-VDSK1.
7/13/2021
2. If this check is unsuccessful ( SY-SUBRC <> 0 ), the outcome is not authorized .
The check for P_ORGXX runs analogously. However, the ORGXX authorization main switch is evaluated and then the following
check is processed:
AUTHORITY-CHECK OBJECT 'P_ORGXX'
ID 'SACHA' FIELD P0001-SACHA
ID 'SACHP' FIELD P0001-SACHP
ID 'SACHZ' FIELD P0001-SACHZ
ID 'SBMOD' FIELD P0001-SBMOD.
The NNNNN authorization main switch is evaluated for the customer-speci c authorization object and then the form routine of
the generated MPPAUTZZ include is processed.
There is no evaluation of an authorization main switch for the P_APPL authorization object (for applicants), since no such switch
exists. The reason for this is that applicants do not normally take part in the structural authorization check and consequently, it
is not desirable to switch off the checks of P_APPL. The following check is carried out for P_APPL:
AUTHORITY-CHECK OBJECT 'P_APPL'
ID 'PERSA' FIELD P0001-WERKS
ID 'APGRP' FIELD P0001-PERSG
ID 'APTYP' FIELD P0001-PERSK
ID 'VDSK1' FIELD P0001-VDSK1
ID 'RESRF' FIELD P0001-SACHP.
See also:
7/13/2021
Process of Time Logic
Purpose
In this process, the system runs the time logic within the General Authorization Check .
Call Parameters
The time logic is called up using the following parameters:

Number
INFTY Infotype
BEGDA Start Date of Infotype Record To Be Checked
ENDDA End Date of Infotype Record To Be Checked
7/13/2021
In addition, the period of responsibility that has already been determined is transferred.
Process Flow
If the period of responsibility is empty, the time logic returns not authorized .
The time logic determines whether the authorization check should be performed on a date-dependent basis (from T582A-
VALDT).
If the check should not be performed on a date-dependent basis, the time logic check returns authorized .
If the check should be performed on a date-dependent basis, the following steps are carried out:
The tolerance time ( ADAYS authorization main switch) is determined.
The check establishes whether the check is for read access (LEVEL = R or M).
If the check is for read access, the following steps are carried out:
The end date of the period of responsibility is determined (see also the following graphic, 2: Period Determination for Read
Access ):
If the current date (SY-DATUM) is not after the end date of the period of responsibility by more than the tolerance time
(ADAYS), the period January 1, 1800 to December 31, 9999 is set as the new period of responsibility.
- If the current date is not after the end date of the period of responsibility by more than the tolerance time, the period
January 1, 1800 to end date of the old period of responsibility is set as the new period of responsibility.
The check establishes whether the validity periodBEGDA - ENDDAof the infotype has a full intersection with the newly de ned
period of responsibility, that is whether there is at least one day, which is in both periods:
If the intersection is not empty, the time logic check returns authorized .
If the intersection is empty, the time logic check returns not authorized .
If the check is for write access, the following steps are carried out (see also the following graphic: 3: Period Determination for
Write Access ):
If the rst day of the period of responsibility concurs with the rst day of the organizational assignment (BEGDAof the rst
infotype record of infotype 0001, normally the date of the initial setting), the period of responsibility is extended to begin on
January 1, 1800. (This is necessary to ensure that users can access dates that are before the initial setting.)
If the current date (SY-DATUM) is within the period of responsibility or after the end of a responsibility interval by no more than
the tolerance time (ADAYS), the period January 1, 1800 to December 31, 9999 is set as the new period of responsibility.
7/13/2021
If the current date (SY-DATUM) is outside a responsibility interval and by more than the tolerance time after the end of each
responsibility interval, all responsibility intervals that are before the current date are deleted.
The check establishes whether the validity periodBEGDA - ENDDAof the infotype is completely within the newly de ned period
of responsibility:
If the validity period is within the period of responsibility, the time logic check returns authorized .
If the validity period is outside the period of responsibility, the time logic check returns not authorized .
See also:
Time Logic in Flowchart 6
Flowchart of the Time Logic
7/13/2021
Call Parameters
The test procedures check is called up using the following parameters:

Number
PERNR Personnel Number
INFTY Infotype
7/13/2021
SUBTY Subtype
BEGDA Start Date of Infotype Record To Be Checked
Process Flow
The system performs all the following steps of the test procedures check.
The APPRO authorization main switch is evaluated If the main switch is not activated, the authorization check returns
authorized immediately.
LEVEL is evaluated. If the check is for read access (authorization level R or. M ), the authorization check returns
authorized immediately.
The check establishes which object the user should be authorized to access:
If the check is for access to an applicant number or to the Organizational Assignment infotype (0001), the authorization check
returns authorized immediately.
If the check is for access to the Test Procedures infotype (0130), the following steps are carried out:
The date after which changes are permitted is determined. This date is taken as the maximum.
If the check is for access to one of the different Test Procedures infotypes, the following steps are carried out:
All the test procedures that are relevant for the infotype (from the T584A table ( Test Procedures – Infotype Assignment )) are
determined:
If no test procedures are found, the authorization check returns authorized immediately.
If test procedures are found, the date after which changes are permitted is determined for each test procedure (that is,
for each subtype of infotype 0130). See also Flowchart 8 ):
1. The maximum of the dates that have just been de ned is determined.
2. The authorization check then establishes whether the start date of the infotype record ( BEGDA ) is after the maximum
determined by the system in the previous step:
If the date is after the maximum, the authorization check returns authorized .
If the date is before the maximum, the authorization check returns not authorized .
 Note
Applicant numbers are excluded from the test procedures for the following reason: The test procedures were developed for
decentralized entry scenarios such as decentralized time evaluation where users evaluate time data outside the HR
department. The HR department is only involved in checking the data. In this scenario, the test procedures should prevent
other users from being able to change data outside the HR department after it has already been checked. Since applicant
data is generally not changed outside of the HR department, such scenarios do not normally occur and are therefore not
supported.
Similar arguments could be put forward for the exclusion of the Organizational Assignment infotype (0001) from the Test
Procedures. The real reason for excluding this infotype is the special function that it has in the authorization check. Since the
Organizational Assignment infotype (0001) controls the periods of responsibility for other infotypes and in particular for the
Test Procedures infotype (0130), test procedures on the 0001 infotype often cause complications in the authorization check.
The 0001 infotype has therefore been excluded intentionally from the test procedures to avoid this.
7/13/2021
See also:
The process ow of the test procedures in Flowchart 7
Flowchart of the Test Procedures
7/13/2021
Process of Determining the Date After Which Changes Are Permitted for Test
Procedures
Call Parameters
The system transfers the following parameters to determine the date after which changes are permitted:
PERNR Personnel Number
CKTYP Test Procedures = Subtype of Test Procedures Infotype (0130)
Process Flow
The check date ( RELDT ) of the speci ed test procedure (data record of the subtype de ned by CKTYP of the Test Procedures
infotype (0130)) is imported:
If no date is found, every change made as of January 10, 1800 (up to and including) is permitted, that is, December 31,
1799 is taken as the date and processing is stopped at this point.
If a date is found, the following steps are carried out:
A personnel number check (with LEVEL = W , SUBTY = CKTYP ) is performed for the test procedure ( CKTYP ) for the Test
Procedures infotype (0130):
1. If the check returns authorized , every change made as of January 1, 1800 (up to and including) is permitted and
processing is stopped at this point.
2. If the check returns not authorized , only changes after the check date are permitted and processing is stopped at this
point.
3. If the check returns authorization unclear , processing continues.
The period of responsibility (for write access) is determined according to the structural authorization check.
The period of responsibility (for the corresponding subtype of infotype 0130, authorization level W ) is determined
according to P_ORGIN, P_ORGXX and the customer-speci c authorization object, P_NNNNN.
The intersection of both periods of responsibility is determined and used as the period of responsibility:
If the current date ( SY-DATUM ) and the check date (P0130- RELDT ) are not after the end of the period of responsibility,
each change made as of January 1, 1800 (up to and including) is permitted.
7/13/2021
If the current date or the check date are after the end of the period of responsibility, only changes after the check date
(P0130- RELDT ) are permitted.
The time logic for test procedures appears at rst to function differently to the general time logic of authorization checks.
However, both follow the exact same process. The only difference is that when you use test procedures, you already know that
the check only returns authorization for write access and that the data records of the 0130 infotype are always valid from
January 1, 1800 to December 31, 9999. The time logic for test procedures is as follows:
If a user has write authorization for all subtypes of the Test Procedures infotype (0130), he or she can change the check
date for each test procedure and is, therefore, permitted to make changes to other infotypes independent of the test
procedures.
If the user has no write authorization for a subtype of the Test Procedures infotype (0130), he or she cannot change the
check date. The user is, therefore, only permitted to make changes that are after the check date to the infotypes tested
by this test procedure.
The general authorization check is always used to determine the date regardless of whether or not the user has write
authorization for a subtype of the Test Procedures infotype (0130).
See also:
See Flowchart 7 for a graphical representation of the test procedures and Flowchart 8 for a graphic of how the date after which
changes are permitted is determined.
Flowchart of Determining the Date After Which Changes Are Permitted for Test
Procedures
7/13/2021
Interaction of General and Structural Authorizations
If you use both structural and general authorizations, a user’s overall pro le is determined from the intersection of his or her
structural and general authorization pro les.
The structural pro le determines which object in the organizational structure the user has access to. The general pro le
determines which object data (infotype, subtype) and which access mode (Read, Write, ...) the user has for those objects.
7/13/2021
Example
An overall pro le could be put together as follows:
The following authorizations or restrictions apply to a user who has the overall pro le illustrated above:
The user has read authorization for positions S1 to SN in infotypes 1000 to 1010 (structural pro le and 1/PLOG pro le).
7/13/2021
The user is not authorized to access organizational units with this pro le since the user has no corresponding PLOG
authorization.
The user has read authorization for persons P1 to PN in infotypes 0000 to 0007. (Structural Pro le and
Pro le/P_ORGIN). The period of responsibility for persons is determined in accordance with the period of responsibility
according to structural authorization. See Determining the Period of Responsibility According to Structural
Authorization .
For the user to be able to access data on persons, you need to assign the user a corresponding PLOG authorization for
persons. The infotype does not have to be speci ed. (Pro le 2/PLOG)
Examples
These examples are intentionally simple. See the explanations of the individual authorization objects and authorization checks
for details on why these examples work.
See also:
Example: Employee Self-Service
Example: Administrator Should Not Be Allowed to Edit Own Data
Example: Administrator Should Not Be Allowed to Enter Data Alone
Example: Decentralized Time Recording
Example: Periods of Responsibility and Time Logic
Example: Telephone List
Example: Payroll
Example: Transaction-Dependent Authorizations
Example: Employee Self-Service
Requirement
Employees should be able to change their own address (infotype 0006) using SAP Employee Self-Service. What is more, each
employee should be authorized to access all master data stored under his or her personnel number. Employees who are not HR
administrators should not be able to access other employees’ data under any circumstances.
Realization
At least one of the authorization main switches (except for P_PERNR) must be active to be able to prevent users access
to other personnel numbers. Assume for this example that the AUTSW ORGIN main switch is the only active main switch.
The AUTSW PERNR main switch must be activated for the authorization check by personnel number to take place.
The user assignment for all employees who use the SAP Employee Self-Service must be maintained in infotype 0105.
Users who are not administrators should not be granted P_ORGIN authorizations. This means that these users have no
access authorization to HR master data for the time being.
7/13/2021
Every employee who uses the SAP Employee Self-Service is granted the following two authorizations for the P_PERNR
authorization object:
AUTHC = R, M
PSIGN = I
INFTY = *
SUBTY = *
and
AUTHC = *
PSIGN = I
INFTY = 0006
SUBTY = *
Example: Administrator Should Not Be Allowed to Edit Own Data
Requirement
An administrator should not be able to edit his or her own salary or other salary-relevant data stored under his or her own
personnel number. For this reason, you want to deny all administrators who may have access to their own personnel number
write access to their own personnel number.
Realization
The AUTSW PERNR main switch must be activated for the authorization check by personnel number to take place.
The user assignment for the corresponding administrator must be maintained in infotype 0105.
Each employee affected is granted the following P_PERNR authorization:
AUTHC = W, S, D, E
PSIGN = E
INFTY = *
SUBTY = *
Example: Administrator Should Not Be Allowed to Enter Data Alone
Requirement
You want to ensure that the Additional Payments infotype (0015) can only be edited by two administrators together. To achieve
this, you want to set up the asymmetrical double veri cation principle where one of the administrators is responsible for
recording the data and the other administrator for controlling the process. For the sake of simplicity, assume that only the
AUTSW ORGIN main switch is activated.
7/13/2021
Realization
The time administrator requires the following authorization for the P_ORGIN authorization object:
INFTY = 0015
SUBTY = *
AUTHC = R, M, E
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
The time administrator requires the following authorization for the P_ORGIN authorization object:
INFTY = 0015
SUBTY = *
AUTHC = R, M, D
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
Example: Decentralized Time Recording
Requirement
You record working time decentrally. Once the time data has been recorded decentrally, it is checked centrally. The time
administrators should not be able to change data that has been checked. The central time administrators, however, should still
be able to change the data.
Realization
Activate the Test Procedures ( AUTSW APPRO authorization main switch) in addition to the authorization checks using
P_ORGIN ( AUTSW ORGIN authorization main switch).
Create an entry in the T584A table ( Test Procedures – Infotype Assignment ) for all time management infotypes and
subtypes. You can use one test procedure for all infotypes. You can also use a different test procedure for each subtype
or the same test procedure for several subtypes only. The decision depends on whether the subtypes should each be
checked together or separately.
The time administrators need the following authorization for the P_ORGIN authorization object:
INFTY = 2*
7/13/2021
SUBTY = *
AUTHC = *
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
The time administrators need the following authorization for the P_ORGIN authorization object:
INFTY = 0130
SUBTY = *
AUTHC = *
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
 Note
If you have different time administrators for different test procedures, you must list each test procedure instead of * in the
SUBTY eld.
The time administrators who should also be able to change time data need an additional write authorization.
Example: Periods of Responsibility and Time Logic

An employee is transferred from personnel area A to personnel area B.
Move Date: Date of transfer in infotype 0001 for the employee (the responsible administrator then changes).
Period of responsibility: If an employee has within a speci c period one or more organizational assignments for which the
administrator is responsible based on his or her authorization pro le, the entire validity period for the organizational
assignments is de ned as the period of responsibility.
7/13/2021
If an administrator accesses the infotype data for a person (employee or candidate), the system reads the organizational
assignment and the work area (infotype, subtype, and authorization level).
 Note
See also the documentation for the authorization objects P_ORGIN (HR: Master Data) and P_ORGXX (HR: Master Data -
Extended Check) .
Each infotype usually has different records with different validity periods. In a speci c period, an employee can have different
organizational assignments (infotype 0001: Organizational Assignment ).
If different administrators (users) are responsible for these organizational assignments, this is taken into account when
checking the authorization for a speci c validity period of the infotype.
If the eld for the access authorization VALDT is set to SPACE in the table T582A , then an administrator has access to
all past, present, and future infotype records for this person if the administrator's authorization pro le enables him or
her to access this data.
If the eld VALDT is set to X , then the authorization check is based on the current (system) date. This means that only
the administrator who is responsible at the current time has access to the infotype data (assuming his or her
authorization pro le permits him or her to access this data).
Example: Telephone List
Requirement
You want all system users to have unrestricted access to the ZTELEFON telephone list report, which is based on the SAPDBPNP
logical database.
Realization
Assign all users the following authorization for the P_ABAP authorization object.
REPID = ZTELEFON
COARS = *
7/13/2021
Example: Payroll
Requirement
You want to achieve the best possible performance of Payroll.
Realization
Assign the payroll administrator full authorization for the activated checks.
In addition, assign the payroll administrator full authorization for the P_ABAP authorization object.
Example: Transaction-Dependent Authorizations
Requirement
You want to ensure that certain authorizations are only granted when speci c transactions are used. In other words, you want
to include the SY-TCODE eld in the authorization check.
Realization
Create a customer-speci c authorization object that contains the TCD eld.
Use this authorization object instead of the standard objects, that is deactivate the AUTSW ORGIN and the AUTSW
ORGXX authorization main switches and activate the AUTSW NNNNN authorization main switch.
See also:
Example 1
Field Values
Plan Version 01
Authorization:
Due to the user’s authorization pro le, he or she is authorized to access plan version 01.
Example 2
Field Values
Plan Version 01
Object Type O (Organizational Unit)
Authorization:
Due to the user’s authorization pro le, he or she is authorized to access organizational units in plan version 01.
7/13/2021
Example 3
Field Values
Plan Version 01
Object ID Organizational Unit ID
Evaluation Path ORGEH ( Organizational Structure )
Authorization:
Due to the user’s authorization pro le, he or she is authorized to access organizational units in plan version 01 from a root
object (entry in the Object ID eld, represented as O1 in the gure for example 6) along the Organizational Structure evaluation
path.
Example 4
Field Values
Plan Version 01
Object ID Organizational Unit ID
Period D (current day)
Authorization:
Due to the user’s authorization pro le, he or she is authorized to access organizational units in the structure that is valid on the
current day in plan version 01.
Example 5
Field Values
Plan Version 01
Object ID 0 = no restriction
Evaluation Path SBESX ( Staffing Assignments Along Organizational Structure )
Function Module RH_GET_MANAGER_ASSIGNMENT
Authorization:
Due to the user’s authorization pro le, he or she is authorized to access objects along the Staffing Assignments Along
Organizational Structure evaluation path from a root object in plan version 01. The root object is determined in this case using
the function module, that is no entry should be made in the Object ID eld.
7/13/2021
The user is then granted access authorization to the organizational unit he or she manages and to all lower-level objects along
the SBESX evaluation path.
Example 6
Field Values
Plan Version 01
Object ID ID of an organizational unit that is subordinate to the organizational

unit in example 3
Authorization:
This pro le is required to not give a user that is to receive the authorization pro le from example 3 authorization for the objects
of a contained lower-level branch.
This authorization pro le is assigned to the user in the same way as the authorization pro le from example 3 in Customizing for
authorizations under Personnel Management Organizational Management Authorization Management Structural
Authorization Assign Structural Authorization, however, theExclusionindicator is also selected for the authorization pro le
created here.
Within the assigned authorization pro les, the user is then authorized in plan version 01 starting from the root object of the
authorization pro le from example 3 (object O1 in following gure) to access all organizational objects along the Organizational
Structure evaluation path, except for the branch with the organizational unit that is given as the root object in this structural
pro le in the Object ID eld (represented as O4 in the following gure for this example). The user cannot access objects that
are in the exclusion set, meaning that are within the excluded substructure.
7/13/2021
See also:

Authorizations in HCM 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Authorizations in HCM 1

Uploaded by

Copyright:

Available Formats

7/13/2021

HR Renewal | 2.0, Feature Pack 5 SP 90

Original content: https://help.sap.com/viewer/4946a4f5c2d7427c96d89242e1ﬀ2d9a/2.5.90/en-US

For more information, please visit the https://help.sap.com/viewer/disclaimer.

Authorizations for Human Resources

General Authorization Check

Authorizations are grouped together in authorization pro les .

Control Mechanisms (Double Veri cation Principle, Test Procedures, etc.)

Administrator Should Not Be Allowed to Edit Own Data

Administrator Should Not Be Allowed to Enter Data Alone

Decentral Time Recording

Setting Up General Authorization Checks

Structural Authorization Check

Structural Pro les

Objects (such as O (Organizational Unit), S (Position), P (Person))

Relationships (such as A003 (belongs to))

Evaluation Paths (such as O-S-P)

Object Type Relationship Relationship Name Related Object Type

O B002 is line supervisor of O

O1, O4, O5, S1, S2, S3, P1, P2, P3

Example in Structural Authorization Check

Flowchart: Example of Period of Responsibility According to Structural Authorization Check

Interaction of General and Structural Authorizations

Example: Structural Authorization Pro les

HRBAS00_STRUAUTH (BAdI: Structural Authorization)

Redundant Read of Objects

Evaluation Paths with Non-Speci ed Target Object Type

Context Problems in HR Authorizations

De nition of Structural Authorizations

The system distinguishes between two diﬀerent uses of structural authorizations:

Maintenance (processing type)

Depth (display depth)

Period: D (= key date)

Period: <BLANK> (= all)

In the standard system, 2 function modules are provided:

RH_GET_MANAGER_ASSIGNMENT (Determine Organizational Units for Managers)

RH_GET_ORG_ASSIGNMENT (Organizational Assignment)

Assignment of Structural Authorizations

HRBAS00_GET_PROFL (BAdI: Determine Assigned Structural Pro les)

HR: Main Authorization Switch

AUTHC (Authorization Level)

VDSK1 (Organizational Key)

Control Mechanisms (Double Veri cation Principles, Test Procedures, etc.)

Authorization Field Long Text

Authorization Field Long Text

AUTHC Authorization level

PERSA Personnel area

PERSG Employee group

PERSK Employee subgroup

VDSK 1 Organizational key

Authorization objects for the HR object class:

P_ABAP (HR: Reporting)

P_APPL (HR: Applicants)

P_BEN (HR: Bene t Area)

P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check)

P_CERTIF (HR: Statements)

P_CH_PK (HR-CH: Pension Fund: Account Access)

P_DE_BW (HR-DE: Statements SAPScript)

P_DEL_PERN (Deletion of Personnel Numbers in Live Systems)

P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company)

P_HAP_DOC (Appraisal Systems: Appraisal)

P_HRF_INFO (HR: Authorization Check InfoData Maintenance for HR Forms)

P_HRF_META (HR: Authorization Check Master Data Maintenance for HR Forms)

P_NNNNN (HR: Master Data: Customer-Speci c Authorization Object)