You are on page 1of 40

Minimize Uncollected Taxes in SAP US Payroll

by Steve Bogner Managing Partner, Insight Consulting Partners April 15, 2008 During US Payroll processing in SAP ERP, companies sometimes find special uncollected tax wage types for employees. These wage types represent the amount of tax the system was unable to collect from the employee. Instead of the typical wage types numbered /4xx (e.g., wage type /401), in which xx is the tax type, wage types for uncollected taxes are displayed as /Nxx (e.g., /N03). Uncollected tax wage types are visible in the RT table, as shown in Figure 1. Some local tax authorities expect payroll to withhold a fixed percentage of wages. If that percentage isnt correct, it causes extra reporting efforts and burdensome tax filing tasks for the employer. Of course, employees dont like under-withheld taxes either because they receive a large tax bill when filing their returns.

Figure 1 Example of uncollected taxes in SAP Payroll RT table These impacts are incentives to minimize uncollected taxes for the benefit of both the employer and the employee. Why are uncollected taxes generated, and how can you reduce the occurrence of these cases in your system? Ill walk you through several typical scenarios and provide tips to minimize uncollected taxes in your SAP Payroll. Note Read more about tax models and tax authorities in Clay Molinaris article Detect the Effect of a Change in US Tax Models on Payroll Before You Do It.

Uncollected Tax Scenarios

Uncollected taxes arise when employees do not have enough cash income to pay for the taxes on their taxable income. This usually occurs when employees have a high amount of taxable, non-cash income in their payroll. Here are four common scenarios: Scenario 1: Say you are processing the year-end taxable value of a company car for an employee. For example, the employee has $1,000 taxable cash income, and you add $5,000 of non-cash taxable income for the taxable value of the company car. This makes the taxable income total $6,000 but the employee has only $1,000 in cash earnings. Given the tax on that amount of income and their other regular deductions (e.g., benefits, federal tax, and state tax), there might not be enough money left over to pay all the taxes, such as the company car tax. Any tax amounts that were not deducted from cash income show up as /Nxx wage types. Scenario 2: A company has an employee on a leave of absence with no pay but who continues to receive imputed income on group term life insurance. This amount is taxable, but because the employee is not being paid, there is no money to pay for the tax amounts. Therefore, the money that the employee should have paid in taxes appears as uncollected taxes. Scenario 3: Uncollected taxes can also happen when an employee retroactively moves to a tax authority with a higher tax rate. When a company retroactively moves employees from one tax authority to another, the system moves the taxes collected under the original authority to the new one. For example, if an employee lives and works in Ohio and then the company retroactively moves the employee to live and work in New York, all the tax collected for Ohio will be allocated to New York. New York has a higher tax rate so the difference goes into uncollected taxes for New York. Likewise, if a company retroactively adds a tax authority to an employee (e.g., adding a local school district tax) the system reports uncollected taxes for that authority. Scenario 4: Sometimes tax authorities retroactively increase their rates due to being late in approving legislation. The same basic logic applies for retroactive changes in tax areas and the system defaults to take only as much tax as it did in the original pay period. Therefore, if a tax rate increases retroactively by 1%, that extra 1% of tax is reflected in uncollected taxes. Not all uncollected tax wage types operate the same. For example, Social Security and Medicare taxes adjust automatically every time tax is calculated, so if those taxes are uncollected in one pay period and the employee is paid the next pay period, the system makes up for that previous uncollected amount. Other employee tax types do not adjust automatically. For example, the employee remains under-withheld for federal, state, and local withholding taxes, even if Social Security and Medicare taxes are adjusted automatically.

How to Minimize Uncollected Taxes in SAP Payroll

Ill describe two ways you can reduce the number of employees with uncollected taxes.

Tip 1. Configure SAP ERP to collect the extra tax in retrocalculations. This reduces uncollected taxes that result from retroactive changes to employees tax areas or rates. To do this, you must change a line in the payroll tax schema UTX0. Remember that you should not make changes to SAP-delivered schemas because SAP ERP always overwrites changes made to standard schemas during upgrades, whereas changes made to custom schemas (e.g., ZTX0) remain intact during upgrades. Copy tax schema UTX0 to ZTX0 if its not already a user-specific schema. In the edit schema screen, select function UTPRI and enter U in the Par1 (parameter 1) field (Figure 2).

Figure 2 Change parameter 1 of function UTPRI to allow uncapped retro tax calculations

If you are using SAPs Concurrent Employment (CE) payroll solution, then the tax schema is UTAC instead of UTX0 because several of the tax functions are different between regular payroll and CE. In this example, copy tax schema UTAC to ZTAC. Then select function UTXCE and enter U in the Par1 field. Be sure to also change your main payroll schema to refer to this new version of the tax subschema. By default, SAP payroll always uses the capped amount for retroactive taxes. Whether you use standard SAP Payroll or CE, setting parameter 1 to U alerts the SAP Payroll calculation to use the uncapped amount for retroactive taxes. During retroactive periods, SAP ERP acquires as much money as possible to satisfy the tax that was due in that period. For example, if $1,000 was in a retroactive period, it retroactively takes up to $1,000 of taxes. Without configuring the uncapped option, during retroactive periods SAP ERP can only obtain the original amount of tax that was collected and stores the remainder in uncollected taxes.

Tip 2. To reduce the number of employees with uncollected taxes, configure SAP ERP to take certain taxes even if there isnt enough cash income to pay for them. You can do this by configuring the tax priority table in the view V_T5US0. Use transaction SM30 to edit view V_T5US0 or go to the Tax Priority node in the US Payroll IMG. You must adjust the O (original period) and R (retroactive period) fields. The default value for both fields is 1. Select wage type /401 (withholding tax) and enter 2 in the O and R fields. This setting alerts SAP ERP to take the whole tax amount, either in the original or retroactive period, even if there isnt enough cash income to cover it. For example, I configured SAP ERP to always take the full amount of tax for tax level E and tax wage type /401, which is local school district tax (Figure 3).

