Ramp-up documentation CUSTOMER

Payroll Control center

Document Version: 1.0 2014-07-18

Payroll Control Center

Contents
1 About this guide........................................................................................................................................... 5
2 Introduction to the payroll control center................................................................................................. 6
2.1 The payroll process manager ............................................................................................................. 7
2.1.1 Process view ................................................................................................................................ 8
2.1.2 Process Overview ........................................................................................................................ 9
2.1.3 Step Details ................................................................................................................................ 10
2.2 The Payroll Control Center for the Payroll Administrator .............................................................. 11
2.2.1 My Worklist ............................................................................................................................... 12
2.2.2 Folders and Checks ................................................................................................................... 13
2.2.3 Check details ............................................................................................................................. 15
2.3 Summary ............................................................................................................................................ 16
2.4 How do the Payroll Process Manager and Payroll Administrator interoperate? ......................... 16
3 Prerequisites and framework extensibility .............................................................................................. 18
3.1 Framework extensibility ................................................................................................................... 19
4 Using the payroll control center ............................................................................................................... 20
4.1 Process introduction ......................................................................................................................... 20
4.2 Process group .................................................................................................................................... 25
4.3 Process step ....................................................................................................................................... 27
4.3.1 Execution ................................................................................................................................... 27
4.3.2 Status ......................................................................................................................................... 28
4.3.3 Confirm ...................................................................................................................................... 32
4.3.4 Action log ................................................................................................................................... 33
4.4 Special kinds of process steps .......................................................................................................... 37
4.4.1 Work-list concept ...................................................................................................................... 37
4.4.2 Single report execution (e.g. Run payroll) ............................................................................... 46
4.4.3 Multi report execution ............................................................................................................. 55
4.4.4 Manual Step .............................................................................................................................. 61
5 Technical overview .................................................................................................................................... 66
1|Pa ge
Copyright/Trademark
 5.1 Packages............................................................................................................................................. 67
5.1.1 Software layer SAP_HR ............................................................................................................. 68
5.1.2 Software layer EA-HR................................................................................................................ 68
6 Technical concepts in detail ...................................................................................................................... 68
6.1 Payroll Datasource framework......................................................................................................... 69
6.1.1 Meta model ............................................................................................................................... 69
6.2 Application of the Payroll Datasource framework.......................................................................... 80
6.3 Payroll process further implementation details .......................................................................... 82
6.3.1 Mapping..................................................................................................................................... 82
6.4 Step Template user interface concept............................................................................................. 91
6.4.1 Components of a step template .............................................................................................. 91
6.4.2 List of sample step templates .................................................................................................. 95
6.5 Payroll process configuration overview........................................................................................... 96
6.5.1 Customizing ............................................................................................................................... 98
6.5.2 Runtime settings ....................................................................................................................... 99
6.5.3 Technical relationship between Payroll process configuration and Datasource framework
configuration............................................................................................................................................ 100
6.6 Additional aspects of the Payroll Datasource Framework ........................................................... 102
6.6.1 Authorizations ......................................................................................................................... 102
6.6.2 oData........................................................................................................................................ 105
6.6.3 User sessions ........................................................................................................................... 111
6.6.4 User variants ........................................................................................................................... 112
6.6.5 Status Model ........................................................................................................................... 113
6.6.6 Auxiliary reports and their usage........................................................................................... 119
6.7 Payroll process data flow................................................................................................................ 123
6.8 Worklist management (backend)................................................................................................... 128
6.8.1 Customizing ............................................................................................................................. 128
6.8.2 Creation of Worklists .............................................................................................................. 132
6.8.3 Consuming the Worklist ......................................................................................................... 133
6.8.4 Deletion of Worklists .............................................................................................................. 135
6.9 Personnel administration Authorization interface for non PNP applications............................. 135
6.9.1 Concept.................................................................................................................................... 135
2|Pa ge
Copyright/Trademark
 6.9.2 Configuration guide ................................................................................................................ 140
6.9.3 Database indexing (extraction) guide.................................................................................... 146
6.9.4 BADI ......................................................................................................................................... 151
6.9.5 Tester tool ............................................................................................................................... 153
6.9.6 Short recap of important transactions and objects ............................................................. 154
7 Installation ............................................................................................................................................... 156
7.1 Download the software (HR renewal 2.0) ..................................................................................... 156
7.2 Check that the following packages are installed in the abap application sever:........................ 156
7.3 Activate the business functions ..................................................................................................... 156
7.4 Set up the gateway server .............................................................................................................. 156
7.5 Set up the sap ui5 service ............................................................................................................... 157
Configure ICF (Internet Communication Framework) nodes for the Payroll Cockpit as follows: .......... 157
7.6 Result (Optional) ............................................................................................................................. 157
7.7 Payroll control center Result (Optional) ........................................................................................ 159
7.8 Integrating the Payroll Cockpit Lane into the Landing Page ........................................................ 159
7.8.1 Prerequisites............................................................................................................................ 159
7.8.2 Process ..................................................................................................................................... 160
7.8.3 Result ....................................................................................................................................... 161
8 Implementation guides ........................................................................................................................... 162
8.1 Payroll and master data validation rules ....................................................................................... 162
8.2 Payroll control center for admin guide.......................................................................................... 162
8.2.1 Configuration views thru the IMG ......................................................................................... 168
8.2.2 Datasource type and data-source instance for validation rules example .......................... 170
8.2.3 Result details Type .................................................................................................................. 171
8.2.4 Authorizations and Authorization type ................................................................................. 173
8.3 How to implement Asynch. batch step runtime class .................................................................. 180
8.3.1 Overview of step runtime class.............................................................................................. 180
8.3.2 Asyn batch step is a kind of base step. .................................................................................. 181
8.3.3 Invoke sequence of the asyn batch step run time class....................................................... 182
8.3.4 Component of asyn batch step .............................................................................................. 184
8.3.5 Detail methods invoke sequence of asyn batch step implementation ............................... 185
Step to build a step runtime class: ............................................................................................................. 186
3|Pa ge
Copyright/Trademark
Samples: ....................................................................................................................................................... 187
8.4 How to implement Manual step run time class ............................................................................ 187
8.5 How to implement Synchronous step runtime class .................................................................... 187
8.5.1 Inheritance hierarchy for CL_PYC_STT_CTRD_BASE ............................................................ 188
8.5.2 Background processing........................................................................................................... 188
8.5.3 Delegation class for result detail data ................................................................................... 189

4|Pa ge
Copyright/Trademark
1 About this guide
This guide explains the Payroll control center solution from both Functional and technical perspective,
including also step by step guides for customizing and implementation. The guide may serve as reference
information about the Payroll control center for different audiences like users, consultants, technical
experts, developers or anyone interested in getting to know more about the solution.

The document is mainly divided into three parts: a Functional part, a technical part and implementation
guides part. The first chapters are under the functional part, then the technical chapters follow, and
finally the implementation guides. Before all that there is an introduction and some general
prerequisites.

The features described in this document are restricted to the software contained in the HR Renewal 2.0
(including the Feature pack 1)

Document structure:

5|Pa ge
Copyright/Trademark
 Introduction
Chapter 2-3

Functional Technical
Chapers 4 Chapters 5-8

Using the payroll control

Technical overview
center
chapter 5
chapter 4

Framework and concepts

chapter 6

Installation, implementation
and How-to s
Chapters 7 and 8

2 Introduction to the payroll control center

The payroll control center is a new application that allows you to work within the SAP HR application
layer in a process-and-role oriented approach, offering a completely new user experience based on SAP
UI5 technology. The payroll control center is delivered as part of HR Renewal 2.0, enhancement package
7.

The Payroll Control Center supports the following two roles:

The payroll process manager, who is in charge of the successful execution of a complete payroll
process (for example, a payroll process manager in charge of the monthly payroll for June for
your organization)

6|Pa ge
Copyright/Trademark
 The payroll administrator, who is the subject matter expert in charge of resolving issues that
have been identified during the execution of a payroll process (for example, clarify if a payment
to a non-active employee is justified)

For each of the user roles, the payroll control center offers a user interface, customized to their
respective requirements:

Payroll Manager

Both application roles are presented in the following subchapters

2.1 The payroll process manager

The Payroll Control Center enables the payroll process manager to execute and monitor the complete
payroll process using a user interface specific to their requirements. This user interface consists of 3
levels:

First Level: Process View

Second Level: Process Overview
Third Level: Step Details

7|Pa ge
Copyright/Trademark
2.1.1 Process view
The process view, which is also the entry screen, shows all the payroll processes that a payroll process
manager is responsible for in a calendar view (standard setting is a 4 weeks view).

For each process, this view provides the following information:

The planned start and end date of the process

The execution status (for example, In Process, Completed, and so on)
The error status (for example, OK, Error, and so on)
The number of individual steps and the execution progress of each step

This view allows you to execute the following actions:

Filter payroll processes by process, process category, execution status, and error status
Navigate to a different period of time
Change the following settings for the calendar display:
o Calendar size (for example, 1 week, 2 weeks, 4 weeks, and so on)
o Start day (e.g. for example, Sunday, Monday, )
Refresh the execution and error status
Select a single process to navigate into and access the process overview

8|Pa ge
Copyright/Trademark
2.1.2 Process Overview
The second level shows all process step groups and process steps of the selected process. The process
step groups are represented by header line boxes on the screen. The corresponding process steps are
represented by the boxes below each process step group.

This view provides the following information about each process step group and process step:

At the process step group level, the following information is provided:

Planned start and end date of the process step group

Execution status (for example, In process, Completed)
Error status (for example, OK, Error)
Number of days already passed since the start date of the process step group

At process step level, the following information is provided:

Execution status (for example, In process, Completed)

Error status (for example, OK, Error)

In this view, you can also execute the following actions:

At process step group level:

Reset Process Step Group: this operation allows the steps in the step group to be again repeated
from the beginning

9|Pa ge
Copyright/Trademark
 Lock Process Step Group: this prevents the steps within a group to be re-executed. The execution
of the process can only continue starting from the first step of the following step group

At process steps level:

You can navigate to the details of a step by double clicking the step (third level of the user interface, see
next sub-chapter).

2.1.3 Step Details

In this level, you can view the step details and execute activities that are possible in the step. This level is
structured in a split screen layout: On the left side, you can view activities possible in this step and on the
right side the details of each of these activities.

SAP delivers the following standard activities applicable to all steps:

Execute: Enables you to perform an activity. Example: verify master data, open payroll, run
payroll, and so on.

Status: Shows the results of the execution of an activity with additional information depending
on the type of step.

10 | P a g e
Copyright/Trademark
 o Example: For the process step Open Payroll, you find information about the new status
of the payroll control record, whereas for the process step Run Payroll, you find details
of the number of rejected employees, if there are any.

Confirm: Enables you to confirm a process step. When you confirm a process step, the process
step status changes to Closed. Only when a process step is confirmed, can you start executing
the next process step.

Action Log: Shows all log entries created by the system and by the user:

2.2 The Payroll Control Center for the Payroll Administrator

The Payroll Control Center for the Payroll Administrator enables the payroll administrator to process all
issues that arise in the payroll processes that are assigned to him.

11 | P a g e
Copyright/Trademark
Example:

The system detected that some salaried employees in the current period have a gross salary that is 10%
above the gross salary of previous periods. The payroll administrator needs to verify if this is right and
eventually correct this.

The user interface for the payroll administrator comprises 3 levels:

First Level: My Worklist

Second Level: Folders and Checks
Third Level: Check Details

2.2.1 My Worklist
The first level, which is also the entry screen, shows all issues assigned to one payroll administrator
grouped by tiles.

12 | P a g e
Copyright/Trademark
Example:

All garnishment issues for employees in payroll area US Salaried Employees Monthly Payroll for the
monthly payroll process of May for a specific payroll administrator

This view provides the following information about each tile:

The payroll process step that generated this worklist

The number of errors in each tile

This view also allows you to execute the following actions:

Filter errors by a specific characteristic of the main entity (Example: filter errors from payroll
area US Salaried Employees Monthly Payroll only)
Select a single tile by clicking it to navigate to folders and check results

2.2.2 Folders and Checks

This level shows all folders of the selected tile. On this level, you can display the check results grouped by
folder (the picture below shows two folders: earnings and time management, a list of checks is available
under each folder. Next to each check you will see its total issue count).

13 | P a g e
Copyright/Trademark
Example

You have a folder called Garnishments and within this folder you have several individual check results.
This view provides the following information:

List of all folders. Example: Master Data Checks, Payroll Checks for Garnishments
Error count for each folder
Error status of each folder (OK or Error)
Error count for each check
14 | P a g e
Copyright/Trademark
This view also allows you to execute the following actions:

Select a single folder

Select a single check

2.2.3 Check details

The third level shows all results of a selected check. This level is structured in a split screen layout: on the
left side all employees for which a result is available are displayed; that is, all employees which
potentially have an error in their data. The right side shows details for the currently selected employee
only and the specific result for that employee.

This view provides the following information about each employee:

Employee details
Check status (OK or Error)
Check details

*note: the results of a check are not restricted the employee entity. This will be clarified in further
chapters

15 | P a g e
Copyright/Trademark
Example

A list of relevant wage types showing why the employee has a gross salary increase above 10% compared
to the previous payroll period.

In this view, you can execute the following actions:

Change the sort order and the sort criteria of the employee list
Search for employees
Select one or several employees and do the following:
o Display details for the selected employee on the right side of the screen
o Set the error status for this employee to either OK or Error

2.3 Summary

Functional responsibility of each application and role:

Payroll Process Manager

Responsible for the overall process

Ensures correctness and timeline
Triggers others to resolve issues
Signs off that all steps are executed correctly

Payroll Process Admin

Receives worklist from payroll manager

System assists with findings and pointing out issues
Payroll admin evaluates, corrects, and ensures error free tasks and payroll activities

2.4 How do the Payroll Process Manager and Payroll Administrator

interoperate?

The payroll process executed by the payroll process manager includes several checkpoints. These
checkpoints allow the payroll process manager to verify the results of the previously-executed process
steps.

Example

16 | P a g e
Copyright/Trademark
 After the first payroll run, the payroll process manager may want to verify the payroll results
before continuing with the next steps of the payroll process.

To make these checkpoints available, SAP delivers two specific types of process steps as standard:
Prepare Data Verification and Verification

Prepare Data Verification

This type of process step executes all defined checks that are relevant at a given time of the process.

Example

After the Run Payroll process step, the Prepare Payroll Data Verification process step is executed
in order to update all relevant payroll checks based on the latest results from the Run Payroll
process step.

Data Verification

This type of process step enables the payroll process manager to distribute the available check results to
the individual payroll administrators. This can be done using different criteria.

17 | P a g e
Copyright/Trademark
 Example

In the process step Verify Payroll Data, the payroll process manager distributes the 50 errors
resulting from the last payroll run to 3 payroll administrators according to personnel area of the
employees. As a result, payroll administrator 1 receives 10 errors; payroll administrator 2
receives another 10 errors, and payroll administrator 3 receives the remaining 30 errors. Once
the 3 payroll administrators access the payroll control center for the payroll administrator, each
of them finds a new tile with the respective errors as distributed by the payroll process manager.

3 Prerequisites and framework extensibility

The payroll control center is a part of the HR Renewal 2.0, so the installation requirements of the Payroll
Control center meet the requirements of HR Renewal 2.0.

HR renewal 2.0 is based on the software component EA-HR 608.

General Installation Requirements

You have installed the initial shipment of HR renewal 2.0 as described in the SAP installation note
1881006.
HR renewal 2.0 is based on SAP NetWeaver 7.4 SPS05 with SAP_UI Component SP07; this is the
minimum SAP NetWeaver stack required.
You have followed the instructions in the Release Information Note (RIN) 1965692.
You have checked that your browser meets the requirements as per SAP Note 1885476.
The minimum SAP NetWeaver Gateway release required is as follows:

18 | P a g e
Copyright/Trademark
 o Remote Gateway
Minimum release: SAP NetWeaver Gateway 2.0 SPS 07. This includes IW_BEP 200 SP7 (for
the instance Gateway BEP) and IW_PGW 100 SP4 (for the instance Gateway PGW).
o Local Gateway
SAP NetWeaver Gateway 7.4 SPS 05 with SAP_UI Component SP 07 is required and this
requirement is met by the SAP NetWeaver stack for HR renewal. With the SAP NetWeaver
Gateway 7.4, the basis functionality was moved to the SAP NetWeaver stack and shipped via
SWCV SAP_GWFND 740.

For both the remote and the local SAP NetWeaver Gateway, SWCV IW_PGW 100 SP4 is also
available. For SAP NetWeaver Gateway 7.4, IW_PGW 100 SP4 is shipped via SAP NetWeaver
Gateway 2.0 SPS 07 (Instance Gateway PGW 740).

For more information on SAP NetWeaver Gateway topics, please refer to

http://help.sap.com/nwgateway

Features that require extra steps after installation of HR renewal are listed in section:
Installation Information. In this section, you will find information about the components that
require extra steps to get them up and running, or links to extra background information that
will be helpful to you.

Browser Requirements
Please check the following sources for detailed information on browser support:
SAP Note1885476: DSM support for UI5 application
The Product Availability Matrix (PAM) on https://service.sap.com/pam . In the search box,
enter HR renewal 2.0 for the product version.

