The Fundamentals of

Customizing SAP
Payroll with Schemas,
Rules, Functions, and
Operations
Mike Timm
Integrated Consulting Group
© 2008 Wellesley Information Services. All rights reserved.
In This Session …

• Develop an understanding of SAP Payroll schemas,

rules, operations, and functions
• Step through an actual payroll process to see examples
of each object
• Learn how to create and modify schemas and rules
• Leave with advice to avoid potentially costly mistakes
when developing custom schemas, rules, operations,
and functions
• Explore functions and operations, and why it may be
more efficient to develop custom operations to address
functionality gaps

1
What We’ll Cover …

• Overview of payroll and payroll objects

• Introducing and configuring schemas
• Understanding and customizing functions
• Introducing and configuring rules
• Understanding and customizing operations
• Putting them all together
• Wrap-up

2
Overview of Payroll and Payroll Objects
• First, select “Release payroll”

In this step the payroll area and payroll period to be processed
are selected

The payroll control record is set to allow payroll processing

Employee master data records are locked
• Next, select “Start payroll,” enter screen parameters, and
launch the payroll process

Payroll processes generating wage types

Assignment to company and cost center are done

Check the results by viewing the Remuneration statement
• Finally, select “Exit payroll”

The payroll control record is set to finalized, allowing for
additional processing such as posting to accounting and third-
party remittance

Employee master data records are unlocked for maintenance
3
Overview of Payroll and Payroll Objects (cont.)

• Payroll screen parameters include a schema

• The schema determines how the payroll program should
be utilized
Payroll Program Schema
(Driver) contains
Function

Function Rule
modules

Operation
Operation
modules

4
What We’ll Cover …

• Overview of payroll and payroll objects

• Introducing and configuring schemas
• Understanding and customizing functions
• Introducing and configuring rules
• Understanding and customizing operations
• Putting them all together
• Wrap-up

5
Schema Introduction and Configuration

• Schemas control the payroll processing steps

Provide the instructions for payroll

Supply the logical flow of data in, calculation performance, and
data out

Customizable and flexible to meet business requirements

However, configuring has a feel of mixing table configuration
and programming together
• The payroll program contains code that is called by the
schema

The schema utilizes the snippets of code within the payroll
program for calculations, etc.

Schemas control the use of functions

6
Schema Introduction and Configuration (cont.)

• Transaction code PE01 is used to maintain Where

to
schemas FIND it

• Copy SAP standard schemas to a customer name range

Copy standard payroll schema U000 and then only
maintain the new Z000 schema

Reduces issues when SAP provides updates to a
standard schema with support packages or upgrades

When making an update to the custom schema, make a back-up
copy first since there is no version management

Makes it easier to reverse changes or scrap all the changes
quickly if needed

7
Schema Introduction and Configuration Example

• We’ve made a copy of standard SAP schema UT00 and

called it ZML2 to handle customized time data
processing
• The payroll driver uses ZMLT (copy of U000) and calls
ZML2 instead of UT00

Customized function

Customized rules
8
Schema Introduction and Configuration Tips

• Compare schemas with menu path Schema  Compare

after displaying the schema in transaction code PE01
• Program RPDASC00 outputs a schema with differing
levels of detail set by the user

Tip

9
What We’ll Cover …

• Overview of payroll and payroll objects

• Introducing and configuring schemas
• Understanding and customizing functions
• Introducing and configuring rules
• Understanding and customizing operations
• Putting them all together
• Wrap-up

10
Overview of Function Use in Schemas

• Functions are snippets of code found in the payroll

program that are called by the schema

Function may or may not have parameters set in the schema—it
isn’t always a requirement

You can determine the available parameters by using the F1
(Help) key when you put your cursor on a function in the
schema view
• Functions may read:

Infotypes

Process rules

Process multiple tables to calculate wage types

Process payroll internal tables
• Version management is available
11
 Function Use in Schemas Example
• In our example schema ZML2, we can see the use of
standard and custom functions
• The functions request the snippet of code from the
payroll program

Standard
functions

Custom
function
12
 Function Use in Schemas Example (cont.)

• Maintaining or displaying the functions is done using

transaction code PE04

You may configure the characteristics of the function and
available parameters

Available for countries

Using F1 (help) next to RAB in the schema