Figure 3 Changing the tax priority table to take all taxes Note Read more about retrocalulations in Steve Bogners article Understanding and Managing Payroll Retrocalculations." You could create records specific for certain tax authorities here by creating a new row and specifying the SAP tax authority code. For example, if you always want to deduct the full tax amount for Cincinnati city income tax, create a row for tax authority OH59 by copying an existing row for tax level C and adding OH59 as the tax authority. Then set the O and R columns to a value of 1. These configuration steps, however, create more claims in payroll. If there isnt enough cash income available when you configure the system to use the uncapped amounts for retroactive taxation, then the extra amount it deducts cannot always be deducted from the current payroll, which leaves you with a claim (wage type / 561). In the second tip, when you tell the tax priority table to take the full amount of a tax even when there isnt enough

cash income to cover it, the system creates a claim to offset it. If the employee is paid in the following pay period, the claim will likely become cleared and the impact is minimal to the employee and to the company. However, if the employee is inactive, then you may never recover that claim amount. When the year-end returns are filed, many payroll departments end up paying these uncollected local tax amounts anyway, so the overall financial impact of making these modifications to reduce uncollected tax could be fairly minimal, depending on the company. For example, say the employer performs the configuration change so that a claim covers the uncollected tax, and then cant recover the $100 claim. Conversely, if the employer didnt configure SAP ERP accordingly, during tax filing the company might end up paying the $100 on the employees behalf. In this case, the employer loses $100 either way.

Correctly Clear Claims in SAPs US Payroll Part 1

by Steve Bogner Managing Partner, Insight Consulting Partners October 15, 2005 SAPexperts/HR If your company uses SAPs US Payroll, then you should be aware of the claims processing procedure. Learn how to clear claims via a basic example. Key Concept A claim is an amount of money that an employee owes the company. It is a receivable created from some sort of payroll activity. Of all the questions and issues I hear from SAP US Payroll customers, claims processing seems to be the most persistent. People often ask, What are claims? How are they created? How do we get rid of them? How do we set up our SAP Payroll system to handle them? Claims clearing can be complicated, and the process requires a substantial amount of careful configuration. If you skip one piece of the process or incorrectly configure key aspects of the wage types, then you may have a difficult and confusing time trying to clear the claims. Ill explain the basics of claims processing via a simple example. All SAP US payrolls face this issue. Tip! Set up your configuration in a sandbox environment or a test system and practice by using simple examples. Once you get comfortable with simple scenarios, start adding complexity with other situations, including pre-tax deductions and more types of earnings.

How Are Claims Created?

Lets use the example of employee X, who was overpaid $100 and then terminated. The empl oyee was gone by the time the company noticed the overpayment. SAP Payroll tracks that overpayment claim in the employees payroll results as wage type /561. The system generates the claim when the wage type representing the $100 overpayment is reduced. When the payroll recalculates that retroactive period, it generates the claim wage type. Figure 1 shows this example using the Wage Type Reporter (report H99CWTR0). Employee X was hired on January 1, 2005, paid on a semi-monthly basis with a salary of $2,100.00 The employee was paid for period 1 (In-Period 200501 and For-period 200501), and then terminated.

Figure 1 How Payroll creates a claim

The HR team discovered that the employee was hired at the wrong salary, so it reduced infotype 0008 from $2,100.00 to $2,000.00. When the Payroll system calculated the period 2 payroll, it reduced employee Xs salary by $100.00. Nothing in period 2 offset that $100.00 reduction, since the employee was terminated. The payroll calculation automatically created the claim wage type /561 to balance it out. You can look at this example using transaction PC_PAYRESULT to see where SAP stores the overpayment data. Figure 2 shows that in the retroactive period, In-Period 200502 For-Period 200501, table XDFRT contains all the taxable wage types with their values before and after the recalculation. Wage type 0SRG was $2,100.00 (the accounted amount) and is now $2,000.00 (the unaccounted amount).

Figure 2 Table XDFRT shows retroactive differences

In the current period, In-Period 200502 For-Period 200502, the payroll calculation tries to recover the overpayment. If it can, the system automatically moves the XDFRT entries to the BAL table, because the retroactive differences were balanced against the current period. If the system cannot recover the overpayment, the XDFRT entries are moved to the UNB table to reflect that the payroll is unbalanced. The BAL and UNB tables have the same layout and format structure as XDFRT. Since no money in period 2 balanced out the overpayment, payroll creates the Claim wage type /561 in the results table (RT), as shown in Figure 3. It also creates a wage type /5PY, called Good Money. This wage type represents the amount of taxable income in the current period against which retroactive taxable differences can be offset. As long as it is negative, no taxable wages can be offset. In my example, the value of -100.00 reflects that the employee was overpaid by $100.00 in taxable money.

Figure 3 Claim and Good Money in table RT Employee X did not pay back the claim, so the employees taxable wages are not reduced. Although the Payroll system reduced the year-to-date salary to $2,000.00 from $2,100.00, taxable wages remain at $2,100.00. If the claim is recovered in a subsequent period, the system will reduce employee Xs taxable wages. This could happen in the next month, quarter, or even the next tax year. Because it could happen in the next tax year, many payroll managers like to clear all the claims before year-end so that taxable wages and paid wages balance out.

How Are Claims Cleared?

Claims are the highest priority deduction in the payroll. Payroll deducts claims from the next available money paid to the employee. Lets rehire employee X on March 1, 2005, and resume paying his salary. When payroll runs for period 5, it clears the claim. Figure 4 shows wage types from the RT involved in the cleared claim.

Figure 4 A cleared claim

Wage type /101 reflects that the employee was paid $2,000.00 in period 5, which is his normal salary. Wage type /563 is the claim amount from the previous period. This comes from wage type /561 from period 2 in this case, since that was the last time he was paid. Wage type /561 does not exist in period 5, which shows that the full amount of the claim was paid off. By subtracting the amount in wage type /561 from the amount in wage type /563, you can determine by how much the claim was reduced. In this case, it was eliminated. Figure 4 also shows wage type /301, one of the wage types for taxable wages, with a value of $1,900.00. This reflects the $100.00 reduction of the $2,000.00 salary. The SAP Payroll system automatically reduces the employees taxable wages whenever it can recover the claim. Finally, wage type /5PY shows that the payroll

