R11i Benefits Fd Questions

Embed Size (px)

DESCRIPTION

R11i Benefits Fd Questions

Citation preview

Oracle Benefits

Frequently Asked Questions About Implementing Oracle HRMS R11i Benefits

Author:Oracle ConsultingCreation Date:May 10, 2000

Last Updated:September 23, 2004

Version:2.5

Document Control

Change Record

DateAuthorVersionChange Reference

May-10-00Oracle Consulting1No Previous Document

Oct-23-00Tanie Guy2.0Update Existing info and Major Additions

Nov-30-00Keith Ekiss2.1Edited Document

Dec-12-00Tanie Guy2.2Fixed Employer Deduction Answer

Dec-18-00Tanie Guy2.3Fixed Change record; Added Performance Section

Apr-10-01Tanie Guy2.4Added New FAQs Since Last Updated

May-13-02Tanie Guy2.5Added new FAQs since last update

Sep-23-04Keith Ekiss2.6Deleted obsolete information; added FAQ for recalculating participant values

Reviewers

NamePosition

Phil ChapmanOAB Product Manager

Keith EkissOAB Information Designer

Distribution

Copy No.NameLocation

1

2

3

4

Contents

2Document Control

Introduction5Expected Background for the Reader of this Document5General6Compensation Object Design8Life Events (Triggers)9Eligibility10Electability12Derived Factors13Rates/Coverage14Actual Premiums16Communications17COBRA / HIPAA (US Customers)18Flex Credit Plans19Flexible Spending Accounts20Waive Plans21What-If Modeling22Elements23Payroll27Batch Processes28Reports29System Extract30Benefits Self Service31Upgrade / Migration Path32Benefits and FastFormula34Performance Considerations35Canadian Implementation Considerations37Imputed Income38Standard Benefits With Advanced Benefits License39

Introduction

Expected Background for the Reader of this Document

This document is written for a reader who currently understands Oracle and Oracle HRMS Applications R11i.

Refer to Managing Total Compensation Using HRMS Release 11i (March 2000), available from Oracle Documentation, or your online help system, for further information.

General

What benefits functionality is available in Oracle HRMS Release 11i?

There are three levels of benefits available: Oracle Basic Benefits, Oracle Standard Benefits, and Oracle Advanced Benefits.

Oracle Basic Benefits (OBB) is part of the core HRMS product and is included in Release 10.7, Release 11.x and Release 11i. Oracle Basic Benefits allows for element based benefit processing. In this basic model, the element and element link have limited eligibility restrictions and functionality. The election opportunities or enrollments made under this model are not available for display under any enrollment forms in Standard or Advanced Benefits. It is highly recommend that you implement either the Standard or Advanced Benefits model.

Oracle Standard Benefits (OSB), Release 11i is considerably more powerful than the earlier Oracle Basic Benefits. Within this product, clients have the added capability of eligibility determination using profiles with a variety of criteria, and using enrollment forms to enter election information.

Oracle Advanced Benefits (OAB), Release 11i contains all the functionality of Oracle Standard Benefits plus:

Life Event Management: Online and Batch Flex Credit Calculations and Administration Communications triggers Reimbursement Requests Batch Processing features for Enrollment Management What-if Enrollment Eligibility Modeling Benefits Service Center Management

R11i Oracle Advanced Benefits is tailored to 3 groups:

1. Employers who administer their benefits programs in-house

2. Companies who administer benefits for other companies

3. Insurance carriers of benefits offerings

Where do I find the latest information regarding Oracle Consulting Tools for R11i Benefits?

For Oracle Consultants and employees, information can be found on the Oracle intranet at the globalxchange Portal.

http://globalxchange.oraclecorp.com

Follow this path from the globalxchange home page: Product & Solution Knowledge Areas and Communities : HRMS : Reusable Components : HRMS Applications : Release 11i Benefits - OAB

Do I have to purchase a separate license for Oracle Advanced Benefits if I purchase an HRMS Release 11i license?

Yes, you must purchase a separate license for Oracle Advanced Benefits in addition to your license for Oracle HRMS (which includes Standard Benefits). Licensing of Oracle Payroll is not a requirement, as the core product contains all the information necessary to establish your benefit plans.

What languages are available with Oracle Advanced Benefits and Oracle Standard Benefits? Presently, Oracle Advanced Benefits is available in English and Canadian French.

Oracle Standard Benefits is translated into all languages supported by the core HRMS product.

Is datetracking available in Standard Benefits and Advanced Benefits?

Yes, over ninety percent of the forms are date tracked in both applications.

What types of plans can be set up in Standard Benefits and Advanced Benefits?

Plans such as Medical, Dental, Life Insurance, Vacation Buy/Sell, Savings Plans, etc. Please refer to Managing Total Compensation Using HRMS Release 11i (March 2000) or your online help system for more examples. This can document can be downloaded from the GlobalXchange Portal.

Does Oracle Advanced Benefits provide a user interface for telephone service representatives for online counseling of employees and other benefits participants?

Yes, Oracle Advanced Benefits has a user interface optimized for environments that support counseling to employees and other benefits participants. The Benefits Service Center form provides access to a participants relevant benefit information. A call center representative can query a persons record and perform many common tasks, such as life event processing and enrollments, directly from the Benefits Service Center.Do I have to purchase a separate license for Self-Service Human Resources (SSHR)?

Yes, you must purchase an additional license for Self-Service Human Resources for use with either Standard or Advanced Benefits.

Compensation Object Design

Is there a recommendation on the number of period dates being set up for programs or plans?

Yes, it is recommended that a minimum of 10 years be set up.

Do you need to define Periods/Dates for both the plan and the program?

Yes, each plan and program must have a 'Year Period' associated to it so that the Participant Management Process will recognize it as an effective compensation object. It also uses these periods to determine how long the year period is for the plan. Plans can have different year periods than the program.

What are Reporting Groups used for?

Reporting Groups are a way of associating programs or plans in groups through data. This way a report or other query has a way of finding groups or sets of plans. It could be used to associate all 401k plans, or only qualified plans within a Program, for example, all the pre-tax benefit plans in the Flex Program.

What do the different Program Types mean?

The Program Types are to be used for reporting or describing the types of plans included in the program. Importantly, it is also used for determining which enrollment form the system should use: i.e. Flex Enrollment or Non-Flex Enrollment. If the Program Type has the word FLEX in it the system allows the Flex Enrollment form to be used. The Non-Flex Enrollment form does not display plans with flex credits.s

Life Events (Triggers)

