Around this time each year, benefits directors begin defining benefits offerings for the next plan year. Many factors including cost, employee satisfaction, and availability can cause employers to drop some of their current benefits and add new ones. This means you must enter new configuration into the R/3 benefits module. It also means that some current employee master data will become invalid.

In a smaller organization, these changes can be done manually, but they must be automated for a larger company.

This article explains how, using standard R/3 function models, you can quickly build a custom application to deal with this annual dilemma. Technical readers will be able to develop a program from these ideas and functional readers will be able to develop an easy-to-understand requirements document for the programmer.

Case Study: Acme Company

I’ll use the example of the Acme Company’s benefits program. Acme has two regions, North and South. Within each region, it has different benefits offerings for full-time and part-time employees.

In the North region, Acme offers three medical plans and a no-coverage option. Urgent HMO (UHMO) is a typical network-only plan with limited covered services. Eligibility is based on zip code. The final version of the provider’s new zip code table is not expected for several months. Blue POS (BPOS), a middle-tier plan, offers both in-network and out-of-network benefits. Blue PPO (BPPO) is a more expensive plan accepted by a wide range of physicians.

In the South region, Acme offers four medical plans and a no-coverage option. The plans are Dixie HMO (DHMO), Sunshine POS (SPOS), Sunshine PPO (SPPO), and Acme Indemnity (AIND). The indemnity plan was part of a union agreement that expired this year, and the company has decided to eliminate it. The provider of Dixie HMO notified Acme that rates would increase 100 percent, and the company negotiated a better contract with HMO-R-US (HMRU). Dixie HMO will no longer be offered. Figure 1 shows the configuration of benefit plans at the IMG path Personnel Management > Benefits > Plans > Health Plans > Define Health Plan General Data; Figure 2 shows the configuration of benefit programs for Acme at the IMG path Personnel Management > Benefits > Flexible Administration >  Programs > Define Benefit Programs.

Using the known changes, you create a list of differences between the new configuration and existing master data.

1. All employees enrolled in Dixie HMO must pick a new plan.
2. All employees enrolled in Acme Indemnity must pick a new plan.
3. Some employees enrolled in Urgent HMO may not be eligible next year based on their zip code.

You should correct these data inconsistencies before open enrollment begins to ensure that your pre-enrollment materials are complete and error-free. Many companies distribute an enrollment form in advance of the enrollment period. It normally indicates the coverage that will remain effective if the employee takes no action. The standard R/3 form does this by printing an asterisk in front of the current coverage. No asterisk appears when an employee’s current coverage is not offered in the new plan year. If your company uses Employee Self-Service (ESS), you have an added incentive to deal with this situation. Ineligible enrollment causes error messages to appear as pop-up dialog boxes in the ESS enrollment window.

The task of this application is to locate employees who meet one of the above criteria and assign a valid coverage option to them. You should make this application as generic as possible so it will be reusable each year with minimal changes. The key to building such a durable program is to rely heavily on standard R/3 function modules and configuration. When it is necessary to develop a custom component, you should make every effort to give it the look and feel of a standard R/3 component.

What to Do About It

The benefits administrator along with the company leadership team must decide on the action to take when an employee’s election becomes invalid. One common solution is to assign the default coverage for the employee grouping. Default coverage is the coverage new employees are given without making an election.

At Acme, the default medical plan for full-time employees is the POS plan, and the default medical plan for part-time employees is the no-coverage option. This information is stored in standard configuration tables at the IMG path Personnel Management > Benefits > Flexible Administration > Standard Selections. The application assigns the default plan to employees currently enrolled in plans for which they are no longer eligible by reading these tables. Figure 3 shows the configuration for default health plans at Acme.

In some cases, you may want to assign a plan other than the default plan for an invalid current enrollment. For example, Acme has decided that all employees currently enrolled in Dixie HMO should be automatically enrolled in HMO-R-US if their zip code allows it.

