Insight Consulting Partners - Sensible Solutions to Your Unique Problems






grey.gif



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!