result could be reduced by another $1,900.00 in taxable wages if needed. It was already reduced by the $100.00 claim. Wage type /5PY is the total amount of taxable income that could be reduced in the current period. This is the simple case, but what if employee X didnt return? In that case, you can collect the overpayment via a personal check, or you can write off the claim as a bad debt. In either case, it is highly recommended to use SAPs claims clearing process for these transactions. It is part of HR/Payroll, but since it is in Payroll and involves money, the results post to FI/CO eventually. SAP R/3 provides a report (RPCLMSU0) for identifying the components of a claim. For example, you would likely ask the employee to pay back only the net amount of that $100.00 overpayment. Determining that net amount can be complicated, so SAP R/3 provides a report that does the work for you. This report is not currently available for Payroll in a concurrent employment environment. For details on how to manually identify the claims components, refer to SAP note 750057.

Configure the Claims Clearing Process

You have three areas to configure for clearing claims. First, you must configure the Off-Cycle Workbench and its follow-up activities. Eliminating the claim depends on being able to run off-cycle bonus checks. Most companies already have this set up and operational, so I wont go into those details. Then you configure the claims reports and the claims clearing wage types.

Configure the Claims Report

The second item to configure is SAP claims clearing report, RPCLMSU0, or transaction PC00_M10_CLAIMS. This report identifies the components of a claim by running a payroll simulation with a special claims schema. (A schema is a collection of functions.) The first step is to create the claims schema that this claims clearing report uses. The claims schema should be exactly the same as the normal payroll schema, with two modifications in the subschema used for taxes. SAPs standard tax subschema is UTX0, but many companies copy UTX0 and customize it. Schema customization is common for configuring SAP Payroll to suit a companys specific needs. The standard approach is to copy UTX0 and modify it rather than change SAPs standard schema. You go to the schema editor PE01, in the companys tax subschema. Just before the schema calls the UPAR1 functions, insert the UTWE function. This tells the payroll driver to perform the tax calculation on a taxed-whenearned basis, instead of the normal taxed-when-paid basis. Second, comment out (put a * character in the D column) the UTPRI function, which is a US Tax PRIority, a function in the schema. In a standard payroll

schema, the UTPRI function may change the taxes returned from SAPs third-party tax calculation service, Business Systems, Inc. (BSI). However, for clearing claims you need to know the tax amounts without such modification. You can use the standard schema UTXC as an example. One of the problems with having two schemas, one for regular payroll and one for claims processing, is that they can get out of sync if people dont remember to maintain them both. You can combine the two schemas with a little effort. The goal of this configuration is to create one main schema used by both regular payroll and the claims report. When running the schema for the claims report, you set a variable to be used as a flag for executing the UTWE function and skipping the UTPRI function. When the regular payroll schema is run, that variable is not set, causing the UTWE function to be skipped and UTPRI to be processed. First, comment out the subschema for payroll initialization, typically UIN0 or ZIN0, in your main payroll schema. Then, create another executable schema using the schema editor via transaction PE01. Add two lines to it, as shown in Figure 5. First, call the initialization subschema UIN0, and then call the main payroll schema ZUA1.

Figure 5 Create a new payroll schema for claims

For the claims schema shown in Figure 6, which you get to via PE01, copy schema ZUAT to ZUAC using the schema editors copy function. Add a variable via a custom rule to indicate that you are processing claims. Payroll rule ZUAG has one line with two operations: AMT=1.00 and ADDWT&CLMS. This creates a variable called CLMS.

Figure 6

Copy schema ZUAT to ZUAC

Since the changes needed for claims processing are in the tax subschema, you can find the variable there. If the variable is set, call the UTWE function and skip the UTPRI function, as shown in Figure 7. On lines 000100 and 000190, the IF function is called with rule ZUAH, which looks at variable CLMS and returns a FALSE if the value is zero. Rule ZUAH is shown in Figure 8. The AMT field is set to the value of variable CLMS, and then compared to zero. If it is equal to zero, the system executes line 000030, returning a FALSE value to the

IF function that called the rule. Otherwise, the TRUE condition is returned to the IF function.

Figure 7 Tax subschema with decisions for claims processing

Figure 8 Evaluate the value of variable CLMS When the system calls this tax subschema via the main ZUAT schema, rule ZUAG isnt processed. This means that variable CLMS has a value of zero when examined in rule ZUAH. Now that youve created the claims schema, you need to create a variant for the payroll driver RPCALCU0 that calls that schema. Be sure to click on the Test run check box. None of the other optional settings in the payroll

driver selection screen need to be set. Then use the feature editor PE03 to edit feature CLMPC and specify this as the variant to use for the claims report, as shown in Figure 9. Always remember to activate features after editing them by clicking on the matchstick icon or pressing F6.

Figure 9 Specify variant for claims schema

To identify which employees have claims, use the wage type reporter (report H99CWTR0 or transaction PC00_M99_CWTR) and find those employees who have wage type /561. You could also run the payroll reconciliation report (RPCPRRU0, transaction PC00_M10_REC) to select and report wage type /561 only from the last payroll result. Dont use the claims report because it performs a payroll simulation for each employee and is quite resource intensive when run for many employees at once.

Configure the Claims Clearing Wage Types

Table 1 shows the many wage types you need to create and configure that support the claims process. SAP claims processing requires a separate wage type for each tax class that is represented in the claim. The claims report output in Figure 10 has a column in the Taxable Repay Amounts for proc. class 71, which is another term for the tax class. A tax class represents a unique way of taxing a wage type in any given tax authority. You define each tax class during the implementation project. Wage types, where x = tax class (processing class 71) 9FEx for earnings, 9FPx for pre-tax deductions that were refunded in the retro, 9FDD for post-tax deductions that were refunded in the retro 9REx for earnings, 9RPx for pre-tax deductions that were refunded in the retro, 9RDD for post-tax deductions that were refunded in the retro, 9NET to record the net amount of the claim repaid by the


Forgive, or write off, the claim

Repay the claim

employee Repay the claim via periodic payroll deductions Goal-balance pre-tax deduction for each tax class to be repaid, for example 9Dx0 for the deduction, 9Dx1 for the goal, and 9Dx2 for the total

Table 1 Claims clearing wage types