Parameter 3
Parameter 4

13
Function Use in Schemas Example (cont.)

• Standard SAP function RAB pulls all absences in from

Infotype 2001 and assigns work center split indicators

When an absence appears in an inactive period (after
termination, LOA, etc.), an error is received

This may be changed with Parameter 4, but this allows all
absences in an inactive period to pass without an error
message
• Our goal is to make it so we don’t receive the error
message for specific absence types

Copy RAB to ZRAB and modify ZRAB using transaction
code PE04
Config change

14
 Function Use in Schemas Example (cont.)

• SAP standard RPCMAS09_FURAB

Calls function HR_CONVERST_2001_INTO_AB_TECH
• ZRPCMAS09_FUZRAB

The function is identical except that the custom version calls
function ZHR_CONVERST_2001_INTO_AB_TECH

And we also define a custom operation, which we’ll look at later

Code change

15
 Function Use in Schemas Example (cont.)
• ZHR_CONVERT_2001_INTO_AB_TECH

zpermitabsences contains absence types that won’t cause
errors

If the absence type is found in the custom table, then no error
and allow continued processing

If the absence is not found in the custom table, then error
(follows SAP standard)

Custom table absence

type lookup
Additional code

16
Summary of Function Use in Schemas

• We’ve been able to use an existing function to make

quick and easy modifications to handle business
requirements

Now we are able to process a specific set of absence types in
an inactive period without errors

Other methods were available, but those methods required
much more complex configuration

Later, we’ll go through an example to show how proration has
to be modified to handle these absences
• Functions are not as difficult to review and understand
as most people first think
• Use custom functions only when existing options will
not meet business requirements

Just because you can, doesn’t mean you should
17
What We’ll Cover …

• Overview of payroll and payroll objects

• Introducing and configuring schemas
• Understanding and customizing functions
• Introducing and configuring rules
• Understanding and customizing operations
• Putting them all together
• Wrap-up

18
Rule Introduction and Configuration

• Rules provide the logic flow of processing payroll

They are attached to schemas and executed during payroll
processing

Functions in the schema process a rule

Rules contain operations that perform calculations or other
decision logic
• Configuring rules is not necessarily intuitive

Configuration has a feel of mixing table configuration and
programming together

Not directly date delimited like table entries, but options are
available to work around this

Placement of the rule in the schema needs to be carefully
considered
19
Rule Introduction and Configuration (cont.)

• Highly customizable to meet business requirements

Rules may make decisions on a variety of objects such as
employee group/subgroup, personnel area/subarea, etc.

Wage types contain splits that link related data, such as WPBP
to it, and should be considered when developing rules

Wage type specific or generic

Hard-coding values should be avoided and table entries such
as constants should be used instead

Variables may be set and used for later processing to trigger
other rules to perform specific tasks

20
Rule Introduction and Configuration (cont.)

• Rules are configured in transaction code PE02

Display or maintain rules

Make decisions based on objects such as employee
group/subgroup or wage type processing class

Operations are set within the rule

21
Rule Introduction and Configuration (cont.)

• Transaction code PE02 is used to display/maintain

rule U010

Multiple operations are performing steps for the desired output

Adds wage type to

Indicates decision output table

22
Rule Introduction and Configuration Example 1

• In the ZRAB function example, we made it so a select

number of absences process through an inactive period
without causing an error
• A side effect was that the proration became skewed
because of the absence

If the payroll period is then days, the person is inactive for the
last five days and has three absences in the last three days

The standard proration returned two active days

Ten payroll days — five inactive days — three absence days

We resolved this by creating a custom operation %TACT, which

we’ll cover later

And, modifying the standard proration

23
 Rule Introduction and Configuration Example 1 (cont.)

• Z000 – US accounting schema for RPCALCU0

• Z000 calls schema ZML3 for the gross calculation

Rule /ML4 uses custom

operation %TACT to look for
action UB

If the action is UB, returns a Y,

otherwise N

When N, the proration follows

standard SAP proration logic

When Y, the proration is

changed to allow for the ZRAB
function allowing absences
during an inactive period

24
Rule Introduction and Configuration Example 2

• In this example, let’s assume that we are using Infotype