What are Life Events? A Life Event is a change in a persons life that would effect a change in their benefits eligibility, enrollment, or contribution rate, such as Marriage or Termination.

What Life Events are delivered with Oracle Advanced Benefits?

There are 17 Life Events seeded with the application:

Age

Combined Age and Length of Service

Compensation

Hours Worked in Period

Length of Service

Loss of Eligibility

Total Percent Full Time

Enrollment Override

Reduction of Hours

Administrative

Open

Unrestricted

Voluntary End of Coverage

Non or Late Payment

Maximum Enrollment Period Reached

Period of Enrollment

Satisfied Waiting Period

You can create other Life Events with the use of data triggers. For example a Marriage life event is defined as a marital status change from null to Married.

Why isnt the New Hire life event predefined in Advanced Benefits? Employers differ in how they define a New Hire life event in terms of data triggers. For some employers, the new Hire Date would trigger the event, for other employers, a change in status from Applicant to New Hire would trigger a New Hire life event.

How is FMLA supported in OAB for U.S. customers? Once a leave reason is entered into the system, OAB can detect the life event (FMLA-conforming leave) and determine if the participant is eligible for continuing benefits; make them ineligible for those benefits which the customer doesn't provide for during such leaves; calculate electable choices; record participant elections; send out literature; and capture the participant's continuing benefits payment. At this time, the system does not have the ability to automatically determine whether a leave is FMLA-conforming based upon its type and/or the amount of such leave which the person has or has not used during the preceding 12 months. This feature is being considered as an enhancement to the product.

When you have more than one event tied to a Life Event is each one treated as an 'OR' expression, meaning the life event will trigger if either of the changes takes place, or as an 'AND' condition, meaning the life event will only trigger if all of the person changes take place.

The multiple data changes attached to the life event will be treated as an "AND" condition.

Eligibility

What are Eligibility Profiles? Eligibility profiles determine whether a person satisfies the rules which govern whether that person could ever enroll in a program, plan, or a coverage option within a plan. For example, in order to be eligible for the Acme HMO medical plan, a person might have to work more than 30 hours a week and be located in Nevada. Both Standard and Advanced Benefits give you the flexibility to define eligibility at many levels within your benefits program.

How do you resolve the following scenario: a Dependent Life plan needs an eligibility profile (the participant must be an employee) and a FastFormula rule (the participant must have elected EE Life). Can you use supply both criteria in one profile?You can create an eligibility profile with multiple criteria and one of those criteria can be a FastFormula Rule. Youll find this eligibility criteria on the tabbed region labeled Other on the Participation Eligibility Profiles window. The person would have to satisfy all criteria in order to satisfy the criteria of the profile, including the rule.

However, the above scenerio refers to a Post Enrollment Edit. The system does not know a persons election until the enrollment is recorded. Eligibility profiles are examined during eligibility determination before electable choices are determined.

In order to allow a participant to enroll in Dependent Life, the participant needs to be found eligible given that the person is an Employee'. You must attach a Rule to the Program Enrollment Requirements>General>Plan>Post Election Edit Rule that returns a 'Y' or an 'N' for the Dependent Life. This Rule will only allow the person to enroll in Dependent Life if they elect Employee life. The rule type needed is "Post Election Edit".

According to the Managing Total Compensation users guide, when you define eligibility profiles, you can define multiple criteria such as location and organization. The participant then must meet at least one value for each criteria defined. Can you define multiple criteria and have the participant meet the value of only one of the criteria, that is having an 'OR' condition as opposed to an 'AND' condition? Could this be done without defining a FastFormula rule?

When you attach an eligibility profile to a compensation object (for example, program, plan, plan-in-program), you can specify whether the profile is required. The person processing must satisfy ALL required profiles and AT LEAST ONE optional profile.

