Accepted Solutions (1)
Please go through below info posted by
Re: PCR and SCHEMAS
SCHEMAS AND FUNCTIONS
In SAP Payroll, functions provide the high-level logic for payroll calculations. Functions perform general processing u2013 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 (letu2019s assume RPCALCU0).
A schema is just a collection of functions executed in a specific order u2013 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 u2013 for example payroll function WPBP maps to the ABAP form u2018fuwpbpu2019; function USTAX maps to form u2018fuustaxu2019. So when the payroll driver is executing the schema, it takes the function name from the current row in schema, puts an u2018fuu2019 on the beginning of the name, and then does a u2018performu2019 statement on it. Itu2019s a very simple and elegant design.
SCHEMAS AND FUNCTIONS
In SAP Payroll, functions provide the high-level logic for payroll calculations. Functions perform general processing u2013 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 (letu2019s assume RPCALCU0).
A schema is just a collection of functions executed in a specific order u2013 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 u2013 for example payroll function WPBP maps to the ABAP form u2018fuwpbpu2019; function USTAX maps to form u2018fuustaxu2019. So when the payroll driver is executing the schema, it takes the function name from the current row in schema, puts an u2018fuu2019 on the beginning of the name, and then does a u2018performu2019 statement on it. Itu2019s a very simple and elegant design.
WAGETYPES
In a broad sense, a wagetype simply holds a piece of data u2013 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 employeeu2019s paycheck. A personu2019s 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 tax forms.
Wagetypes can also be used to store statistical data u2013 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 u2013 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 HRSPu2019s. Technical wagetypes always start with the u2018/u2019 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 HRSPu2019s. 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 u2013 and these are wagetypes that SAP does not change during upgrades & HRSPu2019s. OK, SAP rarely changes them in upgrades and HRSPu2019s. 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 u2018Payroll Rules!u2019. 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 u2018xu2019, if it is UB then do u2018yu2019, otherwise do u2018zu2019.
Operations can also be viewed in transactions PE04 and PDSY, and are edited with transaction PE02. Where a functionu2019s ABAP equivalent form starts with u2018fuu2019, an operationu2019s ABAP form starts with u2018opu2019. For example, operation MULTI would have an ABAP form u2018opmultiu2019. Rules, like schemas, are stored in a table u2013 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 very powerful.
Hopefully weu2019ve 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 SAPu2019s payroll schema.
Central Functions in the Payroll Schema
Previously we presented an overview of the foundation of payroll processing - 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.
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. RTE100 multiplies the contents of the rate field by 100 and stores it back in the rate field. AMTKZNUM 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!
There are lots of threads available online Below are some threads
http://www.hrexpertonline.com/downloads/08-03.doc
http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/d51ca1575e11d189270000e8322f96/content.ht
Answers (1)
| User | Count |
|---|---|
| 94 | |
| 11 | |
| 11 | |
| 6 | |
| 6 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.