2010 to process time from an external system
• If we were to use standard premium code functionality,
multiple premium codes would have to be created for
each type of time (standard, overtime, double time, etc.)
to generate the appropriate premium rate
• Instead, we will use standard configuration tables and
three custom payroll rules to allow only one premium
code to be entered and generate the appropriate
premium rate

25
Rule Introduction and Configuration Example 2 (cont.)

• Configuration requires table updates

The creation of time wage types, such as regular, overtime, and
doubletime

Premium wage types and values

Premium codes
• Configuration also requires schema and rules
development

Modification of schema UT00 by exchanging a rule and adding
a new rule

Modification of rule X930

Creation of rule ZMUL

26
Rule Introduction and Configuration Example 2 (cont.)

• Regular, overtime, and doubletime wage types are

created

The wage types are available in Infotype 2010
• Shift and lead premium wage types are created

Wage types are behind the scenes and not available in any
Infotypes

27
Rule Introduction and Configuration Example 2 (cont.)

• Premium codes are created in table T510P

• Amounts are not assigned to the premiums
• Use of the Premium ID could be used to reduce the
number of premiums even further
• Premium No. could be LD with three Premium IDs—one
for each of the shifts

28
Rule Introduction and Configuration Example 2 (cont.)

• Wage types are added and assigned a value in table

T510J
• Payroll rules will use the premium code entered in
Infotype 2010 to generate a premium wage type
• The premium wage type then receives the value from
this table
• Using the PMod (payroll modifier set in rule UMOD)
grouping, different values may be generated for the
same wage type

29
Rule Introduction and Configuration Example 2 (cont.)

• Schema ZUT0 is a copy of delivered UT00

Two modifications, the first being Z930

Z930 replaces
X930

30
Rule Introduction and Configuration Example 2 (cont.)

• Rule Z930 replaces standard rule X930 in the schema

• The rule makes a decision on the payroll area

If the payroll area is not 03, standard rule X930 is called

If the payroll area is 03, rule ZPRE is called to start the premium
code dynamic valuation

31
Rule Introduction and Configuration Example 2 (cont.)

• Rule ZPRE performs a couple decisions to verify

required data fields are populated

If the amount is not zero, continue directly to the premium rule

If the amount is zero, do hours exist in Infotype 2010 Number of
hours field?

If the amount is zero and the Number of hours field is zero, then
use the hours from the Number field

32
Rule Introduction and Configuration Example 2 (cont.)

• Rule ZPR1 is where the premium code attached to the

time wage type in Infotype 2010 is used to generate a
premium wage type and to add Split C3

The SETIN 3 variable will be used in the new rule ZMUL added
to schema ZUT0
• The rate and amount are zeroed since these will be
calculated as part of the premium process
• The number field is brought from the time wage type to
the generated premium wage type

33
Rule Introduction and Configuration Example 2 (cont.)

• In the case of the premium L3, the Lead wage type is

generated in addition to the Shift wage type

The Lead wage type does not have the C3 Split set since the
rate does not change based on the type of time

Lead wage type Shift 3 wage type

34
Rule Introduction and Configuration Example 2 (cont.)

• Schema ZUT0 is a copy of delivered UT00

Two modifications, the second being ZMUL

ZMUL is added
after valuations
are performed
35
Rule Introduction and Configuration Example 2 (cont.)

• Rule ZMUL uses the C3 Split added in ZPR1 to determine

which percentage the premium wage type needs to be
processed with

36
Example: Processing During Payroll

• Let’s step through example 2 – processing in payroll

• We will use a single premium code, L3, and dynamically
generate the premium wage types and rates
• End users follow the same process as they would
whether this was implemented or not

37
Example: Processing During Payroll (cont.)

• Time wage types are loaded in Infotype 2010

• Premium code L3 is assigned to each entry

Lead premium of $1.50 per hour

Shift 3 premium of $3.00 with time-type reference

38
Example: Processing During Payroll (cont.)

• Process payroll with the log checked

• Expand the P2010

node to see the detail

39
Example: Processing During Payroll (cont.)

• The Input table contains the three entries from

Infotype 2010
• The wage type, hours, and premium no. are all
pulled in and will process through the rule Z930

40
Example: Processing During Payroll (cont.)

• Each wage type processes through Z930 individually and

generates wage types 0413 and 0412
• Wage type 0412 is generated with the C3 Split set when
wage types 0401 and 0402 process

