Authorizations in HCM 2

7/13/2021
Human Resources
Generated on: 2021-07-13 17:30:13 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.
Customer Enhancements
This section presents the possible customer enhancements for authorization checks using Business Add-Ins in mySAP HR .
See also:
HRPAD00AUTH_CHECK (BAdI: Customer-Speci c Authorization Checks)
7/13/2021
HRBAS00_STRUAUTH (BAdI: Structural Authorization)
HRBAS00_GET_PROFL (BAdI: Determine Assigned Structural Pro les)
HRPAD00AUTH_CHECK (BAdI: Customer-Speci c Authorization Checks)
De nition
Business Add-In (BAdI) that you can use to replace the SAP standard authorization check with a customer-speci c authorization
check for HR master data and infotypes.
Use
If your requirements of the authorization check for HR Master Data infotypes cannot be met by either the standard system or
by a customer-speci c authorization object, you can replace the authorization checks completely without modi cation (as of
Release 4.6C). For this, you use Business Add-Ins (BAdI). The BAdI for the master data authorization check is called
HRPAD00AUTH_CHECK.
 Note
You can nd the Business Add-In (BAdI) in the IMG for Personnel Management under Personnel
Administration Tools Authorization Management BAdI: Set Up Customer-Speci c Authorization Check . You can nd
information on implementing a BAdI in the documentation of the corresponding IMG activity.
As soon as an implementation for this BAdI is active,allHR master data authorization checks are stopped and instead only
the activated implementation is performed.
You can implement this BAdI using the SE19 transaction.
In this context, note that access to documentation in this transaction does not work properly sometimes. If this is the case,
you can access the documentation using the SE18 transaction and the corresponding BAdI (here: HRPAD00AUTH_CHECK)
or using the SE24 transaction and the corresponding interface (here: IF_EX_HRPAD00AUTH_CHECK): Double-click an
interface name to leave transaction SE18 or SE19 and go to transaction SE24 where you can access the documentation of
each method.
In order to accommodate the numerous requirements of the authorization check, the IF_EX_HRPAD00AUTH_CHECK is kept
relatively open. The following methods are available and mustallbe implemented:
CHECK_MAX_INFTY_AUTHORIZATION
CHECK_MAX_LEVEL_AUTHORIZATION
CHECK_MAX_SUBTY_AUTHORIZATION
CHECK_MIN_INFTY_AUTHORIZATION
CHECK_MIN_LEVEL_AUTHORIZATION
CHECK_MIN_SUBTY_AUTHORIZATION
SET_ORG_ASSIGNMENT
SET_PARTIAL_ORG_ASSIGNMENT
7/13/2021
CHECK_AUTHORIZATION
CHECK_MAX_PERNR_AUTHORIZATION
CHECK_MIN_PERNR_AUTHORIZATION
CHECK_PERNR_AUTHORIZATION
DELAYED_CONSTRUCTOR
If you want to make only one change to a speci c subfunction of the standard authorization check (for example, a change to the
time logic), simply copy the CL_HRPAD00AUTH_CHECK_STD class used in the standard system, adjust the (customer-speci c)
copy to your requirements, and then activate the copy as a BAdI (see also example ). It is not advisable to adjust only the
CHECK_AUTHORIZATION method for this. This may be sufficient in certain cases but often this kind of adjustment automatically
requires changes to be made to the other methods.
Structure
This section explains the role played by the various methods of the IF_EX_HRPAD00AUTH_CHECK interface during the
authorization check. The method interfaces are stored in the system as documentation of the corresponding methods. Review
the method documentation of the corresponding method if you are implementing a new method or changing method.
CHECK_AUTHORIZATION
This method is the central method of the authorization check on HR Master Data infotypes. The CHECK_AUTHORIZATION
method is processed during each authorization check at single record level.
During implementation, ensure that this method is also processed when you perform hiring actions. In particular cases, there
are no data records available in the database for the Actions (0000) and Organizational Assignment (0001) infotypes at the
point when the method is processed.
Also ensure that the correct interaction with the ..._ORG_ASSIGNMENT methods is achieved during implementation.
SET_ORG_ASSIGNMENT
This method is called by applications that have already read all the data records of the Organizational Assignment (0001)
infotype and want to prevent this data from being read again in the authorization check. This method should be used for
performance tuning only.
SET_PARTIAL_ORG_ASSIGNMENT
Since the organizational assignment is only partly known during hiring actions, a normal authorization check is not possible as
the data required for this check is not yet available in the system. To enable at least a rough check to be carried out, the
application transfers the currently known elds of the Organizational Assignment infotype (0001) to the authorization check
using this method.
CHECK_MAX_LEVEL_AUTHORIZATION
This method is called by applications that want to know if a user has maximum authorization for an authorization level. In other
words, if the user can access all infotypes and all personnel numbers for the authorization level speci ed.
If this method returns the result IS_AUTHORIZED = TRUE , the calling applications do not normally perform any more
authorization checks. If this method returns the result IS_AUTHORIZED = FALSE , the calling applications normally perform
7/13/2021
more speci c authorization checks.
The aim of this method call is performance tuning, that is the method should return a rough result as quickly as possible. Apart
from the performance point of view, it is unproblematic from an authorization perspective if the method always returns
IS_AUTHORIZED = FALSE because the relevant applicants then perform additional checks. It can become critical, in comparison,
if the method delivers IS_AUTHORIZED = TRUE for users with insufficient authorization because the system grants access
without any additional authorization checks. It is therefore particularly important that this method either is implemented in
accordance with the CHECK_AUTHORIZATION method or always returns IS_AUTHORIZED = FALSE .
What is more, the applications that call these methods assume that the response time is well under a second. Implementations
that check the authorizations of all personnel numbers in the system are therefore especially inappropriate at this point.
CHECK_MAX_INFTY_AUTHORIZATION
This method is similar to the CHECK_MAX_LEVEL_AUTHORIZATION method. The only difference is that it determines whether a
user has maximum authorization for a given infotype and a given authorization level. The remarks on the
CHECK_MAX_LEVEL_AUTHORIZATION are also valid here.
CHECK_MAX_SUBTY_AUTHORIZATION
The same applies for this method as for the CHECK_MAX_INFTY_AUTHORIZATION method except that this method determines
whether a user has maximum authorization for the subtype of a given infotype and a given authorization level.
CHECK_MIN_LEVEL_AUTHORIZATION
This method is called by applications that want to determine whether a user has minimum authorization for an authorization
level. In other words, if the user can access at least one (not necessarily existing) data record of an infotype for a personnel
number for the authorization level speci ed.
If this method returns the result IS_AUTHORIZED = FALSE , the calling applications do not normally perform any more
authorization checks.
The aim of this method call is to prevent users from accessing data as early as possible. In other words, instead of being denied
access to every function he or she performs, a user should not be able to start the relevant transaction in the rst place. As with
checks for maximum authorization, the check only needs to return a rough system response as quickly as possible. Apart from
performance and accessibility points of view, it is unproblematic from an authorization perspective if the method always returns
IS_AUTHORIZED = TRUE because the relevant applicants then perform additional checks anyway. It is problematic if the method
returns IS_AUTHORIZED = FALSE for users who have appropriate authorizations because the system denies access in the
foreground. It is therefore particularly important that you implement this method in accordance with the
CHECK_AUTHORIZATION method or that it always returns IS_AUTHORIZED = TRUE .
What is more, the applications that call these methods assume that the response time is well under a second. Implementations
that search this long for a data record of a personnel number for which authorization exists are, therefore, particularly
inappropriate at this point.
CHECK_MIN_INFTY_AUTHORIZATION
This method is similar to the CHECK_MIN_LEVEL_AUTHORIZATION method. The only difference is that it determines whether a
user has minimum authorization for a given infotype and a given authorization level. The remarks on the
CHECK_MIN_LEVEL_AUTHORIZATION method are also valid here.
CHECK_MIN_SUBTY_AUTHORIZATION
The same applies for this method as for the CHECK_MIN_INFTY_AUTHORIZATION method except that this method determines
whether a user has minimum authorization for the subtype of a given infotype and a given authorization level.
7/13/2021
CHECK_PERNR_AUTHORIZATION
This method is called by applications outside HR master data that want to check if a user should be granted access to a speci c
personnel number. This is problematic from a master data point of view because the personnel number as such is not stored in
HR master data as an object. Master data management recognizes only infotypes. For this reason, the logic of a check on the
access authorization for a personnel number is unclear from a master data perspective. Therefore, the standard system checks
the authorization for the dummy infotype < BLANK > if you use this method.
Instead of this method, some applications call one of the following methods:
CHECK_MAX_PERNR_AUTHORIZATION
This method is called by applications that want to determine whether access authorization exists for all the infotypes/subtypes
of a speci ed personnel number, that is whether a full authorization for access to all data of a personnel number exists. The
standard system implements the check by specifying * in the INFTY and SUBTY elds for the AUTHORITY-CHECK statement.
The system does not check if users can access each existing infotype but if users could access all conceivable infotypes (even if
these infotypes do not exist in the system).
CHECK_MIN_PERNR_AUTHORIZATION
This method is called by applications that want to determine whether access authorization exists for one data record of the
speci ed personnel number, that is whether a minimum authorization for access to at least one data record of the personnel
number exists. The standard system implements the check by specifying DUMMY in the INFTY and SUBTY elds for the
AUTHORITY-CHECK statement. The system does not check if users can access an existing infotype but if users could access any
conceivable infotype (even if this infotype does not exist in the system).
DELAYED_CONSTRUCTOR
The BAdI function does not allow the Constructor to be speci ed in the interface. The DELAYED_CONSTRUCTOR method is used
in the interface for this reason. The method is always processed directly after the constructor. The method interface enables
you to obtain information about the environment of instance creation.
The parameters of this method are the result of very speci c customer requirements that were taken into account when the
interface was developed. It is only meaningful in certain special cases to evaluate these parameters. It is therefore advisable
not to implement this method in most cases and instead to use the normal constructor.
See also:
Examples of the HRPAD00AUTH_CHECK BAdI
Example of the Implementation of HRPAD00AUTH_CHECK
Examples of the HRPAD00AUTH_CHECK BAdI
The following examples are intentionally simple because a description of the complete, new implementation of the
HRPAD00AUTH_CHECK BadI (Business Add-In) would be beyond the scope of this documentation.
1. You have implemented the CHECK_... methods to return IS_AUTHORIZED = TRUE each time. This means that all
authorization checks on HR master data are always positive and consequently, that all users can access all infotypes of
all personnel numbers.
2. You have implemented the CHECK_... methods to return IS_AUTHORIZED = FALSE each time. This means that all
authorization checks on HR master data are always negative and consequently, that no users can access any infotypes of
any personnel numbers. However in Reporting, users who have P_ABAP authorizations with simpli cation degree COARS
= 2 would be able to access infotypes because no authorization check takes place in this case.
7/13/2021
3. You have activated the CL_HRPAD00AUTH_CHECK_STD class delivered in the standard system as BAdI. The
authorization checks behave in dialog as expected. In Reporting, the authorization check would not, however, be
simpli ed for reports for which a P_ABAP authorization with COARS = 1 is stored. The reason for this is that the standard
system uses two classes for the authorization check:
4. CL_HRPAD00AUTH_CHECK_STD and CL_HRPAD00AUTH_CHECK_FAST. If no BAdI is active, the second class is used for
COARS = 1 . If a BAdI is active, the system only checks the authorization with COARS = 2 .
5. You have implemented a class that carries out an authorization check in the constructor for SY-CPROG and COARS = 1
and that delegates all method calls to the CL_HRPAD00AUTH_CHECK_STD class if no authorization exists. If
authorization exists, it delegates all method calls to the CL_HRPAD00AUTH_CHECK_FAST class. In this case the
authorization checks would behave identically in dialog and in Reporting. When input helps are processed, the
authorization check normally processes the methods of the CL_HRPAD00AUTH_CHECK_FAST class instead of the
CL_HRPAD00AUTH_CHECK_STD class for reports with COARS = 1 .
6. You have requirements that cannot be met using the standard time logic and therefore want to implement the following
time logic in your system: The user who is responsible for a personnel number on the current day, should be authorized
to access all data on that personnel number. Other users who are not responsible for this personnel number should not
be authorized to access any data. In addition, the test procedures used up to now should continue to function as before.
You do not use P_ABAP authorizations withCOARS = 1 in your system:
The above-mentioned checks are in principle already contained in the CL_HRPAD00AUTH_CHECK_STD class. You need only
adjust the time logic. You do not want to create a copy of the class and implement this copy because you want to use the class
to implement a complete customer-speci c authorization check in your system. This means that all corrections delivered by
SAP would need to be integrated manually. Since the CL_HRPAD00AUTH_CHECK_STD class already reacts correctly to all write
accesses and also to all read accesses on the current date, you continue to delegate your own checks to this class. However,
change the date each time beforehand to ensure the system returns the desired result. Note the following diagram and the
Example: Implementation of HRPAD00AUTH_CHECK :
Example of the Implementation of HRPAD00AUTH_CHECK
PRIVATE SECTION.
DATA a_auth_check TYPE REF TO if_ex_hrpad00auth_check.
METHOD if_ex_hrpad00auth_check~check_max_infty_authorization.
CALL METHOD a_auth_check->check_max_infty_authorization
EXPORTING
level = level
7/13/2021
tclas = tclas
infty = infty
IMPORTING
is_authorized = is_authorized
EXCEPTIONS
internal_error = 1
invalid = 2.
CASE sy-subrc.
WHEN 1.
RAISE internal_error.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_max_level_authorization.
CALL METHOD a_auth_check->check_max_level_authorization
EXPORTING
level = level
tclas = tclas
IMPORTING
EXCEPTIONS
internal_error = 1
invalid = 2.
CASE sy-subrc.
WHEN 1.
WHEN 2.
7/13/2021
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_max_subty_authorization.
CALL METHOD a_auth_check->check_max_subty_authorization
EXPORTING
level = level
tclas = tclas
infty = infty
subty = subty
IMPORTING
EXCEPTIONS
invalid = 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_infty_authorization.
CALL METHOD a_auth_check->check_min_infty_authorization
EXPORTING
level = level
tclas = tclas
infty = infty
7/13/2021
IMPORTING
EXCEPTIONS
internal_error = 1
invalid = 2.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_level_authorization.
CALL METHOD a_auth_check->check_min_level_authorization
EXPORTING
level = level
tclas = tclas
IMPORTING
EXCEPTIONS
internal_error = 1
invalid = 2.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
7/13/2021
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_subty_authorization.
CALL METHOD a_auth_check->check_min_subty_authorization
EXPORTING
level = level
tclas = tclas
infty = infty
subty = subty
IMPORTING
EXCEPTIONS
invalid = 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~set_org_assignment.
CALL METHOD a_auth_check->set_org_assignment
EXPORTING
tclas = tclas
p0001_tab = p0001_tab
EXCEPTIONS
invalid = 2
internal_error = 1.
7/13/2021
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~set_partial_org_assignment.
CALL METHOD a_auth_check->set_partial_org_assignment
EXPORTING
tclas = tclas
p0001 = p0001
eldlist = eldlist
EXCEPTIONS
invalid = 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_authorization.
DATA l_begda TYPE begda.
DATA l_endda TYPE endda.
IF level CA 'R M'.
* read access --> alter data to get nonstandard behaviour
7/13/2021
l_begda = sy-datum.
l_endda = sy-datum.
ELSE.
* write access --> standard timelogik applies
l_begda = begda.
l_endda = endda.
ENDIF.
CALL METHOD a_auth_check->check_authorization
EXPORTING
level = level
tclas = tclas
pernr = pernr
infty = infty
subty = subty
begda = l_begda
endda = l_endda
process_only_partial_checks = process_only_partial_checks
IMPORTING
EXCEPTIONS
invalid = 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
7/13/2021
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_max_pernr_authorization.
CALL METHOD a_auth_check->check_max_pernr_authorization
EXPORTING
level = level
tclas = tclas
pernr = pernr
IMPORTING
EXCEPTIONS
invalid = 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_pernr_authorization.
CALL METHOD a_auth_check->check_min_pernr_authorization
EXPORTING
level = level
tclas = tclas
pernr = pernr
IMPORTING
EXCEPTIONS
7/13/2021
invalid = 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_pernr_authorization.
DATA l_begda TYPE begda.
DATA l_endda TYPE endda.
IF level CA 'R M'.
* read access --> alter data to get nonstandard behaviour
l_begda = sy-datum.
l_endda = sy-datum.
ELSE.
* write access --> standard timelogik applies
l_begda = begda.
l_endda = endda.
ENDIF.
CALL METHOD a_auth_check->check_pernr_authorization
EXPORTING
level = level
tclas = tclas
pernr = pernr
begda = begda
endda = endda
7/13/2021
IMPORTING
EXCEPTIONS
invalid = 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~delayed_constructor.
ENDMETHOD.
METHOD constructor.
CREATE OBJECT a_auth_check TYPE cl_hrpad00auth_check_std.
ENDMETHOD.
HRBAS00_STRUAUTH (BAdI: Structural Authorization)
De nition
Business Add-In (BAdI) that you can use to implement a customer-speci c test procedure for the structural authorization check.
Use
You can implement a customer-speci c test procedure for general and structural authorization checks using a Business Add-In
(BAdI). The BAdI for the structural authorization check is called HRBAS00_STRUAUTH.
 Note