For more detailed information, please refer the HR Renewal 2.0 Installation Guide.

Before running the application the ICF nodes for UI5 application and oData Services need to be activated.

For launch the PCC via portal or NWBC, user can make use of the URL
https://<default_host>:<port>/sap/bc/ui5_ui5/sap/hrpy_cockpit/index.html?sap-client=<client>. This
can be obtained by test run the ICF node of the UI5 application hrpy_cockpit
(/default_host/sap/bc/ui5_ui5/sap/hrpy_cockpit).

3.1 Framework extensibility

The Payroll Control Center is a framework based solution which makes it possible to handle the
personnel administration and payroll applications available on the Business Suite backend leveraging all
the existing business logic and exposing it to a new user experience and working model.

The Framework and its content - which comprises the process modeling, the management of the
validation rules and the API necessary to handle the backend applications - can be extended and made
more specific to the customer needs, as well as to specific countries and business needs. In other words,

19 | P a g e
Copyright/Trademark
thru the Payroll Control Centers framework, SAP has made possible to handle the execution of Payroll
related Business Suite Backend applications in an intuitive process-and-role fashion also providing a
standardized user interface where the relevant applications data can be made available for users.

A standard process template (including process groups and process steps) is provided in the HR Renewal
2.0 FP1 release. Customers can use the standard process template directly as well as implement new
templates by extending the standard templates of ABAP object classes. The implementation of steps as
well as validation rules will be made clear in further chapters in this document.

Customers can not only customize the standard template but also flexibly develop whole new process
templates adequate to their needs. Notice that the installation and customizing of the standard software
delivered with HR Renewal 2.0 FP1 may not be sufficient to get the full payroll process of a company
running on the Payroll Control Center; some workbench effort might be needed for a full scope (either
directly by the customer or by an SAP partner).

4 Using the payroll control center

This chapter focuses on the usage of the Payroll Control Center and the user-interface features for end-
users.

4.1 Process introduction

On the entry screen, the user can view and access all the payroll processes which have been authorized
to him.

20 | P a g e
Copyright/Trademark
On the top of this screen is the selection toolbar. There are four selection criteria: Payroll Process,
Process Category, Error Status and Execution Status.

All of these selection criteria are designed as a dropdown list. When the user clicks one of them, the
respective selection window will pop up.

21 | P a g e
Copyright/Trademark
The user can select multiple values on the window, and if there are too many values in the list, the user
can search for a specific value by using the search textbox. When clicking on button on the right side
of the toolbar, all selection criteria will be reset to default.

Below the selection toolbar, all payroll processes are listed on a calendar view.

On the top of the calendar view, it is possible to navigate thru the process calendar by clicking on the left
and right arrows. By default, the current date is outlined as blue.

22 | P a g e
Copyright/Trademark
By default, the calendar size is set to 4 weeks. The user can change the Calendar Size and Start date

settings by accessing the settings menu via button located at the screens right bottom corner.

Each line shown In the Calendar view represents a payroll process.

On the right side of each Process name, there can be several blocks representing the process instances.
For example on the picture above, blocks 06.2014 and 07.2014 are process instances of Process
California Monthly Payroll.

23 | P a g e
Copyright/Trademark
The length of the block represents the ideal length of the process. By referring to the calendar, the user
can see the predefined start date and the end date of each process instance. The period of the process is
displayed on the top of the block as a header. The background color of the header reflects the error
status of the specific process instance. There is an arrow-like icon at the left of the period text which
represents the execution status (more details about execution status will be given later). Below the
header there is a progress bar divided into so many progress steps as the actual steps which are included
in this process instance. The Progress bar indicates how many steps have been completed for the current
instance. Below you can see a few examples of how the progress and statuses can look like:

When clicking on the headers text, a menu is shown. Three options are provided with the menu:

o Go to process overview (displays all groups)

o Go to process step group (displays only the current group)
o Go to process step (jumps into the current step)

When clicking on the menu item, the user will jump into the process groups screen (or directly into
the current process step if clicking on Go to process step). Example:

24 | P a g e
Copyright/Trademark
4.2 Process group
The screen below shows all process step groups and process steps of the selected process. The process
step groups are represented by header line boxes on the screen. The corresponding process steps are
represented by the boxes below each process step group. The color on the step group box and step box
represents the error status. And the icon represents the execution status. The progress bar on the step
group box shows the start date and the end date of the process step group.

If there are too many process step groups in one process, their display will be distributed across multiple
pages depending also on the screen resolution. Two arrows (left and right) are provided beside the
process step group boxes for switching between the pages.

25 | P a g e
Copyright/Trademark
In this view, you can also execute the following actions:

At process step group level:

o Reset Process Step Group:

If all steps of a step group are either in status Closed or Not Started, you can reset the
complete step group. This means, all steps within the step group are set to status Not
Started and the user needs to perform all steps again. Example: You have executed the
payroll for all employees. You then identify some issues and, therefore, have to change
some master data. Now, you need to repeat the payroll for the employees whose master
data has been changed. To be able to run the payroll again, you must reset the process
step group.

o Lock Process Step Group:

If all steps of a step group are in status Closed, you can set the step group to status
Locked. This means, you can no longer reset the step group or execute any process
steps.

26 | P a g e
Copyright/Trademark
 At process steps level:
o You can navigate to the details of a step by clicking the step (third level of the user
interface).

4.3 Process step

As already introduced in chapter 2, in the process step level, you can view the step details and execute
activities that are possible in the step. This level is structured in a split screen layout: On the left side, you
can view activities possible in this step and on the right side the details of each of these activities.

A common setup will be available on all steps, which is the left panel with the 4 activities: Execution,
Status, Confirm and Action Log. The following sub-chapters illustrate how these activities work taking the
example of the open payroll control record step.

4.3.1 Execution
On the execute activity, the user will be provided with the details involved on the execution of the
current step. After reviewing the execution details (on the right panel) the user triggers the execution of
the step by means of the buttons available at the bottom right corner of the screen (see picture below,
as per example, the open payroll activity)

27 | P a g e
Copyright/Trademark
4.3.2 Status
In the status activity the user can monitor and manage the execution status of the step. In case the step
has not been yet executed, the status activity will display a blue icon (see the picture in the previous
sub-chapter).

The first interaction with the steps status happens when the step is first executed:

28 | P a g e
Copyright/Trademark
The result of the execution will be available as a view in the status activity. For example, the picture
below shows the status views of the open payroll control record step, there the user sees the new
status of the control record (after execution activity) and also the list of Locked Employees if any (in a
separate view tab see picture below). Each step should provide adequate status views depending on the
context.

29 | P a g e
Copyright/Trademark
The processing time of the step execution can vary depending on the type of the step. For example, the
run payroll step can last considerably longer than a simple step such as open payroll control record.
In these cases, the status information will be updated on the screen when the batch job carrying the
execution process is finished. The user will however immediately be provided with information such as
job planning-status on the status view.

Each status view will represent either an OK status (green) or an error status (red). For example, if the
step execution involves running a backend program, it can be that the program returns warning or error
messages which will be displayed on the status view. The status view will then automatically show a red
status. The user can however analyze the displayed information and decide that the execution is in any
case successful, in this case the user clicks on button Set status to ok at the bottom right corner of the
screen ( analogically the user could also set the status to error by means of button set Status to Error).

30 | P a g e
Copyright/Trademark
The user can manually change the execution status after reviewing the date (pressing on button set
status to error)

When all status views are showing a green state, the user can continue to the confirm activity
described in the next sub-chapter.

31 | P a g e
Copyright/Trademark
In the Status activity screen, users can manually set the status to Error or OK by clicking the actions
buttons on the right bottom menu. A log entry will be created automatically after the action is executed.
In some cases, like in the picture above, the status will be automatically maintained so that the user does
not need to manually click on the ok button.

4.3.3 Confirm
After the execution status is reaches an OK state (green), the user should confirm this step in order to
close it and move to the next step. In the detail view of the Confirm activity screen, users can record a
confirmation message and then confirm the step by clicking the Confirm button in the right bottom
corner.

32 | P a g e
Copyright/Trademark
4.3.4 Action log

Create Log Entry is a common action for each step activity. Users can manually create log entries by
clicking this action button.

33 | P a g e
Copyright/Trademark
Every log entry or action related to this step, no matter if manually created by the user or automatically
by the system, will be recorded in in the steps action log. Users can view all the log entries in the Action
Log activity. The number of recorded actions is shown at the right side of the Action log activity title.

All log entries are listed in the Action Log activity screen. Users can view these log entries at any time.

34 | P a g e
Copyright/Trademark
On the top of the detail view is a filter toolbar. Users can filter the log entries by user this toolbar:

35 | P a g e
Copyright/Trademark
For each log entry, detailed information is provided. Users can view this information by clicking the title
of each log entry:

36 | P a g e
Copyright/Trademark
4.4 Special kinds of process steps
4.4.1 Work-list concept
This chapter explains in more detail the chapter 2.4 How do the Payroll Process Manager and Payroll
Administrator interoperate.

During the payroll process, there can be various points to check the correctness of data in order to
continue to the following process steps. Such steps are identified as "Data Verification" steps.
Examples are:
Pre-payroll data verification: before release for payroll and running payroll, the payroll manager
needs to make sure that the master data is correct according to specified data validation rules
(data checks).
Payroll data verification: after running payroll, the payroll manager needs to make sure that the
payroll results are correct according to specified data validation rules (data checks).

In such steps the following business processes are covered:

As a payroll manager, the user needs to:
o Trigger the execution of the validation rules against the systems data (e.g. master data
or payroll results).
o Subsequently, the payroll manager can allocate work-packages (so called work-list),
consisting of the found issues, to payroll admins so that they can work on the resolution
37 | P a g e
Copyright/Trademark
 of these issues. The issues can be distributed to different users according to different
criteria. Mostly the issues are related to employee data, and for these cases the standard
solution allows the payroll manager to build work packages to users according to
organizational assignment of the employees. For example, user payroll admin A will
take care of all issues which are related to employees belonging to company code US01
and user Payroll admin B will take care of the ones for company code US02.
o Finally the payroll manager wants to monitor the status of the resolution of the found
issues which were allocated to User(s).
For the payroll admin user, a certain work-list of found issues (checks, validation rules) has been
assigned by to him/her by the payroll manager. Details of the checks errors and supporting
evidences are provided for them to find the root cause. Then they can either mark it as ok to
indicate that it is a false alarm or correct the master data/configuration that causes the error.
The payroll manager can re-execute the checks to see whether they are fixed and decide
whether the payroll process can be continued.

From the payroll manager perspective, the process data validation process works as follows:

As already introduced in chapter 2.4, the validation process group is composed of two steps: Prepare
Data Verification and Verification. In the standard delivered template, you will find two kinds of data
verification step: masterdata verification and payroll data verification.

In short, the Prepare Data Verification step is where the payroll manager triggers the execution of the
validation rules at the backend (report PYD_EXECUTE_INSTANCES will be run)

The step Data Verification is where the payroll manager will distribute the issues work-list to users
(payroll admins) and monitor the issue resolution.

In the steps customizing, it will be linked which group of checks needs to be executed and monitor. This
allows to organize different checks to different processes accordingly (customizing activities will be
clarified later).

38 | P a g e
Copyright/Trademark
Execution of step prepare data verification:

When executing this step (button prepare payroll master data check, bottom-right corner) a report will
be schedule to execute the checks instances defined in the check class that already been customized for
this step. Furthermore the check instances will be filtered with the payroll areas assigned to this process
as well.

From here users can only see the relevant check instances which are executed, and there is no error or
exception during the execution of the checks. Based on this users can set this status to ok. Setting the
39 | P a g e
Copyright/Trademark
status to ok in this step means: The execution of the validation rules was successfully finished. Setting
the status to ok does not depend on if there were issues found on employees master data or not.
An example of not ok status for this step is, for example, the check instances to be executed depend
on a secondary DB connection, and this connection was broken during the checks execution.

In the Job Result status view, the payroll manager can review the execution status, and set the status
to ok:

In the check errors view, the payroll manager can review the number of issues found per payroll area
(or other grouping, depends on the configuration). The error count on a higher level is useful to allow
users to identify major execution errors (possibly due to the checks configuration), for example, if a
uncommonly high number of errors were found on the current run, or if no errors at all were found
when some should already be expected. Before continuing to the next step, it is necessary to set this
status to ok as well:

40 | P a g e
Copyright/Trademark
After the statuses are set to ok and this step is confirmed, the payroll manager can jump to the next step
and distribute the error findings to payroll admins users.

On the execution tab of this step the payroll manager can choose a set of users to assign the worklist to.
To add a user, click on button "add new user". Default Worklists will be automatically proposed taking
into account the state from the previous process instance (e.g. from the last payroll period). Here the
payroll admin can also distribute the findings to users according to the issues organizational assignment.
This is done by clicking on button Fields:

41 | P a g e
Copyright/Trademark
A popup window shows up where the user can choose which fields will serve as filtering criteria for the
worklists. These fields will become columns on the table below:

42 | P a g e
Copyright/Trademark
The table shown above represents the worklist distribution of the findings to users. Rows are users,
columns are the chosen fields. In each cell, the user can further specify the values for the worklist
filtering criteria, as for example:

When the worklist assignment is done, the user has to click on Submit worklist button (bottom-right
corner).

By submitting the worklist, the error count distribution to users (worklists) can be viewed in the status
views:

Now the payroll admins users can logon to their own payroll admin view to see the list of errors they
need to resolve. Meanwhile the payroll manager can monitor the status in the payroll manager view

Payroll Admin Perspective

When a user for whom a worklist has been assigned logs into the Payroll Control Center for Payroll
Admin perspective, he or she will be able to work on the resolution of the issues also in a process
oriented approach. Basically the entry screen will show a tile for each payroll process available worklist.
The picture below shows an example of the entry page containing three tiles:
The tiles are organized in the following way (from top to bottom):
Number of errors
Title of the tile (indicate what kind of checks are inside). Example: Payroll masterdata check

43 | P a g e
Copyright/Trademark
 Title of the payroll process. Example: US payroll
Period of the related payroll process. Example 06.2014

By clicking on a tile, the user jumps into the folders view (this has already been mentioned in chapter
2.2.2):

Further in the detail view, the payroll admin can see the root cause of why the employees fail the check.
So the payroll admin can decide either to correct the master data based on the evidences and keep the
status as error, or to manually set the employees issue to ok (to indicate that this is a false alarm).

44 | P a g e
Copyright/Trademark
When setting manually the error status to ok, the user will have to specify a root cause reason.

When all issues are solved, or when the payroll admins are finished with the resolution process, the
payroll manager can decide to move on to the next step, and for that the payroll manger, on the payroll
manager perspective, confirms the status view status of checks (button set status to ok on the bottom
right corner):

45 | P a g e
Copyright/Trademark
After that, the step can be confirmed.

4.4.2 Single report execution (e.g. Run payroll)

This kind of steps is designed to run a single report (e.g. Run Payroll) via a batch job. The results of the
batch job are presented to the user on the status views of the step.

For example, when the user enters the run payroll step view, he can trigger the report (payroll driver) by
clicking the button on the right-bottom corner.

46 | P a g e
Copyright/Trademark
A popup message will confirm the triggering of the job:

47 | P a g e
Copyright/Trademark
After that, while the job is planned, on the queue or being executed, the user will see a red triangle icon
next to the title of the Status activity. In the detail view of the Status activity, the user can view the
details of the job status under the tab Job Execution Status which is also marked as red (since it is still
not finished).

48 | P a g e
Copyright/Trademark
 49 | P a g e
Copyright/Trademark
During the period that report is preparing to run or is running in the backend system, the status color of
the current payroll process step group and the payroll process step turns to yellow.

After the repot is successfully executed, the icon after the title of the Status activity will change to a
red cycle (error) or a green square (OK) according to the execution result. And in the detail view, the first
two tabs Job Setup Status and Job Execution turn to green while the last tab Job Result changes its
color. If the color of the last tab is green, that means the report is executed successfully without any
errors. And if the color is red, that means some errors occurred during the execution or the step requires
the user to do some manually confirmation.

The pictures below show all three status views:

50 | P a g e
Copyright/Trademark
 51 | P a g e
Copyright/Trademark
The user can view the details of the job result by clicking the tab Job Result. If the user confirms that
the report result is correct, he can set the status to OK manually:

52 | P a g e
Copyright/Trademark
 53 | P a g e
Copyright/Trademark
When the status of the payroll process step is green, the user can confirm and close this step in the
Confirm activity, and then, the next step will be available.

54 | P a g e
Copyright/Trademark
4.4.3 Multi report execution
This kind of payroll process steps is designed to support running multiple reports at once. This is how, for
example, the payroll posting run step has been deigned.

When the user clicks for the second time (in case it is necessary to repeat the step) on create posting
run, a report is scheduled to delete the previous posting run and another report is triggered for the new
posting run.

55 | P a g e
Copyright/Trademark
 56 | P a g e
Copyright/Trademark
For example, in step Create Posting Document, if the step is executed for the first time, in the detail
view of the Status activity, there are only three tabs Job Setup Status, Job Execution Status and

57 | P a g e
Copyright/Trademark
Job Result:

Then user can run the step again.

58 | P a g e
Copyright/Trademark
In this example, during the running of the report, a posting id will be created by the system. And after
the first execution, each run includes two reports at the same time. One is to delete the previous id and
another one is to create a new id. All relevant records are listed in the new tab Posting Deletion Job
Spool.

