Commonly Used Operations in SAP Payroll
Previously we presented an overview
of the foundation of payroll processing and information
on the central functions in the
payroll schema. So you know the structure of payroll
processing and the major functions - now we will look
at payroll operations, where most of the real work gets
done. This subject area is very large and we are only
scratching the surface here.
Like functions, documentation for operations can be
found via transactions PDSY or PE04. Operations can
be placed in two broad groups - those that make decisions
and those that manipulate wagetypes. Some of them fit
into both groups.
Manipulating Wagetypes
Working with wagetypes in a rule is sort of like working
with internal tables in ABAP. The function that called
the rule (PIT, PRT, P0014 or whatever) loops through
the table, placing each row, one at a time, in a 'header'
space. You work with the wagetype in that header space,
and when finished add it back to the table.
MULTI, DIVID
|
These operations let you multiply two fields
of a wagetype and store it in a third. The fields
you can work with are AMT, RTE and NUM. MULTI
RNA would multiply the rate by the number and
store the result in the amount field. DIVID ANA
would divide the amount field by the number and
store it back in the amount field.
|
NUM, RTE and AMT
|
These are very basic and powerful operations
that manipulate the content of their respective
fields. The F1 help documentation is very useful
since there are so many ways to use these operations.
On a basic level, you set values like NUM=1 or
AMT=2.50 - though that it is bad practice to do
this. Use constants instead - create a constant
in T511K called ZNUM and then do NUM=KZNUM (set
number field to the constant ZNUM). Since constants
are date-effective and rules are not, this will
give you more flexibility when the number has
to change.
You can set the field of the wagetype in the
header equal to the corresponding field of another
wagetype - AMT=E9XXX sets the amount equal to
the amount field of wagetype 9XXX in the RT. AMT<
9XXX sets the amount field to 9XXX in the IT only
if it is less than what is already in the amount
field (takes the minimum of the two values).
Finally, you can use arithmetic on the values.
RTE*100 multiplies the contents of the rate field
by 100 and stores it back in the rate field. AMT*KZNUM
multiplies the amount by whatever is in constant
ZNUM.
|
ADDWT
|
So by now we've set the values of our wagetype
using MULTI, DIVID, AMT, RTE and NUM. ADDWT transfers
the wagetype in the header to some other table
- enabling us to save all that work before the
next wagetype goes to the header. The basic idea
is that you transfer the wagetype to another table,
with or without changing the wagetype number.
ADDWTE* adds the wagetype to the RT without changing
the wagetype number. ADDWTE9XXX transfers it to
the RT and renames it to 9XXX. Again, the F1 help
documentation will tell you all the tables that
you can transfer to.
|
ELIMI and RESET
|
Splits are attributes of wagetypes that link
them to some other table in payroll. Sometimes
you have to remove certain splits when doing work
in a rule - that's what ELIMI does (ELIMInate
splits). After you eliminate splits on a wagetype,
within the same rule you can restore them with
RESET. Generally you should avoid eliminating
splits - it can lead to problems in pro-ration
and reporting. So use with caution and test your
work well.
|
FILLF
|
This simple operation resets the value of a wagetype
field. For example, FILLF A resets the amount
back to what it was when the rule was first called.
|
So, here's how you would put these
all together to calculate a deduction that is fixed
percentage of base pay (there are several ways to do
this, here's just one). Let's assume base pay is in
the IT, the percentage is stored as a whole number in
constant ZNUM, and you've made a rule that has a section
for wagetype **** and for base pay, '0BAS' in this case.
The deduction will be 4XXX. So in the schema we will
do a PIT on rule Z001: PIT Z001. In the rule:
Wagetype ****: ADDWT * (if it's not
0BAS we just want to pass it on without changing it)
Wagetype 0BAS: ADDWT *, NUM=KZNUM,
MULTI ANA, AMT/-100, ADDWT 4XXX (pass 0BAS on to the
output table so we don't lose it, set the number field
equal to constant ZNUM, multiply the number by the amount,
divide the amount by -100 since we store the percentage
as a whole number and we want deductions to be negative,
and store the result as wagetype 4XXX)
Making Decisions
Many times we only want to take action
if certain conditions exist - for example we only want
to calculate deduction 4XXX for certain types of employees.
For these cases, decision operations let us choose when
to take that action.
Decisions put their results into what
is called the variable key - think of this like a case
statement with wildcards. If I put the company code
in the variable key, then the line that has 1234 will
execute for company code 1234, 2*** will execute for
any company that begins with 2, and **** will execute
for companies that match neither.
OUTWP
|
This operation lets us make decisions based on
various data elements in the WPBP table in payroll
- roughly the infotype 0 and 1 data. There are
many elements to look at, via the F1 help documentation.
As an example, you could look at the company code
via OUTWPCOMPY - this puts the contents of the
company code field into the variable key.
|
VAKEY
|
Like OUTWP this places certain data in the variable
key - see the F1 help documentation for all the
possibilities.
|
NUM, RTE and AMT
|
Here they are again, as decisions. If I say AMT?0,
it will compare the value in the amount field
to zero and return either >, <, or =. Or
you could compare it to a constant or another
wagetype using the same concepts mentioned above.
|
VWTCL
|
This operation returns the value of a certain
processing class for the current wagetype. For
example, VWTCL 93 places in the variable key the
value of processing class 93. Rule X023 is a good
example of how processing class values are used.
|
In our previous example we calculated
deduction 4XXX for every person who had base pay wagetype
0BAS. Using OUTWP you could decide to calculate it only
for people in certain personnel areas/subareas, or for
certain employee subgroups for example. Let's say that
you only want to calculate it when someone has entered
wagetype 4XXX in infotype 14 or 15. Assume here that
the wagetype is entered in the infotype with something
required in the number field. Here are the steps you
could do:
Wagetype 0BAS: ADDWT *, NUM= 4XXX,
do a decision on NUM?0 and if = then do nothing, otherwise
(the * condition) do NUM=KZNUM, MULTI ANA, AMT/-100,
ADDWT 4XXX. Depending on how your wagetype splits are
setup at this point, you might want to ELIMI R just
before NUM=4XXX and RESET R before ADDWT 4XXX.
As mentioned earlier, this is just
a scratch on the surface. When configuring payroll you
can not focus exclusively on just one piece of the puzzle
- understanding how all the pieces are related will
lead to the best configuration. There are many ways
you can combine functions, operations, processing classes,
and constants. SAP has created a powerful and flexible
configuration model for payroll. When used correctly
it gets a lot of work done well, but when done incorrectly
it leads to confusion and instability. So test and document
your configuration well!
|
|