You can nd the Business Add-In (BAdI) in the IMG for Personnel Management under Organizational Management Basic
Settings Authorization Management Structural Authorization BAdI: Structural Authorization . You can nd information on
implementing a BAdI in the documentation of the corresponding IMG activity.
For general information on Business Add-Ins and their implementation, see also Notes under BAdI: Customer-speci c
authorization checks .
7/13/2021
You can implement the BAdI using the following methods,allof which must be implemented:
CHECK_AUTHORITY_VIEW
FILL_DATE_VIEW
FILL_HYPER_VIEW
CHECK_AUTH_PLAN1
Structure
The following describes the individual methods, which are coordinated using the IF_EX_AUTHORITY_BADI interface. The method
interfaces are stored in the system as documentation of the corresponding methods. Review the method documentation of the
corresponding method if you are implementing a new method or changing method.
CHECK_AUTHORITY_VIEW ( Check Structural Authorization of an Object )
This method checks a user’s structural authorization for an object once the set of authorized objects for this user (VIEW) is
determined.
This implementation should reduce runtime problems if this user should be granted authorization for large structures. This
enables the check to be performed by object type or by user. The authorization check can also be implemented independently of
the VIEW.
FILL_DATE_VIEW ( Fill Table of Authorization Ranges for an Object )
This method lls the interval tables for the intervals that a user has authorization to access an object. The authorization check
can also be performed independently of the VIEW created.
FILL_HYPER_VIEW ( Fill Table of Authorization Relationships )
This method lls the relationship tables (HYPER_VIEW) for relationships that a user has authorization for. The tables can be
lled by object type or by user.
CHECK_AUTH_PLAN1 ( Check Personnel Authorization )
This method checks the structural authorization from a personnel administration perspective (for example, write or read
access) and lls the period tables for which a user has authorization accordingly.
Example
In the BAdI, you can display sample implementation code under Goto Display Sample Coding . You can also view this sample
code in the Class Builder (SE24), by displaying the CL_EXM_IM_HRBAS00_STRUAUTH class and the corresponding methods.
HRBAS00_GET_PROFL (BAdI: Determine Assigned Structural Pro les)
De nition
Business Add-In (BAdI) that you can use to implement an alternative de nition of structural pro les.
Use
7/13/2021
This BAdI is particularly interesting in the context solution : If you use this BAdI, you do not have to maintain the structural
pro les in table T77UA ( User Authorizations ).
 Note