59 | P a g e
Copyright/Trademark
If the status of the step is OK, then the user can confirm and close this step.

60 | P a g e
Copyright/Trademark
4.4.4 Manual Step
This kind of payroll process steps is designed steps which the system cannot catch the real execution
status automatically such as tasks which are manually handled outside the system (e.g. Print Pay Slip).
For the manual steps, the status is always set to red after the user executes the step, which means that
the user should also manually set the status to OK.

For example, the print payslip step serves for the user/payroll manager to indicate that the printing
process started (no actual program will automatically be invoked by this step, the user has to handle
these cases separately)

61 | P a g e
Copyright/Trademark
After the step was started (executed), the status will show a red color:

62 | P a g e
Copyright/Trademark
When the activity is finished, the user can set the status to ok, he can also add a log message before
setting the status.

63 | P a g e
Copyright/Trademark
 64 | P a g e
Copyright/Trademark
Only after the status of the step is OK, the step can be confirmed.

65 | P a g e
Copyright/Trademark
5 Technical overview

The following diagram explains the system architecture of the Payroll Control Center

66 | P a g e
Copyright/Trademark
5.1 Packages
In the backend system, you will find the Payroll control center distributed into different application
packages

67 | P a g e
Copyright/Trademark
 EA_HR

PAOC_PAY_PYD_PCC_CONT
PAOC_PAY_PYD_CONT

PAOC_PAY_PYD_PCC_FRW PAOC_PAY_PYD_UI

SAP_HR

PCPYD_CONT PCPYD_RT

PCPYD_ODATA PCPYD_FND

5.1.1 Software layer SAP_HR

PCPYD_CONT : Content
PCPYD_FND : Foundation
PCPYD_ODATA: OData Framework Service
PCPYD_RT : Run time execution

5.1.2 Software layer EA-HR

PAOC_PAY_PYD_CONT : Payroll Data Source Framework: Content
PAOC_PAY_PYD_PCC_CONT: Payroll Control Center Content
PAOC_PAY_PYD_PCC_FRW : Payroll Control Center Framework
PAOC_PAY_PYD_UI: Payroll Data Source Framework: User Interface

6 Technical concepts in detail

68 | P a g e
Copyright/Trademark
The SAP personnel administration and payroll components comprehends a large solution based on a big
set of core applications plus several thousands of applications, processes, reports and transactions
localized for more than 50 countries. This large solution serves a big ecosystem of thousands of
customers as well as many users, specialists, consulting companies, service providers and other software
partner companies who develop on top of the existing SAP solution.

In order to reach high development productivity and to leverage the existing ecosystem around SAPs
payroll, a meta model has been developed that allows modeling all these specific payroll processes in a
way that it can be consumed by generic user interfaces and allows modification-free extensions of the
standard delivery.

6.1 Payroll Datasource framework

6.1.1 Meta model
The key idea of the approach is to model steps of the payroll process as so-called Data Sources. The
statement I am responsible for payroll process steps A, B, C can then be translated into I am
authorized for Data Sources X, Y, Z, where Data Source X covers the required functionality of process
step A etc.

This requires that a Data Source offers different kinds of data as well as operations that can be
performed on it. Examples are:

Employees assigned to payroll area UM, having a claim in payroll period May 2013. Data
provided:
o List of selection parameters (Payroll Area UM, Payroll Period May 2013)
o List of corresponding employees
o For each employee, list of relevant wage types from the payroll result, like total gross,
statutory and other deductions, claim amount.

An operation could be to jump to the master data display for a listed employee or to set the
status of an employee to OK in case that the claim correctly occurs.

Main process control for payroll area UM. Data provided:

o Status and period from payroll area control record.

Operations

o Release for payroll, Set to correction phase, etc. (of course list of active operations
depends on the control record status)
Yearly Tax Declaration for Employer 0001, year 2013. Data provided:
o Status
o File that has to be sent to the corresponding tax authority.

69 | P a g e
Copyright/Trademark
 Operations

o Create file (starting a batch process)

o Send file to authority
o Set status to done

6.1.1.1 Data Source Types

A Data Source Type describes a Data Source on type level and is a design time entity that can be
delivered from a development system. It uses Parameter Types to formulate their input as well as result
data. The Data Source Types for the examples above are:

Data Source Type Employees with Claim

o Input Parameter Types:
Payroll Area -> the value for this one has to be fixed by the customer when
configuring the payroll process
Payroll Period -> the value of this one is flexible and depends for instance on the
status of the payroll area control record in the production system.
o Result Parameter Type:
Personnel Number
o Result Details Types:
<Category: Data> Header info for an employee
<Category: Data> List of amounts for total gross, statutory deductions, other
deductions, claim.
<Category: Operation on list level> Refresh list of employees
Data Source Type Main Process Control
o Input Parameter Types:
Payroll Area
o Result Parameter Types:
Payroll Area
o Result Details Types:
<Category: Data> Header info for payroll area
<Category: Data> Status and period from control record
<Category: Operation> Release for Payroll
Data Source Type Tax Declaration
o Input Parameter Types:
Legal Employer
Year
o Result Parameter Types:
Status
Tax Declaration File
o Result Details Types:
<Category: Data> Header info for Tax Declaration File
<Category: Data> Content of Tax Declaration File
70 | P a g e
Copyright/Trademark
 <Category: Data> Detailed status information about communication with
authorities
<Category: Data> Status information about file creation and step completeness
<Category: Operation> (Re-)Create file in batch
<Category: Operation> Send file to authority
<Category: Operation> Set step to done

The Data Source Type implementation has to calculate the result object list (typed with the Result
Parameter Type) based on input parameter values (typed with the Input Parameter Types). It also has to
provide the data or execute the operation reflecting the Result Details Type.

Other Input Parameter Types could reflect the mentioned Legal Employer (these types could be
country-specific). Other Result Parameter Types could be files, missing configuration etc.

The design-time part of the Data Source meta model looks as follows:

71 | P a g e
Copyright/Trademark
Example: Employees with Claim

data source type Input parameter type

Employees with
Payroll Area
Claim

parameter type

Period

parameter type
Personnel
Number
Result
Design Time

Example: Main Process Control

Example: Regular Payroll Run

data source type Input parameter type

Regular Payroll
Payroll Area
Run

parameter type

Period

parameter type
Result
Status

Design Time

Example: Errors in Regular Payroll Run

72 | P a g e
Copyright/Trademark
Example: Tax Declaration

This allows already generically browsing on type level

through the list of process steps, looking at their input and result data and operations (Result Details
Types are not shown in the above examples).

6.1.1.2 Data Source Classification

In order to classify Data Source Types, it is introduced the possibility to define Data Source Classes that
combine a certain list of Data Source Types. Subgrouping is possible via Folders that also allow a
hierarchical structure. All three entities allow defining an order on them. The corresponding meta model
looks as follows:

73 | P a g e
Copyright/Trademark
Data Source Classes are design time entities, that is, they can be delivered by SAP standard development
as well as partners, and they can be extended and created in customer systems.

Typical examples are Data Source Classes that consist of Data Source Types reflecting consistency checks
on master data or payroll results. Folders semantically group those checks, see first example below.

It is also possible to cover a whole end-to-end payroll process for a certain market segment using a Data
Source Class, where the Folders reflect the main steps; the Data Source Types reflect the atomic
individual steps.

Example: Checks on Payroll Results (excerpt only)

The following example additionally illustrates how certain Data Source Classes can be used to iteratively
build high-level payroll process steps. One of the steps in the step group Payroll is reflected by the
Checks on Payroll Results Data Source Type. This one mainly allows to do status monitoring of the
finer-granular work covered by Data Source Class Check on Payroll Results shown in the first example.
It also allows opening a detailed user interface (Payroll Control Center) that displays the details of the
connected Data Source Class.
74 | P a g e
Copyright/Trademark
Example: Regular US Payroll Process (excerpt only)

With this understanding, it is now possible to describe the instantiation of the type level in the customer
configuration and production system:

6.1.1.3 Data Source Instances

With the creation of Data Source Instances the customer decides for using a Data Source Type for a
specific entity value, like using Data Source Type Main Process Control for payroll area UM.

Authorization to access Data Source Instances can be assigned to users; in the mentioned example
assigning Data Source Instance Main Process Control for payroll area UM to user A can be interpreted
as User A is responsible and authorized for controlling the main process flow for payroll area UM.

In order to differentiate between users who have to have read access to a Data Source Instance and who
need to execute operations on the Data Source Instance, finer-granular authorizations can be granted.

This is the corresponding meta model:

75 | P a g e
Copyright/Trademark
One easy example is the payroll run for UM:

In the last diagram, a short abbreviation was used that will be needed in further diagrams, too:

Instead of showing two entities (Parameter Type and the specification of a value or select option during
configuration time), only one is shown specifying both entities in its title, see following picture.

If a context is required when dealing with Data Source Instances, like always showing them together with
a corresponding grouping, its also possible to grant authorizations on Data Source Class level:

Referring to the example Data Source Classes described above, this would allow formulating the
following requirements:

Users A, B and C are responsible for performing the checks on payroll results for payroll area
UM.
o User A is responsible for checking the earnings
o User B is responsible for performing the various checks.
o User C is responsible for monitoring the status of these checks.

76 | P a g e
Copyright/Trademark
This can be translated now into the Data Source concept:

Users A and B get authorization for Data Source Class Checks on Payroll Results for payroll.
User A gets authorization for Data Source Instance Gross Deviation greater than expected for
payroll area UM.
User B gets authorization for Data Source Instances Employees with Claim in payroll area UM
and Errors in Regular Payroll Run for payroll area UM.
o Comment: To simplify authorization profile maintenance, naming conventions can be
introduced for the technical names in order to allow wildcard-based authorization
maintenance.
User C gets authorization for Data Source Class Regular US Payroll Process and for Data Source
Instance Checks on Payroll Results for payroll area UM.
o If User C needs to access the details of the checks on payroll results, he/she also gets
authorization for Data Source Class Checks on Payroll Results and the corresponding
Data Source Instances for payroll area UM.

As one can see, the concept allows at configuration time to model payroll processes using the generic
entities and to assign certain steps for specific selection criteria to individual users (or user groups). This
in turn enables generic (user interface) consumers to show users exactly the objects they are authorized
and responsible for. And the assignment of users to tasks and objects is done directly, not indirectly via
multiple derivations.

The generic meta model has another advantage: As the main payroll entities are transparently visible in
the model, answers to questions like the following ones can easily be given, which has been very difficult
or even impossible so far. This is simply based then on the model and corresponding user authorizations:

What are the payroll areas a user is allowed to see?

o Translation: What are the distinct values for Input Parameter Type Payroll Area used in
Data Source Instances the user is authorized for?
o As there is currently no authorization object in SAP standard that allow granting such
authorization, answering this question is impossible in general. There are only
authorization objects related to the payroll area that deal with special aspects like
authorization for control record changes.
What are the payroll process steps the user is supposed to perform for US payroll?
o Translation: What are the Data Source Types assigned to the corresponding Data Source
Class, that are used in Data Source Instances the user is authorized for? It is also possible
to derive the corresponding entity values (like payroll area UM or Legal Employer 0001)
by looking at the corresponding Input Parameter values.

It has been so far introduced a semantically rich generic model for a kind of process templates by
defining Data Source Types and their assignments to Data Source Classes and their Folders. The
processes that concretely run in a customer system are configured via instantiation of the Data Source

77 | P a g e
Copyright/Trademark
Types. Assignment of certain process steps to users is done via authorization for Data Source Classes and
Data Source Instances.

Still missing is an extension of the meta model for covering the individual process instances, that is, the
instantiation of a given process for a certain payroll period or another flexible selection criterion that
cannot be fixed when configuring the Data Source Instances.

For this, the Data Source Result, as an additional entity, is introduced:

6.1.1.4 Data Source Results

As already mentioned, it is necessary to distinguish process instances like Regular US Payroll Process for
Period May 2013 and Regular US Payroll Process for Period June 2013. Figuratively the result of a Data
Source Instance is calculated when fully specifying the (mandatory) input parameters according to its
Data Source Type:

For typical Data Source Instances like Employees with Claim in payroll area UM there is the need of a
fixed input parameter payroll area UM, which is the targeted population to be analyzed. But for sure
the list of employees found with Claims differs between different payroll periods. This is handled via the
additional (mandatory but not necessarily fixed) input parameter type Period. In a more formal
manner, this can be written as:

The list of employees with claims for payroll area UM, period May 2013 is the list of result
objects of parameter type Personnel Number that are calculated by the Data Source Type
Employees with Claims when using payroll area = UM and Period = May 2013 as input
parameter values.

That means, a process step instance in our meta model is the result of a calculation of a Data Source
Type for the input parameter values configured in the corresponding Data Source Instance plus values
for further mandatory input parameter types that have not been specified by the Data Source Instance.

A Data Source Result therefore consists of

the full list of mandatory input parameter values (or more general select options) used to
calculate the result and
lists of result objects, typed with the result parameter types of the corresponding Data Source
Type. These lists are returned by the calculation of the Data Source Type using the before-
mentioned list of mandatory input parameter values.

This is the implied final meta model:

78 | P a g e
Copyright/Trademark
The following example shows two results for Data Source Instance Payroll Run for payroll area UM,
reflecting the corresponding process steps for May 2013 and June 2013.

The Data Source Result and its sub entities are the keys that allow assigning status, workflow etc. to
concrete process steps. They are also the basis for automated calculations like status aggregations along
the hierarchies on top (Data Source Instance, Folders, and Data Source Classes).

79 | P a g e
Copyright/Trademark
Again such calculations can be very well supported by the generic model as this simplifies the
corresponding algorithms and even allows for synchronous execution of calculations on the fly.

Depending on the way how the data persistency is designed this is also a very promising use case for
redundancy-free real-time analysis of such operational data, using SAP HANA.

6.1.1.5 Summary
The previous chapters have shown how a meta model for arbitrary payroll processes can be used in
order to translate the heterogeneous transactions and various entities around SAPs payroll solution into
a generic model that can be consumed by generic tools.

6.2 Application of the Payroll Datasource framework

The Datasource framework has been applied so far into two major areas within the Payroll control center
solution: one area is in the organizing, designing and execution of the masterdata and Payroll validation
rules and the other area is the modeling and managing of the Payroll process itself (or payroll related
processes like legal reporting, masterdata activities, etc.).

The picture bellows abstracts the way how the Datasource framework (hierarchy in blue) is used to
design payroll validation rules (blocks in green on the left). The abstraction below requires the reader to
be familiar with the Payroll Control center for payroll Admin role application, due to the terms and
hierarchy presented:

80 | P a g e
Copyright/Trademark
 81 | P a g e
Copyright/Trademark
And the picture bellows abstracts the way how the Datasource framework (hierarchy in blue) is used to
model a payroll process (blocks in green on the left). The abstraction below requires the reader to be
familiar with the Payroll Control center for payroll Manager Role application, due to the terms and
hierarchy presented:

6.3 Payroll process further implementation details

This chapter describes in more detail how the introduced meta model for payroll processes can be
mapped to payroll systems. This is explained based on the example of a regular payroll run for a group of
employees.

6.3.1 Mapping
Usually programs covering steps of the payroll processes have one main selection entity like a group of
employees for which payroll is run together (SAP-terminology: Payroll Area; other payroll systems talk
about the company or have other proprietary terms) or a legal employer etc. Additionally they process
data for a certain period of time, like the payroll period (a month, a week, etc.), a quarter or other kind
of period. This leads to the introduction of the following two concepts:
82 | P a g e
Copyright/Trademark
 Instance Selection Parameter Type

o This is the main selection entity type used for a certain payroll process type, for instance
the Payroll Area is used for performing the preparation and calculation of the regular
payroll results.

o The Instance Selection Parameter Type is assigned to the Data Source Class (= the payroll
process template) and tells a generic consumer how the individual process steps (= Data
Source Types and Instances) can be configured. In particular it can be assumed that the
programs performing the individual process steps understand values of that type as
input data or at least a mapping exists between Instance Selection Parameter values
and the input data such a program is able to deal with.

Time Selection Parameter Type

o This is the entity type describing the period of time relevant for a certain payroll process
instance. For example this can be a payroll period for which a regular payroll calculation
runs.

o The Time Selection Parameter Type is also assigned to the Data Source Class and tells a
generic consumer how process step instances (= Data Source Results) are created. Again
it can be assumed that the programs performing the individual process steps understand
values of that type as input data or at least a mapping exists between Time Selection
Parameter values and the input data such a program is able to deal with.

Usually these Parameter Types have implementations behind that allow getting further
information about their values from the existing data available in the payroll system like begin
and end date corresponding to a Time Selection Parameter value. This in turn then allows to
enrich generic user interfaces with such information.

6.3.1.1 Example
A Data Source Class represents the template for the regular Payroll Process, has Instance
Selection Parameter Type Payroll Area and Time Selection Parameter Type Payroll Period.
The Data Source Types (= Process Step Templates) assigned to that Data Source Class have to
have Payroll Area and Payroll Period as input parameter types.

A Data Source Instance (= Process Step) representing the regular payroll run for a given payroll
area AB would specify Payroll Area = AB in its input parameter list.