Wage type 0401 sets Split C3 to 15 and 0402 sets Split C3 to 20

41
Example: Processing During Payroll (cont.)

• The input processes through rules Z930, ZPRE, and

ZPR1 and produces the 0412 and 0413 wage type output

Note the C3 value of 15 and 20 for two of the 0412 wage types

Split C3 values
set by rule ZPR1

42
Example: Processing During Payroll (cont.)

• Move further down in the

payroll log

Where
to
FIND it

• Expand the PIT ZMUL tree

43
Example: Processing During Payroll (cont.)

• The Input table shows each of the 041x wage types with
a rate from table T510J
• Two wage types still contain the C3 Split set by rule
ZPR1

44
Example: Processing During Payroll (cont.)

• The wage types without a C3 Split are added to the

Output table without further processing
• The two wage types with a C3 Split process through
ZMUL

45
Example: Processing During Payroll (cont.)

• The two 0412 wage types have had the rate and amount
recalculated

C3 15 changed from $3.00 to $4.50

C3 20 changed from $3.00 to $6.00

46
Example: Processing During Payroll (cont.)

• The output remuneration statement shows the correct

hours, rate, and amount for each of the time and
premium wage types

Regular
Overtime
Doubletime
Combined
47
What We’ll Cover …

• Overview of payroll and payroll objects

• Introducing and configuring schemas
• Understanding and customizing functions
• Introducing and configuring rules
• Understanding and customizing operations
• Putting them all together
• Wrap-up

48
Operation Use in Rules

• Just like functions, operations are snippets of code

found in the payroll program that are called by a rule
• Operations perform calculations or other data
manipulation steps

Manipulate one wage type at a time and store the wage type in
an output table

May perform decisions within the rule to determine a path to
follow—personnel area, employee subgroup

Up to six operations may be entered on one line of a rule and
you have the option of sequential rows allowing for more
operations when needed

Operations allow for parameters to determine how the
operation should behave
• Version management is available
49
Tips for Creating a Custom Operation
• Use standard SAP routines when possible
• Follow SAP standards when creating new operations
• Do not hardcode values in operations; look up the
values in tables allowing for easier maintenance and
date effectivity
• Variables seem to get overlooked and need to be cleared
so they are not carried along
• Make sure to include error handling that provides useful
feedback
• Do not sort internal tables used in the main payroll driver
since the main program might be expecting the internal
table to be in a specific order. If needed, copy data to a
new internal table for use in custom operations or
functions.
Tips 50
 Maintaining and Displaying Operations

• Maintaining or displaying the operations is done using

transaction code PE04

You may configure the characteristics of the operation and
available parameters

Available for countries

Using F1 (help) next to PPAR in the rule

Parameters

51
Example: Operation Use in Rules

• Following our example of allowing specific absences to

process through payroll without error, we had to create
operation %TACT
• Operation %TACT allows for proper proration when the
absences are in the inactive period

If we had not modified proration, the absence in the inactive
period would cause a reduction in hours paid during the
active period

The operation returns a Y or an N depending on whether the
Infotype 0000 action is the same as the parameter set

The work week contains 40 hours and runs Monday through
Friday

The allow absence occurs on Friday and the LOA action occurs
on Wednesday
52
Example: Operation Use in Rules (cont.)

• Standard proration will end up paying eight hours of

attendance for Monday and Tuesday combined and
eight hours of absence for Friday, a total of 16 hours
for the week
• Our goal is to pay eight hours of attendance for both
Monday and Tuesday and eight hours of absence for
Friday, a total of 24 hours for the week

TSAU = unpaid absence

TSAP = paid absence
TSAX = paid holiday 53
Example: Operation Use in Rules (cont.)

• %TACT is used only in the United States

• The parameter input is two characters with an output of
one character

54
What We’ll Cover …

• Overview of payroll and payroll objects

• Introducing and configuring schemas
• Understanding and customizing functions
• Introducing and configuring rules
• Understanding and customizing operations
• Putting them all together
• Wrap-up

55
Putting Them All Together

• The example we will be stepping through is based on the

schema, function, rule, and operation examples we
discussed previously
• We’ll start by looking at the entries in the employee
master data and then follow them through the payroll log
• Points where the custom logic differs from the standard
SAP logic will be identified
• Payroll periods are a week with five eight-hour days
• The employee was originally paid for 32 hours of
attendance and eight hours for absences