You nd the Business Add-In (BAdI) in the Implementation Guide (IMG) for Personnel Management under Organizational
Management Basic Settings Authorization Management Structural Authorization BAdI: De ne Assigned Structural
Pro les . You can nd information on implementing a BAdI in the documentation of the relevant MG activity.
For general information on Business Add-Ins and their implementation, see also Notes under BAdI: Customer-Speci c
Authorization Checks ..
You can implement the BAdI using the following method, which must be implemented:
GET_T77PR_TAB ( De ne Structural User Pro les )
Structure
The following describes the method that is coordinated by the IF_EX_HRBAS00_GET_PROFL interface.
The method interface is stored in the system as documentation of the corresponding method. Review the method
documentation of the corresponding method if you are implementing a new method or changing method.
GET_T77PR_TAB ( De ne Structural User Pro les ):
This method de nes a user’s structural pro le.
Example
In the BAdI, you can display sample implementation code under Goto Display Sample Coding . You can also view this sample
code in the Class Builder (SE24), by displaying the CL_EXM_IM_HRBAS00_GET_PROFL class and the methods belonging to this
class.
Troubleshooting Authorization Problems
Use
The procedures described in this section are designed to help you analyze problems that arise in connection with
authorizations.
Determining minimum authorization
You can use the following two procedures to determine which authorizations a user requires to carry out a transaction:
1. Set up authorizations for the relevant transaction and for the SU53 transaction for the user. Then call up the transaction
and wait until the authorization check denies you access. Finally, use the SU53 transaction to see what type of
authorization check was carried out. Add the missing authorization and repeat the process. This procedure is simple but
can be fairly lengthy.
2. Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full
authorizations. On the basis of the trace, you can see which authorizations were checked.
 Note