The regular payroll run for payroll area AB and period 01.2014 would then be the Data Source
Result for that Data Source Instance which additionally specifies Payroll Period = 01.2014 as
input parameter value. If there is additionally configuration to derive the program name and
some other administrative information, it is possible then to generically start that program with
the given selection (Payroll Area = AB, Payroll Period = 01.2014) without the need to modify that
program or to even write coding specifically for executing that program.
83 | P a g e
Copyright/Trademark
In case a process step requires some more sophisticated mapping (like parameter values, additional
input data or if it provides some special output information), it is evident that specific mapping
implementations might be required beyond some reusable methods.

The overall approach here is to allow reusing generic implementations on level of a Data Source Type (=
Process Step Template) either complete reuse based on the modeled information, partial reuse by
subtyping/inheritance and redefinition or complete reimplementation of the mapping logic.

This extensibility approach is also expanded to other parts of the template configuration: If existing and
suitable, a delivered process template can completely be reused, it can be enhanced on different levels
or it can be created from scratch by partners and/or customers. Even that creation from scratch for sure
allows reusing a subset of the already existing individual process step templates, if suitable.

The described meta model allows to cover processes like shown in the following two models:

The first shows the overview about a number of payroll process instances within a certain period of time.

The second illustrates how the overview for a certain process instance can look:

84 | P a g e
Copyright/Trademark
Also this is completely based on the meta model. The aggregated status information on step instance,
step group instance and process instance level can be covered by introducing a common result
parameter type that is used to store such status information on step instance (= Data Source Result)
level. This individual status information can be generically aggregated to the higher levels based on the
configured hierarchy.

Proceeding further to individual step instances, like in the following picture,

85 | P a g e
Copyright/Trademark
The user interfaces might have to become more and more specific to the step template. Programs that
simply perform a task in batch to create a result and some status information can be handled by a
handful of generic user interfaces but definitely cases will occur where certain step templates require
specific user interfaces. To allow this in a modification-free way, it has to be allowed to implement and
assign deviating user interfaces on Data Source Type (= Step Template) level.

In the following, the concept how to configure all that is shown in an exemplary way. Provided
information is not complete but should allow understanding the principle.

The focus is now a Step Template for a regular payroll run that usually requires the payroll area and a
period as input information (apart from some administrative information that can already be configured
in the underlying system). For the implementation, coding can be assigned to the configuration, here
shown as class of the corresponding programming language.

Data Source Type (Step Template):

*Note: the maintenance views details are introduced in chapter payroll process configuration
overview

86 | P a g e
Copyright/Trademark
Input Parameter Types:

As mentioned, at least the payroll area (ABKRS = Abrechnungskreis in German) and the payroll period
are required. This is indirectly achieved by the usage of some common minimum required parameter
types for a step:

PYP_PROC (process ID): from this parameter, the relevant payroll areas are indirectly determined
PYP_PROC_INST (process instance): from this parameter, the payroll period is indirectly
determined

The corresponding program name is not configured here because it can be derived from the country in
the underlying system: The Data Source Type is valid for all countries but the corresponding Data Source
Instances have to specify for which country they run, that is, at run time, the name of the program can
be determined automatically and is not required as input parameter type here.

Result Parameter Types: Here we choose two fundamental ones: A status for the whole step that can be
manually set by some operations (shown later), and the identifier of the batch job that performs the
steps program. Other result parameters are also important but not discussed now.

87 | P a g e
Copyright/Trademark
The required operations (status changes and starting/cancelling the batch job) as well as additional
information like the statistics of the program run and other results are modeled as Result Details Types.
The coding that covers the corresponding functionality is implemented in the Data Source Types class
(for example, on class CL_PYC_STT_RUN_PAYROLL).

Operations and Data for the Job (for Result Parameter Type PYP_STS_DET_JOB_PLAN):

Operations for the Status change (Result Parameter Type PYP_STS_DET_JOB_STS):

The already mentioned implementation class is chosen to be specific for the current step template
(which is possible but not mandatory; such classes can be reused across Data Source Types). It inherits
from a generic class that covers the execution of the job and the status handling:

88 | P a g e
Copyright/Trademark
 89 | P a g e
Copyright/Trademark
For this step template, we dont need a deviating user interface.

90 | P a g e
Copyright/Trademark
For some steps though like the data validation, where the payroll manager has to distribute the worklist
to payroll admins, it is required to have a specific user interface that allows the user to work on setting
up the data directly on the user interface. This is done using the so-called User Interface Category
Attributes:

Types of such Attributes are part of the standard delivery, for example path information that can be used
by the generic user interface to find and call a deviating view that shows the underlying data in a specific
format. A Data Source Type now can define values for these Attributes, pointing to the deviating view.
This concept allows even user interface enhancements by partners and customers in a modification-free
way.

So far we have modeled the step template, which means, we still have to specify that this template is
supposed to be used for a certain payroll area. This requires two steps: The creation of the Data Source
Instance for that Data Source Type and the specification of that input parameter for this new Instance.
This will be explained in a next chapter together with the customizing overview.

6.4 Step Template user interface concept

The step template represents a business operation step. It can start a report in backend job or just
remind that some operations should be done offline. Basically the step templates have three typical
types:

Asynchronous batch step which will start one or more reports as background job(s).
Asynchronous manual step which will trigger a task to be done offline.
Synchronous step which will start one or more task and return results immediately.

The template behavior (business logic) depends on its run time class (abap class) implementation.

6.4.1 Components of step template

Step templates have three components:

Input parameter.
Result parameter.
o One result parameter can have multiple result details type.

91 | P a g e
Copyright/Trademark
 UI Category attributes.

6.4.1.1 Input parameter

All necessary information needed to notify the step to run. For instance, the report name which need
start in the step and the variant which should be used for selection criterion .

6.4.1.2 Result parameter

Result parameters are to record the step execution results. For instance, when a job is submitted by a
background job, some questions the step needs to answer:

Is the job started correctly?

What is the job status?
Whats the job run result?

Such questions should be answered by Result Objects.

For example: a background job generally has three result objects:

Job setup status. ex : job setup

Job execution status
Result status (spool file)

The picture bellow indicates where the information of the technical result parameters is related to the
user interface:

92 | P a g e
Copyright/Trademark
6.4.1.2.1 Result details parameter
Result details parameter are always assigned to a given result object, which means how to process the
result object (Operation) or what kind of relative information should be show (displaying data for that
object).

There are two types of result detail parameters:

Data
Operation

The result detail parameters marked as Data retrieve information relative to the result object for
instance job start time, end time, status of the result object PYP_STS_DET_JOB_STS.

The result detail parameters marked as Operation often used to change the result object. For instance
set the job status to OK or Fail manually.

93 | P a g e
Copyright/Trademark
6.4.1.3 UI Category attribute

This component handles the view of the steps main screen (execution screen).

Although most steps share the same default views structure but every step still have chance to configure
its view:

Although most steps share the same default view (the structure how data is presented) it can be useful
to specify a different view for a step. When the user clicks on the activities on the left, the framework
calls a BSP component that will be displayed on the right side. This components are configurable, so that
your own HTML views on the BSP pages can be displayed on the step.

The picture below shows which component is behind which activity:

94 | P a g e
Copyright/Trademark
And on the customizing of the step template, you can specify the location of the BSP component for the
step:

6.4.2 List of sample step templates

Following is the list of standard delivered step templates.

In most cases it is not necessary to build up a template from scratch. There are three templates (Bold
ones) which can be used as base and extended or just copy one of them and add some other input
(output) parameters is a simple way to build up new step template.

Step Template ID Step Template description

PYP_ASYC_BATCH_BASE Copy template for Asyn Batch Step
PYP_ASYNC_MAN_BASE Copy template for manual step
PYP_BASE Copy template for very simple manual step
PYP_CLOSE_PAYROLL Close Payroll Control Record
PYP_CORRECT_PAYROLL Correct Payroll Control Record
PYP_CREATE_DME Create DME File
PYP_CREATE_POSTING Posting Creation Step

95 | P a g e
Copyright/Trademark
 PYP_MD_VERIFICATION Master Data Verification
PYP_OPEN_PAYROLL Open Payroll Control Record
PYP_PREP_MD_VERIFICATION Prepare Master Data Verification
PYP_PREP_PY_VERIFICATION Prepare Payroll Result Verification
PYP_PRE_DME_PROC Create Pre-DME File
PYP_PRINT_PAYSLIP Manual Step : Print Payslip
PYP_PY_VERIFICATION Payroll Result Verification
PYP_RELEASE_POSTING_DOCUMENT Release Posting Document
PYP_RUN_PAYROLL Payroll Process Step Template: Run Payroll
PYP_RUN_PAYSLIP Run Payslip
PYP_SEND_DME Send DME
PYP_SIMULATE_CREATE_POSTING Simulate Posting Create Step
PYP_TRANSFER_POSTING_DOCUMENT Transfer Posting Document

6.5 Payroll process configuration overview

The step templates explained in the previous chapter can be combined in certain groups and in a certain
order to form a process. This is called a process template. It is for example, possible to create a
regular payroll process template which is used throughout the year and a year-end payroll process
template which is used toward year end. The process template can be time-dependently assigned to a
payroll process ID (for example, to assign these two mentioned process templates to a process called
payroll for headquarters payroll area A1). Finally it is necessary to have several instances of a process
ID, one for each payroll period.

The following picture illustrates the idea of a process template (= collection of steps in a certain order)
assigned to process IDs:

96 | P a g e
Copyright/Trademark
A complete payroll process is actually not only comprised of the steps involved on running payroll
itself, but also preliminary steps like masterdata maintenance, where it might be necessary to run some
data preparation programs like pay scale update for example, and also of many subsequent steps like
legal reporting. Legal reporting steps are usually not related to a payroll area in terms of employee
reporting grouping but rather legal entities like Tax Company or Company Code. Therefore it is clear that
such steps cannot be included in the same actual Payroll Process process which runs by Payroll area. In
order to achieve a synchrony between payroll area processes and, lets say, Company code processes
(not restricted to company code entity, but just as an example) it is required to set up multiple Processes
with different templates, periodicity and main grouping parameter (technically called instance selection
parameter)

97 | P a g e
Copyright/Trademark
The following picture illustrates how a payroll area and a Company code process might interact from a
calendar perspective. Notice that the employees from payroll areas A1 and A2 can be included in the
process of company code US01, therefore the idea of sync-point towards day 20 on the calendar below,
because the legal reporting on US01 could not start before the payroll areas A1 and A2, which have
different periodicities, are closed and finished for the periods that belong to July:

6.5.1 Customizing

The following picture illustrates the customizing steps to be followed and the relevant maintenance
views (or view clusters) required to configure the payroll processes in the development system:

Note: view clusters (accessible in transaction SM34 ) start with prefix VC_*, while maintenance
views(SM30) stats with prefix V_*

98 | P a g e
Copyright/Trademark
Notice that the program PYC_GENENRATE_STEP is also a customizing step. This program helps to set up
and auto-generate customizing data for the individual process steps that can be adjusted and completed
still on the dev. system. More information about this report, you find on chapter Auxiliary reports and
their usage.

6.5.2 Runtime settings

In the production system, it will be necessary to generate the actual Process instances. If you have a
process like Regular monthly payroll for Headquarters location then you will probably require twelve
instances of this process, one for each month. In order to do that, you run report

99 | P a g e
Copyright/Trademark
PYC_GENERATE_PROC_INSTANCE. More information about this report, you find on chapter Auxiliary
reports and their usage.

By running this program which is done on the Production system, runtime objects are generated for the
selected periods.

One process instance represents Process objects generated for one period containing the set of
Groups and Steps and all parameters necessary to the execution of the steps

Updated tables:

PYD_D_RES (stores technical internal information)

PYD_D_RESP: contains information necessary for the handling of the steps (like, Payroll driver
variant, Class ID for PY checks execution, etc...)
PYD_D_RESO: contains mainly information about the current situation of the steps(execution
status, error status, batch report names triggered by the step)

6.5.3 Technical relationship between Payroll process configuration and Datasource

framework configuration
The following pictures illustrate the equivalence between the Datasource framework and the payroll
process configuration. In yellow color it is shown the Datasource framework specific views. Eventually,
both lines of maintenance views will update the same database tables. The views for the payroll process
were built in order to offer a more payroll process oriented configuration experience.

100 | P a g e
Copyright/Trademark
Runtime instance execution:

Recap:

Steps = datasource type

Group = Folder
Process template = Class
Step instances = datasource instance

101 | P a g e
Copyright/Trademark
6.6 Additional aspects of the Payroll Datasource Framework

6.6.1 Authorizations

The payroll control center is a solution to manage the existing SAP_HR software layer bringing simplicity
and valuable user experience. That also means that the existing authorization concepts present on the
SAP_HR software applications are involved in every activity performed on the payroll control center by
the users. If the user for example triggers a step execution which at backend level means to run an HR
report, this step will only be successfully initiated if the user who trigger the step executed at the payroll
control center UI has actually authorizations for the classic HR report (at abap layer). The same is valid
for displaying of payroll related information on payroll control center. Only users who are authorized at
the backend to view the information will actually be able to view the information at the payroll control
center.

For sure the payroll control center offers an additional authorization objects set which makes it possible
to control which users have access to which steps or processes and which operations these users are
allowed to execute. However, it is necessary to understand that simply authorizing users to Payroll
control centers steps will not automatically grant access to the actual application layer on the backend
system. In other words, if a user is to be authorized to start the payroll thru the run payroll step on the
payroll control center, this user must be first authorized to run the payroll driver (e.g. RPCALCU0),
otherwise the step execution will fail.

Therefore the authorization concept for the payroll control center can also be seen as a way to distribute
payroll processes responsibilities among payroll managers, who technically are authorized to display and
execute activities globally in the HR system.

Recommendation: During the generation of the steps in the customizing system, with program
PYC_GENERATE_STEP (see previous chapter) there is the option to include an authorization prefix for
the generation of the process. This prefix will be included in the technical names of the step objects (see:
process data flow chapter). These names will be checked against authorization objects when users are
accessing the payroll control center application. Therefore, it is recommended to set up authorization
prefixes on the authorization profiles with generic names composed by a prefix and a star (like
prefix*).

102 | P a g e
Copyright/Trademark
Below you will find specific information about the payroll control center (actually data source
framework) authorization objects. These are more payroll process oriented. The authorization concept
behind the selection and displaying the check results data to payroll admins is extensively described in
chapter Personnel administration Authorization interface for non PNP applications.

The SAP Net Weaver authorization concept is based on assigning authorizations to users based on roles.
For role maintenance, use the profile generator (transaction PFCG) on the AS ABAP and the User
Management Engines user administration console on the AS Java.

These are the security-relevant authorization objects that are used by the Payroll control center.

Authorization Field Value Description

Object
P_PYD_CLS P_PYD_CLS: Class P_PYD_CLS: Class ID. This authorization
ID. The values of the field P_PYD_CLSA are object allows
P_PYD_CLSA: the following: access to Data
Activation status 0: Not specified Source Classes
with fixed values 1: Inactive and allows
of a domain 2: In preparation controlling what
3: Active classes the users
are able to
access.
Translated into
the user
interfaces, the
classes are the
main steps the
users see in their
screens (like the
tiles on the first
screen of the
Payroll control
center).
The Class ID also
corresponds to
the Payroll
process
template, this is
explained later in
this document
P_PYD_INST P_PYD_INST P_PYD_INST: Instance ID This authorization
P_PYD_IAUT P_PYD_IAUT: Activity with fixed values object is used to
P_PYD_RDT of a domain (most important activities control the access
for a typical user are R, O, and D) to Data Source
R: Read Results Instances with

