Minimize Uncollected Taxes in SAP US Payroll

7/23/2019 Minimize Uncollected Taxes in SAP US Payroll

1/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
http://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-Ithttp://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-Ithttp://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-Ithttp://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-Ithttp://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-Ithttp://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-Ithttp://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-Ithttp://sapexperts.wispubs.com/Articles/2007/August/Detect-the-Effect-of-a-Change-in-US-Tax-Models-on-Payroll-Before-You-Do-It


2/40

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. Forexample, 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 paidin 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 taxtypes 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.


3/40

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 ZTX0if 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.


4/40

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 of1.

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
http://sapexperts.wispubs.com/Articles/2003/June/Understanding-and-Managing-Payroll-Retrocalculationshttp://sapexperts.wispubs.com/Articles/2003/June/Understanding-and-Managing-Payroll-Retrocalculationshttp://sapexperts.wispubs.com/Articles/2003/June/Understanding-and-Managing-Payroll-Retrocalculationshttp://sapexperts.wispubs.com/Articles/2003/June/Understanding-and-Managing-Payroll-Retrocalculationshttp://sapexperts.wispubs.com/Articles/2003/June/Understanding-and-Managing-Payroll-Retrocalculationshttp://sapexperts.wispubs.com/Articles/2003/June/Understanding-and-Managing-Payroll-Retrocalculations


5/40

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 taxamounts 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.


6/40

Correctly Clear Claims in SAPs US Payroll Part 1

by Steve Bogner


October 15, 2005

SAPexperts/HRIf 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-taxdeductions and more types of earnings.

How Are Claims Created?

Lets use the example of employee X, who was overpaid $100 and then terminated. The employee 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.


7/40

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.


8/40

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


9/40

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 viaa 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 editorPE01, 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-when-

earned 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


10/40

schema, the UTPRIfunction 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 thatthey 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 orZIN0, 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


11/40

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 ZUAGisnt 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 driverRPCALCU0 that

calls that schema. Be sure to click on the Test run check box. None of the other optional settings in the payroll


12/40

driver selection screen need to be set. Then use the feature editorPE03 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 forproc. 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.

ActionWage types, where x = tax class (processing

class 71)

Forgive, or write off, the

claim

9FEx for earnings, 9FPx for pre-tax deductions that

were refunded in the retro, 9FDD for post-taxdeductions that were refunded in the retro

Repay the claim 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


13/40

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 of1, 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.

WageAccounting


14/40

types

9FEx,

9FPx,

9FDD,

9Dx0 (x

= the tax

class)

Either the accounts that were charged by the original overpayment

or a bad-debt account

9REx,

9RPx,

9RDD

The same accounts used for the claims wage types /561 and/563

9NET The same account in which the employees repayment was

deposited

Table 2 Accounting configuration for claims clearing wage types

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

typesInfotypes used

9FEx,

9FPx,

9FDD

0267

9REx,

9RPx,9RDD,

9NET

0221

9Dx0 0014

9Dx1 0015


15/40

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.


16/40

Understand Payroll Wage Type Processing: Payroll Schema andRule Basics

by Steve Bogner


August 15, 2003

SAPexperts/HRPayroll schemas and rules are the bridge between HR Master Data and Payroll results. Creating thatbridge is similar to writing programs and performing table configuration. Rules and schemas can be aconfusing process for those who are not familiar with the concepts. Configured correctly, they can leadto a stable payroll calculation. Done incorrectly, they can produce difficult errors. In the first article of atwo-part series, the author illustrates the basic principles of the payroll schema and rule process withthe 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 payrollcalculation. 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.
http://sapexperts.wispubs.com/HR/Articles/~/media/SAP%20Experts/Downloads/2003/August/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download.dochttp://sapexperts.wispubs.com/HR/Articles/~/media/SAP%20Experts/Downloads/2003/August/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download.dochttp://sapexperts.wispubs.com/HR/Articles/~/media/SAP%20Experts/Downloads/2003/August/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download.dochttp://sapexperts.wispubs.com/HR/Articles/~/media/SAP%20Experts/Downloads/2003/August/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download/Understand%20Payroll%20Wage%20Type%20Processing%20Payroll%20Schema%20and%20Rule%20Basics%20Download.doc


17/40

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 currentwage type (in the header row) to the IT, keeping the same wagetype identifier 0BAS.

NUM=0.15: sets the value of the wage types number field equalto 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 numberfield.

Figure 1

Calculation logic for rule ZUA1


18/40

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 OUTWPoperation 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


