The basic structure of schemas, rules, function and
operations. Now let�s take a look at the major functions in the payroll
schema.Functions can have up to four parameters, and usually the SAP
documentation does a good job telling you what each parameter does.
Documentation for functions and operations can be found via transactions
PDSY or PE04.
COPY
This is the same as �include� in
ABAP and other programming languages. COPY just inserts the
schema contained in parameter 1 when payroll is executed. Good
programming style and good schema configuration style are
basically the same - put commonly used logic in an �include� so
that it can be used in several places and to improve
readability.
BLOCK
As of release 4.0 the schema log
is organized in a collapsible tree structure. BLOCK BEG starts a
node and BLOCK END ends the node. Everything between BEG and END
is contained within the node. BLOCK BEG/END can be nested
several levels deep. Again, place the BLOCK BEG/END functions
appropriately to make the log easy to read.
IF/ELSE/ENDIF
There are two ways to specify the
true/false condition for an IF function. SAP has several
built-in conditions that you can use in parameter 2 (IF NAMC in
schema U000). You can also specify a custom rule in parameter 1,
and in the rule perform whatever logic you want. In the rule you
use operation SCOND to set the true/false switch for the IF
function.
Pxxxx
The payroll driver & schema read
and process data from many infotypes. The common way of doing
this is with infotype-specific functions - named as �P� and the
four-digit infotype number. So, P0014 reads and processes data
from infotype 14, P0168 processes life insurance plans from
infotype 168 and P2010 reads in additional payments from
infotype 2010. Many of these functions, but not all, allow you
to futher refine the processing with a payroll rule. Schema
UAP0, for example, shows that P0014 is processed futher by rule
U011. Function P0168 is one of those that does not use a rule
(in some older releases it does) - you specify options in
parameter 1 instead (see schema UBE1).Some infotypes are used in
payroll, but do not have a Pxxx function. Examples include
infotypes 207, 208, 209 and 210 which are all read and processed
in the main tax function USTAX. Infotypes 0, 1, 7, and 8 are
processed by function WPBP.
PIT
PIT is an acronym for Process
Input Table, and is one of the most used and most powerful
functions in payroll. When wagetypes are read into payroll by
the Pxxx functions, they are stored in an internal table called
IT - Input Table. PIT loops through that table and applies logic
contained in rules. So for each wagetype in the IT, it will
apply the logic from a rule.The goal of PIT is to move wagetypes
out of the IT and into the RT - Results Table. Most often, the
rules called by PIT will change some attributes of the wagetype
and then transfer it from the IT to the RT. The wagetype can
also be left in the IT and even moved to other tables. We�ll
cover those possibilities when we reiew how operations work. A
good example of PIT is in schema UAL0 - PIT X023. When the
payroll driver gets to this point in the schema, PIT will look
at each wagetype in the IT, and rule X023 tells it to do certain
things depending on the wagetype�s value in processing class 20.
Values 3, 4, 5, 6, 9 and B will move the wagetype to the RT,
while values 1, 7, and 8 leave it in the IT. Value 2 has no
operation, essentially eliminating the wagetype from the IT.
PRT
PRT is short for Process Results
Table. Although most wagetype processing happens via PIT, there
are several occasions where you want to process the wagetypes
that have already been transferred to the Results Table (RT).
PRT work much the same as PIT, looping through the RT and
applying logic from a rule.In schema UTX0, PRT is used to
process tax wagetypes that are already in the RT. Function UTX0
(US tax function) returns its wagetypes directly to the RT, so
any processing on tax wagetypes has to be done with a PRT
function.
ACTIO
The ACTIO function processes a
payroll rule, but it does not loop through a wagetype table.
Instead it can loop over the different workplace/basic pay
records and process the rule for each one. For example, suppose
the employee had two infotype 1 records for the current pay
period. ACTIO would have two records to loop through.Schema UTX0
again has a good example of ACTIO using rule UWH1 to calculate
the number of working hours in the pay period.