103 | P a g e
Copyright/Trademark
This is checked if the Instance and their possibilities for
Result Objects are read. Every Payroll fine-granular
Control center user should have it for configuration
the Instances he/she is responsible for. based on the
C: Execute and rebuild complete exact user role.
Instance
This is checked if rebuild of the result
object list is requested ("delete and
recreate list"). This can currently only be
done by directly calling the backend
service (OData and/or ABAP) or by
starting report
PYD_EXECUTE_INSTANCES (transaction
PYD_EXI) with option Rebuild = true.
E: Execute and refresh complete
Instance
This is checked if refresh of the result
object list is requested ("recalculate
status of existing objects, add new
objects but do not delete existing
ones"). This can currently only be done
by directly calling the backend service
(OData and/or ABAP) or by starting
report PYD_EXECUTE_INSTANCES
(transaction PYD_EXI) with option
Rebuild = false.
O: Change field values of Result Objects
This is checked if the user changes the
error status of a result object and/or
adds a change reason. - A Payroll
Control center user who is supposed to
change the error status should have it.
D: Access Result Details Type
This is checked if the user accesses the
details for a result object (like the
employee header or the generic
overview). For which Result Details Type
the user is authorized is determined in
the third field P_PYD_RDT.
I: Recheck individual Result Objects
This is currently not supported. Already
added for possible future
enhancements.
H: Display change history
This is currently not supported. Already
added for possible future
enhancements.
X: Delete Result
104 | P a g e
Copyright/Trademark
 This is checked if a result of the Instance
is deleted. This can currently only be
done using report
PYD_DELETE_INSTANCE_RESULTS
(transaction PYD_DIR).
P_PYD_RDT: Result Details Type which is
checked in case of activity "D"
P_PYD_UV ACTVT The values of the field ACTVT are the This authorization
following: object allows a
01: Create or Generate user to maintain
02: Change user variants for
03: Display other users.

6.6.2 oData
The communication between the UI and the backend is done via SAP gateway server. A total of four
OData projects were created and provided as odata services:

Odata Project Odata service Description

PYC_CONT PYC_CONT_SRV Payroll Control Center Content
PYC_FRW PYC_FRW_SRV Payroll Control Center Framework
PYD_CONT PYD_CONT_SRV Payroll Data Source Content International
PYD_FRW PYD_FRW_SRV Payroll Data Source Framework

6.6.2.1 PYC_CONT

6.6.2.1.1 Entity Types

ExecuteWorklist
o Association
ToWorklistDetails(WorklistDetails)
SessionWorklistDetail
SessionWorklistISP
SessionWorklistPayrollArea
StatusDetailsGenericOverview
o generic overview data. Sometimes it will be showed by GOV structure.
StatusDetailsLongText
o Get status detail description.
StatusWorklist
WorklistCreate

105 | P a g e
Copyright/Trademark
 o Association
ToWorklistCreateDetails(WorklistCreateDetails)
WorklistCreateDetail
WorklistDetail
WorklistField
o Association
ToWorklistParamValues(WorklistParamValues)
WorklistFieldValue
WorkListTile
WorkListUser

6.6.2.1.2 Entity Sets

ExecuteWorklists
o Association
WorkListToWorkListDetails
SessionWorklistDetails
SessionWorklistISPs
SessionWorklistPayrollAreas
StatusDetailsGenericOverviews
StatusDetailsLongTexts
StatusWorklists
WorklistCreate
WorklistCreateDetails
WorklistDetails
WorklistFields
o Association
ToWorklistParamValuesSet (WorklistFieldValues)
WorklistFieldValues
WorkListTiles
WorkListUsers

6.6.2.2 PYC_FRW
ActionLogDetail
o Get action log detail data
o Association
ToActionLogItems(ActionLogItem)
ActionLogItem
o Get action log item data
APIVersion
o Get version data which relative to BF
ConfirmDetail

106 | P a g e
Copyright/Trademark
 o Get confirm detail data
ExecuteDetail
o Get execution detail data
o Association
ToSelectionGroups(SelectionGroup)
Process
o Get process data
o Association
ToProcessInstances(ProcessInstance)
ProcessFilterValue
o Get process filter values
ProcessInstance
o Get basic data of a process Instance
o Association
ToStepGroupInstances(StepGroupInstance)
SelectionGroup
o Get selection group data
o Association
ToSelectionGroupGenericOverviews(SelectionGroupGenericOverview)
SelectionGroupGenericOverview
o Get group GOV data
StatusDetail
o Get status detail data
StepGroupInstance
o Get step group data
o Association
ToStepInstanceOverviews(StepInstanceOverview)
StepInstance
o Get step instance run result data
o Association
ToExecuteDetails (ExecuteDetail)
ToStatusDetails(StatusDetail)
StepInstanceOverview
o Get step instance run result data
o Association
ToStepInstances

6.6.2.2.1 Entity Sets

ActionLogDetails
ActionLogItems
APIVersions

107 | P a g e
Copyright/Trademark
 ConfirmDetails
ExecuteDetails
Processes
ProcessFilterValues
ProcessInstances
SelectionGroupGenericOverviews
SelectionGroups
StatusDetails
StepGroupInstances
StepInstanceOverviews
StepInstances

6.6.2.2.2 Function Imports

StatusDetailsOperation
o Perform some operation on status details such as set ok ,set error
StepGroupInstanceOperation
o Perform some operation on status details such as reset
StepInstanceCreateActionLog
o Add action log
StepInstanceOperation

Perform some operation status such as lock step instance

6.6.2.3 PYD_CONT

6.6.2.3.1 Data Model

6.6.2.3.1.1 Entity Types

InstanceSelectionPayrollArea
ResultObjectDetailsGenericOverview
ResultObjectDetailsSimpleWageType
ResultObjectDetailsText

6.6.2.3.1.2 Entity Sets

InstanceSelectionPayrollAreas
ResultObjectDetailsGenericOverviews
ResultObjectDetailsSimpleWageTypes
ResultObjectDetailsTexts

6.6.2.3.1.3 Function Imports

6.6.2.3.2 Service Implementation

InstanceSelectionPayrollAreas(GetEntitySet(Query))
ResultObjectDetailsGenericOverviews(GetEntitySet(Query))
108 | P a g e
Copyright/Trademark
 ResultObjectDetailsSimpleWageTypes(GetEntitySet(Query))
ResultObjectDetailsTexts(GetEntitySet(Query))

6.6.2.4 PYD_FRW

6.6.2.4.1 Data Model

6.6.2.4.1.1 Entity Types

AllowedResultDetailsType
AllowedStatusChangeReason
APIVersion
Class
DefaultErrorStatus
DefaultResultObject
DefaultResultParameter
Folder
Navigation - Instances
Associations - ToInstances
Instance
Navigation AllowedResultDetailsTypes
Associations - ToAllowedResultDetailsTypes
Navigation DefaultErrorStatuses
Associations - ToDefaultErrorStatuses
Navigation DefaultResultObjects
Associations - ToDefaultResultObjects
Navigation DefaultResultParameters
Associations - ToDefaultResultParameters
Navigation Folders
Associations - ToFolder
Navigation - InstatnceUIMetaDatas
Associations - ToInstatnceUIMetaDatas

InstanceSelectionParameter
InstanceUIMetaData
ParameterTypeMetaData
Navigation - ParameterTypeUIMetaDatas
Associations ToParameterTypeUIMetaDatas
ParameterTypeUIMetaData
ResultDetailsTypeUIMetaData
SessionUserVariantDetail
UserVariant
Navigation Details
109 | P a g e
Copyright/Trademark
 Associations - ToUserVariantDetails
UserVariantDetail

6.6.2.4.1.2 Entity Sets

AllowedResultDetailsTypes
AllowedStatusChangeReasons
APIVersions
Classes
DefaultErrorStatus
DefaultResultObjects
DefaultResultParameters
Folders
Instances
InstanceSelectionParameters
InstanceUIMetaDatas
ParameterTypeMetaDatas
ParameterTypeUIMetaDatas
ResultDetailsTypeUIMetaDatas
SessionUserVariantDetails
UserVariants
UserVariantDetails

6.6.2.4.1.3 Association Sets

InstancesToDefaultErrorStatus
InstancesToDefaultResultObjects
InstancesToDefaultResultParameters
InstancesToFolders
InstancesToInstanceUIMetaDatas
ParTypeMetaDatasToParTypeUIMetaDatas
UserVariantsToUserVariantDetails

6.6.2.4.1.4 Function Imports

InstanceDefaultResultRebuild Type:POST
InstanceDefaultResultRefresh Type:POST

6.6.2.4.2 Service Implementation

AllowedResultDetailsTypes(GetEntity(Read)/GetEntitySet(Query))
AllowedStatusChangeReasons(GetEntitySet(Query))
APIVersions(GetEntitySet(Query))
Classes(GetEntity(Read)/GetEntitySet(Query))
DefaultErrorStatus(GetEntity(Read))
DefaultResultObjects(GetEntity(Read)/GetEntitySet(Query)/Update)
110 | P a g e
Copyright/Trademark
 DefaultResultParameters(GetEntitySet(Query))
Folders(GetEntity(Read)/GetEntitySet(Query))
Instances(GetEntity(Read)/GetEntitySet(Query))
InstanceSelectionParameters(GetEntitySet(Query))
InstanceUIMetaDatas(GetEntity(Read)/GetEntitySet(Query))
ParameterTypeMetaDatas(GetEntity(Read)/GetEntitySet(Query))
ParameterTypeUIMetaDatas(GetEntity(Read)/GetEntitySet(Query))
ResultDetailsTypeUIMetaDatas(GetEntity(Read)/GetEntitySet(Query))
SessionUserVariantDetails(Create/Delete/GetEntity(Read)/GetEntitySet(Query)/Update)
UserVariants(Create/Delete/ GetEntitySet(Query)/Update)
UserVariantDetails(Create/Delete/GetEntity(Read)/GetEntitySet(Query)/Update)

6.6.3 User sessions

If a user carries out work in multiple transactions in different windows or browser tabs, he/she may
create different operation contexts. The User session concept is created to support such cases.

Every browser session (new tab or new window) will be associated to a specific session ID on the
backend. The operation context(what the user is handling with on the browser session) is saved in the
session user variant or virtual user variant. These user session data is then stored in database table
PYD_D_US. In addition, an expiration time is generated upon creation of the session.

Session Expiration Period

The default expiration period will be 2 hours (120 minutes). However it is possible for users to modify the
expiration period via user parameter PYD_USER_SESSION_EXP in number of minutes. For example, a
user can set the expiration period to 3 hours by setting PYD_USER_SESSION_EXP to 180.

Sub-Session Concept

In order to establish different selection criteria for different worklists in a single transaction (user
session), the sub-session concept is introduced in Payroll Control Center for payroll admin. Each worklist
will be assigned a sub-session ID and corresponding session user variant. The session user variant holds
the selection criteria of the worklist. All these sub-sessions will be organized under a unique main session
ID in table PYD_D_US.

Session Storage in UI

If the oData service calls do not pass a session ID in the request header, the system will return a newly
generated session ID to the UI in the http response header. In order to read the session related context,
and to keep working on that session context, the subsequent oData service calls need to pass the session

111 | P a g e
Copyright/Trademark
ID in the http request header. Each successful oData call with a valid session ID will extend the session
expiration time by the preset period.

Expired Sessions

The old user sessions data need to be cleaned up from the database tables, as these tables will grow
with time during usage. In order to clear the expired session an auxiliary report needs to be executed
(PYD_DELETE_EXPIRED_SESSIONS).

6.6.4 User variants

As introduced in the previous section about user sessions, the user variant is used to store the navigation
and operation context from the application. User variants are stored in the database table PYD_D_UV
with its ID; the name, and its selection criteria are stored in table PYD_D_UVD with pairs of parameter
type and value. Both tables will save the administration info like the creation/change user, time and an
ETAG to manage and keep track of changes.

User variants are also used for:

Storing worklists selection criteria for a specified process step in a process instance;
Storing worklists template for a specified step in all process instances of a process;
Virtual user variants to apply certain filtering and selection criteria during runtime.

Worklist and Worklist Template

As introduced before, the payroll manager assigns worklists to payroll administrators by applying certain
selection criteria on a check result set. The selection criteria are then saved as a user variant with
category WL or WT.

When creating a worklist in a process step of a process instance, the worklist is created together with a
worklist template. The relation between the worklist and the process context is stored in database table
PYD_PC_D_WL, with the user variant ID, the process step ID and process instance ID (for worklist), or the
process ID (for worklist template). Upon confirmation of the data verification step, the Worklists linked
to the process step of the process instance will be deleted. However the worklist template will be kept
and used as a default worklist set up in the new subsequent process instances of the step.

Virtual User Variant

In the Payroll Control Center for payroll manager application, the process instance and process step
instances need to be filtered according to users navigation operations. These selection criteria are only
used for navigation purposes, thus there is no need to store them into the database. The concept of
Virtual User Variants is introduced (using class CL_PYD_USER_VARIANT_VIRTUAL), where a user variant
is constructed and applied at runtime.
112 | P a g e
Copyright/Trademark
6.6.5 Status Model

6.6.5.1 Error Status for Data Source Framework

In the Data Source Framework, each result parameter contains an error status which normally has the
type Simple Error Status, i.e. the error status value comes from the ABAP DDIC domain PYD_EST. So
if the Simple Error Status strategy is used, the value of the error status would be within Error,
Manually set to OK and Automatically set to OK. Otherwise, the value of the error status will be
always set to Not specified. This will lead to the error status of each data source (result object) not be
counted up to the error count (error aggregation process).

For example, one of the result parameters of data source instance Gross variance>5% in data source
class Wage Type Check (China) is PERNR. If one person does not pass the check originally, the error
status of the result object will be set to Error. Then if the user (payroll admin) found that the issue is
really caused by some errors in the masterdata and correct them accordingly, after the refresh of the
execution status of the data source, the error status of the result object will be set to Automatically set
to OK. If the error on the masterdata still persists, the end-user still has the chance to manually set the
error status to OK with a mandatory change reason. Thus the error status of the result object will be
Manually set to OK. The result objects error status of all data sources will be aggregated to their data
source folder and be aggregated to their data source class through the error count number.

The following pictures illustrate the use case Manually set to OK.

Clicking on a tile (data-source class) which shows a total error count 2:

113 | P a g e
Copyright/Trademark
Clicking on a check instance (data-source instance), its folder also shows an error count of 2:

Setting the error status of an employees issue to OK:

114 | P a g e
Copyright/Trademark
The error count on Folder level decreases to 1 (when going back to the previous screen):

The error count also decreased to 1 on the Tiles (Classes) screen

115 | P a g e
Copyright/Trademark
6.6.5.2 Payroll Process Status Model
In the concept of payroll process of payroll control center, the status model is a bit more complex than
the so called Simple Error Status model. Basically, with the context of payroll process, all of the step
instances have two types of status (result objects), i.e. Execution Status and Error Status. Both status
values will be aggregated to each step group instance and then be aggregated to each process instance.
The end user can check both of the status values of any process instance and even filter the process
instances by those two types of error status.

6.6.5.2.1 Execution Status

The execution status, which contains status values as Not Started, In Execution, Closed, and
Locked, reflects the execution information of each step instance. The following status machine
diagram illustrates the status transitions for a Stand-alone step (that is, a step that runs without a
process context).

116 | P a g e
Copyright/Trademark
When running a step within a process, some of the status transitions would not be triggered directly at
the step level but rather at the group level, e.g. Reset as well as Lock is only allowed to be triggered
at group level. The operation Reset, is only allowed when the current processing step status is Closed
and the current processing step group status is In Execution or Closed. The operation Lock is only
allowed when the current processing step group status is Closed, and once locked, it cannot be
changed any more.

For example, you have executed the payroll for all employees with the payroll control record status
Released for Payroll. You then identify some issues and, therefore, have to change some master data.
Now, you need to repeat the payroll for the employees whose master data has been changed. To be able

117 | P a g e
Copyright/Trademark
to run the payroll again, you must reset the process step group to release the payroll control record
again.

6.6.5.2.2 Error Status

The error status, which contains status values as Not Specified, In Preparation, Error, and OK,
reflects the error information of each step instance. The main activity of each step instance will trigger
the status change of both execution status and error status. The status transition would be checked by
so called Veto Status Check. The following pictures describe the status values and their relationship.

Basically, there are two kinds of step template according to the synchronous characteristic of its
wrapped activity. For some activities like payroll control record operations, the execution time would be
fast enough to let the front end waiting for the execution results synchronously. The error status can be
Error or OK directly without user interaction. But for some other activities like running payroll which
is a time-consuming operation, the wrapped step template will start an asynchronous batch job and
returned immediately. Once the background job is finished it will trigger another batch job to refresh the
execution result of the step instance. In this case, once the step instance is started, the error status will
be transited from Not Specified to Error, after the end user gets the refreshed result data and check
the results validity, the user then needs to manually set the error status from Error to OK.
118 | P a g e
Copyright/Trademark
Another important concept for the error status processing is the sub-status registration and aggregation.
The error status of each step instance should be composed by several so called Registered Sub-Status.
The whole error status of each step instance should be aggregated by all of its sub statuses and cannot
be changed directly. The following picture illustrates the status transition and aggregation process of a
step instance (two out of three status views are green; the other one is till red. The overall status is then
red, shown as a triangle red).

6.6.6 Auxiliary reports and their usage

This chapter describes various auxiliary reports and their usages in Payroll Data Source Framework and
Payroll Process Framework.

6.6.6.1 Payroll Data Source Framework

6.6.6.1.1 PYC_DELETE_EXPIRED_SESSIONS Delete Expired User Sessions

This report is used to delete expired sessions, the corresponding user variants and details. User variants
are created for each UI session. The expiring period is defined by default 2 hours, or taking the value
from user parameter PYD_USER_SESSION_EXP. It is also possible to schedule a regular job with this
report to clean the expired sessions data in their system.

119 | P a g e
Copyright/Trademark
6.6.6.1.2 PYC_DELETE_INSTANCE_RESULTS Delete Data Source Instances
This report is used to delete all data source instances selected and the log related to each data source
instance.

6.6.6.1.3 PYD_EXECUTE_INSTANCES Execute Data Source Instances

This report is used to execute all data source instances selected. Normally, this report will be triggered
automatically by the payroll control center steps. It can also be manually started depending on the use
case.

120 | P a g e
Copyright/Trademark
6.6.6.2 Payroll Control Center
In Payroll Control Center, three standard reports are delivered for generating process steps, process
instances and refresh process step instances. Meanwhile, additional SE38 reports are delivered as
consultant utilities to configure processes, to monitor each process instances input and output and reset
process instance hierarchy. More details about the customizing and steps below you find in chapter
payroll process configuration overview.

6.6.6.2.1 Transaction PYC_STEP_GES Generate Process Step

You use this report to generate process steps for a process. You are required to do so before you can
generate process instances for the same process. For example, in Customizing for Payroll under Payroll:
International -> Payroll Control Center -> Payroll Process Management, you have defined a process
Regular Payroll for Payroll Area California and a step template Master Data Verification in this process.
You then use this report to generate the steps for this process. In this case, the report generates a
process step Master Data Verification for Payroll Area California.

This is still a customizing step. After completing the data on the different sub-views, click on save button.
The completed sub-views will show with a highlighted green color

121 | P a g e
Copyright/Trademark
6.6.6.2.2 Transaction PYC_INSTANCE_GES Generate Process Instance

You use this report to generate payroll process instances. A process instance is a process for a given
payroll period which is based on a certain process ID which is assigned to a process template.

Here, you can better specify the date intervals of each step group. These dates will appear on the
calendar screen on the end-user application

122 | P a g e
Copyright/Trademark
6.6.6.2.3 Transaction PYC_RSI Refresh Process Step Instance

You can use this report to refresh step instances, such as refreshing job status for asynchronous activities
and recalculating error count for steps dealing with checks on master data or payroll results. By default,
the report refreshes step instances with the execution status In Execution and the error status In
Preparation on the back end. The front end uses the refreshed data when requesting data. The user can
refresh the Payroll Control Center front end to see the refreshed data. You can also schedule the report
to run regularly for a list of processes in order to automatically trigger the refresh. Alternatively, you can
also execute this report for arbitrary step instances - independent of their error status (the Step
Template base class might reject this refresh if the execution status of a step instance does not allow
changes).

6.7 Payroll process data flow

This data flow explains the end-to-end distribution of the payroll process and steps customizing and
runtime objects on the database tables. This is a more technical description rather than implementation
focused.

VC_PYC_PYP_PT

123 | P a g e
Copyright/Trademark
V_PYC_D_PYP

Assign Template
V_PYC_D_PYPTE

Generate Step 1
PYC_D_INSTP to find instance

124 | P a g e
Copyright/Trademark
Generate Step 2
instance detail information

125 | P a g e
Copyright/Trademark
Generate Step Instance & Execute 1
step instance

Generate Step Instance & Execute 2

step instance result

Generate Step Instance & Execute 3

step instance result parameter

126 | P a g e
Copyright/Trademark
Generate Step Instance & Execute 4
step instance result object

127 | P a g e
Copyright/Trademark
6.8 Worklist management (backend)
As mentioned in previous chapters, the Worklists is managed in the backend system as user variants.
This chapter will introduce how the worklist concept is managed from technical point of view.

6.8.1 Customizing

Payroll Manger Perspective

a) Payroll Process Step: Prepare Data Verification
Here a predefined set of checks need to be executed. This step is called "Prepare Data
Verification".
Configuration
o The check class (CLASS ID, which is the technical name to the tiles on the payroll admins
screen) related to the step needs to be assigned to the step( in Report:
PYC_GENERATE_STEP)

See the above parameter CLASSID, it contains the reference to the data-source class ID which contains
the folders with the checks.

b) Payroll Process Step: Data Verification