Figure 10 Output of the claims report

Report RPDLGA20, or transaction PC00_M99_DLGA20, can determine which tax classes your SAP R/3 system uses. Run the report for wage types 0001 through 9___, which is the highest wage-type identifier that is possible in the system; 9___ eliminates all the model wage types delivered by SAP from the report. Whether running the report with the output in tables or the tree structure, you can navigate to processing classes and then to processing class 71 to see which tax classes the system is using. You need to create a claims clearing wage type set for each of these tax classes because claims are cleared by tax class. The easiest way to create these claims schema wage types is to copy them via transaction OH11 from your existing wage types that have the same tax classes. In my example, wage type 0SRG has a tax class of 1, so you could use it as the source for creating 9FE1 and 9RE1. The same follows for the other earnings and deductions. Note that some companies may have more or different tax classes than others. Once you copy the wage types for the claims schema, you need to check several settings to make sure they are processed correctly. When a claim is created, the payroll reduces expenses, usually represented as earnings wage types, and increases a receivable, which is mapped to the claim wage types /561 and /563. When you forgive or repay a claim, make sure the correct accounts are updated, as shown in Table 2. Wage Accounting

types 9FEx, Either the accounts that were charged by the original overpayment 9FPx, or a bad-debt account 9FDD, 9Dx0 (x = the tax class) 9REx, 9RPx, 9RDD 9NET The same accounts used for the claims wage types /561 and /563

The same account in which the employees repayment was deposited Accounting configuration for claims clearing wage types

Table 2

Some companies decide to display the claims clearing wage types on the payslip, and some dont. Your payslip may select wage types based on the evaluation class 02 values, or the wage types may be hard-coded into the form. In any case, you probably wont want them to appear in the same place as the wage types you copied from because clearing a claim is not the same as earning money and its confusing to the employee. Therefore you have to change evaluation class 02, in view V_512W_O, for example, or by changing the HR form used for your payslip via transaction PE51. Each set of wage types also has to be available to be entered on certain infotypes. Use view V_T512Z to make sure the infotypes can be entered according to Table 3. Use transaction SM30 for view maintenance. Wage types 9FEx, 9FPx, 9FDD 9REx, 9RPx, 9RDD, 9NET 9Dx0 9Dx1

Infotypes used



0014 0015

Table 3

Valid infotypes for claims clearing wage types

Finally, every wage type that is processed on infotype 0221 (Payroll adjustments) must have a value for processing class 82. This processing class determines how to handle override cost assignments, and can be maintained via view V_512W_O for the selected wage types. My next article will provide an overview of the claims clearing process and advanced claims techniques.

Understand Payroll Wage Type Processing: Payroll Schema and Rule Basics

by Steve Bogner Managing Partner, Insight Consulting Partners August 15, 2003 SAPexperts/HR Payroll schemas and rules are the bridge between HR Master Data and Payroll results. Creating that bridge is similar to writing programs and performing table configuration. Rules and schemas can be a confusing process for those who are not familiar with the concepts. Configured correctly, they can lead to a stable payroll calculation. Done incorrectly, they can produce difficult errors. In the first article of a two-part series, the author illustrates the basic principles of the payroll schema and rule process with the example of a cost of living allowance Payroll schemas and rules are the bridge between HR master data and payroll results. Creating that bridge is similar to writing programs and performing table configuration. Rules and schemas can be a confusing process for those who are not familiar with the concepts. Configured correctly, they can lead to a stable payroll calculation. Done incorrectly, they can produce difficult errors. This two-part series aims to familiarize you with the payroll schema and rule process. In this article, Ill illustrate the basics with the example of a cost of living allowance (COLA) that I want the system to automatically calculate and pay to employees. Ill present five COLA examples to show how the rules and schemas are applied. For a download of background information on basic wage type processing concepts such as the relationship between a schema and a rule and for more detail for the examples that follow, click here: download. This series wont make anyone an expert the subject is too complex and broad to master without practice and experience but it will get you started in the right direction. Functions for Processing Wage Types: The two primary tables in payroll calculation are the Input Table (IT) and the Result Table (RT). Wage types in those tables are processed with functions Process Input Table (PIT) and Process Result Table (PRT). Each loops through the table and executes a rule for every wage type. Each function also has an Output Table (OT). When the function is finished, it returns the OT back to the payroll driver. I will use the PIT function for examples. Calculating Values and Saving the Results: Each wage type has three fields you can calculate, named number, rate, and amount. Operations MULTI and DIVID can multiply and divide two fields and store the results in another field. After you multiply and divide, you save the results using the ADDWT operation. ADDWT copies the wage type in the header row to another table. You can copy it using the same or different wage type name. SUBWT does the same thing, except it multiplies the number and amount by -1 before copying.

Example 1: Calculating a COLA Wage Type

In my first example, COLA is paid at 15 percent of base pay. The base pay wage type is 0BAS and COLA is 0COL. In rule ZUA1, you process only wage type 0BAS. You execute rule ZUA1 from schema ZUA2 (a copy of standard schema UAP0), using the PIT function with parameter 2 blank, and parameter 3 as NOAB. Figure 1 shows the calculation logic for rule ZUA1. For wage type 0BAS, four operations are processed:

ADDWT *: copies the current wage type (in the header row) to the IT, keeping the same wage type identifier 0BAS. NUM=0.15: sets the value of the wage types number field equal to 0.15 MULTI ANA: multiplies the amount field by the number field and stores the result in the amount field ADDWT 0COL: copies the current wage type (0BAS) to the IT and renames it 0COL

Figure 2 shows the IT table after rule ZUA1. The wage type 0BAS is $2,000, Wage type 0COL appears with an amount of $300, and 0.15 is in the number field.

Figure 1 Calculation logic for rule ZUA1

Figure 2 IT table after calling rule ZUA1

Making Decisions in Rules