56
Putting Them All Together (cont.)

• Infotype 0008 — Basic Pay

Employee is paid 1,711.9106 per 40-hour work week

• Infotype 2001 — Absences

Absence entry is made prior to LOA action

Absence 0200 is located in zpermitabsences

57
Putting Them All Together (cont.)

• Proration in the original period was eight hours of

absence and 32 hours of attendance at an hourly rate of
42.7978 (salary divided by 40)

Eight hours of absence = 342.38

32 hours of attendance = 1,369.53
• Infotype 0000 — Actions

An LOA action is created retroactively into the period

This effective date of the action causes the previously entered
absence to be in an inactive period

58
Putting Them All Together (cont.)

• Under standard SAP, the absence in the inactive period

will cause an error

59
Putting Them All Together (cont.)

• However, custom function ZRAB allows processing,

since the absence type 0200 is found in the custom table
zpermitabsences

60
Putting Them All Together (cont.)

• The payroll period runs from 09/09/2007 to 09/15/2007

09/09 and 09/15 are days off

Thus, with an LOA effective date of 09/12, the employee has:

Two active days (09/10 and 09/11)

Three inactive days (09/12, 09/13, 09/14)

Company policy is that the eight paid absence hours are not
recouped
• During the retro calculation for the period:

The employee should be paid for the two days of attendance

And, the employee should still be paid for the day of absence
after the LOA began

61
Putting Them All Together (cont.)

• However, with standard proration, the employee is paid

only for one day of attendance and one day of absence

The absence reduced the two attendance days by one

The first /801 is the active period

40,000 is equivalent to 40% of the period or two days

The second /801 is the inactive period

20,000− is equivalent to −20% of the period, or one day

Two entries exist for the salary found in Infotype 0008

Each salary entry will be multiplied by each /801

62
Putting Them All Together (cont.)

• The first 1,711.91 is multiplied by 40% to generate salary

of 684.76
• The second 1,711.91 is multiplied by 20% to generate
salary of -342.38
• Salary nets to 342.38

• Remember, the company policy is that the employee

receives the two days of salary plus the absence that
falls in the LOA period

The employee is missing half the salary amount he/she is owed

63
Putting Them All Together (cont.)

• The custom proration rule and operation we created

earlier allow for the correct proration

• Two /801 wage types flowed into the custom rule /MLP

However, only the /801 from the active period came out
with a value

In the active period /801, as with standard SAP proration, 40,000
is equivalent to 40% of the period, or two days
64
Putting Them All Together (cont.)

• The second /801 was reduced to 0% and was dropped,

since absences are not included in the proration

In the standard SAP proration, absences are considered and
caused the −20%
• Two entries exist for the salary found in Infotype 0008

Each salary entry will be multiplied by /801

65
Putting Them All Together (cont.)

• The first 1,711.91 is multiplied by 40% to generate salary

of 684.76
• The second 1,711.91 does not have a corresponding /801
and is removed

• The result is the employee does not have absences

during the inactive period recovered from them
according to company policy

66
What We’ll Cover …

• Overview of payroll and payroll objects

• Introducing and configuring schemas
• Understanding and customizing functions
• Introducing and configuring rules
• Understanding and customizing operations
• Putting them all together
• Wrap-up

67
Resources

• Schema, function, rule, and operation help at

http://help.sap.com

SAP ERP > ERP Central Components > SAP ERP Central
Component > Human Resources > HR Tools
• Program RPDSYS00 or transaction code PDSY
for HR documentation about specific objects

68
7 Key Points to Take Home

• Schemas control the logical flow of data during payroll

processing
• Do not change SAP-delivered schemas, rules, functions,
or operations—make a customer copy and then modify
• Make a back-up copy of schemas and rules prior to
making changes since there is no version management
• Schemas and rules are not date delimited like table
entries
• Functions and operations call snippets of code from the
payroll program

69
7 Key Points to Take Home (cont.)

• Custom functions or operations should be created when

standard functionality does not exist or configuration
would be more time consuming
• Functions and operations have version management

70
Your Turn!

How to contact me:

Mike Timm
[email protected]
(866) 415-0072 71