A Worklist is a collection of check errors to be corrected by specific payroll admins. The
collection is a subset of the check results generated in the previous preparation step.
Configuration
o The check class related to the step need to be assigned to the step.(Report:
PYC_GENERATE_STEP, similar to the previous step)
o In order to get the list of payroll admin users who will be assigned to work on the issues to
be fixed, an administrator group (SBMOD) needs to be assigned to the step. The user list will
come from the table T526 under the specified administrator group. (see parameter SBMOD
below)

128 | P a g e
Copyright/Trademark
2. More Details
Object filtering for worklists
After assigning a check class to the data verification step, the filters for defining the worklist will
also be decided. For example, if the check instances under a class has the result parameter type
PERNR (personnel number), then filters like personnel area/subarea, employee group/subgroup,
cost center etc. can be used as selection criteria for defining the worklist.
Following parameter types are created in standard to be used as filters for result parameter type
PERNR:
o ABKRS Payroll Area
o BTRTL Personnel Subarea
o BUKRS Company code (test)
o JUPER Legal Person
o KOSTL Cost Center
o ORGEH Organizational Unit
o PERNR Personnel Number
o PERSA Personnel Area
o PERSG Employee Group
o PERSK Employee Subgroup
o SBMOD Administrator Group
o VDSK1 Organizational Key
o WERKS Personnel Area

These has been assigned in the maintenance view cluster VC_PYD_DTL

129 | P a g e
Copyright/Trademark
Furthermore, a new interface IF_PYD_PAR_TYPE_FILTER needs to be implemented by the result
parameter types runtime class to enable the filtering.

In case of customer defined result parameter type, user may also enable filtering for creating
Worklists for the result objects. These configuration and implementation are also required. The
standard parameter type PERNR can be used as a reference. All the filtering coding and

130 | P a g e
Copyright/Trademark
customizing (for PERNR parameter type) is already delivered on standard and is ready to be
used.

Step specific texts related to the check class

For data verification steps, some of the texts on screen are dynamically decided. This is to ensure
that the Prepare data verification and Data verification steps can be reused in different
phase of the payroll process (for example, pre-payroll check and payroll result check).

For the Execution view of prepare data verification step has the following dynamic texts:
o The description of the step.
o The execution button of the step.

131 | P a g e
Copyright/Trademark
 Similarly in the Data verification step follows, the check class description texts will also
dynamically be shown in:
o The description of the step.

And the error count generated by the executed checks will also be displayed dynamically in the
step description.

6.8.2 Creation of Worklists

For the end-user, the only way to create a worklist is from the Payroll Control Center, in a data
verification step, where the payroll manager defines and assigns Worklists to payroll administrator(s).

Note: in one step of a single process instances (for example, payroll data verification step in regular
payroll process US for period 2014.01), for each payroll administrator, a maximum of only one worklist
can be assigned.

Upon submission of the Worklists, the runtime facade will create the user variant with category WL
and WT. Meanwhile to record the relationship between the worklist and the process instance, a record
in table PYD_PC_D_WL will also be created. This record will serve as a directory table to search for
Worklist information using the process contexts.

132 | P a g e
Copyright/Trademark
6.8.3 Consuming the Worklist
For the payroll manager, viewing other users (payroll admins) worklists on the data verification
step:
Worklists are retrieved with the process contexts (Process instance and step ID), all the worklists
created in these contexts need to be return to the UI.
To do this the table PYD_PC_D_WL is looked up, and the worklist ID is returned. If there is no
existing worklist, the corresponding process ID if used to look for the worklist templates, which is
saved in previous process instance. Then, corresponding worklists will be created based on this
worklist template.
The selection criteria are stored in the user variant indicated by the worklist ID.
This is realized in the oData service for getting the entity set ExecuteWorklist and
WorklistDetails.

Then the worklist error status and count can be retrieved by applying the user variant on the
result object list, indicated by the check Class ID assigned to the process step.
This is realized by calling the facade method CL_PYD_PC_RT_FACADE -
>GET_CLASSID_ERROR_CNT_FOR_USER().

For the payroll admins transactions: generating, updating and deleting session user variants in
the payroll administrators view is necessary. For this, the worklists need to be retrieved
according to the user name. In order to do further filtering by instance selection parameter (for
example payroll area ABKRS), session IDs need to be generated for every worklist of the user.
This is achieved by adding a sub-session concept to the main transaction (main session id). The
sub sessions will holds the session user variant, where the session specific filter values are
stored. These filters are actually the logic behind getting different content under the tiles shown
in the picture below

133 | P a g e
Copyright/Trademark
Table PYD_D_US where the session and user sessions are stored:

The above screenshots shows the relationship between the worklist in UI and the sessions in
backend. There are two user variants related to each sub session:
o Instance selection variant:
This is used to store the instance selection parameter currently chosen by the user.

o Filter variant:
This holds the worklist selection criteria defined by the payroll manager.

From the above introduction, you can see that for the payroll administrator, the check result
objects are/can be filtered twice. First, it is filtered by the filter variant. If the user chooses some
instance selection filter on UI, the result will be further filtered again.

134 | P a g e
Copyright/Trademark
 An example would be: the payroll manager assigned a worklist to payroll admin A, where it
contains all the check errors for personnel area PA01 (filter variant is applied), where the
employees with error might be in payroll areas A1 and A2. Then the payroll admin chooses to
see only the results from payroll area A1 (instance selection variant is applied).

A user could choose different payroll areas in different browser sessions for working efficiently.
Since the entire contexts are stored as session specific user variants, this can be guaranteed.

The related oData services are:

o WorkListTile get entity set

This will complete several tasks:

Retrieve all worklists of the user

Generate sessions and session user variants for each worklist

o SessionWorklistDetails update entity and delete entity

This is to update and restore the session user variant contents.

o SessionWorklistISP get entity set

This is to get workist related instance selection parameter values

o SessionWorklistPayrollArea gt entity set

If the instance selection parameter is payroll area, the detail information is retrieved
with this service.

6.8.4 Deletion of Worklists

The worklists can be destructed when the data verification step is confirmed (and actually this happens
automatically). This is to make sure that the completed worklist will not be shown on the payroll
admins view anymore.

There is no specific oData for doing this. Instead, the logic is compiled in the data verification step
implementation when executing the operation Confirm.

6.9 Personnel administration Authorization interface for non PNP

applications
6.9.1 Concept
This is a development tool which can be used by HR applications to organize how the Personal-related-
authorization- checks are to be performed

135 | P a g e
Copyright/Trademark
With the advent of HANA and the increasing trend on mobile and on-demand applications, some new
technologies paradigms like in-memory database processing and Rest-full services became quite present
and essential to new applications developments. These new paradigms shift the way the data is
processed and consumed with regard to the conventional way, heavily based on the usage of the
application server. Now, with the application logic being pushed down the database layer (due to column
store, in-memory) and having stateless communications from mobile and on-demand applications
(restful services) to the application server, two new concepts are required: that the data processing is
more tuple oriented instead of for each oriented, and that more application logic is left for the
database with less dependency on the application server sessions memory.

Up to now, the great majority of HR applications, which must deal with a set of Personal numbers, use
the concept of PNP logical database to decide upon the Personal numbers to be selected (according to
the requested criteria by the application) and to filter out which Personal numbers the current user is
not allowed to have access to. The authorization concept for the existing applications using the PNP
logical database is mainly based on a predefined combination of infotypes defined globally on an
applications code. Ex:

The PNP engine will determine a list of Personal numbers to be selected (considering the selection
criteria the user entered on the applications selection screen) and will filter out, one by one, the
personal numbers which the user is not allowed access according to the defined infotypes combination
(in this case, infotypes 0001, 0002 and 0008). If the user is not allowed to display data to at least one of
the predefined infotypes in the application, the relevant personal number(s) are rejected. The processing
of the business logic of the application itself happens in between each of these one-by-one selections
and authorization checks. This one-by-one processing paradigm imposed by the PNP makes it difficult to
push down application logic to the database (especially in case of analytics). In addition, not all future
applications that combine analytical with transactional properties can be restricted to the working mode
of the PNP.

The new authorization interface reuses the same standard HR authorization components as the PNP.
Therefore nothing is new in terms of authorization in the system. What it actually does is basically to
allow the implementer application to take a bit more control of the data retrieval and decide in which
order the authorization checks should be performed, with or without the assistance of pre-calculated
information, how the result of these checks are consumed, when the actual authorization check must be
performed (for example, before or after the data retrieval from the application, in any case before
making it available as an output).

136 | P a g e
Copyright/Trademark
6.9.1.1 Authorization types
The authorization type was introduced as a way to organize common sets of infotypes that should be
taken into consideration during personal data selection by an HR application. In contrast to the PNP
based reports, these infotypes sets are no more hard-coded into a global area of an application but
simply customized in the system as an authorization type. Different applications may be assigned to
these authorization types.

For example, many classic wagetype-based reporting tools (such as H99CWTR0, or similar country
specific reports, such as payroll journals or payslip tools) perform the authorization check on the
common set of infotypes: 0001, 0002 and 0008 (org. assignment, personal data and salary info) with
read operation. The user executing such a report will be able to see all employees for whom the user is
authorized for these three infotypes at the same time. The same can be achieved by an application
implementing the new authorization interface which is making use of an authorization type consisting of
infotypes: 0001, 0002 and 0008.

In a nutshell: an Authorization type is a collection of infotypes and other HR objects for which an
authorization check must be performed. An HR application can make use of this authorization type,
which will take care of filtering out the employee data that an user is not allowed to access. An
Authorization type can be used by several different applications.

6.9.1.2 Evaluation type

The evaluation type determines how the authorization interface will perform the authorization checks
and how the implementing application may obtain the list of authorized employees checked by the
interface.

The evaluation type considered for a given authorization check is determined by the authorization
interface and depends on the user who is requesting the data and also on the authorization type
involved. This flexible evaluation type determination is important for performance reasons due to the
granularity and quantity of authorized data an user might have for a given authorization type.

How the list of authorized employees can be obtained from the authorization interface, depends not
only on the evaluation type but also on how the application has implemented the usage of the
authorization interface (for example, which evaluation types are supported by the implementing
application)

There are three main categories of evaluation types:

137 | P a g e
Copyright/Trademark
 With DB indexing assistance: in this case, the implementing application can make use of a pre-
calculated (this data has a time expiration limit) list of authorized objects (PERNRS) useful for
data selection and perform the single authorization checks in a further point in time upon the
display of data to the user (or as required by the implementing application). This category is also
essential for BI applications which bypass the application server (in this case only the DB indexing
is used, in case the data in it is still valid according to an expiration date). This category is also
useful when the number of authorized objects for a given user/authorization type combination is
big.
The evaluation types A and B are part of this category

Without database indexing assistance: in this case the authorization interface derives a list of
objects(PERNRS) assigned for the user for the given authorization type and perform the
authorization checks on the list providing the positive results to the implementing application by
means of an abap internal table. This category is useful when the number of authorized objects
for a given user/authorization type combination is not too big.
The evaluation type C is part of this category

Delegation of authorization check to the implementing application: for the cases of super-users
or IT-users, which normally are allowed to display a greater portion of the systems data, and
therefore also personnel-related data, it might make no sense to perform single authorization
checks on every involved object (PERNR). Such cases can be identified by the implementing
application (for example by means of the authorization object P_ABAP) which might then bypass
the single authorization check on person data. Therefore this category (delegation) serves to tell
the authorization interface, for certain special users, to ignore authorization checks on a given
authorization type and leave that to the implementing application.
The evaluation types D and E are part of this category

List of available evaluation types:

138 | P a g e
Copyright/Trademark
6.9.1.3 Time interval evaluation type
The authorization checks, especially on infotype data, depend on the time interval taken into
consideration for the check.

For a given authorization check, the following time interval evaluation types are available:

(default) From customizing(PCTR_T_AUTH_IFTY) or default(low-high date)

(1) Current EE's control record
(2) Current month
(3) User/Pernr-specific(controlled by Badi) or default(low-high)

6.9.1.4 Authorization level

The concept of authorization level serves to define how the authorization interface will behave (or will
be consumed by the caller application) for a given group of users and for a given authorization type.

For now, it is basically a combination of an Evaluation type and a time interval evaluation type.

The authorization level may vary according to the authorization type and user as per example:

Authorization type User Authorization level

IT0008 MUSTER01 L1
IT0008 MUSTER02 L3
TIME_DATA MUSTER01 L2

139 | P a g e
Copyright/Trademark
6.9.2 Configuration guide

6.9.2.1 Authorization object P_PCTR_AUT

The concepts of authorization type and authorization level explained above are directly or indirectly
assigned to users via customizing (which will be explained in further chapters). In addition, the
authorization object P_PCTR_AUT allows a fine grained control on the allowed authorization types and
level for a user. With this authorization object it is also possible to determine if the user is allowed to
consume/update authorization information for his own user or even for other users.

List of authorization fields:

1. P_PCTR_USR: Action on own user/other user

Possible values:
o Own user
o Other users

Whatever action which is being performed by the authorization interface (whether it is checking
authorizations or updating indexing information of authorizations), here it is defined if the action
can be done for the user or even for another user. In order to run administrative tools such as
the extraction tool or the display tool (which will be explained later), which affect several users
on the system, an administrator user is needed. Such administrator user will be able to control
what other users are capable on terms of this authorization framework. The authorization value
other users is required for the administrator users.

2. P_PCTR_LVL: Authorization level

the authorization level(s) for which a user may be assigned to;
the authorization level(s) that an administrator user may manage in terms of the extraction tool
for other users
3. P_PCTR_TYP: authorization type
the authorization type(s) for which a user may be assigned to;
the authorization type(s) that an administrator user may manage in terms of the extraction tool
for other users

4. P_PCTR_ACT: Authorization activity

140 | P a g e
Copyright/Trademark
 Possible values:

Consume: if a user is relevant for the authorization interface in the context of the relevant
authorization type and level
Update/delete: if a user can update his or another users data (indexing or administrative table,
see further chapters). Usually an administrative user.

6.9.2.2 Authorization levels

In maintenance view PCTR_V_AUTH_LEVL, customize which authorization levels are necessary for
applications.

Fields:

Auth level: define the two-character long ID of the authorization level

Allow o.d.: check this box if it should be allowed on-the-fly database updates (for now just
indexing) or a regeneration of the current users list of authorized objects in the database, in
case the data is not yet available or is already with the validity expired. If this box is left blank,
then the indexing of authorized objects for the given authorization level can only be done via the
extractor report HR_TR_AUTH_EXTRACTOR.
Eval Type: choose here the relevant evaluation type
Time eval: choose the time interval evaluation type
Description: define a text for the authorization type