Decision Operations: Payroll rules allow you to perform conditional processing using decision operations. Think of decision operations as a type of case statement whereby you perform various operations for each value of a data element. Two of the most common decision operations are OUTWP and VAKEY. OUTWP makes decisions based on data elements from the employees infotypes 1, 7, and 8. VAKEY gives access to a variety of data elements, including the current payroll period and year, leave year, off-cycle reason and category, and some bank transfer specifications. Working with the Variable Key: Decision operations place their data values in the rules eight-character variable key. When it finds a match between a lines variable key and the decision operations data value, that line is executed. If it does not find a match, the decision operation resets the data value to the wildcard character * and takes another look to find a match. If it doesnt, the employee is rejected from payroll with an error message.

Example 2: Restricting COLA to Specific Groups of Employees

The previous example paid 15 percent COLA to every employee. Lets refine that by saying only employees in employee subgroup PS and personnel area ACAF can receive COLA. Figure 3 shows rule ZUA3, where you have a nested decision. You tell the OUTWP operation that you want to put the value of the employees personnel area (i.e., PLANT, the former term for personnel area) in the variable key. If the employee is in

personnel area ACAF, then you look at which employee subgroup they are in (OUTWP operation with the PERSB option). If they are in employee subgroup PS, then you calculate COLA. For employees who are not in personnel area ACAF, or who are in ACAF but not employee subgroup PS, you perform the ADDWT * operation. This copies wage type 0BAS from the header row to the IT. If you dont do this, that wage type is dropped from the payroll calculation.

Figure 3 Rule ZUA3 a nested decision

Working with Wage Type Values

Amount, Rate, and Number Fields: The next three operations are small but powerful AMT, RTE, and NUM. They work the same, but affect different fields of the wage type. In addition to setting a field to a literal value, they assign other values. The syntax for these operations can be a bit complicated, so its useful to refer to the system documentation. (Select the operation with your cursor and press F1 for help.) Note! Documentation for the function, operation, schema, and rule editors is available online at Click on SAP R/3 and R/3 Enterprise, select your release level and language, and go to the Human Resources>HR Tools section. A common practice is to use these operations to assign the value of another wage type to the current wage type for example, to set the amount field of the current wage type equal to the amount field of wage type x in the IT. You can also assign it to the number of days or hours in the payroll period or the number of absence hours in the period, among others. The value of constants from view v_t511k can also be assigned. There are several operators for these operations (Table 1). Operator Description

= + / * < > Table 1

Assign value to field Subtract value from field. If the amount field equals 10, AMT-8 will leave it at 2. Add value to field Divide field by value Multiply field Set field to the minimum of its current value or the operand. If the amount field is currently 10, AMT<8 sets it to 8. Set field to maximum value Commonly used operators

Making Decisions Based on a Value: The other use for these operations is making decisions. The ? operator compares the current value of the field to another value, and places =, <, or > in the variable key. For example, if the amount is 10, then AMT?8 places the > sign in the variable key.

Example 3: Bracketed Calculations and Flat-Amount Override

Lets change the COLA calculation from a flat 15 percent to one that changes with the amount of base pay 15 percent for base pay up to $1,500, 10 percent for $1,500 to $2,000, and 5 percent for more than $2,000. To handle exceptions that always occur in payroll, lets say that if someone enters the COLA wage type 0COL via master data with a fixed amount, you pay that amount instead of using the calculation logic. Since not enough room is left in the variable key, you put the new logic in another rule and execute it only for employees in personnel area ACAF and employee subgroup PS, as shown in Figure 4. Ive changed the line type to P, which tells the PIT function you are going to call a sub-rule on that line. Operation PCY calls rule ZUA5 and then returns to ZUA4.

Figure 4

Rule executed only for employees in personnel area ACAF and employee subgroup PS

Rule ZUA5 calculates the COLA amount. In Figure 5, line 10, set the amount field equal to the value of wage type 0COL in the IT, and compare that amount to zero. If someone had entered wage type 0COL in infotypes 14, 15, 267, or 2010 this period, you would have that wage type in the IT. In that case, the amount is greater than zero, so line 20 is executed (the * condition, since there is no > case in the rule). Remember that wage type 0BAS is in the header, and its that wage types amount that you just set to the value of 0COL. Operation FILLF resets the amount (A), number (N), and rate (R) fields of the header row back to their original values. After that, you copy 0BAS back to the IT.

Figure 5 Rule ZUA5 calculates COLA amount

If wage type 0COL has an amount of zero, or if it doesnt exist in the IT, line 30 is executed. You again use FILLF to restore the amount field and then compare it to the value of $1,500. If it is less than $1,500, line 70 is executed. Compare the amount field to $2,000, and if it is less than that, execute line 60. Otherwise, you know the value is $2,000 or greater, and use line 50 to calculate COLA. When payroll is run, you can see the decision logic for the new rule in the payroll log (Figure 6). In the processing section for rule ZUA4, it determined the employee was in personnel area ACAF and employee subgroup PS, so it called subrule ZUA5. It tested the value of 0COL and found it was zero. It calculated wage type 0COL based on the value in wage type 0BAS and then returned to rule ZUA4, where it ended.

Figure 6 Decision logic in payroll log

Figure 7 shows wage type 0COL entered on infotype 2010 with an amount of $150. The amount doesnt show in the processing section, but you can see the different logic that was used because there was something in the amount field.

Figure 7 Logic when amount is entered

Making It Date-Effective
Processing Classes: The COLA calculation is getting closer to a real example, but a couple of items are missing. Many calculations like this are done on a set of wage types, not just a single one like base pay. Processing classes can specify which wage types are subject to the COLA calculation. Customers can create their own processing classes, starting with class 99 and working down. The processing class value of a wage type can be read in the rule, which can subject it to certain calculations and other processing. Processing classes are a preferred way to get wage types into a rule, instead of hard-coding them as in the previous examples. I used hard-coding for the wage types to make the first examples easier to understand. If the COLA policy is eliminated some time in the future, then how do you stop calculating it? Payroll rules have no effective dates, so if you remove the logic in the rule and a retrocalculation happens, you will not calculate COLA at all. The system would determine that employees who received COLA in the past were overpaid, and it would take that money back from the current payroll. However, there are effective dates on wage types and the processing class values assigned to them. If COLA were discontinued, you would only have to make a dateeffective change to the wage types processing class.