( If you attach only one profile, the profile is mandatory regardless if the profile is indicated as required. The system will read this profile as optional and at least one optional profile must be satisfied.

( If you attach more than one profile and no profile is required, only one profile needs to be satisfied to make the person eligible.

( If you attach more than one profile and all are marked as required, all profiles must be satisfied to make the person eligible.

( If you attach more than one profile, and some profiles are marked as required and some are not marked as required, all of the required profiles must be satisfied and only one of the non-required profiles must be satisfied to make the person eligible.

You do not have to write a FastFormula rule to accomplish most and/or conditions for eligibility.

How do you access the benefits tab on the People form which has the benefits group field that is used to attach a Benefits Group to an employee? This is a secured view (function) that should be available on all of the seeded menus for each localization. The following seeded US navigators have this function: US SHRMS Navigator, US HRMS Navigator, US HR Navigator, US HR + OAB (also called US SHR Navigator). These are the menu structures customers in the US should be using as models for customized menus. This also applies for the UK, Canada, France, Global, and all other menu structures.

The above menus are attached to seeded responsibilities such as US Super HRMS Manager, US HRMS Manager, US HR Manager, and US Benefits Manager. Therefore, when logging on as one of the seeded responsibilities, you should have access to the appropriate menu structure.

Note: It is possible to change the menu structure for these seeded responsibilities or to create new responsibilities with the incorrect menus. Should either event occur, you can update the menu structure to include the Benefits tabbed region. As a system administrator, query the BEN_MANAGER menu in the Menus window and add the HR View Benefits function to the menu. The menu should not have a display name.

Electability

What is Electability? Electability determines whether a person can enroll in a plan for which they satisfy the eligibility criteria. In order for a benefits choice to be electable, a person must be eligible for it. However, there are many cases when a person cannot elect a benefit for which they are eligible.

Typically, plan sponsors (and the IRS in the US) place restrictions on when a person can enroll in a benefit plan for which they are eligible. For example, Fred is eligible for all coverage options (Employee Only, Employee Plus Spouse, Family) in the Acme HMO and the Good Health Medical Plan and is currently enrolled in Acme HMO Employee Only. If he gets married, Fred receives Acme Employee Plus Spouse as an electable choice but the coverage options for the Good Health plan will not be electable choices.

Medical plans are electable. If Fred moves to a location where Acme HMO plan is not offered, he loses eligibility for that plan and the Good Health Medical Employee Only choice becomes electable.

During open enrollment, a person can typically enroll in all of the electable plans and options for which they are eligible. Exceptions to this exist: for example, once a person has enrolled in a given dental plan, often they cannot enroll in a different dental plan (even if they are eligible) until they have satisfied the minimum enrollment period (often two years) in the original dental plan.

Derived Factors

On the Derived Factors window, there is a field labeled "Alternate Value." This field contains a list of values including "Persons Eligibility Value" and Persons Rate Value". What are these values, where are they defined, and what would trigger their use? The Alternate Value is the value to use when the system tries unsuccesfully to find a given value. This is more likely to happen in cases of compensation than length of service. The person's eligibility value is the value used to determine whether the person is eligible. This value is recorded on the BEN_ELIG_PER_F or BEN_ELIG_PER_OPT_F table. This value can be viewed on the Participation Override window along with the participants rate value.

Note: This functionality is planned for future implementation.

What is the Override Service Date and where is it defined?The Override Service Date can be entered and viewed on the Participation Override window. It allows the user to enter a date to be used in place of the other service dates: original hire date, hire date, adjusted service date. The user can specify that the length of service factor look at any of these dates. There is a hierarchy in place that checks if the date specified is not available/null. If the service date is not available or null, the system checks for the next available service date in the hierarchy. The hierarchy is:

Override Service Date

Adjusted Service Date

Hire Date

Original Hire Date

Rates/Coverage

Which default enrollment code do I use to provide no default elections for a new enrollee, but to retain the existing election for a current participant, while assigning the latest rates?

Use the default enrollment code of 'New Nothing, Current Same, Enrollment and Rates'. The issue you may be having is around the 'latest rates'. The default process enrolls the person into whatever rate they previously had ONLY if the rate is defined with 'Enter Value at Enrollment.

For example, last year a participant elected to contribute $1200 per year to a Health Care spending account. Using the default enrollment code of 'New Nothing, Current Same, Enrollment and Rates' maintains the default enrollment in this plan at the rate of $1200. If you use the code 'New Nothing, Current Same, Enrollments but Default Rates' the system applies the default value defined on the Standard Rates window for the activity base rate when it is 'Enter Value at Enrollment'. Customers may set up the Health Care spending account with minimum and maxium values, for example Min $120 to Max $1200, with a default rate, such as $120. If a specific election is not made, the participant receives the default min of $120.

For open enrollment, the coverage/rates start the first day of next year and end the last day of the following year. What coverage/rate end date should I use? One day before event?

For open enrollment, you could use a coverage/rate start date of 'Event' and an End date of 'One day before Event date'. During open enrollment, we specify the life event occurred on date for the open event, for example 01-JAN-2001. This is the date you want the system to determine age, length of service, salary, etc, and the date you want rates and coverage to begin.

How does Benefits handle arrearages?

Example: New Hire on 08/01/01. Check Date is Semi-Monthly 8/15/01 but New Hire wasn't entered until 08/16/01 which is one payroll later.

Benefits doesn't change the way arrearages are handled. This is a payroll function. This feature works as it has in previous releases of Oracle HRMS and is determined based on how elements are defined for your implementation.

You should create elements using the Deductions form (template). This form does all of the FastFormula work behind the scenes. Then, if you need to alter anything for arrearages, you would alter the formula as you did prior to r11i.

How do I set up the Employer portion of a benefits deduction?

Create another standard rate and check the "Assign on Enrollment" field on the Standard Rates window. The person will be assigned this rate (i.e, the system will create a Participant Rate Value). Do not check the "Display on Enrollment" field. This prevents the value from displaying in the enrollment form. If you pass the value to the assignment element entries, you must create an element entry for the employer liability that will be processed by Oracle Payroll. To accomplish this, check the Process in Run field for this rate.

What is the appropriate use of the Parent/Child rate field?

The use of this field is to identify the Parent rate, and additional rates for the same comp object, child rate(s). One of the Calculation Methods available for rates is Multiple of Parent. This allows the user to set up a Parent rate that is perhaps the Total Amount Due, one Child rate that is the Employee portion, e.g. 60% of Parent, and another that is the Employer portion, e.g. 40% of Parent.

On the Program definition form: Activity Reference Period and Enrollment Frequency, what do they indicate and how do they affect Program settings in OAB? How are they used?

The Activity Reference Period describes the frequency in which all rates for the program and any components of the program will be specified - e.g. all rates will be monthly values. (Although you can define a rate so that the user is entering an annual value - this is a separate tab on the Standard Contribution/Distribution form.)

The Enrollment Rate Frequency is a secondary frequency, which may be specified. It is calculated and stored for the rates and is mainly available for reporting. This allows the customer to have participants with varying pay frequencies to receive communications that specify the rates in the amount per pay period, whether weekly, biweekly, etc.

I have multiple variable rate profiles. Does it matter in what order they are attached to the compensation object?

If you have multiple variable rate profiles and the criteria are not mutually exclusive, you should give the earliest sequence number to the most restrictive profile, next most restrictive, etc. Example:

Variable Rate Profiles:

1. Sequence Number 1: Valid Service Area 3 + Assignment Set "PT"

2. Sequence Number 2: Valid Service Area 3 + Assignment Set "Exec"

3. Sequence Number 3: Valid Service Area 3

The variable rates determination process evaluates the profiles in the sequence number order.

Actual Premiums

To take advantage of the Premium Calculation process, do I need to set up a separate rate for the employer cost on each option?

The premium is the amount paid by the plan sponsor (employer) to the carrier (Aetna, Kaiser, etc). Premiums are usually calculated on a per participant basis for an option in plan. Sometimes premiums are based on the total number of participants covered in a plan or an option in plan. So, you will want to consider the premium to be the total cost to the 'Company'. How the company determines what it will pay versus what the employee pays is accomplished through defining Standard Rates.

Define the premiums on the Actual Premiums window as the total cost of a benefit to the 'Company', usually for an option in plan. Then define a standard rate for the Employee portion and one for the Employer portion. The two rates should total the premium amount for the option in plan. This is how you derive the 'Employer' portion of the premium. You can also attach elements that will cost the Employer portion accordingly if you use Oracle Payroll. Please refer to the Managing Total Compensation Using Oracle HRMS users guide or your online help system for more information.

On the Actual Premiums form there is a Reference Period field that is grayed out. Once you save the Premium, it automatically fills in the Reference Period with "Monthly." Does this mean we should be entering monthly Premium amounts instead of annual (like we are doing for Rates)?

Premiums can only be entered as Monthly amounts. The reference period for the program/plan not in a program may be different. The application converts the amounts, for example, when the rate is annual and the premium is monthly and the rate is a multiple of the premium.

When and how do I use Assignment, Assignment Level, Prospective vs. Retrospective and Payer?

1) Assignment: when would you use Enrollment vs. Premium Process?

This tells the system whether the premium is to be calculated during the enrollment process (i.e. benmngle runs) or when the Premium Calculation Process is run. The latter is generally used for calculation methods based on Total Participants or Total Coverage.

2) Assignment level

This is telling the calculation process whether to determine and save the premium just for the Participant, for the Participant and the Plan or Option, or just the Plan or Option. If you want premium values only for each individual Participant, choose Participant. Plan or Option is the total premium for all participants in the plan or option. If the premium is really for the plan or option as a whole and you don't need the participant level premiums, choose Plan or Option. If you care about values or you want to report on either, choose Participant and Plan or Option.

3) Prospective/Retrospective

This tells the system whether the premium is to be calculated prospectively: for the upcoming month, in advance of the period of coverage, or retrospectively: for the month just passed, as a result of coverage previously received. Mostly it's used for determining credits for earlier months.

4) Payer: when to use Employer vs. Participant vs. Total Plan Premium?

