One of the strengths of the HR module is its complete integration with data that is generated by other SAP modules. For better or worse, what this usually means is that non-HR users share the same physical database with HR users. For this reason, R/3 provides a full set of HR authorization objects and HR-specific security frameworks to ensure that sensitive HR data is invisible to those who are not authorized to see it.

One of the first questions typically posed during a project when SAP HR security comes into focus is, “Does SAP support field-level security for HR information?” The answer is both yes and no. Straight out of the box, SAP may not support “field-level security” to the degree that most users expect. However, I’m going to show you how to control exactly which fields an SAP user actually sees or has access to in HR infotype screens.

This article demonstrates how to use standard SAP infotype screen control configuration coupled with custom ABAP code to strictly and precisely control what fields appear on HR infotype screens for each user. All the examples and code snippets are from an SAP HR 4.6C system, but should function in older releases with minimal or no changes.

Scenario: “I want User A to see fields X, Y, and Z on infotype nnnn, but I want User B to see only field X.”

HR data access is normally handled in a binary fashion when dealing with HR and non-HR users – i.e., the user has or does not have access to HR infotype data and transactions. For this article, the assumption is that you are dealing with SAP users that for business reasons have already been granted access to SAP HR infotype transactions such as display or maintain HR master data (transaction codes PA20/PA30). The problem is how to determine and control what HR data is visible to each of these different users in those transactions.

Table 1 lists examples of scenarios in which non-HR users may need access to HR infotype data. It is often beneficial to give non-HR users access to employee information to better fulfill their job requirements. After all, part of the benefit of R/3’s integrated database is that cross-functional data, including some HR data, should be readily available to the users who need it.

I’m using infotype 0002 (personal data) for all the examples in this article. The goal is to present two different screen layouts to the appropriate users – one with access to sensitive HR data fields and one without. Figures 1 and 2 show the two different infotype 0002 screens.

Figure 1

User A's unrestricted view of infotype 0002, with access to sensitive HR data fields

Figure 2

User B's restricted viewof infotype 0002, without access to sensitive HR data fields

Table 2 is a summary of the main requirements and desired outcomes for User A and User B.

Solution: Create and Configure Multiple Infotype Screens

Standard R/3 HR functionality provides a framework through which different infotype screen configurations (i.e., list of what fields are visible, editable, etc.) can be displayed under different circumstances. In Release 4.6C, this functionality is configured via the IMG menu path Personnel Management> Personnel Administration> Customizing User Interfaces>Change Screen Modifications (Figure 3).

Figure 3

Customizing step Change Screen Modification

The R/3 system goes through the following process to decide which screen to present to the user when the display or maintain HR master data transactions are invoked:

• User or application calls up HR infotype display or maintenance transaction.
• Before the appropriate screen is displayed, R/3 queries the corresponding infotype screen control feature Pnnnn, where nnnn represents the infotype number.
• Decision logic is executed in the feature Pnnnn. The outcome of that decision logic is a variable key that is matched against the available entries in table T588M (infotype screen control).
• The resulting match in table T588M determines which screen layout is presented to the user.

Keep in mind that you can use this method not only to show and hide fields, but also to make them optional, required, read-only, or initial. Each screen configuration is assigned a unique Variable key identifier that corresponds to the return value of the screen control feature.

For my example, the screen configuration represented by Variable key 10 in Figure 3, on page 3, has all the sensitive HR fields marked as hidden (Figure 4). The screen configuration represented by Variable key 10HR in Figure 3 has these same fields marked as visible. All other field attributes for these two screen configurations are the same. The value of P0002 in the Feature column indicates that the feature P0002 is responsible for determining which screen to present to the user. You maintain the decision logic of the feature via transaction PE03.

Figure 4

Screen represented by Variable key 10, restricted view of infotype 0002

Configure Screen Control Feature

To provide the desired field-level security, R/3 needs to be able to present the right infotype 0002 screen to the right user at the right time. The key to this solution is the return value from the screen control feature, P0002 in this case. However, as you can see in Figure 5, the standard available fields upon which R/3 can make a screen choice decision are mostly related to the employee whose record is being accessed and not to the user who is attempting to access the HR infotype data. To meet the goal of this article, R/3 needs to be made aware of the user’s attributes before it can make the decision about which infotype screen to present. Simply put, I want R/3 to decide which screen to present based on the user’s attributes, and not the attributes of the employee whose record is being accessed. The feature decision logic must be able to query the user’s attributes and return a pointer either to the restricted or unrestricted infotype 0002 screen layout.