Payroll Constants: What if COLA rates or wage brackets change? Those numbers are hard-coded in the rules. A better practice is to put those values in the payroll constants table t511k. Those constants are dateeffective, so if the rates or wage-brackets change in the future, you just update view v_t511k.

Example 4: COLA with Date Flexibility

For this example, Im moving the COLA wage brackets and rates into v_t511k constants, as shown in Figure 8. With this new calculation structure, you can change which wage types are subject to COLA, the wage brackets, and the rates by effective dates. It requires a little extra time for configuration (15 minutes for me), but it also provides flexibility and stability. Based on my experience, calculations like this change over time, so configuring the system to account for this makes sense.

Figure 8 Moving the COLA wage brackets and rates into v_t511k constants

As shown in Figure 9, you can create Processing class 90 to specify which wage types are subject to the COLA rate. Then in the wage type view v_512w_o, you assign wage types 0BAS to value 1 in processing class 90.

Figure 9

Creating Processing class 90

The payroll rules change a bit, too. In schema ZUA2 where you call the rule, you use a different syntax. Parameter 2 was empty in the previous examples; now you set it to P90, which tells PIT to send all wage types to the rule, along with their processing class 90 values. In rule ZUA6 (Figure 10) there is a new decision operation called VWTCL. It was used to put the value of processing class 90 in the variable key. If processing class 90 for the current wage type has a value of 1 and the employee is in personnel area ACAF, then you execute rule ZUA7.

Figure 10 Decision operation called VWTCL places Class 90 in the variable key

In ZUA7 (Figure 11), you make a decision on the employees employee subgroup, and if it is PS, you continue with the calculations. The logic from this point is the same as in rule ZUA5, except you use constants instead of literal values.

Figure 11 Using constants for the COLA wage brackets

Wage Type Splits

What Are Splits and Why Do I Need Them?: A wage type split is an attribute of a wage type that links it to another piece of data in payroll results. For example, if an employee changes cost centers in the middle of the pay period, R/3 splits certain wage types, linking one part to the first cost center and the other to the second. That is how you know how much to charge each cost center when running the posting to FI/CO. Other splits link a wage type to a tax authority, a benefit provider, and so on. Figure 12 shows an RT result for Test Employee. The heading for the RT shows the splits that could exist (i.e., A, AP, C1, C2, C3, etc). See the download section at the bottom of the article for more material that describes some of the frequently used splits. If a wage type has no value for a split, there is no link.

Figure 12 Sample RT result

Splits in Rule Processing: Splits cause confusion because a rule may have been set up so that it expects only one occurrence of a wage type. The split causes two occurrences, though, and custom rules need to consider that possibility. For example, the test employee transferred in the middle of period two, so two cost centers are charged. Since COLA is calculated on wage types, and there are two in this example, two COLA wage types result. The current calculation logic doesnt work because it does not consider the total base pay for the whole period. The IT has two wage types 0BAS, as shown in Figure 13. The first is calculated at a COLA rate of 0.15 and the second at 0.10 because those are the wage brackets they fall into on an individual basis. However, together for the whole period, they add up to $2,000, which falls into the 0.05 COLA rate.

Figure 13 View of two wage types

The rule also doesnt work for mid-period transfers when COLA is entered with an override amount. In period 3, there was another transfer plus a $150 COLA override was entered on infotype 2010. Figure 14 shows the incorrect result. How did this happen?

Figure 14 Incorrect result after mid-period transfer

When rule ZUA7 processes the first wage type 0BAS, it looks for wage type 0COL in the IT, with the same corresponding value for all the split indicators. So for wage type 0BAS with split AP = 01 and split A = 3, it finds wage type 0COL with split AP = 01 and split A = 3 (wage type 0COL was entered in infotype 2010 on the first day of the pay period and was assigned to the first AP split of 01). But when it processes 0BAS with split AP = 02 and split A = 3, it doesnt find a matching 0COL wage type, so it returns a value of zero. When rule ZUA7 sees a value of zero for 0COL, it processes the automatic COLA calculation.

Example 5: Calculate COLA with splits

One of the challenges with the COLA calculation is that the wages must be cumulated regardless of splits, with COLA based on the total amount. To do this, break the calculation into three rules instead of two. The first two rules, ZUA8 and ZUA9, build the COLA wage base in a new wage type 9COL. ZUA8 is a copy of ZUA6, and ZUA9 is shown in Figure 15. A new operation ELIMI eliminates the split indicators on the wage type in the header row. Copy that wage type to 9COL to build a wage base for COLA that goes across all splits in the payroll result. Now you can assign more than one wage type to the COLA wage base using processing class 90, value 1. Any wage type with the specification cumulates to 9COL.1

Figure 15 Rule ZUA9 build COLA wage base

The next rule is ZUAA. It calculates the COLA amount, as shown in Figure 16. For each wage type that cumulated to the COLA wage base (processing class 90, value 1), you look for a corresponding wage type 0COL. Wage type 0COL in this case is entered on infotype 14, and its processing class 10 has been changed to a value of 1. This allocates it across the payroll splits in the same way as wage type 0BAS. If you do not have an override wage type 0COL, eliminate all the splits and look for an amount in wage type 9COL in the IT (line 050), the wage type built in the preceding rules ZUA8 and ZUA9. Compare that amount to the constants to see which wage bracket the COLA allowance falls into. Once you find the bracket, set the splits back to their original values with RESET * and calculate COLA as in previous rules. Figure 17 shows the results, with COLA calculated for each occurrence of 0BAS. Not shown is wage type 9COL, which has a value of $2,000 and no splits.

Figure 16

Calculate COLA amount based on COLA wage base

Figure 17 COLA calculated for each occurrence of 0BAS

When and How to Develop Custom Functions and Operations

by Steve Bogner Managing Partner, Insight Consulting Partners November 15, 2003 SAPexperts/HR SAP's standard functions and operations provide functionality to solve most time and payroll calculations. But in some cases they dont, and that is when you can develop custom functions and operations for both payroll and time management. The author introduces you to the basics, including how to design, code, and use them. SAPs standard functions and operations provide functionality to solve most time and payroll calculations. But in some cases they dont, and that is when you can develop custom functions and operations. Both payroll and time management can use custom functions and operations. The process for creating them is much the same. Im going to introduce you to the basics of knowing when to create custom functions and operations, if it is a function or an operation that is needed, and how to design, code, and use them.