6.9.2.3 Authorization type configuration

Define the authorization type in the maintenance view cluster VC_PCTR_AUTH_TYPE:

For example:

141 | P a g e
Copyright/Trademark
On the node Auth. Objects Set, define which objects and which values should be checked:

For example, the following authorization type requires a check for infotypes 0001, 0002 and 0008 and in
addition to payroll result cluster from USA (relid RU):

Other objects and more complex combinations are possible. Below follows a description of each field
and possible values:

sortNo: a sequence number to differentiate the rows

Check type: can contain the possible values:
o Infotype: an infotype to be checked. Requires also that fields L, Itype, and optionally
start date and end date to be filled. Normally the authorization objects
P_ORGIN/P_ORGINCON are involved (or additional objects in case the extended
authorization checks switches in table T77S0 is active)
o Cluster Rel-ID: access to payroll cluster id to be checked (see table T52relid)

142 | P a g e
Copyright/Trademark
 o Abap authorization object: for customer authorization objects or for country specific
objects. For using this, an authorization set has to be defined (see below in chapter
authorization set)
o Logical condition OR: normally if there are multiple rows in an authorization type, lets
say, one for infotype 0001, another for IT0002 and another for IT0008, it is assumed a
logical condition AND between each row (check). That is, the authorization check will
only be positive if all the single infotype checks are positive (IT0001 AND IT0002 AND
IT0008). By choosing value OR in this field, it is possible to create a brackets of AND-
connected-values with an OR condition
Field L: define the operation mode: R for Read, W for Write (depends on the authorization
object involved!)
ITYPE: the infotype to be checked in case the field Check type is set to infotype
Fields start date and end date: this time interval is optional since it also doesnt allow much
flexibility. It is only possible to be used with infotype checks. Normally these fields are left empty
and the time interval for the checks is determined automatically by the authorization interface
(or by the implementing application)
CL: this field represents the relid (cluster ID) of the payroll cluster to be checked in case the
field Check type is set to Cluster Rel-ID
Auth. Set: this field has to be set in case the field check type is set to Abap authorization
object

6.9.2.4 Authorization type- Indexing parameters

In this node of the view cluster it is possible to configure the options related to the indexing of
authorization data. The Authorization Levels that use evaluation types A and B will refer to this
configuration when accessing authorization data or during the extraction of data via report
HR_TR_AUTH_EXTRACTOR

143 | P a g e
Copyright/Trademark
Allow DB indexing: check this field if you want to allow the authorization handling of evaluation type A
and B to this specific authorization Type.

Commit size (number of users for each commit): during the extraction of authorization data via report
HR_TR_AUTH_EXTRACTOR, the data can be committed into the database depending on a package size of
a certain number of Users. The employee numbers to be indexed in the database can be really big, and
especially for Column-store databases, the insert statement generated by the extraction can take a
while. Therefore it is advisable to adjust the commit size to an adequate number according to the
system.

Package size (number of users per parallel process extraction instance): the extraction process triggers
sub-processes that work in parallel for the extraction of users data. Here it can be defined an estimation
for the number of users that will be distributed to each parallel instance.

Tolerance days: it represents the number in days in which the data of the extraction can be considered
valid by further authorization interface accesses in the following day(s). This can avoid executing the
extraction every day, in case the user data and profiles are not updated every day. If for example the
extraction report determines that employee 1 is assigned to user A and this is recorded on the database,
it can be that an organizational assignment on employee 1 to an unauthorized Personnel area for the
user A could lead to a unsuccessful authorization check. To be completely accurate with the indexing,
then the extractor report should run daily. In any case, if the structure authorization checks is active in
the customers system, then in the case of an organizational assignment change, a tolerance of usually
15 days is allowed for users who were previously authorized to that employee (this is customized in table
T77S0). In this case it is useful to set the tolerance days value to 10 in the authorization type view cluster.

144 | P a g e
Copyright/Trademark
Job class: the system priority to batch jobs generated by the extractor report. Allowed values are A, B
and C; A has the higher priority. B is a default value

Maximum processing hours: The extractor report waits for the batch sub-jobs to finish in order to
provide a consolidated log. This field controls the maximum processing time

Maximum number of job: a maximum number of sub-jobs that an extraction can generate.

Default time interval: this defines a time interval equal to: the system date minus the given number of
days. This determined interval is used for the authorization checks on infotypes for Authorization levels
using the time interval evaluation type 3. For other authorization levels, the default time interval plays
no role.

6.9.2.5 Default authorization levels

In this node it is possible to define default authorization levels per different structural authorization
profiles roles. This serves ultimately for the system to decide on an attribution of an Authorization level
for a given user/authorization type combination. A user might be linked to one or multiple profiles,
which at the end influences on the quantity of employees that the user is finally authorized for.
Therefore this node provides a flexible way for the system to guess an adequate authorization level for a
certain user.

If the customer does not make use of structural authorization profiles, then here it can be use the
default profile ALL

The exact determination of authorization levels per users can be overwritten and controlled by a badi
(explained in a further chapter).

145 | P a g e
Copyright/Trademark
6.9.3 Database indexing (extraction) guide

Program (and the transaction with the same name) HR_TR_AUTH_EXTRACTOR is used for the indexing
(or extraction) of users personnel related authorizations regarding a specific authorization type.

The program runs for a single authorization type, selecting users according to its authorization type
configuration. The selected users are registered in the transactional table PCTR_T_AUTH_ADM. The
actual results of the authorization values (personnel assigned to each user) are registered in table
PCTR_T_AUTH_INDX.

Table PCTR_T_AUTH_ADM is composed by the following fields:

Authorization type: the authorization type which was indexed

User name: the users selected by the report, according to the authorization types configuration.
Authorization level: the value of authorization level identified by the extractor report for the
given combination of user/authorization type
Set on: the date in which the entry was first created on this database table
Sync. On: the data in which this entry was last synchronized by the extraction report
Sync. Status: the status of the extraction job. If the extraction job finished successfully without
any application or runtime errors, this field will be marked with an X.

The purpose of this administrative table is mainly to have an index of the relevant data:

users for an authorization type,

146 | P a g e
Copyright/Trademark
 authorization levels clearly visible and defined in the system
to control the expiry and frequency of the authorizations results for users

6.9.3.1 Expiry and frequency of extractions

Regardless if there are Person-numbers assigned to a user or not, a record in the administrative table for
the user is created (provided that the user has a user Role configured as relevant for extraction in the
authorization type configuration). This assures that the system knows when the extraction tool was run
successful for that given user and authorization type pair. The results of the extraction, that means, the
authorization assignments have a validity period in number of days (Tolerance days field in the node
indexing parameters of authorization type maintenance view), this provides a certain tolerance interval
in which the authorization interface may consume the extracted data and avoid the necessity to run the
extraction tool on a daily basis. This concept works in accordance to the tolerance mechanism for
infotypes and structural authorization checks (by means of the constant autsw adays in table T77S0). In
other words, since the authorization checks on infotype level take anyway a certain tolerance interval
into consideration, it is not necessary to keep the indexing of the authorization types more up-to-date
then the authorization on infotypes level itself.

In case of multiple or frequent extraction, an authorization type / user combination which has already
been recently extracted and finds itself still within the tolerance period, will simply be skipped by the
extraction tool.

In order to control what the extraction tool should in any case ignore, or re-extract it is possible to use
the following screen parameters:

Force for all: with this checkbox it is possible to force the extraction of all relevant users
regardless of any tolerance period
Process last sync. before: all extractions that occurred before the given date in this parameter
will be processed

Notice: All new users, or new relevant-users will always be taken into account during extraction, since
they dont fit into any tolerance concept. Users which the extraction job was not successfully finished
(sync status field in admin. Table is not OK) are automatically selected on a next extraction run
regardless of tolerance intervals.

6.9.3.2 Further Extraction options

In the selection panel of the selection screen of the extraction report, the user shall define the
authorization type to be run. It is possible to filter out users, structural authorization profiles and user
Roles for the extraction.

On the mode panel, the user must decide between extract or delete authorizations. In case the delete
operation is selected, this will only cause the user indexing on the administrative table to be removed
(deleted). In this case the user has no more authorization to the given authorization type, even if the

147 | P a g e
Copyright/Trademark
assignment data in table PCTR_T_AUTH_INDX is not deleted. This is done so primarily for performance
reasons.

On panel options:

Checkbox delete obsolete index: with this option,, the extractor tool will trigger an additional
background job that takes care of cleaning the index table PCTR_T_AUTH_INDX for all entries whose
respective users are/were removed from table PCTR_T_AUTH_ADM (via the radio button delete
explained above).

Force start date and end date: with these fields it is possible to specify a time interval for which
authorizations can be checked for. This is not recommended for productive cases, since the time interval
can be better controlled by configuration or by a badi.

6.9.3.3 Background jobs and parallelization

It is only possible to run one instance of the extraction tool per authorization type at a time. Multiple
parallel instances on different authorization types are possible. The system will automatically (according
to the authorization type configuration) create sub-background-jobs for parallelizing the extraction of a
single authorization type. The jobs that are generated by the main extraction instance (the report itself)
are printed out in the output log on the spool after all jobs finished. The main instance waits until all sub-
jobs finished. It is advised to plan and start the extraction tool also in background mode, to avoid
timeouts due to possible long runtimes.

The naming convention of the generated background jobs follows:

In case of extraction jobs: PCTR_AUTH_E_(authorization type)_(job number).

In case of deletion jobs: PCTR_AUTH_D_(authorization type)_(job number).

6.9.3.4 Output log

The output log of the extraction tool shows information organized in different nodes:

148 | P a g e
Copyright/Trademark
The nodes are:

Use specific messages: in case of user-specific errors during executions, relevant messages
assigned to usernames will appear here.
Statistics: number of selected, processed and rejected users
General messages: general information about execution parameters and how the report was
started
Processed users: a list of successfully processed users
Auth index admin data: a representation of the admin table for the successfully processed users
Jobs list: a list of generated background jobs for the extraction.

149 | P a g e
Copyright/Trademark
 Additional nodes may be present showing the spool of each sub-job. These nodes are called: Log for
job

6.9.3.5 Transaction HR_TR_AUTH_V_ADM

With this transaction, users can explore both admin and index tables for a given authorization type. In
addition it is possible to jump to the job monitor with the job prefix already defined in order to search
for relevant extraction jobs or spool logs.

Selection screen of transaction HR_TR_AUTH_V_ADM:

150 | P a g e
Copyright/Trademark
Upon executing, the view of the admin table with relevant filters appears:

By clicking twice on a row, it jumps to the indexed data:

6.9.4 BADI
The Badi definition PCTR_AUTH_CONTROLLER in enhancement spot PCTR_AUTH_CONTROL is available
to allow the control of a few aspects of the authorizations checks and extractions.

151 | P a g e
Copyright/Trademark
The corresponding badi interface is IF_PCTR_AUTH_CONTROLLER.

The following methods exist currently in the interface:

GET_AUTH_LEVEL_FOR_USER: determines the authorization level of a certain user depending on

a given authorization type
GET_TOLERANCE_SYNC_DATE: controls the tolerance date limit for extracting authorizations
GET_TIME_INTERVAL_FOR_CHECKS: controls time interval for infotypes check
CHANGE_RELEVANT_USERS_LIST: changes the list of users to be processed during an extraction

The Badi definition PCTR_AUTH_CONTROLLER works already with an active default implementation in
class CL_PCTR_AUTH_IM_CONTROLLER

The following section explains the current default implementation of each method above and where the
method is called

GET_AUTH_LEVEL_FOR_USER:
o Logic: the authorization level is determined according to the configuration on tables
T77UA, T77PR and pctr_t_auth_org. The badi HRBAS00_GET_PROFL is also taken into
account if implemented. In case the user is assigned to different OM profiles, it can be
that the profiles are assigned to different authorization levels and evaluation types(in
pctr_t_auth_org). Then the method tries to find the profile (and therefore the
authorization level) with the highest authorizations (the one which grants more
authorizations) to the user
o Where used: in method get_user_auth_level of class cl_pctr_auth_controller, which is
the central point where the the authorizaito level is determined

GET_TOLERANCE_SYNC_DATE:
o Logic: reads the tolerance number of days from table pctr_t_auth_parm field toleranc
and deducts from the current system date to form the tolerance date. If the field in the
table mentioned is not customized, then the default 10 days is assumed. In addition, if
the extraction tool is being executed with a date in the field Process last sync. before:
then this date is considered instead.
o Where used: the date determined by this method is used during the extraction report
during the selection of users from the admin. table to determine which users need to be
updated.
o It is also used in the method handle_db_reading of the authorization controller class
just before reading the adm. Database table to determine if the indexing of data is up-to-
date according to the tolerance configuration.
GET_TIME_INTERVAL_FOR_CHECKS: controls time interval for infotypes check

152 | P a g e
Copyright/Trademark
 o Logic: reads the interval number of days from table pctr_t_auth_parm field deftichk and
deducts from the current system date to form the begin of the time interval. The end of
the time interval is the system data plus one day. If the field in the table mentioned is
not customized, then the default 30 days is assumed.
o Where used: in class CL_PCTR_AUTH_CHECKER in case the current users time interval
evaluation type is 3

CHANGE_RELEVANT_USERS_LIST: this has no default implementation, it is called at the

beginning of the execution of the extraction tool

6.9.5 Tester tool

The program (and transaction) HR_TR_AUTH_TESTER simulates an HR application making use of the
authorization API. The application simply prints out a list of employee numbers that a user is authorized
for according to a given authorization type.

In this way, it is possible for an administrator to check the configuration and authorizations of a given
authorization type with respect to a given group of users. In addition this tool serves as an example on
how the authorization API can be implemented by an HR application.

Regarding the usage of the parameters:

Panel authorization type and parameters

153 | P a g e
Copyright/Trademark
 The authorization type is a mandatory input.
The authorization level should normally be left empty since the system determines it
automatically depending on the user and authorization type. In case it is intended to force the
authorization interface to accept another authorization level, or if the concept of authorization
level is not being configured on the usual way, this selection screen parameter can be then used
(it overrides the automatically determined authorization type).
Test for user: if left blank, the tool is executed for the point o view of the current logon user, if
filled, it is executed for the point of view of the specified user.
Start date/end date: filled for forcing a certain time interval for authorization checks. Can be left
blank as default.

Panel execution mode:

Default execution: the authorization handling will be performed using the default execution
steps where mainly the authorization level of the user determines what will be the behavior on
the system depending on the current users situation
Force sync.: with this execution mode, the indexing and administrative information of the user
will be updated in the database, regardless if the data was still valid according to the tolerance
period.
Direct authorization check: in this case, the system determines a list of employees a user may be
assigned to and performs an authorization check (according to the configuration in the
authorization type) on all employees of this list. That means that the filtering out of
unauthorized employees is done on the fly without any database indexing, even if the user is
assigned to an authorization level that requires database indexing. In general this option can be
used to test the usage of the authorization interface for cases where the database indexing is not
required, or in cases that the database indexing is not wanted at all.

Panel execution parameter: these are advanced options relevant for developers testing the
authorization interface. They serve to test different execution paths which are relevant for the
implementation of an HR application making use of this API. Further details on this see the technical
implementation guide chapter.

6.9.6 Short recap of important transactions and objects

Configuration view

(1)PCTR_V_AUTH_LEVL

Configuration view cluster

(2)VC_PCTR_AUTH_ASID

154 | P a g e
Copyright/Trademark
 (3)VC_PCTR_AUTH_TYPE

BAdI

PCTR_AUTH_CONTROL

Message class

PCTRRES_MSG

Controller class (that developers will use on applications )

cl_pctr_auth_controller

Programs/transactions

HR_TR_AUTH_ADM/HR_TR_AUTH_V_ADM (to display the transactional data of extraction on

tables)
HR_TR_AUTH_EXTRACTOR/HR_TR_AUTH_EXTRACTOR
HR_TR_AUTH_TESTER/ HR_TR_AUTH_TESTER

155 | P a g e
Copyright/Trademark
7 Installation

7.1 Download the software (HR renewal 2.0)

Import the transports; check that there were no critical import errors on the transports.

7.2 Check that the following packages are installed in the abap application
sever:
PAOC_PAY_PYD
PCPYD
PCDCT
PCTRRES

7.3 Activate the business functions

HCM_LOC_CI_62 - Payroll Data Source Framework
HCM_LOC_CI_63 - authorization framework
HCM_LOC_CI_68- Payroll Control Center for the Payroll Process Manager

7.4 Set up the gateway server

To install and set up the gateway server on your system landscape (if not already done), please refer to
the following SAP Gateway guides:
http://help.sap.com/saphelp_gateway20sp05/helpdata/en/82/4ad13ee9dd4d4a88e1ef8712e33aee/co
ntent.htm

In the SAP NetWeaver Gateway system, you activate the required OData services in Customizing
for SAP NetWeaver Gateway oData Channel Administration General Settings Activate and
Maintain Services .

Application Technical Name of OData Service (Maintain in SAP NetWeaver Gateway

Application system)
Payroll Control HRPY_COCKPIT PYD_FRW_SRV
Center
PYD_CONT_SRV

156 | P a g e
Copyright/Trademark
7.5 Set up the sap ui5 service
Go to the SICF transaction and activate the payroll cockpit UI5 services:

