Quite a few steps are required to configure benefit salary and they are spread throughout the IMG. If you take the time to identify all of the criteria that can affect benefit salary and implement configuration and customer enhancements to automate your rules, then you can have a system that accurately calculates insurance coverage amounts for all employees at all times.

Many companies offer one or more insurance plans with coverage calculated as a factor of salary. One common example is a life insurance plan with coverage options of one, two, or three times the salary. Another is a long-term disability plan that offers 50 percent salary replacement coverage. Plans such as these make it necessary for the company to have a specific definition for “salary” as it relates to these benefits plans. In some cases, the definition of salary is different for each plan. SAP R/3 contains configuration options that allow the benefits administrator to have precise control over the calculation of the benefit salary for each plan. The configuration steps required to implement these rules are scattered throughout the IMG, but I’ve assembled them all here in this article.

What Is Benefit Salary?

Before starting any configuration, it is important to clearly document all the rules. A good place to start is the summary plan description (SPD). Most companies have these written documents that contain a plain-English explanation of the benefit plan rules. Other good sources of information are the employee benefits handbook, enrollment forms, and confirmation statements. Ultimately, the rules for benefit salary and insurance coverage must be verified with the HR leadership team.

I’ll illustrate this article with two sample insurance plans. The first is a life insurance plan and the second is a long-term disability (LTD) plan. The life insurance plan is described in the SPD this way: “Employees may elect optional life insurance amounts of one, two, or three times their annual salary rounded up to the next higher $1,000. Your annual salary is frozen each July 1 for the following plan year.” The description of the LTD plan is: “All full-time regular employees are covered by the company LTD plan. The LTD plan pays 50 percent of your base pay should you become disabled.”

These plan descriptions sound simple, but some vague terms and phrases require further investigation. The life insurance plan description mentions “annual salary” and the LTD plan description mentions “base pay.” Do these two terms have different meanings? The insurance plan description says, “times their annual salary rounded up to the next higher $1,000.” Does this mean that the annual salary is rounded up to the next $1,000 before multiplying or is the coverage rounded up to the next even $1,000 after multiplying? The answers to these questions must be known before the insurance plans can accurately be configured.

You can gather the required information by holding a joint application development (JAD) session. The JAD session is a meeting focused on building a thorough and accurate definition of benefit salary. The session leader should gather and organize all available information beforehand. Figure 1 shows the agenda and resulting notes from a sample JAD session. With this information, you have a complete understanding of how the base wage for these two insurance plans should be calculated. Now it is time to start configuration.

Creating Customer Wage Types for Benefit Salary

R/3 contains a model wage type for benefit salary called BSAL. If you review the information from the JAD session, then you will see that my sample company requires two different wage types for benefit salary. This is true for two reasons. The basic wage types that make up benefit salary for life insurance are different from those that make up benefit salary for LTD insurance, and the rounding rule for life insurance salary is different from the rounding rule for LTD salary.

SAP recommends that you copy the BSAL model wage type when creating a customer-specific wage type for benefit salary. This is done via the IMG menu path Payroll>Payroll US>Basic Settings> Environment for Maintaining Wage Types>Create Wage Type Catalog. Use the copy feature shown in Figure 2. Customer-defined wage types names must start with a number. I chose 9LIF as the wage type for life insurance salary and 9LTD as the wage type for LTD salary. The copy utility creates entries in all of the tables required to activate your new wage types. Using it ensures that you do not forget a step when creating a new wage type.

Figure 2

Create 9LIF and 9LTD using copy function

Now that the new wage types have been created, you can begin to customize them. At IMG menu path Personnel Management>Personnel Administration> Payroll Data>Wage Types>Define Valuation of Base Wage Types, you can specify the basic wage types that make up the two different benefit salaries. Figure 3 shows how this step is configured. The first column indicates that this is an annual salary calculation. The second and third columns contain the benefit salary wage type and its description. The fourth column is just a sequential number.

Figure 3

Valuation of base wage types (table T539J)

The next two columns, Start date and End date, represent the validity period. This makes it possible for your definition of benefit salary to change over time. The Base WT column is populated directly from the JAD session notes. Finally, the Percent column indicates that you want the related amounts to be taken at 100 percent value. You can enter a different value in this column if, for example, your company only credits 50 percent of shift premium toward benefit salary.

You need to make your new wage types valid on the benefit plan infotype before they can be assigned to the benefit plans. You incorporate these changes on table T512Z. There is no IMG path for this configuration, so you must use transaction SM31 with view name V_T512Z. Figure 4 on the next page shows that the two new wage types are now valid on the insurance plans (0168) infotype.