7/13/2021
This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do
ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not
very effective. You can recognize these cases because certain elds of the corresponding programs are speci ed with * or
DUMMY at some point of the authorization check.
Analyzing authorization problems in an unknown program
The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger
breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior.
Determining all the authorizations a user has for an authorization object
When troubleshooting, it is often helpful to nd out all the authorizations a speci ed user has for a speci c authorization object.
A simple method of reading these authorizations as raw data from the user master record is to execute the
GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The
result table is not formatted for output, but is very compact and easy to understand for authorization experts.
Analyzing an authorization problem that occurs for only one user
It is often the case that a certain authorization problem occurs for only one speci c user. This kind of authorization problem
generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing
the HR authorizations, you can add the S_A.DEVELOP authorization pro le (if available) to the user’s authorization pro les. In
production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the
development environment) to access any system data easily (especially in other clients).
Analyzing an authorization problem that occurs for only one personnel number
Authorization problems that occur for a single personnel number are caused almost always by incorrect settings in the
environment of the P_PERNR authorization object.
Authorization problems that are user-independent and occur for a single personnel number are caused almost always by a
specialized organizational assignment (or even an incorrect organizational assignment). In this case, you should check the data
of the Actions (0000) and Organizational Assignment (0001) infotypes and the relationships with the organizational structure
(actively integrated systems) thoroughly.
Analyzing authorization problems in connection with locking and unlocking infotype records
Authorization problems that occur in connection with locking and unlocking infotype records are often caused by the
CHECK_AUTH_SET_ENQ (SAPFP50M) form.
Localizing the cause of authorization problems after the import of HR Support Packages
The majority of code for the HR Master Data authorization check is localized in the CL_HRPAD00AUTH_CHECK_STD and
CL_HRPAD00AUTH_CHECK_FAST classes, the SAPFP50P report, and the HRAC function group. You can also nd smaller parts
of code in the SAPDBPAP, SAPDBPNP, and SAPFP50M reports. If authorization problems are caused by HR Support Packages, a
good place to start looking for changes to the code is in the above-mentioned classes and reports.
Useful questions for solving authorization problems
Over 90% of SAP’s incoming messages about authorization problems are consulting problems. What is more, in many cases
customers are convinced that an error is causing their problems when in fact the problem is due to a misunderstanding of the
functions of the corresponding protection mechanism. When analyzing authorization problems, it is therefore important that
you can answer the following questions:
7/13/2021
What data (which infotype/subtype) did the user access and how (using which transaction or which function of a
transaction)?
How did the system react (did it incorrectly allow or deny access)?
How should the system have reacted (should it have allowed or denied the user access)?
Which authorization main switches are set up in the system?
How are the authorizations for the activated authorization checks set up?
Are the data records of the Organizational Assignment infotype (0001) as they should be for the personnel number in
question?
Constraints
In this section you can nd information about known problems with the authorization check for mySAP HR and solutions to help
you overcome these problems.
See also:
Special Processing of the Authorization Check in Dialog (Master Data)
Special Processing of the Authorization Check in Reporting (Master Data)
Performance Aspects
Redundant Read of Objects
Evaluation Paths with a Non-Speci ed Target Object Type
Context Problems in HR Authorizations
Special Features of the Authorization Check in Dialog (Master Data)
Problem Description I
In the dialog transactions for master data, authorization checks always run from "top to bottom" rst. This means that even if
the check is for read access, the system checks whether write authorization exists for the corresponding data record. The
authorization level is checked in the following order:
1. W (Write) = write access
2. S (Symmetric) = write access using the Symmetric Double Veri cation Principle
3. E (Enqueue) = write access using the Asymmetrical Double Veri cation Principle. E also enables you to create and
change locked records
4. D (Dequeue) = write access using the Asymmetrical Double Veri cation Principle. D also enables you to change the lock
indicator.
5. R (Read) = read access
As soon as the authorization check has run successfully, the result is stored in the buffer and the check is ended.
Consequently, all write authorizations in the dialog also work as read authorizations. However, since there are special modules
that check for read access directly, this can lead to an inconsistent system response.
7/13/2021
Solution I
Ensure that you always specify a read authorization together with the write authorization.
Problem Description II
The order in which the authorization level is checked can have the following additional effect: a user with authorization levels E
and D for a data record, actually needs authorization level E to access the data record in question. Due to the business
importance of authorizations, you would, however, expect this user to have the same authorizations as a user with
authorization level W . This is also the case for users with the combinations E with S and in particular D with S .
Solution II
In future releases, it is planned to carry out this interpretation in a business-oriented sequence rather than the present
technically oriented sequence. For this reason, you should not implement any authorization concepts that are based on the
authorization level combination E , D or S for an infotype for a user.
Problem Description III

The system always checks infotypes with subtypes using the corresponding speci cation of the subtype eld when it accesses
the initial screen for single record maintenance. If you attempt to edit an infotype record without specifying a subtype, the
authorization check is performed using the < BLANK > subtype. This often results in users with limited subtype authorizations
seemingly not being able to access data records.
Solution III
There are two ways to avoid this:
1. Users always explicitly specify a subtype for which they have authorization.
2. Users are granted an additional authorization for the dummy subtype < BLANK > .
 Note
The second option is preferable. In principle, users are not granted any unnecessary authorizations since the < BLANK >
subtype does not exist and is always explicitly checked when users access existing data records and when they create new
data records.
Special Processing of the Authorization Check in Reporting (Master Data)
Problem Description
The SAPDBPNP and SAPDBPAP logical databases are used in many reports. In these reports, they provide certain generic
functions such as selection and the authorization check.
If there is no authorization for data selected on a personnel number, the logical databases cannot determine what the optimal
response to the special request is.
As long as nothing to the contrary is determined in the code, personnel numbers for which all data records except one can be
accessed by users are completely skipped.
Examples
7/13/2021
1. A report that should output only address data can continue to run using partial data of a personnel number.
2. A report that runs evaluations by personnel number generally works best if it can read all the data requested on the
personnel number concerned.
3. A report that generates a set of statistics yields a correct result only if all selected personnel numbers are processed by
the system
Solution
You can use the following procedures if you want to change the behavior of the SAPDBPNP logical database:
1. You can program the logical database not to skip personnel numbers. The data is, nevertheless, only made available to
the relevant reports for the authorization check There is no direct way to access the data that was not read by the
authorization check. This procedure is meaningful for the rst example, but not for the other two examples. The relevant
report implements the setting as follows:
2. INITIALIZATION.
PNP_SW_SKIP_PERNR = 'N'.
3. It is conceivable in examples 2 and 3 that the evaluation would be possible for a certain period but not for a longer
selection period. Normally, the logical database always selects all the data of an infotype and checks the authorization. If
you want the system to read and check only the data of the selection period, you can use the RP_SET_DATA_INTERVALL
macro (for the START-OF-SELECTION period) for this.
4. The data is not requested immediately (addition MODE N for the INFOTYPES statement) and is checked by the report
itself. The report uses the HR_READ_INFOTYP and/or the HR_CHECK_AUTHORITY_INFTY function modules from the
HRAC group to check the data and decides itself how to react to missing authorizations.
 Note
