HR2008 2emea

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
2
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
3
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
4
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
5
• Wrap-up
6
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
7
Schema Introduction and Configuration (cont.)
• Transaction code PE01 is used to maintain schemas
• 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
f Makes it easier to reverse changes or scrap all the changes
quickly if needed
8
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
9
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
10
• Wrap-up
11
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

12
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 13
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
14
• 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
15
• SAP standard RPCMAS09_FURAB
Calls function HR_CONVERT_2001_INTO_AB_TECH
• ZRPCMAS09_FUZRAB
The function is identical except that the custom version calls
function ZHR_CONVERT_2001_INTO_AB_TECH
And we also define a custom operation, which we’ll look at later
Code change
16
• 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
17
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
18
• Wrap-up
19
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
20
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
21
• 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
22
• 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
23
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 ten days, the person is inactive for the
last five days and has three absences in the last three days
f The standard proration returned two active days
f 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
24
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
25
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
26
• 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
27
• 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
28
• 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
29
• 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
30
• Schema ZUT0 is a copy of delivered UT00
Two modifications, the first being Z930
Z930 replaces
X930
31
• 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
32
• 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
33
• 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
34
• 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

35
• Schema ZUT0 is a copy of delivered UT00
Two modifications, the second being ZMUL
ZMUL is added
after valuations
are performed
36
• Rule ZMUL uses the C3 Split added in ZPR1 to determine which
percentage the premium wage type needs to be processed with
37
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
38
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
39
• Process payroll with the log checked
• Expand the P2010

node to see the detail
40
• The Input table contains the three entries from Infotype 2010
• The wage type, hours, and premium number are all pulled in and
will process through the rule Z930
41
• 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
42
• 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
43
• Move further down in the
payroll log
• Expand the PIT ZMUL tree
44
• 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
45
• 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
46
• 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
47
• The output remuneration statement shows the correct hours, rate,
and amount for each of the time and premium wage types
Regular
Overtime
Doubletime
Combined
48
• Wrap-up
49
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
50
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.
51
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
52
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
53
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
54
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
55
• Wrap-up
56
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
57
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
58
• 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
59
• Under standard SAP, the absence in the inactive period will cause
an error
60
• However, custom function ZRAB allows processing, since the
absence type 0200 is found in the custom table zpermitabsences
61
• 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:
f Two active days (09/10 and 09/11)
f 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
62
• 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

f 40,000 is equivalent to 40% of the period or two days
The second /801 is the inactive period

f 20,000− is equivalent to −20% of the period, or one day
Two entries exist for the salary found in Infotype 0008

f Each salary entry will be multiplied by each /801
63
• 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
64
• 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
65
• 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
66
• 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
67
• Wrap-up
68
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
69
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
70
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
71
Your Turn!
How to contact me:

Mike Timm
mtimm@integratedcg.com
(215) 667-8429
72
Disclaimer
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver®, Duet™, PartnerEdge, and other SAP products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All
other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor
controlled by SAP.
73

HR2008 2emea

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

HR2008 2emea

Cargado por

Copyright:

Formatos disponibles

The Fundamentals of

Customizing SAP Payroll

Payroll Program Schema

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

 However, configuring has a feel of mixing table configuration

 Process multiple tables to calculate wage types

 Process payroll internal tables

• Version management is available

Available for countries

Custom table absence

 Rules contain operations that perform calculations or other

 Hard-coding values should be avoided, and table entries such

 Make decisions based on objects such as employee

Adds wage type to

f Ten payroll days — five inactive days — three absence days

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

Rule /ML4 uses custom

If the action is UB, returns a Y,

When N, the proration follows

When Y, the proration is

• Configuration also requires schema and rules development

 Creation of rule ZMUL

• Shift and lead premium wage types are created

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

Lead wage type Shift 3 wage type

 Shift 3 premium of $3.00 with time-type reference

• Expand the P2010

• Expand the PIT ZMUL tree

 C3 20 changed from $3.00 to $6.00

Available for countries

TSAU = unpaid absence

• Infotype 2001 — Absences

 Absence 0200 is located in zpermitabsences

 32 hours of attendance = 1,369.53

• Infotype 0000 — Actions

 This effective date of the action causes the previously entered

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

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

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

 The first /801 is the active period

 The second /801 is the inactive period

 Two entries exist for the salary found in Infotype 0008

• Remember, the company policy is that the employee receives the

How to contact me:

También podría gustarte

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

However, configuring has a feel of mixing table configuration

Process multiple tables to calculate wage types

Process payroll internal tables

Rules contain operations that perform calculations or other

Hard-coding values should be avoided, and table entries such

Make decisions based on objects such as employee

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

Creation of rule ZMUL

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

Shift 3 premium of $3.00 with time-type reference

C3 20 changed from $3.00 to $6.00

Absence 0200 is located in zpermitabsences

32 hours of attendance = 1,369.53

This effective date of the action causes the previously entered

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

The first /801 is the active period

The second /801 is the inactive period

Two entries exist for the salary found in Infotype 0008