19/40

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 0BASfrom the header row to the IT. If you dont dothis, 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 athttp://help.sap.com.

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
http://help.sap.com/http://help.sap.com/http://help.sap.com/http://help.sap.com/


20/40

= 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 Set field to maximum value

Table 1 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 =, 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-AmountOverride

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 foremployees 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


21/40

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.


22/40

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.


23/40

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 itwould 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 date-

effective change to the wage types processing class.


24/40

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 date-

effective, so if the rates or wage-brackets change in the future, you just update view v_t511k.

Example 4: COLA with Date FlexibilityFor 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


25/40

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.


26/40

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 splitslink a wage type to a tax authority, a benefit provider, and so on.

Figure 12 shows an RT result forTest 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.


27/40

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


28/40

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 f irst

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


29/40

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 f ind 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


30/40

Calculate COLA amount based on COLA wage base

Figure 17

COLA calculated for each occurrence of 0BAS


31/40

When and How to Develop Custom Functions and Operations

by Steve Bogner


November 15, 2003

SAPexperts/HRSAP's standard functions and operations provide functionality to solve most time and payrollcalculations. But in some cases they dont, and that is when you can develop custom functions andoperations for both payroll and time management. The author introduces you to the basics, includinghow 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: Then this approach fits best:

The calculation requires several wage types. Forexample do you use several wage types plusother factors to calculate the value for a new wagetype?

This is best implemented with a function. You could selectvarious wage types from the result table (RT), look upsome data in infotypes or custom tables to perform acalculation, and put the results into a new wage type in theRT.

The calculation is intended to introduce a customdata value into a wage type or time type. Forexample, you added a new field to infotype 1 orcreated a custom infotype and need to bring thatdata into time evaluation.

Use a custom operation for this. When processing thewage type or time type in a rule, you can retrieve a datavalue from a custom field or custom infotype and put it intothe calculation (the HRS field in time evaluation or

AMT/RTE/NUM in payroll).

You want to make a decision some sort ofbranching logic in time evaluation or payroll.

Use a custom operation to read that data value and put itinto the variable key of the rule.


32/40

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 evalact-anz = 0.

* get the field on infotype 9002select * from pa9002 where pernr = pernr-pernr and

endda >= acdate andbegda


33/40

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 isexecuted. For example, you could print out the input table (IT), RT, and Workplace Basic Pay (WPBP) tablebefore the function is processed. These parameters do not have any bearing on what internal tables areavailable 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 foroperations is op followed by the operation name.

Operations can have complex variations in how parameters are specified. The best way to approach this is tofind 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 athttp://help.sap.cominthe HR Tools section

Table 2 Frequently used attributes in the function/operation editor
http://help.sap.com/http://help.sap.com/http://help.sap.com/http://help.sap.com/


34/40

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 OOOOOfive 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.


35/40

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


36/40

endform.

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 vargvalue 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 asimilar 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


37/40

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 high-

level calculation logic. This practice helps you determine which internal payroll tables need to be accessed, asshown in Table 3.

Calculation Step Payroll Tables Required

Find the correct accrual rate for the employeespersonnel subarea and employee subgroup

Internal table WPBPcontains the employees personnelsubarea and employee subgroup, but they could havetransferred from one to another during the period. If thathappens, do you prorate the accrual for each personnelsubarea/employee subgroup combination? Or do you onlylook at the first or last assignments in the payroll period? Inthis example, you always use the last WPBP assignment ofthe period. You need a custom table to store the accrualrates.

Multiply the benefit accrual wage base by theaccrual rate

You need to know if the accrual wage base wage types willbe 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 ensuredthat the wage types involved in the calculation haveprocessing class 20 values that keep them in the IT.

Create the benefit accrual wage type thatcharges the employees cost center

Should you put this accrual wage type in the IT or RT? Inthis case, you will put it in the RT since there is no need toprocess the wage type further.

Create the benefit accrual wage type for thecorporate benefit expense

This wage type also goes in the RT, but you need to attacha specific corporate benefit cost center to it so that when theaccounting transfer to FI/CO is run, it will not be charged tothe employees cost center. The corporate benefit cost

center is stored in table C1 in payroll. You have to link thewage type in the RT to the cost center in the C1 table via awage type split indicator. This is the same technique used inthe standard system when assigning override cost centersto wage types on infotypes 14, 15, and 267.

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.


38/40

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 wouldmake 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.


39/40

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 9shows 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.


40/40

* 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.

Documents

Minimize Uncollected Taxes in SAP US Payroll