Figure 5

Standard feature decision operation fields from strucure PME04 for infotype screen control

Infotype screen control features use some or all of the decision operation fields from the structure PME04 (field string for feature — screen control). During infotype transaction processing, the values of this structure are filled with data from the employee that the user is attempting to access. This step happens during infotype processing and before any infotype screen is presented to the user. The data in this structure is then made available to the infotype screen control feature to determine which screen is presented to the user. Screen control decisions are therefore limited to the values in the fields of this structure.

Limitations of Standard SAP Screen Control Configuration Feature

As you can see in the structure of PME04, it is not possible through standard SAP to make screen control decisions based on the attributes of the user. Although the structure field User group (USERG) is available and related to the user and not the employee, it is not a suitable choice. The USERG field corresponds to the parameter ID UGR, user group (HR master data), in the user’s SAP user profile. Parameter IDs are used to store default values that are supplied to R/3 fields. The main reasons why the USERG/UGR field is not a good field upon which to make a screen control decision are as follows:

• If user access to maintaining parameter IDs is not restricted, a user can change the user group value and thus gain access to a restricted infotype screen layout.
• The user group parameter ID must be maintained each time a user is granted or denied restricted HR infotype screen access — e.g., User A works in the HR department and is allowed access to the restricted HR infotype screens, then User A moves on to become a manager with access to HR data. If the user group value is not changed in User A’s user profile, access to the restricted HR infotype screens will still be available.
• The parameter ID UGR already has a business and configuration meaning in the area of infotype menu configuration, and the infotype menu configuration logic may not coincide with its potential use here in the area of screen control.
• User parameter ID functionality is designed to facilitate repetitive data entry by the user. User parameters supply defaults to R/3 fields. As such, it is easily accessible and modifiable by the general user through the menu path System>User Profile>Own Data or the transaction code SU1. This functionality is not typically restricted by authorization settings.

Link R/3 User to HR Employee Information

In order to be able to query useful user attributes, a link must exist between users and their SAP HR employee information. A subtype of the standard infotype 0105 (communication) provides the link. By default, this subtype is 0001, system user name (SY-UNAME). (See Figure 6.) This solution therefore requires that the communication infotype be populated for any and all SAP users that are restricted via this method.

Figure 6

Determining which infotype 0105 subtype corresponds to the SAP user ID

Once the link is established, it is possible to query in code the user’s HR employee information to make the appropriate screen control decisions.

Write Custom ABAP Logic

Now that the desired screens have been configured and the link established between user and employee data, the custom logic to determine which screen to present needs to be written. This custom logic will be customer-specific according to company-specific business requirements.

Create a custom ABAP source code object including the subroutine shown in Figure 7 to hold the custom screen control business logic.

*———————————————————————————————————*
*       FORM EXT_CALL_F                                                
*———————————————————————————————————*
*  —>  NAMEN     Feature name from feature editor &xxxxx              
*  <—  BACK      Feature return value
*  <—  STATUS    Returncode 0 :                         2 : ERROR                                 
*———————————————————————————————————*
FORM CALL_549B USING BACK STATUS STRUC STRUCTURE struc 
... 
*-> customer logic to determine and return screen control variable 
*-> key value via FORM parameter BACK
... 
ENDFORM.

There is virtually no limit to the logic that can be programmed to determine which screen value R/3 returns to the user. All you have to do is write the custom code to return the appropriate variable key value to the R/3 screen modification processing that points to the desired screen configuration. You do this by filling the return parameter BACK in the custom ABAP FORM routine CALL_549B.

For example, start with the system variable SY-UNAME and look up the matching employee record via infotype 0105. Once you have the employee key number (PERNR) for the user, you can now query, via ABAP, any organizational or other attributes of the user using this employee key. You could present the unrestricted infotype 0002 view to all users who belong to the organizational unit (P0001-ORGEH) “Human Resources” as determined by the user’s infotype 0001 (organizational assignment). Additional permitted non-HR users can be defined based on a set of known (i.e., hard-coded) job key codes (P0001- STELL) from infotype 0001 or even simply based on their SAP user IDs (SY-UNAME) if the user does not have an employee record in the system, e.g., a temporary data entry clerk or contract consultant.