Procedures 1 and 2 are available for SAPDBPNP and are not supported by SAPDBPAP. Procedure 3 is always available.
Procedure 3 is the only way of solving problems with the authorization check if a report requires only one subtype of an
infotype and if users should not be able to access the other subtypes of the infotype.
Performance Aspects
Problem Description
The creation of the set of objects for the structural authorization check can be very time-intensive at runtime if the evaluation
paths are extensive and the organizational structures large. This is due to the fact that the set of objects must be newly
created each time a user starts or changes transaction so that the system can evaluate organizational changes as soon as
possible. Performance problems often occur when structural authorizations are used.
Solution
Performance problems can be avoided for the most part by pre-generating pro les or by de ning the structural authorization
pro les more clearly:
1. You can use the RHBAUS00 report to work with pre-generated pro les.
2. When you de ne structural authorization pro les, avoid above all the following elds, which are described in more detail
together with solutions in:
7/13/2021
Evaluation Paths with Non-Speci ed Target Object Types
Problem Description
Unnecessary performance losses can occur if there are redundancies after the structural authorizations have been de ned,
that is if the entries in the T77PR table ( De nition of Authorization Pro les ) overlap for a user. This is illustrated in the
following example.
Example of an overall pro le that leads to redundant checks:
Pro le Root Object Evaluation Path
Pro le 1: O1 O-S-P ( Staffing Assignment Along

Organizational Structure)
Pro le 2: O1 O_O_S_C ( Position per Organizational

Unit )
This type of pro le (several evaluation paths) is often used to implement authorization requirements that cannot be met using
a standard evaluation path.
In the present example, the pro le needs to contain authorization for organizational units, positions, jobs, and persons. This
combination is not covered by any standard evaluation path, which is why the two evaluation paths mentioned above are used.
However, the creation of the set of objects takes longer because speci c objects (O, S) are read several times:
Evaluation Path O-S-P
O B002 O
O B002 S
S A008 P
Evaluation Path O_O_S_C:
O B002 O
O B003 S
S A007 C
If these two evaluation paths are used simultaneously, organizational units (O) and positions (S) are read redundantly during
the creation of the set of objects.
Solution
You can avoid this by de ning your own evaluation path that meets all the requirements of the pro le and reads the necessary
objects only once. In the present example, you could de ne a Z_O_S_C_P evaluation path, for instance:
Evaluation Path Z_O_S_C_P:
7/13/2021
O B002 O
O B003 S
S A008 P
S A007 C
Evaluation Paths with Non-Speci ed Target Object Types
Problem Description
The use of evaluation paths with an unspeci ed target object type of a relationship is an additional cause of performance
problems, even though the request on the authorization pro le is limited to certain (target) object types, as the following
example illustrates:
Example
Assume that the authorization pro le should determine the permitted persons by organizational unit and position. You can use
the SBESX evaluation path for this:
Evaluation Path SBESX:
O B002 O
O B002 S
S A008 *
If you use this evaluation path, the objects linked with positions are not determined by the de nition of the evaluation path but
according to the T77E table ( Permitted Relationships ).
As a result, all other objects that could be linked to a position (object types BP and US) are also imported to the set of objects.
This is NOT necessary for the current requirement.
Solution
To avoid this, an evaluation path with a speci ed target object type should be used:
The Z_SBESP evaluation path could be used for this example:
O B002 O
O B002 S
S A008 P
Context Problems in HR Authorizations
Problem Description
The technical separation of general and structural authorization pro les can cause context problems for users who perform
different roles in a company (see graphic). This is due to the fact that you cannot simply add any number of structural and
general authorization pro les required for different tasks (in different contexts) without overriding something.
7/13/2021
Example
A user (referred to as manager 1 in this example) is the manager of a team and should be allowed to edit infotypes 0000 –
0007 for the employees in his or her team.
Manager 1 is also Payroll Manager for another organizational structure. In this second role, manager 1 has access to all payroll-
relevant infotypes (0008 and 0015) for the employees in this organizational structure.
The business requirements of the roles Manager and Payroll Manager are represented again in the following overview table:
Business overall pro le of the role Manager :
Objects Type of Authorization
All employees in the manager’s team Full read and write authorization for infotypes 0000 to 0007
Business overall pro le of the role Payroll Manager :
Employees in the organizational structure Full read and write authorization for infotypes 0008 to 0015
This cannot be illustrated without the Context Solution because there is no relationship of any kind between an individual
structural pro le and an individual basis authorization. This leads to overriding.
7/13/2021
You cannot create an assignment between a user’s speci c structural pro le (here, for example, structural pro le 2) and a
speci c general pro le (pro le with P_ORGIN).
What in fact happens is that the structural pro les (that is, the set of objects) and the general pro les are added (in this case,
using P_ORGIN) to give the overall pro le. Consequently, the following effect occurs in the above example: Manager 1 has
complete read and write authorization for all objects in both structural pro les. When the authorization pro les are added
together, the following overall pro le is produced:
All employees in the manager’s team and organizational structure Full read and write authorization for infotypes 0000 to 0008 and for
0015
Workaround
If you use a separate user for each context, it is easier to map different contexts (roles) with the correct authorization.
For example, if Manager 1 wants to perform his activities as Manager of his team, he simply uses his user name. As soon as he
wants to perform his role as Payroll Manager , he needs a second system user (with the respective authorization as in the
above example).
The problem is that you will need many users to map the user-speci c contexts in your company. This is why the context solution
has been developed for HR Master Data.
See also:
7/13/2021
Context Solution
Context Solution
Use
The technical separation of general authorization pro les (based on authorization objects) and structural authorization pro les
can cause context problems . This is due to the fact that you cannot add any number of structural and general authorization
pro les required for different tasks (in different contexts) without overriding something.
You can use the context-sensitive realization of authorizations for HR master data (context solution) to avoid authorizations
from being overridden. The context solution enables you to link individual general and structural authorization pro les to each
other.
Integration
You can implement context authorization objects together with non-context authorization objects (see also Example
Implementation of the Authorization Main Switches ).
Prerequisites
You require the following technical settings for the context solution:
Maintain the context authorization objects using transaction SU21 or PFCG (Role Maintenance):
P_ORGINCON (HR: Master Data with Context)
P_ORGXXCON (HR: Extended Check with Context)
Customer-speci c authorization object for HR master data P_NNNNNCON (HR Master Data: Customer-Speci c
Authorization Object with Context) for the context solution and the appropriate parameterization of the RPUACG00
report.
Settings for the context authorization main switcher using table T77S0:
AUTSW INCON
AUTSW XXCON
AUTSW NNCON
AUTSW DFCON
You can enter the settings of the authorization main switches using the OOAC transaction ( HR: Authorization Main Switch ).
You nd these settings in the Implementation Guide (IMG) for Personnel Administration under Tools Authorization
Management Context Authorization Check Edit Context Authorization Main Switches.
 Note
