Page tree
Skip to end of metadata
Go to start of metadata


This document would help you to understand the functionality of Central Delegation, in which tables data gets stored, what is the flow of code while reading the data and most important how we can debug the same in case of any problem.

Central Delegation Overview

Central Delegation functionality helps you to delegate your responsibilities to someone else for a specific period of time. Using below link in NWBC or Portal, you would be able to create your new delegation, change existing one and delete future delegations.

At the time of maintaining the Central Delegation data, you need to give the Delegator (whose responsibilities needs to be delegated) and Delegate (receiving user who is going to receive the delegated responsibilities) with start date and end date information.




Flow of Central Delegation data

Once we maintain any central delegation data, system stores the data into 'HRUS_D2' table. This table stores all the delegation records. All the expired delegation records stay in this 'HRUS_D2' table with X value in ACTIVE column. However, Central Delegation would show only the current or future End Date records.

For example, if delegation record was applicable from 1st Jan, 2014 to 31st Jan, 2014 and today is 1st Feb, 2014, Central Delegation list would not have this record in the list. Only 'HRUS_D2' table would have this record with X value in ACTIVE column for historical information.

All the users listed in 'HRUS_D2' table would be available in SU01 users list. If any user is deleted from SU01, same would be deleted from 'HRUS_D2' table and further same would be deleted from Central Delegation list.

Dealing with Central Delegation data

There are 3 different scenarios under which data can be stored with different periods and only Current or Future applicable records would be shown in the Central Delegation list.

  1. Delegation record with Future Start Date and Future End Date :- This kind of data can be maintained for future delegation usage. This data can be easily deleted from the list without any issue as this delegation is not yet used anywhere.
  2. Delegation record with Past/Current Start Date and Future End Date :- This kind of data could be the example of current delegation usage. It represents that Delegator has delegated all the authorizations to the Delegate till Future End date. This record cannot be deleted as this would become the part of Historical data.
    In case where Delegator has left the department/organization and not a GRC user any more, Delegation record would not changed automatically. This needs to be delimited manually via adjusting the End Date as current date.
  3. Delegation record with Past Start Date and Past End Date :- This kind of records would not be listed in the Central Delegation list and would become the Historical data. However, this can be find in 'HRUS_D2' table with X value in ACTIVE column.

Debugging techniques

  • Get the information, whether records are coming 'HRUS_D2' table properly.

Use webdynpro 'GRFN_DELEGATION' ==> Go to 'COMPONENTCONTROLLER' ==> Go to INIT_UI method ==> Go inside the 'query' method of class cl_grfn_api_dl_master.


Then double click on List method.

Under list, double click on Load_buffer method.

Here, all the records are getting read from 'HRUS_D2' table and stored into LT_DELEGATE internal table.

During debugging, we can check whether this is an issue with 'HRUS_D2'  table records or GRC code logic further.


  • Central Delegation checks whether user is a GRC user (means whether user has GRC role/authorizations) while creating/saving/modifying the data. Below method can help to check the same.

'Query' method of class CL_GRFN_UTIL_USER is checking whether user is a GRC user using method 'IS_GRC_USER'. Result of LV_GRC_USER can be checked at the time of debugging. Similarly, IS_EXISTING_DELE_USER method can be used to find whether user is already part of 'HRUS_D2' table.


  • No labels