Figure 4

Permissibility of wage types per infotype (table T512Z)

Finally, you adjust the wage type attributes at IMG menu path Payroll>Payroll US>Basic Settings>Environment for Maintaining Wage Types>Check Wage Type Attributes. Figure 5 is an image of the wage type characteristics for BSAL. The only fields you are likely to adjust on this screen are the rounding type and rounding divisor. The possible values for rounding type are shown in Table 1. The rounding divisor includes an implied decimal point. A value of 100 indicates the salary is to be rounded to the dollar. A value of 1 would round to the penny.

Figure 5

Attributes for wage type BSAL

Now that the 9LIF and 9LTD wage types are completely configured, you can connect them to the appropriate benefit plans at IMG menu path Payroll>Payroll US> Benefits Integration> Assign Wage Types to Plans. These wage types are entered as the calculation base wage type for the plans.

How Indirect Evaluation Works

In Figure 5, you can see that indirect evaluation module ANSAL is used to calculate the value of BSAL. The ANSAL module is a function that takes a wage type and a date as input arguments. The date is known as the evaluation date and the wage type is the one to be evaluated, such as 9LIF or 9LTD. The standard ANSAL module starts by looking at the configuration on table T539J to determine which wage types are collected. Then the module takes the amounts of these wage types as stored on IT0008 and annualizes them. For hourly wage earners, this is the hourly rate times 2,080. For salaried wage earners, it is the per period amount times the standard number of pay periods in a year for their pay frequency. Next it reads IT0014 for a one-year period ending on the evaluation date. The amount from the appropriate wage types on IT0014 is included for each pay period in the preceding year in which the IT0014 record was valid. Finally, the module reads IT0015 for a one-year period ending on the evaluation date. The amount from the appropriate wage types on IT0015 existing in that one-year period is added to the annual salary.

My sample company has a rule for the calculation of annual salary that differs from the standard procedure. It stores shift premium on IT0014 and the rule says that whatever shift premium is in effect on the salary evaluation date should be annualized and made part of the annual salary. If the IT0014 record is valid for less than the entire year prior to the cutoff date, the standard process will prorate the amount. This means that the standard ANSAL module does not suit the sample company’s needs. You can overcome this problem in two ways. You can implement the BAdI for wage type valuation via IMG menu path Personnel Management>Personnel Administration> Payroll Data>Indirect Valuation>BAdI Maintain Indirect Valuation Module. Or you can implement customer enhancement PARA0002 via transaction CMOD. In either case, you copy the R/3 ABAP code from function RP_SALARY_GENERIC_CALC and modify it to suit your needs.

Frozen Salaries

My sample life insurance plan indicates that the base salary amount is frozen on July 1 for the next plan year. This rule presents a problem that cannot be solved with simple configuration. At IMG menu path Personnel Management>Benefits> Plans>Insurance Plans>Define Coverage Variants, you can specify a salary cutoff date as shown in Figure 6. This standard cutoff date configuration causes the benefit salary to be frozen from July 1 until the next June 30. For this plan you don’t want the July 1 salary to take effect until January 1. Implementing this special salary cutoff rule requires activation of customer enhancement PBEN0025. In the user exit, you can also program logic to query the actions infotype (0000). This logic sets the cutoff date as needed to accommodate the special rules concerning promotions and retirements. It also sets the cutoff date to the hire date for persons hired after July 1. For a download of some sample code for this user exit click here: Download.

Figure 6

Assigning salary cutoff day

Benefit Salary vs. Insurance Coverage

Do you remember that the SPD for the sample life insurance plan said that the amount of coverage was one, two, or three times the employee’s annual salary rounded up to the next higher $1,000? The JAD session revealed that the $1,000 rounding was part of the coverage rule and not part of the salary rule. Here is an example to illustrate the difference. If Joe Employee has an annual salary of $41,100 and he chooses three times his salary for insurance coverage, the total coverage amount should be ($41,100 * 3) = $123,300 rounded up = $124,000. If the salary is rounded up to the next $1,000, his total coverage would be ($42,000 * 3) = $126,000. Take care to keep details about the benefit salary separate from details about the insurance coverage as you gather information in your JAD session.

Clay Molinari

Clay Molinari has 20 years of experience in the IT industry and has been working as an SAP HR consultant since 1997. He is currently president of C&C Savant, Inc., an SAP consulting firm that specializes in combining standard SAP configuration and custom ABAP programming to help its clients solve unique or complicated requirements.

You may contact the author at claymolinari@comcast.ne.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.