Note that it is possible to activate AUTSW ORGIN ( HR: Master Data ) with AUTSW XXCON ( HR Master Data: Extended
Check (Context) ), or AUTSW ORGXX ( HR Master Data: Extended Check ) with AUTSW INCON ( HR Master Data (Context)
) simultaneously.
Features
7/13/2021
The context solution creates a technical connection between general structural authorization pro les (based on authorization
objects) and structural authorization pro les using special authorization objects ( P_ORGINCON and P_ORGXXCON ). These
authorization objects differ from the master data authorization objects P_ORGIN and P_ORGXX in that they contain an
additional eld, PROFL , in which you can enter structural pro les.
The context authorization objects enable users to perform as many roles as they want using a single user ID and without
causing the current authorization pro les to be overridden.
 Caution
Note that the structural pro le assigned to a user is de ned from the T77UA table (User Authorizations). Therefore, you
should only enter structural pro les that have been entered in this table in the PROFL eld (Authorization pro le) of the
context authorization objects for user master record maintenance. If you use the HRBAS00_GET_PROFL (BAdI: De ne
Assigned Structural Pro les) Business Add-In (BAdI) , you do not have to maintain then entries in table T77UA. This enables
you to implement an alternative de nition of structural pro les by having the structural pro les de ned from the user maser
record (context authorization objects), for example.
Activities
1. Maintain the context authorization objects you require using transaction SU21 or PFCG.
2. Activate the appropriate context authorization main switch.
Authorization Objects for the Context Solution

7/13/2021
Special authorization objects are used to implement the context solution . These authorization objects differ from the "normal"
master data authorization objects P_ORGIN and P_ORGXX in that they contain an additional eld, PROFL, in which you can
enter structural pro les.
If you want to use a customer-speci c authorization object for the context solution, it must also contain this additional eld.
P_NNNNNCON (HR Master Data: Customer-Speci c Authorization Object 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:
Authorization Field Long Text
INFTY Infotype
SUBTY Subtype
AUTHC Authorization Level
PERSA Personnel Area
PERSG Employee Group
PERSK Employee Subgroup
VDSK 1 Organizational Key
PROFL Authorization Pro le
More Information About the Fields
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 (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.
7/13/2021
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
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
AUTHC Authorization Level
SACHA Payroll Administrator
SACHP Master Data Administrator
SACHZ Time Recording Administrator
7/13/2021
SBMOD Administrator Group
PROFL Authorization Pro le
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 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
P_NNNNNCON (HR Master Data: Customer-Speci c Authorization Object with

Context)
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
7/13/2021
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.
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 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:
Context Authorization Check
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
7/13/2021
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 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_NNNNN (HR: Master Data: Customer-Speci c Authorization Object)
P_NNNNNCON (HR Master Data: Customer-Speci c Authorization Object with Context)
Authorization Main Switches for the Context Solution

For the context authorization check there are context authorization main switches of group AUTSW in table T77S0 ( System
Table ), which enable you to control the use of context authorization objects :
AUTSW INCON (HR Master Data (Context))
AUTSW XXCON (HR Master Data: Extended Check (Context))
AUTSW NNCON (Customer Authorization Object (Context))
AUTSW DFCON (Authorization Check for a Person with Default Position)
You can enter the settings of the authorization main switches using the OOAC transaction ( HR: Authorization Main Switch ).
You nd these settings in the Implementation Guide (IMG) for Personnel Administration under Tools Authorization
Management Context Authorization Check Edit Context Authorization Main Switches.
 Note
Note that it is possible to activate AUTSW ORGIN ( HR: Master Data ) with AUTSW XXCON ( HR Master Data: Extended
Check (Context) ), or AUTSW ORGXX ( HR Master Data: Extended Check ) with AUTSW INCON ( HR Master Data (Context)
) simultaneously.
See also:
Example Implementation of the Authorization Main Switches
AUTSW INCON (HR Master Data (Context))
De nition
7/13/2021
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:
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)).
7/13/2021
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 .
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.
This section provides you with suggestions on how best to set up the authorization main switches if you implement the context
solution .
Example 1
You implement the context solution for all authorization objects:
INCON on ORGPD off ORGIN off
XXCON on ORGXX off
NNCON on NNNNN off
Example 2
You implement a combination of context authorization object and non-context authorization object, for example, ORGINCON
and ORGXX:
INCON on ORGPD on ORGIN off
XXCON off ORGXX on
NNCON off/on NNNNN off/on
Additional Functions for Authorization Checks
In this section you can nd information on the most important reports that play a role for mySAP HR in the context of
authorizations.
7/13/2021
See also:
Report RHPROFL0
Report RHBAUS00 (Regeneration INDX for Structural Authorization)
Report RHBAUS01 (Output of Views on Objects in the Structural Authorization)
Report RHBAUS02 (Check and Compare T77UU (User Data in SAP Memory))
Report RPUACG00 (Code Generation: HR Infotype Authorization Check)
Report RHUSERRELATIONS (Display User Assignments)
RHPROFL0 Report
Use
You can use this report to create authorization pro les for users within an organizational plan. This applies to standard
authorization pro les and to authorization pro les for structural authorizations. In addition, this report assigns user roles and
their pro les.
Features
Using the PROFL0 start evaluation path, the system searches for all users found in the structure and saves them
temporarily. On a key date, starting from these users, the system reads all linked objects that have valid relationships at
this point and for which the Standard Authorization Pro le infotype (1016) and/or the Authorization Pro le for
Structural PD Authorizations infotype (1017) is stored. The system reads all such objects up to the next highest
organizational unit. This means that the higher-level organizational units are not taken into account.
The relevant object types are jobs (C), positions (S), organizational units (O), tasks (T), task groups (TG), work ow
template (WS), work ow tasks (WF), standard tasks (TS), work centers (A) and responsibilities (RY). In addition, all user
roles (AG) and their standard authorization pro les are included.
Then, the report checks whether the users found have already been created in the system. This is necessary because in
the Communication infotype (0105), subtype System user name (0001) of a person, users can be entered that are not
created in the system.
If a user does not exist in the system, it is automatically created. The authorization pro les for all users found in the
organizational plan are then entered.
You can check the results for the standard authorization pro les and user roles using the SU01 transaction. You can
display the structural authorizations using the OOSB transaction.
 Note
For more information about this report, such as setting the report parameters, see the documentation for the RHPROFL0 in
the SAP system.
RHBAUS00 Report (Regeneration INDX for Structural Authorization)
Use
7/13/2021
You can use this report to generate indexes for structural authorization pro les for selected users. By generating indexes, you
achieve much better performance values for users with structural pro les, for which the system must read a large set of
objects.
Prerequisites
You can use this report only for users who are entered in the T77UU table ( Save User Data in SAP Memory ) as a user. You can
make this entry in the Customizing activity Save User Data in SAP Memory (in the Implementation Guide (IMG) for Personnel
Management under Organizational Management Basic Settings Authorization Management Structural Authorizations ).
Indexes for quick access to the organizational structures are available only for these users.
 Note