You could write the logic for the mapping of the old plan to the new plan directly into the program, but that would make the program obsolete after just one year. A better solution is to design a customizing table to contain the mapping information. This allows the functional analyst to control the application logic through configuration and makes the application function more like a standard R/3 module. Figure 4 shows the attributes of this table, which I’ll call Z_PLAN_MAP. Figure 5 shows the configuration of table Z_PLAN_MAP for Acme. Old enrollments that will be changed to the default plan are not configured on this table to avoid duplicate configuration. It contains only exceptions to the rule of assigning default plans.

How to Do It

With the problem defined, you can write a narrative of the solution in a single sentence. Write a program that locates current enrollment that is not eligible and assigns an eligible plan from the configuration tables. Since most programmers need more than a one-sentence requirements document, let’s explore the details.

The first step is to locate current enrollments that are not eligible. For this, use a standard R/3 function module called HR_BEN_GET_OFFER. Referred to simply as GET_OFFER in this article, it is the guts of the benefits enrollment screen (transaction HRBEN0001). On the enrollment screen, provide a personnel number, date, and adjustment reason. The transaction presents a list of allowed changes. A dot adjacent to an option indicates the employee’s current coverage (green when the current coverage is still allowed and red when it is not). The GET_OFFER function returns a list that includes every plan and option along with cost and coverage information available to the employee for the specified adjustment reason.

To solve the annual enrollment problem, the GET_OFFER function module must be called for each employee who is eligible for any benefits. The effective date, SEL_DATE, comes from the application’s selection screen and should be the first day of the new plan year. The function returns a set of tables, one for each plan category. Each table contains a column named ENROLLED that is set to ‘X’ if the employee is currently enrolled in that option and a column named NOT_ELIG that is set to ‘X’ when the option is no longer allowed.

A simple way to process all employees eligible for benefits is to read infotype 171. Only employees who have an infotype 171 are eligible for benefits. Figure 6 shows pseudo-code for locating all ineligible enrollments. The select option, sel_pernr, allows you to process the application for specified employees only.

Next, determine which plan will replace the ineligible plan. The application first checks the Z_PLAN_MAP table. If a match is not found, the application checks the standard SAP table for default plans. If it does not find a match, it prints an error message indicating that an ineligible election could not be changed. The code in Figure 7 illustrates this process.

The final step is to create the new enrollment record. SAP recommends using a Batch Data Communication (BDC) session to make master data changes in batch mode. BDC processes the master data updates through transaction PA30, which ensures that the attempted updates are valid. PA30 does not enforce all eligibility rules, but since you based your new plan selection on the configuration tables, this is not a big concern. Figure 8 shows the code for creating the new enrollment for health plans.

This BDC transaction uses the copy function of PA30 and changes only the benefit plan and benefit option fields. The dependent coverage level and the covered family members remain unchanged. Some of the BDC transactions may fail if a family member who is no longer eligible still has coverage. You can easily correct these transactions by processing the session manually (menu path System> Services>Batch Input).

This example, which demonstrates a method for adjusting elections by using standard SAP code in a custom-built program, produces an application that works year after year without modification. All of the complex micro-eligibility logic is encapsulated within HR_BEN_GET_OFFER, allowing the programmer to focus on the simple task of changing invalid elections to valid ones.

Technicalities

Some figures in this article contain code fragments from a program I wrote in SAP ABAP for version 4.6C. Figure 9 illustrates the declaration and main procedure parts of the application. Combining this code with that previously presented code produces a working program.

Tip!
The GET_OFFER module, a complex function, provides a convenient and safe way to incorporate all standard configuration rules into the application. The price paid for this power is poor performance. A large company should divide its employee base into groups of approximately 1,000 personnel numbers. Only process one group per execution of the application. Check with your Basis team to determine how many parallel processes your system can run, and submit as many as possible at the same time. Run these jobs after hours to avoid impacting the online activity of your employees.

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.