Build a Function or an Operation?

Custom functions and operations require a good deal of thought, analysis, and design. My rule of thumb is that 90 percent of the effort should be spent in analysis and only 10 percent on coding. Functions and operations are coded in ABAP, so you have all the flexibility of that programming language, but should you create a custom function or a custom operation? Table 1 has guidelines on how to know when to create a function versus an operation, but keep in mind there are no hard and fast rules on when to do one or the other. A function performs a specific job. For example, it reads data from custom tables, manipulates multiple wage types at the same time, calculates taxes, and processes wage types. An operation does a small unit of work, such as multiplying a single wage types number by a rate to get an amount. If the requirement is: The calculation requires several wage types. For example do you use several wage types plus other factors to calculate the value for a new wage type? The calculation is intended to introduce a custom data value into a wage type or time type. For example, you added a new field to infotype 1 or created a custom infotype and need to bring that data into time evaluation. You want to make a decision some sort of branching logic in time evaluation or payroll. Then this approach fits best: This is best implemented with a function. You could select various wage types from the result table (RT), look up some data in infotypes or custom tables to perform a calculation, and put the results into a new wage type in the RT. Use a custom operation for this. When processing the wage type or time type in a rule, you can retrieve a data value from a custom field or custom infotype and put it into the calculation (the HRS field in time evaluation or AMT/RTE/NUM in payroll). Use a custom operation to read that data value and put it into the variable key of the rule.

Table 1

When to create a function or operation

Example 1: Time Evaluation Operation for Sell-Back Hours

I ran into a recent requirement to provide the number of paid time off (PTO) sell-back hours to the time evaluation program RPTIME00. This PTO sell-back number was stored in a custom infotype 9002, and the time evaluation schema needed it for a calculation. This custom operation was called ZSLBK. The ABAP code for this is simple, as shown in Figure 1.
form opzslbk. tables: pa9002. * act-anz is the HRS field in time eval act-anz = 0. * get the field on infotype 9002 select * from pa9002 where pernr = pernr-pernr and endda >= acdate and begda <= acdate. act-anz = pa9002-z_hrsbback. endselect. endform. opzslbk

Figure 1

ABAP code for operation ZSLBK

When operation ZSLBK is called from time evaluation, RPTIME00 actually executes the ABAP form opzslbk. The ABAP code for that form sets the HRS field to zero (act-anz = 0), then reads table pa9002 for the current personnel number (the pernr-pernr field). The acdate field is the accounting date for time evaluation which is the current day being processed in the time schema. As with most functions, operations, or ABAP code in general, there are other ways to accomplish this. For example, some programmers might use the HR_READ_INFOTYPE function to read infotype 9002 instead of directly accessing table PA9002. Note! Time evaluation functions and operations are stored in RPTMOZ00. Payroll functions and operations are stored in PCBURZxx0, where xx is the country code (US, MX, DE, etc.). These are not user exits; they are includes to the time and payroll drivers. When you first modify them, you are asked to open a repair on them since they are standard SAP include files (work with your Basis team for help on repairs). However, SAP doesnt deliver any changes to these includes, so your changes will not be overwritten. Rules and functions must also be defined via transaction PE04, the function/operation editor. A number of attributes are specified here. Table 2 describes the more frequently used ones. Operation ZSLBK has a simple configuration in PE04, as shown in Figure 2.

Functions The name of the ABAP form that contains the code for functions this is fu followed by the functions name. Which countries the function is valid for. Time functions are valid for all countries. The parameter list describes what each of the four parameters is used for, and that can vary by country. The input parameters button tells the function which internal tables to print out in the log before the function is executed. For example, you could print out the input table (IT), RT, and Workplace Basic Pay (WPBP) table before the function is processed. These parameters do not have any bearing on what internal tables are available to the function. The output parameters describe which tables are printed out after the function has been executed. Operations Similar to functions, the ABAP form and valid countries are specified. The name of the ABAP form for operations is op followed by the operation name. Operations can have complex variations in how parameters are specified. The best way to approach this is to find an operation that has similar processing logic and see how its parameters have been defined. Note: More information on transaction PE04 can be found on SAPs Web site at in the HR Tools section

Table 2

Frequently used attributes in the function/operation editor

Figure 2 Attributes of operation ZSLBK A critical attribute of a rule is the parameter model in the case of operation ZSLBK, the parameter model is EA. The structure of the parameter model EA is OOOOO five letter Os. The letter O is used to tell the payroll driver that whatever takes that space is part of an operation name. Since ZLSBK is a five-character operation, model EA fits well. There are many possibilities for the parameter model, as shown in Figure 3. The letter F is a symbol for a field parameter, V is for a value parameter, and S is for the mathematical sign.

Figure 3 Parameter models for operations

Returning a Value to the Variable Key in a Rule

One of the most important uses of operations is to return a value into the rules variable key so that a decision can be made. Operation ZXPTO is an example of that. It reads a custom field from infotype 1 and returns it to the variable key, as shown in Figure 4.

form opzxpto. * find the infotype 1 valid as of the acdate loop at p0001 where endda >= acdate and begda <= acdate. vargt = p0001-zzextrapto. endloop.

* if its empty then return ** if vargt = . vargt = **. endif. * fill the variable key perform fillvargt.


Figure 4

ABAP code for operation ZXPTO

Since infotype 1 has already been read into memory by the time evaluation program RPTIME00, you dont have to read it again within this operation. You simply loop through infotype 1 (the internal table P0001) where its effective dates span the time evaluation accounting date, field acdate. If the infotype 1 field ( zzextrapto) is empty, then you return ** to the variable key (the variable key doesnt accept spaces, so the default value is **). The standard form fillvargt is used to put the varg value into the rules variable key. The attributes for a decision operation are different than what you saw in example 1. Figure 5 shows how the parameters are configured for this decision operation.

Figure 5 Defining parameter values for a decision operation in PE04 Note! A good way to determine what needs to be set for the parameter values of a decision operation is to look at a similar existing operation. Use the F1 key to get the system help text for each field to determine the possible values and combinations of values. The parameter values correspond to the selected parameter model.