For information about checking and editing entries in the T77UU table, see also the RHBAUS02 report.
Features
Generating indexes for structural authorization pro les for selected users. You should have the system regenerate the
indexes at night using a batch job for executing the existing report.
 Note
SAP recommends that you execute the report manually for a direct regeneration if you have made changes to the
organizational structure since the last automatic regeneration.
Creating a log that contains a list of the users whose index was regenerated and the number of objects that were
included in the index for a user.
 Note
For more information about this report, see the report documentation in the SAP system.
RHBAUS01 Report (Output of Views on Objects in the Structural Authorization)
Use
You can use this report to perform a comparison of the INDX ( INDX System Tables ) and T77UU ( Save User Data in SAP
Memory ) tables.
Features
The report generates a list of users who have data of the structural authorization in the SAP Memory but who are no
longer entered in the T77UU table.
The report also enables you to delete the entries of the users no longer in the T77UU table from the INDX table.
RHBAUS02 Report (Check and Compare T77UU (User Data in SAP Memory))
Use
7/13/2021
You can use this report to enter users with authorization for a large number of objects in the T77UU table ( User Data in SAP
Memory ). This improves performance because the system saves the objects of the structural authorization in SAP Memory for
the users entered in this table, which makes the authorization check run quicker.
 Note
It is only meaningful to enter users in this table who have authorization for a large number of objects.
Features
The existing report enters users in the T77UU table or deletes users from this table if they have too small a number of objects
depending on a threshold value. You can de ne the threshold value for the report.
The report can then automatically perform the Save User Data in SAP Memory Customizing activity.
 Note
RPUACG00 Report (Code Generation: HR Infotype Authorization Check)

Use
You can use this report to generate the necessary ABAP code for a customer-speci c authorization object that is to be included
in the HR infotype authorization check (using the MPPAUTZZ report).
If you want to implement the context solution , that is create a customer-speci c authorization object that contains the PROFL
eld, you must select the With Context Solution parameter on the report’s selection screen.
This generates the ABAP code for the customer context authorization object that you have newly created (using the Include
MPPAUTCON).
 Note
See also:
Report RHUSERRELATIONS (Display User Assignments)
Use
You can use this report to evaluate all existing HR authorization pro les of a user.
This includes structural authorization pro les and the HR Basis authorization pro les that are assigned to the user directly
(using role maintenance) or indirectly (using Organizational Management ).
Features
7/13/2021
You can access a range of functions in this report that enable you to perform a targeted evaluation of the authorization pro les.
You can display the following information:
the complete list of authorization main switches and the speci ed values (in the selection screen using the function bar)
all persons assigned to the user in the Communication infotype (0105) (in the selection screen using the function bar)
the organizational units that the user is related to
the structural authorization pro les
the user’s role assignments and standard pro les
the authorizations on the basis of HR authorization objects (in Personnel Administration/Personnel Planning – multiple
selection is possible here)
In addition, you can execute the report directly or in the background.
Selection
On the selection screen, you can choose one of four different options by selecting the relevant radio button each time you
execute the report (no multiple selection possible):
Related Organizational Units
If you select this radio button and choose Execute , the report evaluates all relations between user and organizational units. The
report determines:
the organizational units to which the user belongs (using the ORGASS evaluation path)
the organizational units for which the user is the manager (using the MANASS evaluation path)
Structural Pro les
If you select this radio button and choose Execute , the report evaluates the tables for structural pro le maintenance:
table T77PR in which structural pro les are maintained
table T77UA in which the user assignment of structural pro les takes place
In the output list, you can choose between displaying a Pro le View and a User View :
in the Pro le View , all objects belonging to the structural pro le that you selected in the output list are displayed
in the User View , the objects for which the user is authorized are displayed
 Note
If a function module is used in a structural pro le, all root objects that this function module determines are also displayed.
Roles and Standard Pro les
If you select this radio button and choose Execute , the report evaluates the following:
all roles assigned to the user directly by transaction PFCG (role maintenance)
7/13/2021
all standard pro les the user has access to indirectly because of his or her relationships to an organizational
unit/position
The 007 relationships "described" to the Role object type and to the Standard Pro les infotype (1016) of the related
organizational unit/position are evaluated.
Display HR Authorizations
If you select this radio button and choose Execute , you must also select at least one HR Basis authorization object from the
following list to ensure the authorizations belonging to it are displayed for the user (no multiple selection possible):
P_ORGIN (HR: Master Data)
P_ORGXX (HR: Master Data – Extended Check)
P_ORGXXCON (HR: Master Data - Extended Check with Context)
P_PERNR (HR: Master Data – Check by Personnel Number)
P_ABAP (HR: Reporting)
PLOG (Personnel Planning)
Output
According to the option you selected, the output is a table screen, which contains the current authorization pro le data.
Activities
1. Enter the user name.
2. Using the radio button, choose one of the four evaluation options Related Organizational Units, Structural Pro les,
Roles and Standard Pro les, or Display HR Authorizations .
3. If you want to display the HR Basis authorizations, also select one or more authorization objects.
4. Choose Execute .
Authorizations for BI Content for Human Resources
Use
As of SAP NetWeaver 7.0 there is a new authorization concept for analysis authorizations in SAP NetWeaver that can also be
used for BI Content for Human Resources.
In the Human Resources area, in addition to the SAP standard authorization concept, structural authorizations are also used,
which can be extracted in BI Content.
If you decide to use the new analysis authorization concept of SAP NetWeaver, you can extract the structural authorizations
from the back end and reuse them as the basis for your analysis authorizations.
For more information on the new SAP NetWeaver authorization concept, see Analysis Authorizations and Migration of
Reporting Authorizations to the New Concept for Analysis Authorizations .
Prerequisites
7/13/2021
The following prerequisites apply to using the new SAP NetWeaver authorization concept for Human Resources:
You have selected the new authorization concept. For this setting, see the BI system inSAPCustomizing and choose
SAPNetWeaver Business Intelligence Settings for Reporting and Analysis General Settings for Reporting and
Analysis Analysis Authorizations: Select Concept .
You have performed the Customizing activities described in the BI system inSAPCustomizing under
SAPNetWeaver Business Intelligence Settings for BI Content Human Resources HCMAuthorizations for BI Content.
The required users must exist in both systems (BI system and back-end system).
At least one of the following InfoObjects should be selected as authorization relevant in the BI system using transaction
RSD1 (on the tab Business Explorer under General Settings ):
Characteristic Organizational Unit ( 0ORGUNIT )
Characteristic Employee ( 0EMPLOYEE )
Characteristic Position ( 0HRPOSITION )
Features
For the structural authorization check there is a purpose-built transformation from the DataSource 0HR_PA_2 to the
DataStore object Structural Authorization ( 0PA_DSO2 ). This transformation has the following logic:
Only entries for objects relevant for authorization are considered.
Only those objects are considered for which existing users are created in the BI system.
Since the new authorization logic cannot interpret * (= authorization for all objects of every object type), in the
transformation, such a data record is replaced with a record of each authorization relevant object type with
authorization for all objects. Thereby, the quantity of all authorization relevant objects/characteristics is determined
before the transformation (only 3 characteristics are checked: 0EMPLOYEE = object type P , 0HRPOSITION = object
type S , 0ORGUNIT = object type O ).
Additionally, the authorization HRTMC_ SPEC _DIM is assigned in the BI system for every authorization relevant user.
This authorization contains special authorizations for reading data from InfoProviders and refers to the characteristics
Activity ( 0TCAACTVT ), InfoProvider ( 0TCAIPROV ), Validity ( 0TCAVALID ), and Key Figure in Analysis Authorizations
( 0TCAKYFNM ):
These characteristics are indicated as authorization relevant from the outset:
You can use the characteristic Activity ( 0TCAACTVT ) to restrict the authorization to various activities. Read ( 03
) is set as the default activity.
You can use the characteristic InfoProvider ( 0TCAIPROV ) to restrict the authorization to individual
InfoProviders. The default value asterisk ( * ) provides authorization for all InfoProviders.
You can use the characteristic Validity ( 0TCAVALID ) to restrict the validity of an authorization. 'Always valid' ( *
) is set as the default value for validity. You can restrict this validity.
The characteristic 0TCAKYFNM is the special characteristic for key gure authorizations. The system creates
authorizations for this characteristic and checks whether key gure authorizations are required. No hierarchy
authorizations may be used for 0TCAKYFNM . The default value asterisk ( * ) provides authorization for all key
gures.
 Note
