SCHEMAS AND FUNCTIONS
In SAP Payroll, functions provide the high-level logic
for payroll calculations. Functions perform general
processing such as calculating payroll taxes
on a given set of wages, reading wagetypes from specific
infotypes, calculating benefits premiums, and storing
the results of the payroll calculation. There are dozens
of functions in SAP payroll, some are country-specific
and others are not. Each function is defined and documented
via transaction PE04; you can also view the function
documentation via transaction PDSY in releases 4.5 and
greater, or with report RPDSYS00 in earlier versions.
In SAP HR terms, a payroll function is not the same
as an ABAP function. A payroll function does consist
of ABAP code, but it is not executed in the same way
an ABAP function would be. Payroll functions are executed
within a schema by the payroll driver program (lets
A schema is just a collection of functions executed
in a specific order each one passing its results
on to the next. Schemas are always created and edited
via transaction PE01, but are actually stored as a collection
of rows in tables T52C0 (SAP standard schemas) and T52C1
(customer-created schemas and modified SAP-standard
schemas). The payroll driver reads the lines in T52C0/T52C1
and executes the functions one by one.
So how do we make the leap from a payroll function
stored in a table to the execution of ABAP code to get
the work done? In transaction PE04 you can see the ABAP
code associated with every function. The function name
in the schema correlates to an ABAP form for
example payroll function WPBP maps to the ABAP form
fuwpbp; function USTAX maps to form fuustax.
So when the payroll driver is executing the schema,
it takes the function name from the current row in schema,
puts an fu on the beginning of the name,
and then does a perform statement on it.
Its a very simple and elegant design.
In a broad sense, a wagetype
simply holds a piece of data a rate, number,
and/or amount. But more specifically, a wagetype has
dozens of attributes that control how it is manipulated
and processed. In the end though, it ends up as an object
in the payroll results database that stores a rate,
number, and/or amount.
The most typical use of a wagetype is to store the
amounts of earnings, deductions and taxes in an employees
paycheck. A persons base pay is stored in a wagetype,
the amount of their United Way deduction is stored in
a wagetype, and their taxable wages & taxes are
stored in wagetypes. Wagetypes, as the primary data
element for employee paychecks, are also mapped to FI/CO
accounts to record the debits and credits resulting
from the paycheck and reported on the W-2 and other
Wagetypes can also be used to store statistical data
such as the number of hours worked in a pay period,
the average weekly wages for the past six months, or
the amount of wages eligible for a profit sharing calculation.
Wagetype attributes are stored in several tables, but
the central table is T512W. Much more time will be spent
on various aspects of T512W.
There are three categories of wagetypes model,
technical, and user. Model wagetypes are delivered by
SAP for customers to use as guidelines for creating
their own wagetypes. They always start with a letter
and SAP may add, delete or update them in system upgrades
or HRSPs. Technical wagetypes always start with
the / symbol, and are delivered by SAP.
They are intended for very specific standard processing
in payroll, and while you can modify them, SAP may also
update them during upgrades or HRSPs. So if you
ever (I mean EVER) change a technical wagetype, check
it after each upgrade or HRSP to make sure it still
has the attributes you want. And never delete a technical
wagetype. User wagetypes always start with a number
and these are wagetypes that SAP does not change
during upgrades & HRSPs. OK, SAP rarely changes
them in upgrades and HRSPs. User wagetypes are
for all the company-specific payroll payments and deductions.
RULES AND OPERATIONS
A long-time client of ours once created a screen-saver
message that stated Payroll Rules!. Those
of us who were experienced SAP Payroll analysts or consultants
immediately saw the double meaning, and corny humor,
in that message. Rules contain the most basic logic
used in SAP Payroll. Where a schema is a collection
of functions, a rule is a collection of operations.
An operation is a very basic piece of logic that is
used, mostly, to manipulate wagetypes. For example,
operation MULTI multiplies the number and rate fields
of a wagetype to determine the amount to pay an employee.
Operation OUTWP retrieves specific data about an employee
so that another operation can make a decision on how
to process it. For example, if the work contract on
infotype 1 is UA then do x, if it is UB
then do y, otherwise do z.
Operations can also be viewed in transactions PE04
and PDSY, and are edited with transaction PE02. Where
a functions ABAP equivalent form starts with fu,
an operations ABAP form starts with op.
For example, operation MULTI would have an ABAP form
opmulti. Rules, like schemas, are stored
in a table rules are stored in T52C5.
The more senior SAP consultants who have been working
with computer systems for many years often find similarities
between payroll rules and programming mainframe computers
in Assembly language. While there is nothing fancy about
operations, when used correctly together they can be
Hopefully weve presented a good but brief overview
that makes sense. In our next SAP Payroll Technical
Basics article we will get into more detail on the common
functions used in SAPs payroll schema.