Whatever value is placed in the BACK return parameter of the subroutine is processed as the variable key used in customizing table T588M to determine the appropriate screen layout presented to the user. If the result of the custom logic places 10 into the BACK parameter, then the restricted infotype 0002 screen is displayed. If the BACK parameter contains 10HR, then the unrestricted infotype 0002 screen is presented to the user. See the sample code in Figure 8 for more details.

*&——————————————————————————————————-*
*& Module pool       ZP_SCREEN_CONTROL_HR                              *
*&                                                                     *
*&——————————————————————————————————-*
*& Author: Graham Wong, DataCarver Systems, Inc.                       *
*& Date Created: 170MAR2003                                            *
*                                                                      *
*  Description: FORM routine to carry out custom logic for surpressing *
*               Innnn screen fields. Determine PSA of SAP user by      *
*               linking through I0105/0001 subtype SY-UNAME to obtain  *
*               PERNR. Use PERNR to read I0001 for PSA or BTRTL. If not*
*               HR then return variable key for restricted screen in   *
*               T588M via feature Pnnnn.                               *
*     19MAR2003 reorganized checks and added check of STELL/PLANS      *
*     17MAR2003 added generic check for non-employee user id to have   *
*               access to HR enabled screens                           *
*&——————————————————————————————————-*
PROGRAM  ZP_SCREEN_CONTROL_HR          .
INCLUDE DBPNPCOM.
INFOTYPES: 0001.                       “organizational assignment
TABLES: PA0105.                        “communications infotype
*———————————————————————————————————*
*       FORM EXT_CALL_F                                                *
*———————————————————————————————————*
*  —>  NAMEN     Feature name from feature editor &xxxxx              *
*  <—  BACK      Feature return value
*  <—  STATUS    Returncode 0 :                                       *
*                            2 : ERROR                                 *
*———————————————————————————————————*
FORM EXT_CALL_F USING NAMEN BACK STATUS PME04 STRUCTURE PME04.
  DATA: UNAME LIKE SY-UNAME,
        KEYDATE LIKE SY-DATUM,
        PERNR LIKE PERNR-PERNR,
        RETCD LIKE SY-SUBRC,
        subty like p0006-subty.
*       len type i.
  CLEAR PERNR.
  IF NOT ( SY-UNAME IS INITIAL ).
    UNAME = SY-UNAME.
    KEYDATE = SY-DATUM.
  ENDIF.
*1> determine valid P0105 subtype for SAP userid from T77S0
  IF subty IS INITIAL.
    CALL FUNCTION ‘RH_GET_HR_USER_SUBTY’
         IMPORTING
              hr_subty              = subty
         EXCEPTIONS
              subtype_not_available = 1
              OTHERS                = 2.
    IF sy-subrc <> 0 OR subty IS INITIAL.
      subty = ‘0001’.
    ENDIF.
  ENDIF.
*2> find PERNR from SY-UNAME
  SELECT SINGLE * FROM PA0105 WHERE USRTY = subty AND
                                    USRID = UNAME AND
                                    BEGDA LE KEYDATE AND
                                    ENDDA GE KEYDATE.
  IF SY-SUBRC EQ 0.
    PERNR = PA0105-PERNR.
*3> read I0001 of SAP logon user!
    RP-READ-INFOTYPE PERNR 0001 P0001 KEYDATE KEYDATE.
    IF PNP-SW-FOUND EQ 1.              “P0001 found!
*4> check BTRTL for HR association
      PERFORM CHECK_BTRTL USING p0001-btrtl
                                RETCD.
      if retcd is initial.
        BACK = ‘10HR’.               “variable key for T588M
      else.                         “BTRTL HR* not found!
*5> if BTRTL does not contain HR*, then check for hard-coded
*-> job/position listing for satellite locations!
        perform check_job_position using p0001-stell
                                    p0001-plans
                                    retcd.
        if retcd is initial.
          BACK = ‘10HR’.             “variable key for T588M
        else.
*6> final check is against hard-coded list of userids
          perform check_userid using uname
                                   retcd.
          if retcd is initial.
            back = ‘10HR’.
          else.
            BACK = ‘10’.             “restricted screen fields
          endif.
        endif.
      endif.
    else.                            “no valid P0001 found
      BACK = ‘10’.                   “restricted screen fields
    endif.
  ELSE.                              “no valid I0105 record available!