It's to identify who's paying or what portion of the premium it is. There is an edit that when the calculation method is Total Plan Premium minus Participant Contribution, the Payer code must be Employer.

Communications

How is the term communications used with the applications? Generally, communications are the primary means by which you inform employees and other participants of enrollment periods, administrative procedures, and electable choices. Within the application, communications refer to the triggers created for a participant under certain conditions that are written to the Person Communication table. For example, a communications trigger indicates that a New Hire Statement should be generated when certain eligibility requirements are met.

What types of communications triggers are available in Standard Benefits?

Standard Benefits supports manually triggered communications. Because this product does not have any automatic processes, the communication triggers cannot be created automatically.

What types of communications triggers are available in Advanced Benefits?

Within Advanced Benefits, some examples of the communication triggers that are available to trigger automatically are: Pre-Enrollment Literature - Enrollment Window Opened, Final Confirmation Literature - Close Enrollment, Election Modification Literature - Determined First Time Ineligible and De-Enrolled.

Does Oracle Standard Benefits or Oracle Advanced Benefits automatically send out communications?

No, neither system automatically sends out communications. Within Advanced Benefits, after running a batch process, a communication row is written to the Person Communication table. Using the System Extract feature, data from this table may be extracted to a text file and then merged into the body of your communication.

Do both Oracle Standard Benefits and Oracle Advanced Benefits have the ability to handle targeted mass mailings?

Only Advanced Benefits has the Determine Communications Batch Process. However, by using the System Extract process, Standard Benefits administrators may create extract files that will function similarly if the proper eligibility is defined.

COBRA / HIPAA (U.S. Customers)

Does Oracle Standard Benefits in R11i assist with the administration of COBRA?

Yes, both Oracle Standard Benefits and Oracle Advanced Benefits help the client administer the requirements imposed by the Consolidated Omnibus Reconciliation Act legislation.

Does Oracle Advanced Benefits assist with the administration of HIPAA?

Yes, both Oracle Standard Benefits and Oracle Advanced Benefits help the client administer the requirements imposed by the Health Insurance Portability and Accountability Act legislation.

My set up includes one plan that will be used for both an Active Program and a COBRA program. Is it necessary to set up COBRA Regulations? What purpose does this tab serve other than to identify what plans are subject to COBRA and to group them for reporting purposes?

The COBRA regulation must be associated for all plans subject to COBRA. The Participation Process looks for this regulation as part of the determination for eligibility within the COBRA program.

Flex Credit Plans

Can Advanced Benefits handle the distribution of excess credits from a flexible benefits plan?

Yes. Participants may choose to roll over excess credits to another plan, forfeit excess credits, or receive the credits as cash. This is accomplished through the definition of flex credit benefit pools.

Does Standard Benefits have the same functionality?

No. Only Advanced Benefits has the functionality to automatically define Flex Credit plans and to define excess credit distribution rules within the application.

How does a participant accumulate flex credits?