This characteristic replaces the technical characteristic 1KYFNM of the previous concept for reporting
authorizations. As soon as this characteristic is relevant for authorization, it is always checked so that you
7/13/2021
should only select it as relevant for authorization after careful consideration.
For more information, see Authorization Dimension .
You have two options for adjusting this authorization:
1. You can change the end method of the transformation in such a way that each user has suitable authorization after
authorization objects have been generated.
2. You can use the transaction RSECADMIN to change/adapt the special authorization HRTMC_ SPEC _DIM manually after
the generation process for all authorizations. This process is necessary after each new generation.
Activities
For the conversion, proceed as follows:
1. Delete all data from the DataStore object (DSO) Structural Authorizations (0PA_DS02).
 Note
Note
This rst step only applies to customers that had already extracted the structural authorizations for the concept for
reporting authorizations and have now decided to use the new concept for analysis authorizations. However, you
must perform the following steps, even if you are introducing analysis authorizations for the rst time.
2. Transfer the new transformation (RSDS 0HR_PA_2 C5ZCLNT070 ODSO 0PA_DS02) from the BI Content.
3. Start the data transfer process to load the data from the DataSource Structural Authorizations ( OHR_PA_2 ).
4. In the transaction RSECADMIN, under Generation , enter the DataStore object 0PA_DS02 for the at authorization and
generate the authorization objects.
5. Use transaction RSECADMIN to check the generated objects.
6. If required, adapt the authorization HCM _ SPEC _DIM .
 Note
Furthermore, you can perform the following steps at query level:
You can create an authorization variable for the characteristics indicated as relevant for authorization, for example,
for the characteristic Organizational Unit ( 0ORGUNIT ), and include it in your customer queries for the characteristic
restrictions. This variable evaluates the analysis authorization and uses these values as lters in the query
evaluation.
 Example
You create a lter variable for the lter characteristic Organizational Unit . Enter the following under Global Settings :
Type of Variable : Characteristic Value
Processing By : Authorization
Reference Characteristic : Organizational unit
See also:
Authorizations
7/13/2021

Authorizations in HCM 2

Uploaded by

Document Information

Original Description:

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 2

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

HRPAD00AUTH_CHECK (BAdI: Customer-Speci c Authorization Checks)

HRBAS00_GET_PROFL (BAdI: Determine Assigned Structural Pro les)

HRPAD00AUTH_CHECK (BAdI: Customer-Speci c Authorization Checks)

You can implement this BAdI using the SE19 transaction.

Examples of the HRPAD00AUTH_CHECK BAdI

Example of the Implementation of HRPAD00AUTH_CHECK

Examples of the HRPAD00AUTH_CHECK BAdI

Example of the Implementation of HRPAD00AUTH_CHECK

DATA a_auth_check TYPE REF TO if_ex_hrpad00auth_check.

CALL METHOD a_auth_check->check_max_infty_authorization

CALL METHOD a_auth_check->check_max_level_authorization

CALL METHOD a_auth_check->check_max_subty_authorization

CALL METHOD a_auth_check->check_min_infty_authorization

CALL METHOD a_auth_check->check_min_level_authorization

CALL METHOD a_auth_check->check_min_subty_authorization

CALL METHOD a_auth_check->set_org_assignment

CALL METHOD a_auth_check->set_partial_org_assignment

DATA l_begda TYPE begda.

DATA l_endda TYPE endda.

IF level CA 'R M'.

* read access --> alter data to get nonstandard behaviour

* write access --> standard timelogik applies

CALL METHOD a_auth_check->check_authorization

CALL METHOD a_auth_check->check_max_pernr_authorization

CALL METHOD a_auth_check->check_min_pernr_authorization

DATA l_begda TYPE begda.

DATA l_endda TYPE endda.

IF level CA 'R M'.

* read access --> alter data to get nonstandard behaviour

* write access --> standard timelogik applies

CALL METHOD a_auth_check->check_pernr_authorization

CREATE OBJECT a_auth_check TYPE cl_hrpad00auth_check_std.

HRBAS00_STRUAUTH (BAdI: Structural Authorization)

CHECK_AUTHORITY_VIEW ( Check Structural Authorization of an Object )

FILL_DATE_VIEW ( Fill Table of Authorization Ranges for an Object )

FILL_HYPER_VIEW ( Fill Table of Authorization Relationships )

CHECK_AUTH_PLAN1 ( Check Personnel Authorization )

HRBAS00_GET_PROFL (BAdI: Determine Assigned Structural Pro les)

GET_T77PR_TAB ( De ne Structural User Pro les )

GET_T77PR_TAB ( De ne Structural User Pro les ):

This method de nes a user’s structural pro le.

Troubleshooting Authorization Problems

Determining minimum authorization

Analyzing authorization problems in an unknown program

Determining all the authorizations a user has for an authorization object

Analyzing an authorization problem that occurs for only one user

Useful questions for solving authorization problems

Which authorization main switches are set up in the system?

Special Processing of the Authorization Check in Dialog (Master Data)

Special Processing of the Authorization Check in Reporting (Master Data)

Redundant Read of Objects

Evaluation Paths with a Non-Speci ed Target Object Type

Context Problems in HR Authorizations

Special Features of the Authorization Check in Dialog (Master Data)

1. W (Write) = write access

5. R (Read) = read access

Problem Description III

Special Processing of the Authorization Check in Reporting (Master Data)