*7> generic HRTEMP* user id used for those HR users who are not in HR
*   master and therefore are not true employees (i.e., able to have
*   I0105/0001 entries)
    IF UNAME CP ‘HRTEMP*’.
      BACK = ‘10HR’.                 “unrestricted screen
    elseif uname = ‘GWONG’.
      back = ‘10HR’.
    ELSE.
      BACK = ‘10’.                   “restricted screen fields
    ENDIF.
  endif.
ENDFORM.
*&——————————————————————————————————-*
*&      Form  CHECK_BTRTL
*&——————————————————————————————————-*
*       text
*———————————————————————————————————*
*      —>P_PERNR  text                                                *
*      —>P_RETCD  text                                                *
*———————————————————————————————————*
FORM CHECK_BTRTL USING    btrtl
                          RETCD.
*-> HR BTRTL = HR* , note must change if config. changes!
  IF BTRTL cp ‘HR*’.
    RETCD = 0.                       “HR variable key, 10HR
  ELSE.
    RETCD = 1.                       “restricted variable key, 10
  ENDIF.
ENDFORM.                               “ CHECK_BTRTL
*&——————————————————————————————————-*
*&      Form  check_job_position
*&——————————————————————————————————-*
*       text
*———————————————————————————————————*
*      —>P_PERNR  text
*      —>P_KEYDATE  text
*      —>P_RETCD  text
*———————————————————————————————————*
FORM check_job_position USING    stell
                                 plans
                                 RETCD.
*-> check hard-coded list of HR-related jobs/positions
    that do not have
*-> BTRTL of HR*
*-> STELL/job 99991758, references HR clerk positions 
    at site A
*-> PLANS/position 99996627, references single HR clerk
    position at site B
*-> PLANS/position 99992470, references Manager
    Payroll at site C
  if stell = ‘99991758’.
    clear: retcd.
  elseif ( plans = ‘99992470’ or plans = ‘99996627’ ).
    clear: retcd.
  else.
    retcd = 1.
  endif.
ENDFORM.                    “ check_job_position
*&——————————————————————————————————-*
*&      Form  check_userid
*&——————————————————————————————————-*
*       text
*———————————————————————————————————*
*      —>P_UNAME  text
*      —>P_RETCD  text
*———————————————————————————————————*
FORM check_userid USING    _UNAME
                           _RETCD.
*-> hard-coded userid listing of users allowed to see HR data
  case _uname.
    when ‘YODA’.
      clear: _retcd.
    when others.
      _retcd = 1.
  endcase.
ENDFORM.                    “ check_userid

Modify the Appropriate Screen Control Feature Pnnnn

The final step is to link the custom business logic in your custom ABAP code to the standard screen modification processing configuration. Use transaction code PE03 (feature editor) to maintain the appropriate feature, P0002 (personal data infotype screen control) in my example, to reference the custom ABAP subroutine using the program operation method. (See Figure 9) By referencing the custom ABAP code object, ZP_SCREEN_CONTROL_HR in Figure 9, you are telling R/3 to use the logic contained in this code to determine the feature return value.

Figure 9

Linking custom code contained in object ZP_SCREEN_CONTROL_HR to standard screen processing logic in feature P0002

If there are no bugs in your ABAP code or syntax errors in your feature for screen control, all should be ready and working. Simply create two user IDs that are associated to employee records that have different user/employee attributes and run the display or maintain HR master data transactions. If the user possesses the appropriate attributes to have an unrestricted view of the infotype data fields, as determined by the custom ABAP logic, then an unrestricted infotype screen should be presented to the user.

For More Information

You can find mySAP HR documentation on HR-specific security and authorizations in the R/3 Enterprise release at https://service.sap.com/hr, under the topic Services for mySAP HR > Special Documentation.

Information on setting up user interfaces in HR can be found under the IMG menu path Personnel Management > Personnel Administration > Customizing User Interfaces > Change Screen Modifications.

Information on developing custom feature decision tree logic can be found at: SAP Help Library>Human Resources > HR Tools (PY-XX-TL) > Features Editor > Feature > Decision Tree for a Feature > Additional Information on Program Operations.

Graham Wong

Graham Wong is a consultant and co-founder HR Focal Point, an SAP and technology consulting company. He has been working with SAP applications and technology since 1994. He holds bachelors degrees in commerce and French from the University of Virginia as well as a master's degree in management information systems from the McIntire School of Commerce at the University of Virginia.

You may contact the author at graham.wong@hrfocalpoint.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.