Configure ICF (Internet Communication Framework) nodes for the Payroll Cockpit as follows:
a. In your SAP ABAP back-end system, access the Maintain Services (SICF) transaction and
choose Execute.
The Maintain Service screen appears.
b. Choose default_host SAP bc bsp SAP, select the following services:
o HRPY_COCKPIT
o HRPY_COCKPIT_XX
Activate the above services (either via right-click of the mouse and Activate Service or in
the menu under Service/Host -> Activate).
c. Choose default_host SAP bc ui5_ui5 SAP, select the following services:
o HRPY_COCKPIT
o HRPY_COCKPIT_XX
Activate the above services (either via right-click of the mouse and Activate Service or in
the menu under Service/Host -> Activate).

More information about transaction SICF can be found here:

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/46/d28dfa34bb12bee10000000a1553f7/content.
htm

7.6 Result (Optional)

The Payroll Cockpit is now installed. To check that the installation is complete, it is possible to enter a
single category of payroll check customizing on the system and check if this is represented on the
Payroll cockpits UI. This will test all the software layers (application server, gateway and UI5
configuration).
Go to transaction SM34 and enter the view cluster VC_PYD_CLASSN.
Create a new entry, for a custom Class ID like showed below on the picture (like Z_TTT):

157 | P a g e
Copyright/Trademark
Specify a name (will appear on the UI)
Specify class category = PY_COCKPIT
Specify Parameter type = ABKRS
Country grouping: 99
Save the entry
Now access the payroll cockpits URL for your server (should be in the following format:)
https://<server:port>/sap/bc/ui5_ui5/sap/hrpy_cockpit/index.html?sap-client=<client>&sap-ui-
language=EN&sap-ui-appcache=false

The UI should display the tile configure on the view cluster

158 | P a g e
Copyright/Trademark
7.7 Payroll control center Result (Optional)
1. Create payroll process : V_PYC_D_PYP
2. Copy a payroll process template : VC_PYC_PYP_PT
3. Assign payroll process template to payroll process: V_PYC_D_PYPTE
4. Assign payroll instance parameter V_PYC_D_PYPISP
5. Create payroll process step: PYC_GENERATE_STEP
6. Create payroll process instance : PYC_GENERATE_PROC_INSTANCE
7. Access the link : https://host:server/sap/bc/ui5_ui5/sap/hrpy_pcc_proc/index.html?sap-
client=000&sap-ui-language=EN&sap-ui-appcache=false
8. Then you will see the calendar view

7.8 Integrating the Payroll Cockpit Lane into the Landing Page
You can use this process/procedure to integrate the Payroll Cockpit function into the HR Renewal 2.0
landing page.

7.8.1 Prerequisites
Payroll Cockpit has been installed and implemented.
For more information about the installation and implementation of Payroll Cockpit, see xxxxx
HR renewal 2.0 has been installed and implemented.
For more information, see http://service.sap.com/instguidesnw -> SAP Business Suite
Applications -> SAP ERP Add-Ons -> HR renewal 2.0.

159 | P a g e
Copyright/Trademark
7.8.2 Process
1 Configure ICF (Internet Communication Framework) nodes for the Payroll Cockpit Lane.
d. In your SAP ABAP back-end system, access the Maintain Services (SICF) transaction and
choose Execute.
The Maintain Service screen appears.
e. Choose default_host SAP bc bsp SAP, select the HRPY_COCKPIT_L service,
and activate it (either via right-click of the mouse and Activate Service or in the menu
under Service/Host -> Activate).
f. Choose default_host SAP bc ui5_ui5 SAP, select the HRPY_COCKPIT_L
service, and activate it (either via right-click of the mouse and Activate Service or in the
menu under Service/Host Activate).
2 Create a new catalog on the Suite Page Builder (SPB) Administration Page.
a. Launch the SPB Administration Page using the following URL:
https://<server>:<port>/sap/bc/ui5_ui5/sap/arsrvc_spb_admn/main.html
b. Choose the + icon next to Catalogs.

c. Give the new catalog an ID and description, for example, ZSPB_PYADMIN: Payroll Admin.
Note: The new catalog appears under Catalogs with an indicator next to it. The indicator
shows that the catalog has not yet been linked to a PFCG role in the back end.
3 Add the Payroll Cockpit CHIP (Collaborative Human Interface Parts) to the newly created catalog.
To do so, choose the Add button of the Payroll Cockpit CHIP and in the dialog box, choose the
newly created catalog.

160 | P a g e
Copyright/Trademark
4 Link the new catalog to a role.
The newly created catalog has to be linked to an authorization role for the purpose of role
awareness in the Suite Page Builder.
To link a catalog to a role, proceed as follows:
a. Start transaction PFCG in the backend ABAP system and select the role that provides
authorizations to all of the CHIPs in the catalog.
If no role exists, create one. For more information, look for Creating Single Roles in the
documentation of SAP
NetWeaver at http://help.sap.com/saphelp_snc70/helpdata/en/52/6714b6439b11d189
6f0000e8322d00/content.htm.
b. Launch the role in PFCG. Choose Menu Insert Node Catalog Provider from the
list.
c. Enter the following information in the Create Catalog Provider dialog box:
Catalog Provider: Enter the description for the catalog.
Catalog Page: Choose the newly created catalog.

d. Allocate the role to Payroll Cockpit users

After the role is linked to the catalog containing Payroll Cockpit CHIP, you can allocate
the role to the users who are authorized to use Payroll Cockpit.
Choose User and enter the user name in the list and save the role.

7.8.3 Result
Users that are assigned the role linked to the new catalog can see the Payroll Cockpit CHIP in their HR
Renewal landing page by taking the following steps:
1. Choose Toggle Settings.
2. Select the checkbox next to Payroll Cockpit.

161 | P a g e
Copyright/Trademark
8 Implementation guides

8.1 Payroll and master data validation rules

Please refer to SAP Note 1995698 for the implementation guide regarding payroll validation rules

8.2 Payroll control center for admin guide

The issue findings are displayed according to authorization set up in your system (see the previous
authorization chapters):

162 | P a g e
Copyright/Trademark
On the payroll control center for Admin, the following data hierarchy occur:

163 | P a g e
Copyright/Trademark
The technical implementation and the check instances part of this hierarchy is here exemplified:

And a correspondence from the hierarchy to the actual data-source framework terms is presented:

164 | P a g e
Copyright/Trademark
An example of a payroll validation rule translated to technical terms:

165 | P a g e
Copyright/Trademark
 166 | P a g e
Copyright/Trademark
The usual order in which the configuration for validation rules ha to be set up:

167 | P a g e
Copyright/Trademark
8.2.1 Configuration views thru the IMG

The following pictures explain how to access the configuration views thru the IMG:

IMG: Payroll International -> Payroll Data Source Framework

168 | P a g e
Copyright/Trademark
View Cluster (tcode SM34)

1. VC_PYD_DTL

2. VC_PYD

View Cluster (tcode SM34)

1. VC_PYD_CLASSN

View Cluster (tcode SM34)

1. VC_PYD_INST

169 | P a g e
Copyright/Trademark
8.2.2 Datasource type and data-source instance for validation rules example
*Note: The content of this subchapter is explained in more details in Note 1995698

The data-source type view will indicate a runtime abap class which will contain the business logic (and
also the logic for displaying the issues root-cause) for the validation rule:

Then in the data-source instance view, the data source type is linked to an instance, where in this
instance the parameter values for execution will be specified:

170 | P a g e
Copyright/Trademark
The runtime classes liked to the Datasource type inherit pre-defined interfaces. Methods execute and
result_details_get of these interfaces are the ones responsible for the validation rules logic and
displaying the root cause. They have to be implemented according to each validation rules use case:

8.2.3 Result details Type

Result details type allows the display of different root-cause views on the right side panel of the user
interface. The following picture illustrates where the root-cause views below are customized:

171 | P a g e
Copyright/Trademark
In view VC_PYD_DTL, it is possible to specify the attributes of a result detail type. These attributes tell
where the application can locate the html-bsp components and the specific odata calls in case you which
to implement custom root-cause views

And now lets see how these components link to the validation rule:

On the Datasource type view, the result parameter type is assigned to the validation rule (the result of a
validation rule is usually a list of employees, therefore the result parameter is a PERNR type):

172 | P a g e
Copyright/Trademark
In this same view, for the PERNR parameter type, it is possible to specify the result detail types create in
view VC_PYD_DTL as follows:

8.2.4 Authorizations and Authorization type

Authorizations in HR programs are infotype oriented. A program specifies which infotypes are
considered into its logic. The Authorization checks are performed for those specified infotypes

Example:

173 | P a g e
Copyright/Trademark
Different checks -> different infotypes required

174 | P a g e
Copyright/Trademark
 175 | P a g e
Copyright/Trademark
View cluster VC_PCTR_AUTH_TYPE

176 | P a g e
Copyright/Trademark
Authorization type assignment to datasource type (check)

177 | P a g e
Copyright/Trademark
Recap of the Auth. process

Authorization checks pre-calculation (optional)

178 | P a g e
Copyright/Trademark
Authorization Levels and assignments to OM profiles

Auth. Level = how the system performs the pre-fetch of result objects according to pre-calculated
authorization information

Auth. Level = assigned to user/auth type via Org management profiles or via badi

View PCTR_V_AUTH_LEVL

179 | P a g e
Copyright/Trademark
8.3 How to implement Asynch. batch step runtime class
This chapter mainly focuses on how to implement asynchronous batch step runtime class.

8.3.1 Overview of step runtime class

IF_PYD_TY_DT : design time interface

IF_PYD_TY_RT run time interface ( main asyn batch logic is an implementation of this
interface )
IF_PYC_STT_DT : consistence check

180 | P a g e
Copyright/Trademark
8.3.2 Asyn batch step is kind of base step.

CL_PYC_STT_ASYNC_BATCH_BASE: This class is base class of the asyn batch steps. In general it
will submit two jobs in chain. One is the logic job and the other is the wrap up job.
CL_PYC_STT_ASYNC_BATCHS_BASE: This class supports submitting more than one logic job.

181 | P a g e
Copyright/Trademark
8.3.3 Invoke sequence of the asyn batch step run time class
Asyn batch step mainly focus on implementing three methods of the interface IF_PYD_TY_RT.

IF_PYD_TY_RT~RESULT_DETAILS_EXECUTE: mainly submit report (or confirm, setOK,setError)

IF_PYD_TY_RT~EXECUTE: Wrap up job will invoke this method
IF_PYD_TY_RT~RESULT_DETAILS_GET Show running status

Main activity will invoke RESULT_DETAILS_EXECUTE to submit report and use EXECUTE to refresh the job
status.

182 | P a g e
Copyright/Trademark
Show status: will invoke IF_PYD_TY_RT~RESULT_DETAILS_GET

183 | P a g e
Copyright/Trademark
8.3.4 Component of asyn batch step

1. Process program : IF_PYC_PROCESS_PROG

This component focus on organize all jobs and make sure all jobs submit in order.
A default implementation is provided: CL_PYC_BAISC_PROCESS_PROG
The implementation can be registered into the Step run time class by overwriting the
GET_EXEC_PROG method of the asyn batch run time class.
2. Job: IF_PYC_JOB
This component is in charge of submit report with background job
default implemented classes
CL_PYC_BASIC_RPT_JOB : used to submit logic job
CL_PYC_WRAP_UP_JOB : used to submit wrap up job
All jobs can inject into PROCESS_PROG by ADD_JOB method
Job decide which report should be submit
There two main components of the Job:
Printer configuration : IF_PYC_PRINTER_CFG
Param filler: IF_PYC_PROC_PARAMS_FILLER
3. Printer configuration : IF_PYC_PRINTER_CFG
Some jobs need printer information while some not. A default printer configuration which
gets the printer info from R3 configuration is provided.
The default printer configuration class is : CL_PYC_DEF_PRINTER_CFG
Any implementation of the interface IF_PYC_PRINTER_CFG and be registered into a job by
SET_PRINTER_CFG method.
184 | P a g e
Copyright/Trademark
 4. Parameter filler: IF_PYC_PROC_PARAMS_FILLER
All kinds of reports have different selection screens. The filler parameter is used to match
the requirements of the reports.
On job can have more than one parameter filler.
To make the filler easier to manage a factory class for the filler is provided
There are two implementation of the interface:
CL_PYC_PROC_FREE_FILLER :
1. Append any parameter passed by step to submit parameters.
2. Get the parameter form input parameters which start by FREE_
CL_PYC_PROC_PNP_PARMS_FILLER:
1. Support PNP (CE) report.
2. Fill leading parameter and time parameter automatically
3. If not_only_lead_params be set input parameters will be used to fill the
parameters Rule like following
a. PNP+INPUT PARAMETER NAME = PNP (CE) selection screen.

8.3.5 Detail methods invoke sequence of asyn batch step implementation

IF_PYD_TY_RT~RESULT_DETAILS_EXECUTE( main activity)
o Generally following main method will be invoked when the user executes the main
activity.

185 | P a g e
Copyright/Trademark
 o In most case CL_PYC_STT_ASYNC_BATCH_BASE is enough .But blue background one is
the most likely be overwrite by subclass
1. sts_det_reso_default_reset : reset result object .
2. sts_det_reso_other_reset : leave to subclass to implement
3. sts_det_sub_reso_default_reset: reset sub result object (use for multi jobs)
4. submit_main_act: submit main activity
5. get_prog_name: get report name (default come from input parameter)
6. get_param_filler: _kinds default is pnp only
7. get_fill_params: if have hardcoding params write here
8. get_printer_cfg : get printer configuration (default implementation class)
9. write_job_info_to_reso: write job status information into result object
10. write_other_info_to_reso: leave to subclass to implement
IF_PYD_TY_RT~EXECUTE (wrap up job will invoke the method)
o Main task of the method is to wrap up the status of the job(s)

o In most case CL_PYC_STT_ASYNC_BATCH_BASE is enough.

1. refresh_job_status : retrieve job status into result object
2. refresh_other_info : leave to subclass to implement
3. store_info_pers : if have anything need share within all step can implement the
method

Step to build step runtime class:

1. Choose a base class

a. Submit single report : CL_PYC_STT_ASYNC_BATCH_BASE
b. Submit multi report : CL_PYC_STT_ASYNC_BATCHS_BASE
2. Check the report you want to submit
a. Report name
b. Report selection screen

186 | P a g e
Copyright/Trademark
 i. Choose fillers for selection
ii. Choose printer configuration
iii. Choose parameters needed set to the report
3. Decide the data need share in steps

Samples:

All runnable samples can be found in the package: PAOC_PAY_PYD_PCC_CONT and class name :
CL_PYC_STT_*

8.4 How to implement Manual step run time class

1. Hierarchy of inherence

2. Main methods which need to be overridden:

a. al_header_cat_name_get : show log head information
b. sts_data : show detail status information
c. exe_det_operation_name_get : main activity button name
d. exe_det_info_get: execution detail information
e. sts_det_info_get: status detail information

Manual steps serves mainly for tasks which have to be completed offline or not connected to the
system, so its main purpose is to trace process status and auditing information on the screen.

8.5 How to implement Synchronous step runtime class

Besides the Asynchronous kind of step templates, there are also some step templates which do not need
long-time execution and users can get the execution results within seconds. Those step templates are
called Synchronous step, which means no background batch job will be started for those steps.

187 | P a g e
Copyright/Trademark
Instead, some other background processing methods will be used. For example, the payroll control
record related processing. The base runtime class behind this kind of step is CL_PYC_STT_CTRD_BASE.

8.5.1 Inheritance hierarchy for CL_PYC_STT_CTRD_BASE

8.5.2 Background processing

In runtime class CL_PYC_STT_CTRD_BASE, BDC (Batch Data Communication) is used for invoking
transaction PA03 to execute payroll control record related actions.

188 | P a g e
Copyright/Trademark
8.5.3 Delegation class for result detail data

The interface IF_PYD_RDT_DELEGATION is introduced to automatically delegate RDT (Result Detail Type)
execution & data retrieval. A null implementation for the interface (CL_PYD_RDT_DELEGATION_BASE) is
created. And a field DEL_CLASSNAME is available (as of FP1) to table PYD_D_RDT. The view cluster tool
VC_PYD_DTL has been enhanced for this field.

189 | P a g e
Copyright/Trademark
The interface is injected to the base class CL_PYD_TY_BASE. The implementation logic is:

When invoking IF_PYD_TY_RT~RESULT_DETAILS_EXECUTE and

IF_PYD_TY_RT~RESULT_DETAILS_GET, if the delegation class is provided by the RDT and the RDT
is used by the step template, the new interface method
IF_PYD_RDT_DELEGATION~RESULT_DETAILS_DELEGATE is always invoked.
If you want to prevent that for some RDTs for whatever reason, you have to ask for those
exceptional RDTs in your redefinitions and only delegate the call to the super class for other
RDTs.
Guidance for usage of delegation class
o New delegation implementation should inherit from CL_PYD_RDT_DELEGATION_BASE.
o If not every subclass needs the corresponding functionality (like control record info
retrieval), use of the new concept makes sense.
o If every subclass requires certain functionality, covered by an RDT (like the text retrieval
for the Step Template), it is suggested to not using the new concept but just use normal
inheritance.

190 | P a g e
Copyright/Trademark