You define the flex credits at whatever level the person must enroll in order to receive the flex credits. (You shouldn't have any problems using variable rate profiles to determine the amounts.) Example: If person enrolls in Medical Employee Only, the person gets $25 in flex credits. Define the flex credit at the option in plan in program level.

How can flex credits be used?

This is determined by defining Benefit Pools. If your program has flex credits that can be used for anything in the program, you need to define a Program level pool. You need to associate (on the Applications tab of the Benefit Pools window) any rates that reduce the flex credits in the pool.

What happens when the person enrolls?

The flex credit process determines which plans/options the person has enrolled in and whether those plans/options have flex credits associated with them. It comes up with a total. The total amount is saved on the 'placeholder' Flex Credit Plan. Example: participant enrolls in Flex Program and selects Medical Employee Only. Program credits $50, Medical Employee Only $25 = Total flex credits for the Flex Credit Plan: $75.

The plan/option enrollment results and rates are created the same as if there were no flex credits. Example: Participant enrolls in Medical Employee Only, Employee Contribution $35.

Element Entries get created.

When Participant is paid, they will see:

Flex Credits Distribution $75

Medical Deduction $35

This will result in a net addition of $40 to the participant.

Flexible Spending AccountsCan Flexible Spending Accounts be defined to process payments to participants?

Yes. Reimbursement requests may be set up to reimburse payments from a spending account when the benefits department receives the appropriate paperwork from the participant. Only Advanced Benefits provides the capability to administer spending accounts.

If you configure reimbursement information after a person is enrolled, can you still process reimbursements for the person?

Yes.

When configuring reimbursements, do you have to provide relationships?

No.

When configuring reimbursements, do you have to provide certificate information?

No.

Do I need a rate set up for the reimbursement amount to work?

Yes. You need to set up a distribution rate for the amount to be paid out that is nonrecurring. We do not yet handle recurring flexible spending account distributions, such as monthly child care payments.

Waive Plans

What is a Waive Plan?

The Waive Plan check box indicates which plan will represent your 'No Coverage' plan. Since the plan names are user defined, the system has no way of knowing which plan represents no coverage. You will need to explicitly enroll a participant into the 'No Coverage' plan (waive plan) if you want to track this information. You would want to track this information if you need to report on the number of participants who explicitly elect NOT to accept provided coverage.

Note: This concept also applies to Options.

What-If Modeling

The What-if Modeling feature in Oracle Advanced Benefits covers employee modeling. Does it also include employer modeling?

The What-If feature covers only employee life event eligibility modeling. Future plans include the addition of employer what-if modeling, which would allow the employer to model costs associated with different program and plan designs.

Is What-if Modeling included in Oracle Standard Benefits?

No. What-if Modeling is only included in Oracle Advanced Benefits.

Does What-if modeling change information at the database level?

No. What-if modeling does not change database information. This feature examines information for a person at a specific point in time and allows the participant to model the effect of changes to their benefits. When you exit the form, the data is not saved.

Elements

How do you fill out the Element Description form when creating elements for Standard or Advanced Benefits? Primary Classification: This only tells Payroll how to tax the element once it comes over to Payroll. Thus, if the primary classification is pretax then make it pretax, if it is after-tax then make it after-tax, etc. This does not change the calculated rate within the benefits module.

Benefit Classification: Leave this field blank. This was used only for Basic Benefits with Release 10.7 and 11.

Recurring vs Non-recurring: Usually, for benefits, the element will be recurring.

Make sure that the Allows Multiple Entries flag is checked to ON.

Make sure that you have chosen the correct ending point, either actual or final close (normally actual termination).

For imputed income, do not use the payroll seeded element because it may double calculate imputed income.

Further Information: This is a required field for Oracle Payroll. It is mainly used for Tax purposes. Select the option that is most relevant (i.e. using Pre-tax 123). This field provides instruction to payroll regarding how to calculate the element.

Note: Once you define your elements and attach them to your rates, if you go back and change anything to your elements you must unattach them from your rates and then reattach them. If you do not do this, you will cause problems with your rates.

Note: When linking the elements, in order for costing to work correctly, you need to be consistent with your link criteria. For example, consistently linking your benefits elements to all payrolls would allow eligibility calculations to work properly.

When should I use existing elements vs new elements? Without a clear understanding of existing element setup, it is impossible to know the ramifications of using existing elements. Therefore, Oracle development (Payroll and Benefits) strongly encourages creating new elements when using Standard or Advanced Benefits to capture rates (costs) associated with benefit elections.

Oracle Benefits will be authoring a detailed white paper on the subject of using elements. For now, here is a brief explanation of the concepts and the pros and cons of using existing elements vs. creating new elements.

Basic Benefits

The old way of administering benefits, prior to r11i, has not been removed from the product. Elements and Input Values use benefit tables and FastFormula to derive an amount (Employee or Employer contributions/distributions). Element linking restricts which elements can be assigned to an individuals assignment. Once assigned to an individuals assignment, these amounts can then be processed accordingly by Oracle Payroll or a third party payroll.

Standard or Advanced Benefits

Users create a compensation hierarchy of Plans (HCA) or options in plans (Coyote Dental - EE only). The eligibility criteria are attached to the individual compensation objects within the hierarchy to determine participant eligibility. The coverage amounts, flex credits, premiums, imputed income, and Rates (EE/ER contrib/distribs) are also created for each compensation object.

Activity Base Rates (ABRs) are created on the Standard Rate form (imputed income has its own form) for each compensation object for which we calculate costs such as EE/ER contribs/distribs. For Payroll to process, 1 Element and 1 Input Value is attached to the ABR on the Standard Rate form. We can have multiple ABRs for each comp object. Example, 1 ABR for EE contribs and 1 ABR for ER liabilities.

When a person enrolls in a compensation object, the associated element(s) and input value(s), on the ABR, are assigned to the employees assignment or benefits assignment element entry. The input value will contain the amount calculated by BEN and will simply need to be added/subtracted/costed by payroll.

Pros and cons for Using Existing Elements:Pros

1. Already linked for costing

2. No transfer of balances needed

Cons

1. Cannot create new input values for elements that have already been linked

2. Must disable existing benefit tables

3. Must alter ALL existing FastFormula which uses the input value in the element

4. Additional T&E altering old benefit tables and formulas

5. Exposure to errors in changing benefit tables and formulas

Pros and cons for Creating New Elements:

Pros

1. Less setup needed with new elements as BEN is doing all of the calculations

2. Can create new input values to capture calculations from BEN

3. Open link can be used if there is NO costing

4. No manipulation needed for benefit tables or FastFormula, the Amount input value will appear correctly on SOE

5. New Input Values are NOT being used by existing benefit tables and FastFormula

6. Can add a new input value to existing FastFormula if needed

Cons

1. Costing - new elements would have to be linked accordingly (however, may have fewer elements)

2. Balances may need to be transferred if converting mid year

3. T&E implementing new elements and removing existing

There may be additional pros and cons under each category depending on the specific conditions of your implementation.

How do I setup elements for Benefits and the ADP Connection?

There are 4 different types of elements you might set up when implementing the ADP interface. You wouldn't normally set up both basic and standard/advanced benefits.

Basic benefits

When creating basic benefit elements, create elements with a a primary element classification of "Voluntary Deductions" and a benefit classification of Medical, Dental or Vision. Set the ADP Deduction flag to Yes. Three input values will automatically be created (for coverage, EE contribution and ER contribution).

When you use basic benefits, deductions relating to non-Medical/Dental/Vision benefits (for example, savings plans) should be implemented as regular ADP deductions if they are to be interfaced to ADP.

Basic benefit info is interfaced using the hr_adp_benefit_v view.

Standard and Advanced Benefits

Standard and Advanced Benefits functionality is new in 11i. The ADP interface will interface employer and employee payroll contributions for benefit plans defined using the new standard and advanced benefits functionality, providing the following conditions are adhered to:

1) Benefit contribution amounts are calculated by Standard/Advanced Benefits and the results of the calculations are interfaced to ADP via element entries. So you must associate elements with your activity rates if you want the contribution amounts to be interfaced to ADP. Check the "Assign on Enrollment" check box when you create your activity rates so that the appropriate element entries are created on enrollment.

The elements that you associate with activity rates do not have to be created as ADP deduction elements. You simply need to create an element with one input value. This input value will hold the rate. Create a different element for each activity rate.

If you have already created your activity rate elements as ADP deduction elements, this is not a problem. Use the amount input value to hold the rate, and set the ADP Deduction flag to No. Also set the Units input value to not required. Your activity rate elements will have 3 input values instead of 1, but that will not break the interface.

2)Activity rates should have activity rate types of either "Employer Payroll Contribution" or "Employee Payroll Contribution". If you want to pass both Employee and Employee Contribution amounts to ADP you should create two activity rates. You should use a different element definition for each rate.

3)If you use variable rate profiles, these should also have activity rate types of "Employer Payroll Contribution" or "Employee Payroll Contribution" if they map to activity rates that are used in plans whose contribution amounts are to be interfaced to ADP.

4) If you want to interface flat dollar contribution limits, you can do so by setting up period-to-date limits against your activity rates. Please ensure you create only one period-to-date limit for each activity rate.