Example 2: A Custom Function for Benefit Accrual

Functions are easier to define than operations, but usually involve more complex ABAP programming. A function can process all the entries in a particular payroll table, the IT or RT for example, but an operation only has to be concerned with one wage type at a time. Using a custom function for calculating a benefit accrual is a good example to show how the process works. Some companies calculate an accrual for the cost of employee benefits. This accrual is charged to the employees cost center as a debit. The credit then goes to a corporate expense for employee benefits. In this example, an accrual rate is multiplied by a wage base to get the accrual amount. Each combination of employee subgroup and personnel subarea (in this case, each labor union is in a separate personnel area) can have its own accrual rate. The number of possible rates is well over 100. For a smaller number of rates, you

could set up payroll constants in V_T511K, and use those constants in a rule to calculate the benefit accrual. But given the number of rates in this case, a payroll function makes sense. Before approaching the ABAP code or even the definition of the function in PE04, it is good to define the highlevel calculation logic. This practice helps you determine which internal payroll tables need to be accessed, as shown in Table 3. Calculation Step Find the correct accrual rate for the employees personnel subarea and employee subgroup Payroll Tables Required Internal table WPBP contains the employees personnel subarea and employee subgroup, but they could have transferred from one to another during the period. If that happens, do you prorate the accrual for each personnel subarea/employee subgroup combination? Or do you only look at the first or last assignments in the payroll period? In this example, you always use the last WPBP assignment of the period. You need a custom table to store the accrual rates. You need to know if the accrual wage base wage types will be in the IT or RT when this function is called. In this case, they will be in the IT simply as a matter of design. I ensured that the wage types involved in the calculation have processing class 20 values that keep them in the IT. Should you put this accrual wage type in the IT or RT? In this case, you will put it in the RT since there is no need to process the wage type further. This wage type also goes in the RT, but you need to attach a specific corporate benefit cost center to it so that when the accounting transfer to FI/CO is run, it will not be charged to the employees cost center. The corporate benefit cost center is stored in table C1 in payroll. You have to link the wage type in the RT to the cost center in the C1 table via a wage type split indicator. This is the same technique used in the standard system when assigning override cost centers to wage types on infotypes 14, 15, and 267.

Multiply the benefit accrual wage base by the accrual rate

Create the benefit accrual wage type that charges the employees cost center Create the benefit accrual wage type for the corporate benefit expense

Table 3

High-level calculation logic for benefit accrual calculation

Unlike operations, functions do not have parameter models. They simply have four parameters that can be passed from the schema to the function. Each parameter value is stored in the as structure as as-parm1,

as-parm2, as-parm3, and as-parm4. Figure 6 shows the definition of payroll function ZBNAC, which
calculates the benefit accrual during the payroll calculation. My example function doesnt require any input parameters.

Figure 6 Defining payroll function ZBNAC in transaction PE04 When defining a function, you can specify which internal tables are printed to the log before and after the function. For example, my function reads wage types from the IT and writes new ones to the RT, so it would make sense to print them to the log. It also creates an entry in table C1, so displaying that before and after the functions processing helps users determine what the function changed in that table. The Input parameter button specifies which tables are printed in the input section of the payroll log, and the Output parameter defines those printed in the output section. Figure 7 shows the definition of input parameters. Earlier releases of SAP R/3 may not have these two buttons on the function/operation editor. In that case, simply maintain view V_T52BW instead.

Figure 7 Defining input parameters (tables) for a function The first part of the actual ABAP development is to use transaction SE11 (Data Dictionary) to create a table to store the benefit accrual rates. In addition to the table definition, the table maintenance generator was used to create a maintenance view that can be used with transaction SM30 to maintain the rates (Figure 8).

Figure 8 The table maintenance view for ZHR_BEN_ACCRUALS The BASE_LGART is the wage type that has the wage base for the benefit accrual, while ACCRUAL_LGART holds the wage type that carries the calculated amount to accrue for benefits. You also store the company code and controlling area because they are needed to create the entry in the C1 table. Those values could have been determined dynamically in the ABAP code, but putting them in the table makes the code simpler. Now that you know which internal tables to access in payroll and you have the custom table to store the benefit accrual rates, you can write the ABAP code for the function. Using the employees personnel subarea and employee subgroup and each wage type in the IT, you search the data in ZHR_BEN_ACCRUALS (where the IT wage type equals the BASE_LGART). If you find an entry, then the found variable is set to X. Figure 9 shows the ABAP code used to calculate the accrual wage types for the ABAP function fuzbnac. As with payroll operations, this code goes into the include PCBURZUS0. (To save space, the ABAP code used to select the correct benefit accrual rate from ZHR_BEN_ ACCRUALS is not shown.) If you do find a rate, then the variable found is equal to X.

* * * * * * *

* * * * *

zhr_ben_accruals was read with the company code, employee subgroup, and personnel subarea from the last wpbp split along with the current wage type in the IT and the value of variable calc_molga if we found an entry in zhr_ben_accruals then create the accrual wage types, one for employees current cost center and one for cost center coming from zhr_ben_accruals. if found = X. it-lgart = zhr_ben_accruals-accrual_lgart. it-betrg = zhr_ben_accruals-ben_factor * it-betrg. it-betpe = zhr_ben_accruals-ben_factor. create wt without new cost center split this will debit the employees cost center for the benefit accrual amount move-corresponding it to rt. collect rt. create wage type with cost center link, this will be a credit to the cost center coming from zhr_ben_accruals next_c1znr has the next split number for the c1 table rt-c1znr = next_c1znr. rt-betrg = rt-betrg * -1. collect rt. c1-c1znr = next_c1znr. c1-bukrs = wpbp-bukrs. c1-kokrs = zhr_ben_accruals-kokrs. c1-kostl = zhr_ben_accruals-kostl. append c1. endif.

Figure 9

ABAP code to calculate benefit accrual

When payroll is run with the log turned on, you obtain the output shown in Figure 10. In the Input section, you see the tables used as inputs to the calculation the IT, WPBP, and C1 tables. The Output section shows the tables that the function changed RT and C1.