5) Element definitions that are created as part of your activity rate setup should have the ADP Deduction flag set to No. If this flag is set to Yes it can adversely impact the operation of the standard/advanced benefits functionality.

Standard/advanced benefits information is interfaced using the hr_adp_oab_benefit_v view.

GTL

There is a GTL specific view called hr_adp_gtl_v that returns GTL info. To interface GTL info to ADP, set up an element called ADP GTL as described in the ADP interface implementation guide.

Regular ADP Deductions

If you want to interface any other deductions that are not returned by the previous three views, set up regular ADP deductions as described below.

These regular deductions are interfaced via the hr_adp_deduction_v view.

1) Set ADP Deduction flag to Yes.

2) Each Element should have the 3 Input Values - Amount (type Money), Units ( type Look-up HR_ADP_DEDUCTION_UNITS and Limit (type Money).

How does the system utilize Deduction Schedules?

The deduction schedules are currently only used for reference or exporting a name to a foreign payroll. They don't do any calculations. The process that creates element entries does look at the Frequency Rules defined for related Element Types.

Eligibility is based off of normal fields like employment category and person type, it does not use payroll. The client needs to cost the medical deduction to 13 accounts. There are 13 payrolls being configured under 1 GRE. We want to set up 1 element and create 13 links based on the 13 payrolls in the system.

When an employee transfers from payroll 1 to payroll 13 in the old days the link would break. Is there some functionality that will not break the link, continue the deduction, cost using the new link and keep ben_prtt_rt_val_f up to date?

In Release 11i, people who cross link boundaries and are still eligible will not get the Element Entries end-dated.

Payroll

Do both Oracle Standard Benefits and Oracle Advanced Benefits integrate with Oracle Payroll?

Yes, both products integrate with Oracle Payroll.

Why must you define a default monthly payroll?A monthly payroll must be determined to be the default monthly payroll for non-active employees who elect continuing benefits such as COBRA in the U.S. A monthly payroll must be set up only if no other monthly payroll exists in the designated Business Group. This allows the administration and costing of assignments for non-active employees who elect continuing benefits.

Please refer to Managing Total Compensation Using HRMS Release 11i for a further discussion of benefits assignments. This users guide can be downloaded from the GlobalXchange Portal.

How are element entries created for participants?

Elements are automatically created in Standard and Advanced Benefits after saving the record within the enrollment form in the Professional User Inteface or Self-Service as well as through certain batch processes in Oracle Advanced Benefits.

Must Oracle Payroll be installed if the client purchases an Oracle Advanced Benefits license?

No.

Does Oracle Advanced Benefits utilize any of the Oracle HR and / or Oracle Payroll tables? Yes, in addition to the newly created benefits tables, Oracle Advanced Benefits utilizes some of the Oracle Human Resource and Oracle Payroll tables (shared/core applications tables).

Batch Processes

What Benefits Batch Processes are included in Oracle Standard Benefits?

Three batch processes exist in Oracle Standard Benefits, they are:

Extract Process - creates an extract for an extract definition you have defined.

Extract Write Process - saves the output from the Extract Process to a file.

Premium Calculation Process - selects appropriate participants and creates premium results.

What Benefits Batch Processes are included in Oracle Advanced Benefits?

Oracle Advanced Benefits contains the three batch processes that are included with Oracle Standard Benefits. In addition, Oracle Advanced Benefits includes the following seven batch processes:

Participation Batch Process - determines eligibility and enrollment information for the persons and benefits plans you select.

Back Out Life Events Process - this process is run when a life event has been started in error for a group of persons.

Default Enrollment Process - automatically enrolls a person into a plan based on predefined criteria.

Close Unresolved Action Items Process - used to close any required or optional Action Items that have not been completed by the participant.

Close Enrollments - closes a persons enrollment after elections have been made and resolves any incomplete election information.

Temporal Communications.

Maintain Designee Eligibility.

How frequently should I run the Oracle Advanced Benefits Participation Batch Process?

This varies based on the size of the organization. Typically, plan sponsors with large employee populations will run the process daily, whereas small employers may run the process once a pay period, prior to each payroll processing. Depending on client requirement for Life Event detection and timeliness of life event evaluation, the Participation Process may be run as often as required.

I get an ORA-20001:BEN_91663_BENMNGLE_LOGGING: error when trying to run participant management batch process?

This is because the Audit Log Flag is turned ON and the Audit log tables are running out of space.

Proper procedure should be to keep the Audit Log flag turned OFF. Refer to the report created by the Participation process for errors and for the number of people processed in the run.

Note: If you receive this error, you need to run the Participation Audit Activity Purge batch process. This will clean out your Audit log tables.

Reports

Are standard benefits reports included in Oracle Advanced Benefits?

There are no standard reports delivered in Oracle Advanced Benefits at this time. Reports may be developed using Oracle Reports, or, ad hoc reports may be developed using Oracle Discoverer. The OAB System Extract process may be run to extract data in a file that could be imported into another external report writer product.

Note: Oracle Consulting has developed some custom reports for Oracle Advanced Benefits. Contact your Oracle Consulting representative for more information.

Why do I see Benefits Reports in the Table of Contents of the Managing Total Compensation User Guide?

This section refers to the capabilities within the product to identify reporting groups for selection within the System Extract process.

What are the Summary reports?

These are the activity summary reports generated by the batch processes. They display information such as number of people processed successfully, number of people processed with an error detected, total processed, etc.

How do I add a Regulator Body to the system?

Use the Organizations window to set up an external organization with a classification of Regulatory Body. You can then select the Regulatory Body when defining a regulation.

System ExtractIs the System Extract functionality available with Oracle Standard Benefits?

Yes. The System Extract functionality is a part of the core HR product in Release 11i, and as part of Oracle Standard Benefits and Oracle Advanced Benefits. The System Extract functionality can be accessed from the navigator window.

Is the System Extract an Application Object Library (AOL) function or does it utilize Application Data Export (ADE)?

The System Extract function is a part of the core HRMS product. It is not related to the Application Object Library or Application Data Export functionality.

Is the System Extract date tracked?

The System Extract is not date tracked. However, when you submit a job through the Concurrent Manager you are able to enter an effective date for the extract.

Does the System Extract function provide the ability to meet ANSI (American National Standards Institute) standards for benefit enrollment and maintenance (834)?

Yes. The System Extract feature allows plan administrators the ability to create field definitions, file layouts, and criteria to meet the U.S standard benefits interface format ANSI 834.

Is the System Extract functionality available with Oracle Basic Benefits?

Yes. The following list of fields do not need any benefits data (OSB or OAB data) to be extracted.

Element Name

Element Reporting Name

Element Description

Element Processing Type

Element Input Currency

Element Skip Rule

Element Input Value Name

Element Input Value Units

Element Entry Value

Element Entry Costing

Element Entry Effective End Date

Element Entry Identifier

Element Primary Classification

Element Output Currency

Element Input Value Sequence

Element Entry Reason

Element Entry Effective Start Date

The following list of fields require Enrollment Data to be extracted:

Enrollment Entry Value - Employee Pre Tax Contribution

Enrollment Entry Value - Employee After Tax Contribution

Enrollment Entry Value - Employee Total Contribution

Enrollment Entry Value - Employer Total Contribution

Enrollment Entry Value - Employee Total Distributions

Enrollment Entry Value - Employer Total Distributions

Enrollment Entry Value - Total Other Rates

Benefits Self Service

Can Standard Benefits customers use Self-Service Enrollment?

Standard Benefits customers need to be careful about using SS enrollment. Because there is no life event management capability for Oracle Standard Benefits, standard customers must specify that their benefits programs and plans use "unrestricted enrollment" (meaning that participants can enter and exit plans at any time). We recommend that you make the SS enrollment user interface available only during the open enrollment period. If the self-service interface is available outside of the open enrollment period, participants will be able to enter and exit plans at will.

How can I see the price tag and taxable benefit on the same row, for the confirmation / overview page?

For each option, define two rates. The price tag rate with Tax Type of Pre or After Tax, and activity type of employee payroll contribution. Hide the column (pre/after tax) that you choose not to use. If you want this to reduce the Used Total amounts when a benefit is selected, then select the rate in the application tab of the benefit pool form. The After Tax Total Amount bucket will increment if the price tag has tax type = After Tax. You may hide any of these totals buckets. The taxable benefit column should have an activity type of Self Service Display. This will make it appear in the correct column (same row as price tag). Make both price tag and taxable benefit display on enrollment.

Upgrade / Migration Path

Is there an upgrade plan or migration path for benefits from Release 10.7 or Release 11.x to Release 11i Benefits?

There is a not an upgrade path from prior releases of Oracle HR to Release 11i Benefits. R11i provides a major paradigm shift in how benefits were processed from Release 10.7 and Release 11.x to how they will be processed in Release 11i, thus precluding any automatic migration.

Will any of the new benefits functionality be back ported to prior releases?

No. Due to the major change in the database design and how benefits will be administered and processed in Release 11i, there will be no back port of the new functionality.

Will Oracle 10.7 or 11.x elements migrate to Release 11i?

The older functionality exists, however, due to the new models, prior enrollments made in earlier releases are not visible under the Release 11i enrollment forms, nor are you able to use the new profiles for eligibility determination. For clients who are not going to implement Advanced Benefits, it is recommended that they implement Oracle Standard Benefits due to the enhanced functionality.

Moving from Release 10.7 or Release 11.x to R11i Benefits is considered a new implementation of the benefits portion of the system. It is not recommended that benefits elements defined under earlier versions be migrated and reused in Release 11i. The new model does not use previously defined benefit tables. High level upgrade activities include:

Business Requirements Review - update the business needs impacted by the upgrade project. Document changes in business processes between the current and new release of the application.

Requirements Mapping Update - evaluate the changes in the new applications release against the business requirements defined in the Business Requirements Review.

Application Set-up - document and create new benefit plans

Data Migration - migrate current system data to the new Oracle Applications tables

Documentation - update existing or develop new documentation.

Business System Testing - focus on verifying that the new application release functions meet business objectives.

Training - educate the project team so they can perform the required analysis and prepare the users to assume the tasks of running the upgraded system.

Product Migration - move the company, system, and people to the new application release

Other areas of the applications will be minimally impacted and will be addressed through a normal system upgrade path.

Note: There will be a time when the Basic Benefits model (R10.7, 11.x model) will no longer be supported.

Do the APIs recognize binary files?

No.

Which version of Datapump does Benefits use?

Same as HR11i.

Note: A detailed document on converting historical benefits elections to the new benefits tables (including table and column information) has been authored by development and is available on MetaLink. See the document titled: Implementation Approach, Oracle Applications HRMS: Implementing Oracle Benefits in Release 11i.

Data Pump calls the APIs and knows in which order to call the APIs and which columns need data.

Can you convert text notes to OAB?

You cannot convert text files to OAB.

When converting data, do the APIs or Data Pump do any eligibility checking?

No. Using the APIs or Data Pump (which uses the APIs) only enforces the business rules built into the APIs, (i.e. cannot be enrolled in multiple medical plan types). They do not evaluate records based on the eligibility criteria profiles that you link to Programs and Plans.

Benefits and FastFormula

Where can I find more information about using FastFormula with Standard and Advanced Benefits?

See the MetaLink document entitled Oracle FastFormula Reference Guide for Standard and Advanced Benefits for a thorough overview of the available formula types for use with benefits.

Is it possible to add database items to the benefit type FastFormulas?

You can add DBIs in the same manner that you do for Payroll.

What is a formula function and how is it used?

A formula function is a function called by a formula, it behaves in the same way as any other pl/sql function, uses pl/sql syntax, and has no knowledge of database items. It understands parameters passed into it. You define where these parameters derive from in the Formula Function window. Database Items (dbi) work inside formula, you can pass the value of a dbi into a variable and use that variable as a parameter call to a function.

You cannot enter a dbi in a formula function and expect it to be interpreted, since pl/sql doesn't know what a dbi is.

Performance Considerations

Which tables are high volume and need to be watched by the local DBAs?

The tables that will have the most data are the tables where participant information is stored.

The largest of these are the eligibility tables:

BEN_ELIG_PER_F

BEN_ELIG_PER_OPT_F

The Participation process loads about 100 - 300 rows per participant into these two tables. These tables will balloon in size if you track in-eligibility for your program or plans.

The next in size are the electable choice and enrollment results tables:

BEN_ELIG_PER_ELCTBL_CHC (The Participation process loads about 60 - 100 rows per participant life event into this table.)

BEN_PRTT_ENRT_RSLT_F

Other high volume tables include:

BEN_ENRT_BNFT

BEN_ENRT_RT (The Participation process loads between 20 - 50 rows per participant life event into this table).

BEN_PRTT_RT_VAL

BEN_ELCTBL_CHC_POPL

BEN_PER_IN_LER

BEN_PTNL_LER_FOR_PER

BEN_REPORTING (This is a problem if you are running a participation process with audit log on).

BEN_PERSON_ACTIONS (Gets very large if you run batch processes for the population with a chunk size of 1).

BEN_BATCH_RANGES (Gets very large if you run batch processes for the population with a chunk size of 1).

and look at the other children of:

BEN_ELIG_PER_ELCTBL_CHC

BEN_PRTT_ENRT_RSLT_F

Batch processes are running extremely slow and forms list of values are taking a long time to load. What do I need to check?

The main areas of performance problems are not analyzing the BEN tables and compensation object design.

Starting with 11i we have moved from a rules based optimizer to a cost based optimizer (CBO). The CBO uses table statistics to determine the least expensive access path to retrieve the requested data. To analyze the BEN tables you will need to submit the following from the concurrent manager:

FND_STATS.GATHER_SCHEMA_STATISTICS

(

schemaname

VARCHAR2,

estimate_percentNUMBER DEFAULT 10,

degree

NUMBER DEFAULT NULL,

internal_flag

NUMBER DEFAULT NULL,

request_id

NUMBER DEFAULT NULL

);

For the schemaname use BEN and for estimate_percent a number from 0-99.

For compensation object design keep in mind the following:

Program/Plan Hierarchy:

Try and minimize the number of plans not in program. By putting a plan in a program you can minimize the hits to the database by including business requirements at the program level which will cascade to the lower levels.

Eligibility/Electability:

Set the track ineligible flag off below the program level. This prevents multiple writes for ineligible compensation objects within the same program.

Eligibility has a top down hierarchy so by defining the broadest criteria at the top and refining the criteria as you drill down you can find the highest population ineligible at the highest level in the hierarchy to reduce processing for participants.

Electability has a bottoms up determination. Define the most general at highest level and restrict at the lowest levels.

Rates:

Define rates at the highest possible common level to minimize calculation and write processing. Avoid option in plan in program (lowest level) as this has the highest processing times.

Rules:

Create these at the lowest level possible. A person level rule, i.e. a derived factor, will be fired off for every person processed versus a rate or coverage rule that would only be fired once for the associated compensation level.

Canadian Implementation Considerations

What Benefit functionality exists for the Canadian Legislation?

OAB was designed to meet global requirements. There are specific local legislative requirements that may not be met, but we haven't planned for localizations, currently, and don't have any Canada-specific functionality.

We have not found anything yet that isn't handled with the standard product. There are some differences between the US and Canada for payroll purposes however. For example:

Imputed Income:

This is a US only requirement. However in Canada, if the employer pays for life insurance coverage, this is considered a taxable benefit. The amount that is taxable is the premium paid by the employer. This can be handled in Canada by setting up a taxable element called Basic Life Taxable Benefit. (Do not use GTL). Then set up the premium, which is employer paid, using the appropriate calculation. Finally set up a rate, even though the EE isn't paying for anything, so that the system will generate the taxable benefit, and reference the element set up earlier.

Imputed Income

Where do I get a list of age rate values?

Internal Revenue Code Section 79

Rates:

You will need to look for the most recent version of Internal Revenue Service REG 209103-89. The uniform premium table is Table 1 of Treas. Reg. Section 1.79-3(d)(2) and was last updated in 1999 (reg-209103-89: Prop Reg Section 1.79-3(d)(2)) - those rates are:

Cost per $1,000 of protection for

5-year age bracket one month

Under 25 $0.05

25 to 29 .06

30 to 34 .08

35 to 39 .09

40 to 44 .10

45 to 49 .15

50 to 54 .23

55 to 59 .43

60 to 64 .66

65 to 69 1.27

70 and above 2.06

Standard Benefits With Advanced Benefits License

Can you define a program with both unrestricted enrollments and regular Life Events?

This is faulty plan design configuration and should never be done. A single compensation object (program or plan not in a program) cannot have both processing models (Unrestricted enrollments and life events) configured.

Please note, you can have both processing models in the same business group, as long as the models are defined for separate compensation objects. For example, perhaps you have a program that uses life events and a 401(k) plan that allows unrestricted enrollments. If the 401(k) plan is outside the program, then both processing models can exist as the compensation objects are independent of each other.

You can also have a program that allows unrestricted enrollments and then another program that uses life events in the same business group. Both programs are independent of each other, even if they both have the same plans inside of them. When a plan is attached to a program it is unique to that program (plan in program id is created) and will use the processing model (business rules) for that particular program.

I am getting ready to migrate from Standard to Advanced Benefits, is there a recommended approach to move from Unrestricted Enrollments to Regular Life Events?

You must turn OFF the ability to allow unrestricted enrollments for a program when you attach a life event to that program. When you begin the transition from the OSB processing model to OAB, create a 'Dummy' life event and attach it to your program and then remove the unrestricted capabilities for that program and its plans.

To process a person, you can then manually give the person the 'Dummy' life event on the Person Life Event form and run the regular life event process (Participation: Life) either in batch or through the Benefit Service Center. Then navigate to the enrollment form and make your elections. When finished, close the life event or schedule the 'Close Enrollment Process' to close the event for you after the enrollment window has ended.

What are the benefits of using a Generic Life Event verses using Unrestricted Enrollments?

The generic life event allows:

1. If a person loses eligibility in another program or miscellaneous plan, it will de-enroll the person because the Participation Process is running and always updates eligibility for everything. Unrestricted will not automatically do this for other comp objects unless you explicitly save the enrollment for that particular comp object. Only the participation process in Life, Selection or Scheduled mode will ever de-enroll someone for OAB (OSB could run the Maintain Participant Eligibility process).

2. Batch capabilities - could be associated to several people during the day, who could process overnight.

3. Use of SSBEN enrollment throughout the year

4. Allow for defaults to be applied after the generic life event is processed, via the default enrollment process.

5. Will only allow elections for those programs in which this life event appears in timing. So it will not re-evaluate election capabilities for plans not in a program (it will check their eligibility but will not allow for enrollments - slightly diff than #1 above).

6. Elections can be made without re-processing as long as the event is open.

7. Can be backed out if processed in error

8. Will not replace the electable choices as unrestricted does, instead, it will create new electable choices each time it processes.

9. Could have different coverage/start and end dates than the Termination, New Hire, or Open life events, if needed.

10. Improves testing time as there are more tools to use to troubleshoot:

a. Can process via batch with audit log on if necessary during testing

b. Can restrict the batch process to only 1 comp object to focus testing in one area

c. Can be used to quickly test coverages, rates, premiums, credits, etc. by overridding eligibility during testing.

_1029766715.doc