Open Enrollment White Paper V 1 7

ORACLE COMPENSATION AND
BENEFITS
OPEN ENROLLMENT
PROCESSING
AND
PLAN DESIGN MAINTENANCE
ORACLE ADVANCED BENEFITS

ORACLE STANDARD BENEFITS
Author: Oracle Support Services
Version: 1.7
Last Updated: July 15, 2011
Updates made to this document made in 2011 have been highlighted in
Green for ease of identification and use.
All Applicable MyOracleSupport Note Numbers are highlighted in blue
for easy reference
Open Enrollment White Paper Page 2 of 91

Contributors
Name Position
Carol Margolis Oracle Support, Senior Analyst

Philip Chapman Oracle Development, Senior Product Manager
Lynda Tollefson Principal Product Manager Total Compensation
Doug Sterchi Oracle Consulting, Principal Consultant
Kathryn Tucker Oracle Consulting, Principal Consultant
Marie Maderis Oracle Support, Support Engineer
Kathy Marlow Oracle Support, Support Engineer
Srilatha Shanigarapu Oracle Support, Principal Technical Support Engineer
David Manoharan
Marce Clarkson
Deborah Clement
Change Record
Date Author Version Change Reference
01-Oct-2011 Carol Margolis 1.0 Creation

23-Aug-05 Kelly McClain 1.1
31-Oct-05 Lynda Tollefson 1.2 Added Reinstatement functionality, default
modifications, period determination codes, mocks
steps, changed mock recommendations.
15-Aug Kelly McCLain, Ashton 1.3 Updated recommended practices for Open
Kawanishi Enrollment life event collapsing. Also added
suggested temporal run set up. Removed Carol
Margoliss name from the point of contact Note, and
replaced with Kelly Mcclain. Made recommendations
on how to update Element links without destroying
database-wide enrollments. Added information
regarding Open Enrollment Window Modification and
Reopen life event batch process.
28-Jul-09 Srilatha Shanigarapu 1.4 Modified the Flow of Document, Added Several New
Sections
29-Aug-2009 Srilatha Shanigarapu 1.5 Added Total Compensation Wizard.
16-Sep-2009 Srilatha Shanigarapu 1.6 Check and Clean Up for Previously Detected
Temporal And Other Life Events
Added Script for identifying pending action
items
12-Oct-2010 Marce Clarkson 1.6 Corrected Run Analyze and Gather Statistics section
15-Jul-2011 Srilatha Shanigarapu 1.7 Review and update of complete document
Approvers
Name Position
Kathryn Tucker Senior Product Manager

Phil Chapman Oracle Development; Senior Product Manager
Lynda Tollefson Principal Product Manager Total Compensation

Feedback
Name Position
Srilatha.Shanigarapu@oracle.com
NOTE: The contents of this document are deemed to be correct and accurate at time of going to
press. If inaccuracies are discovered, contact Srilatha.Shanigarapu@oracle.com. Please also
contact me if you have experiences to share that would fit within the scope of this document.
Guidelines made within this document may not hold true for every Oracle Advanced Benefits or
Oracle Standard Benefits implementation at every site due to the variety of plan designs. The
information must therefore be thoroughly tested.

Table of Contents
Contents
Minimum Baseline Patching Requirement...................................................................8
Requested Information While Logging Service Request with Oracle Support................8
Open Enrollment Processing......................................................................................9
Phases of Open Enrollment Processing.....................................................................11

Sample Timeline For Open Life Event Processing...................................................14
Mock Open Enrollment..........................................................................................17
Self Service Setup for Mock Open Enrollment........................................................18
Using Total Compensation Wizard To Review /Modify and Update Program and Plan
Design................................................................................................................. 19
Check payroll calendar..........................................................................................20
Check plan year periods........................................................................................21
Verifying Plan Year Periods and Complete Plan Design using Total Compensation
Wizard................................................................................................................. 21
Update Plan Year Periods using Total Compensation Wizard...................................22
Add the Scheduled Life Event to the Program........................................................22
Adding Scheduled Life Event to the Program using Total Compensation Wizard.......26
Add Reinstatement Codes to the Scheduled Life Event...........................................27
Assess and Modify Derived Factors and Eligibility..................................................30
Assess and Modify Derived Factors and Eligibility Using Total Compensation Setup
Wizard................................................................................................................. 31
End Existing Plans That Are No Longer Being Offered.............................................31
Ending Existing Plans Using Total Compensation Setup Wizard...............................33
End Existing Options That Are No Longer Being Offered.........................................33
End Existing Options That Are No Longer Being Offered Using Total Compensation
Setup Wizard....................................................................................................... 35
Add New Plans..................................................................................................... 35
Add New Plans/Update Existing Plans Using Total Compensation Setup Wizard.......38
Add New Options to Existing Plans........................................................................38
Add New Options /Update Existing Options Using Total Compensation Setup Wizard39
Check Self Service Display on Plan Type (If using SSBEN).......................................40
Add New Rates to New Comp Objects....................................................................40
Add New Rates to Plans using Total Compensation Setup Wizard............................40
Add Premiums to New Comp Objects.....................................................................40
Modify Rates and Premiums on Existing Comp Objects...........................................41
Check Self Service Display Order on Standard rate (If using SSBEN)........................42
Mass Update of Rates Using Total Compensation Wizard........................................44
Modify Elements on Existing Rates........................................................................45
Modify Links on Existing Elements.........................................................................45
Flex Credits and Benefit Pools...............................................................................46
Review Default Enrollment Setup..........................................................................48
Review Default Enrollment Setup Using Total Compensation Setup Wizard..............48
Start New Coverage for Flexible Spending Accounts (FSA).....................................48
Close Unprocessed Life Events..............................................................................53
Check and Clean Up for Previously Detected Temporal And Other Life Events..........54
Review Due Date Setup for the Action Items and Resolve Any Pending Action items 56
Check for Previously Overridden Data (Enrollment Overrides)................................57

Set Up Collapsing Rules........................................................................................59
Processing Temporal Events..................................................................................61
Purge Batch Related Tables...................................................................................62
Evaluate Size of Eligibility Tables..........................................................................64
Set Max errors..................................................................................................... 65
Performance Testing............................................................................................. 65
Phase II: Open Enrollment procedures.....................................................................69

Process the Open Life Event..................................................................................69
Processing Open Life event for single person from Benefits Service Center.............70
Maintain Participant Eligibility..............................................................................72
Recalculate Participant Values..............................................................................72
Check for Errors and Resolve................................................................................73
Monitor a Started Process.....................................................................................73
Restart a Failed Process.......................................................................................74
Default Enrollment Process...................................................................................74
Enter Participants Enrollment Choices..................................................................76
Processing Life Events That Occur Within the Open Enrollment Period....................78
Back Out the Open Life Event (if needed)..............................................................81
Open Enrollment Window Modification*.................................................................82
Close the Open Life Event.....................................................................................83
Reopen life event batch process*..........................................................................84
Phase III: Post-Open Enrollment procedures............................................................85

Verify Enrollment data (new plans, check defaults and automatic)..........................85
Investigate Incorrect Elections..............................................................................85
Processing Life Events That Occur After the Open Enrollment Period, but Before the
New Plan Year...................................................................................................... 87
Print Enrollment Reports and Confirmation Statements:.........................................89
Inactivate Plans that are no Longer Being offered:.................................................89
Frequently Asked Questions....................................................................................91

Oracle Advanced Benefits (OAB)............................................................................91
Oracle Standard Benefits (OSB).............................................................................95
Questions Applicable to both OAB and OSB............................................................97
Questions applicable to SSBEN..............................................................................98
Appendix of Sample Reports....................................................................................99

Eligibility and Enrollment List...............................................................................99
Life Event Summary Report.................................................................................102
Life Event Summary Report.................................................................................102
Benefits Enrollment Kit Report............................................................................105
Benefits Confirmation and Summary Report.........................................................107
Sample Open Enrollment Checklist OAB................................................................113
Sample Open Enrollment Checklist OSB................................................................116

Minimum Baseline Patching Requirement
Please note that all customers, be they full HR or Shared HR must be up on FP.K RUP3 by Dec. 1,
2010 This is Mandatory. Please refer to MyOracleSupport Document 883202.1 Minimum Baseline
Patch Requirements for Extended Support on Oracle E-Business Suite 11.5.10.
After December 1, 2010 Development requires a minimum baseline patch for Extended Support
on Oracle E-Business Suite 11.5.10, the code levels must be the equivalent of 11.5.10 CU2 plus
any additional patches listed in Doc ID 883202.1 Section 2. More information can be found in E-
Business Suite 11.5.10 Minimum Patch Level and Extended Support Information Center:
Document 1199724.1.
Oracle E-Business Suite Release 12.0 will transition from Premier Support to Extended Support on
February 1, 2012. New EBS 12.0 patches will be created and tested during Extended Support
against the minimum patching baseline documented in this E-Business Suite Error Correction
Support Policy (Note 1195034.1).
To be eligible for Extended Support, all EBS 12.0 customers must apply the EBS 12.0.6 Release
Update Pack, technology stack infrastructure updates, and updates for EBS products if they're
shared or fully-installed. The complete set of minimum EBS 12.0 baseline requirements are listed
in the document. Oracle E-Business Suite Error Correction Support Policy (V.3) (Doc ID 1195034.1)
Requested Information While Logging Service Request with

Oracle Support
It will helpful for support to debug the issues if the following are uploaded to the Service Request
when you are creating one:
1. Screenshots detailing the issue and error message.
2. Out of Benper.sql Instructions for running the script is documented in MyOracleSupport
Note 208923.1 - BENPer.sql. Run this script from SQLPLUS, as the APPS user and password,
and not execute from TOAD or SQL DEVELOPER. The PERSON_ID is the only input value.
The purpose of this script is to collect data for a person's benefits selections and elections.
The input parameter for this script is person_id. Please run this script for the employee
that is receiving the error or encountering a specific issue in the application, and upload
the results to the SR for review.
3. PYUPIP Trace for a Form Error- Please refer to MyOracleSupport Note 160469.1 - R11.5
How to Setup and Run PYUPIP on a Form.
4. PYUPIP trace for a self service issue - Please use MyOracleSupport Note 281071.1 -
Generating PYUPIP Information from a Self Service Type Page (.jsp)
5. PYUPIP trace for concurrent program issues Please use MyOracleSupport Note
130374.1:Using PYUPIP in OracleHRMS
Open Enrollment Processing
A companys open enrollment period is an opportunity for eligible participants to:
Enroll in a plan if not currently enrolled

Change coverage from one plan to another
Change enrollment status of eligible family members
Enroll in dependent care (current enrollees must re-enroll each year)
Enroll in health care reimbursement account (current enrollees must re-enroll each year)
Decline coverages
This period is also the opportunity for a company to:

Update rates and premiums from benefit providers
End the offering of compensation (comp) objects
Start new offerings of comp objects
Modify plan design
There are many procedures that encompass the Open Enrollment process. Such procedures are
included herein for processing benefits using the Oracle Advanced Benefits (OAB) and Oracle
Standard Benefits (OSB) models.
Note: OAB implementations may be running in an Unrestricted (OSB) mode. If this is the case,
ensure that all areas of this document are reviewed and select the areas applicable to your
implementation.
Abbreviations Used in this Document
OAB Oracle Advanced Benefits
OSB Oracle Standard Benefits
SSBen Self-Service Benefits
Comp object Any compensation object (Program, Plan Type, Plan or

Option)
Enrollment form Any of the available enrollment forms: Flex, Non-Flex,

Miscellaneous, Savings Plan
PUI Professional User Interface or Forms
TCW Total Compensation Setup Wizard
Unless noted otherwise by Audience: OAB or Audience: OSB, the procedures included in this
document apply to both benefit models.

Phases of Open Enrollment Processing
Open Enrollment procedures can be divided into three phases:
Pre-Open Enrollment
Open Enrollment
Post-Open Enrollment
Phase Task Audience
Pre-Open
Enrollment
Check Payroll Calendars OAB and OSB
Check Plan Year Periods OAB and OSB
Add the Scheduled Life Event to the OAB
Program
Add Reinstatement Codes to the OAB
Scheduled Life Event
Assess and Modify Derived Factors OAB and OSB
and Eligibility
End Existing Plans That Are No OAB and OSB
Longer Being Offered
Add New Plans to the Programs OAB and OSB
Add New Options to Existing Plans OAB and OSB
Check Self Service Display on Plan OAB and OSB
Type (If using SSBEN)
Add Rates to New Comp Objects OAB and OSB
Add Premiums to New Comp Objects OAB and OSB
Modify Rates and Premiums on OAB and OSB
Existing Comp Objects
Check Self Service Display Order on OAB and OSB
Standard rate (If using SSBEN)
Mass Update of Rates Using Total OAB and OSB
Compensation Wizard
Modify Elements on Existing Rates OAB and OSB
Modify Links on Existing Elements OAB and OSB
Modify Flex Credits and Benefit Pools OAB
Review Default Enrollment Setup OAB
Start New Coverage for Flexible OAB and OSB note the
Spending Accounts (FSA) separate procedures
Close Unprocessed Life Events OAB
OAB
Check and Clean Up for Previously
Detected Temporal And Other Life
Events
Review Due Date Setup for the OAB
Action Items and Resolve Any
Pending Action items
Check for Previously Overriden Data OAB and OSB

(Enrollment Overrides)
Set Up Collapsing Rules OAB
Process Temporal OAB
Mock Open Enrollment OAB and OSB
Purge Batch Related Tables OAB
Set Max Errors OAB and OSB
Evaluate Size of Eligibility Tables OSB
Analyze Performance OAB and OSB
Open Process the Open Life Event (Batch OAB

Enrollment Process)
Maintain Participant Eligibility OSB
Recalculate Participant Values OSB
Check for Errors and Resolve OAB and OSB
Monitor a Started Process
Restart a Failed Process

Run Default Enrollment Process OAB
Enter Participants Enrollment OAB and OSB
Choices
Processing Life Events That Occur OAB and OSB (note the
Within the Open Enrollment Period separate procedures)
Open Enrollment Window OAB
Modification*(If Needed)
Back Out the Open Life Event (if OAB and OSB (note the
needed) separate procedures)
Close the Open Life Event OAB
Post-Open
Enrollment
Verify enrollment OAB and OSB
Investigate and Correct Elections OAB and OSB
Process Events That Occur After the OAB and OSB (note the
Open Enrollment Period, but Before separate procedures)
the New Plan Year
Inactivate Plans that are no Longer OAB and OSB
being offered
Print Enrollment Reports OAB and OSB
Important!
It is recommended that All 3 phases of Open Enrollment Processing (Viz., Pre-Open, Enrollment
and post-Open) should be thoroughly tested during Mock open enrollment. Mock Open
Enrollment should be performed in the latest copy of production at least 2 months before
actual open enrollment.

In the cases where it is needed to add new compensation objects to current plan design
(like adding new plans or new options), it is recommended that the plan design, the
eligibility and enrollment is tested at least 3 months before actual open enrollment.
Also, it is very important to test performance of Concurrent Processes, PUI and self-
service during mock open enrollment by running open enrollment on entire population.
All recommended patches have to applied and tested during mock open enrollment and
make sure all the functionality is working as expected.
MyOracleSupport Note 124100.1 - Compensation and Benefits Patch List
The procedures discussed within this document have been based on the following:
Open Enrollment elections are effective on January 1.
Open Enrollment and Programs & Plans are based on Calendar Year
Coverage begins on January 1
Rates begin on January 1.
In this regard, the Coverage and Rate Start/End Codes are:

Event and One Day before Event.
Therefore, if your companys Open Enrollment is effective on any other date within the year, or
you are utilizing other Coverage and Rate Start/End Codes to meet your business requirements,
thoroughly test the Open Enrollment procedures using your companys setup.
MyOracleSupport Note 247317.1 Oracle Applications HRMS Compatible Start and End Date
Codes provides the compatible start and end date codes for Enrollment, Rates and Coverages.
Sample Timeline For Open Life Event Processing
Audience: OAB
This sample timeline will be used in the next step of the Pre-Open Enrollment phase. Your
dates/timeframe may be different than the scenario listed. The Following is a sample OE
for benefits to start Jan. 01 of following of next year.
October (Two months before actual open enrollment)

Complete Pre-Open Enrollment procedures
Run a Mock open enrollment
Timeframe: Two months before actual open enrollment and after plan design
changes are completed and tested.

Also testing performance and self service during mock open enrollment
Check the Recommended patch list for any recommended or mandatory patches
for open enrollment MyOracleSupport Note 124100.1
01-Nov
Open Life Event is run (Participation Process: Scheduled) on 01-Nov
01-Nov
Defaults are applied (Default Enrollment Process)
02-Nov
Benefits Enrollment letters are sent to all participants notifying them of what they are
eligible for and showing their current elections that they will default into unless they
indicate the desired changes.
Throughout November
Elections are entered via Self Service Benefits or Enrollment Forms
02-Dec
Confirmation letters are sent to all participants.
Participants who made explicit elections will get confirmation of these elections.
Participants who did not respond or did not enroll in Self Service Benefits will be defaulted
into their current enrollment (if plan design designates this) and may get a printed
confirmation.
15-Dec
Run the Close Enrollment Process to close all elections.
In between 02-Dec and 15-Dec, benefit administrators may still enter elections as needed by date
tracking into the enrollment window (such as 30-Nov).
Audience: OSB
October
Complete Pre-Open Enrollment procedures
Throughout November
Elections are entered via Self Service Benefits or Enrollment Forms
December
Confirmation letters are sent to all participants.

Mock Open Enrollment
(Important!!! It is very important to test all 3 phases of Open enrollment During Mock Open
Enrollment i.e
Pre-Open Enrollment Procedures
Open enrollment Procedures
Post Open Enrollment Procedures )
Timeframe: At least Two months before actual Open Enrollment after plan design
changes are completed
The recommendation is for all open enrollments using OAB or OSB, to run Open Enrollment in a
mock, or test, mode for the entire participant population. You may choose to run a sample of
participants that will contain all scenarios that could occur, but in this case you will not benefit
from a full performance test run. Mock open will help your resolve errors in design, setup, self-
service, and performance long before the official open enrollment begins. Not doing so will defer
issue resolution to the official open enrolment period that may cause interruption in business
critical processes.
This mock enrollment offers the ability to:

Resolve any plan design issues;
Resolve any specific participant errors;
Understand the timing of the steps involved with Open Enrollment
Understand the processes and procedures involved;
Verify that Open Enrollment is offering the correct electable choices;
Verify that Self Service Benefits is set up correctly for employee enrollments;
Ensure that peak performance is being achieved in forms, processes, and self
service
Create a plan for processing considering schedules of other integrated products.
I.e.) payroll processing, segregating batches
Anticipate other life events that will be occurring during Open Enrollment and
understand their usage, frequency, and nature. Create a plan to handle these
during open period
Anticipate any issues that will occur with the actual Open Enrollment(Rates, plans,
options, etc)
Anticipate and Resolve any issues that may occur during the post-open enrollment
ahead of time.
Copy the instance with all of the Pre-Open Enrollment setup into an instance closely
resembling production server for testing purposes. Then follow all the procedures
contained under Phase II: and Phase III of Open Enrollment procedures.
Self Service Setup for Mock Open Enrollment

It is very important to test open enrollment from self-service side thoroughly if you are going to
use self-service benefits for enrollment. This will help your resolve errors in design, setup via self-
issue resolution to the official open enrolment period that may cause interruption in business
critical processes.
It is very important to verify that Self Service Benefits is set up correctly for employee
enrollments.

OAB Customers:
For Mock Open enrollment purpose you can enable the date Tracking in SSBEN to test the open
enrollment. This has to be done in Test instance only , never enable session date in Production
instance.
Please refer to MyOracleSupport Note.270670.1 -In Self Service Benefits (SSBEN) How To Enable
The Session Date
OSB Customers:
Customers using unrestricted enrollment can enable the Benefits Selection page in self-service
from Nov 1 to Nov 30 and set the Change Session Date menu parameter to Jan 1 so all changes
made during
Nov 1 and Nov 30 have a life event occurred on date of Jan 1. If an employee goes into self-
service on Nov 15 and makes a change, the life vent occurred on date will be Jan 1. If the
employee then returns to
self-service on Nov 16 and makes another change, the first change will be lost and the new
change will also have a life event occurred on date of Jan 1. Without setting the Change Session
Date, the first life event
occurred on date would be Nov 15 and the second would be Nov 16. Please refer to Implementing
Oracle SSHR 4.2 (9/02) Chapter 17 for instructions on how to set the Change Session Date
parameter.
MyOracleSupport Note: 211557.1 Implementing Oracle Self-Service Human Resources (SSHR)

4.2
Refer to Chapter 17 for the setup of Self-Service Benefits
MyOracleSupport Note:215159.1 Self-Service Benefits Enrollment with Standard and

Advanced Benefits. Key sections include:
MyOracleSupport Note.228543.1 - How To Date Track In Self Service Benefits:

Using Total Compensation Wizard To Review /Modify and Update
Program and Plan Design
Using the Total Compensation Wizard, changes to program setup can be made as part of a single process.
The changes can be made and saved for later with a final review before submission to the data base. In this
document we have provided few sections where you can use Total Compensation Setup Wizard to Review and
modify the program/plan design.
Total Compensation Wizard provides you ability to:

Review Program Details
Review Program and Plan Years
Create and Add New Plans to Existing Program
Create and Add New Options to Existing Plans
Create and Add New Rates to New or Existing Compensation Objects
Create and Add New Coverage to Compensation Objects
End existing plans that are no longer being offerred
Review, Modify and Add Enrollment Requirements
Review, Modify and Add Default Enrollment Requirements
Review, Modify and Add Eligibility Profiles
There are 7 Tasks available to peform the above-mentioned actions:

Task#1 Program Details
Task#2 Plans and Options
Task#3 Enrollment Timing
Task#4 Enrollment Requirements
Task#5 Eligibility
Task#6 Default Enrollment
Task#7 Review and Submit
Note 330033.1 outlines the details of each task.

Also for the customers above Family Pack K Rup1 the name has been changed from Plan Design
Wizard to Total Compensation Setup Wizard (refer to Note 382640.1)
Phase I: Pre-Open Enrollment Procedures

Timeframe: One to two months prior to actual Open Enrollment.
Check payroll calendar
Ensure that the payroll periods extend through the entire New Year.

Navigation: Payroll > Description
Refer to MyOracleSupport Note: 105642.1 How to Extend Payroll Calendar Periods
Note: If your payroll calendars include Weekly and Bi-Weekly periods, you may find that every
few years there is an extra pay period. For example, your bi-weekly payroll consists of 26 pay
periods, but in 2012 there are actually 27 pay periods.
If your Programs Enrollment/Rate Frequency is set to Per Pay Period, this will use the actual
number of payroll periods (27). This may be changed to Estimated Per Pay Period to only use
26 pay periods (or 52 in the case of weekly payrolls).
Scenario:
What would happen if the payroll calendars were not kept up to date or extended?
Rates would not calculate correctly, and deductions could be incorrect.

The payroll calendar would need to be extended, and then reprocess open afterwards.
See Questions Applicable to both OAB and OSB for further information.
Check plan year periods
Ensure that the plan year periods are correct on each plan and program.
Recommendation: Plan year periods exist for the next five years.
If the plan year periods were not extended, both plans and programs will not appear.
Extend the plan year periods, and then reprocess open.
Step 1:
Navigation: Total Compensation > General Definitions > Additional Setup > Program/Plan Years.
Ensure that a plan year exists for the new year (example: Start Date 01-Jan-2012, End Date 31-
Dec-2012).
Step 2:
Check that all active programs have this New Year.
Navigation: Total Compensation > Programs and Plans > Programs > Periods tab.
Step 3:
Check that all active plans have this New Year.
Navigation: Total Compensation > Programs and Plans > Plans > Details button.
Verifying Plan Year Periods and Complete Plan Design using Total
Compensation Wizard
Using the Total Compensation Wizard you can verify the program setup and plan year periods.
To view the plan years (and other existing setup):
Navigation: Total Compensation > Total Compensation Setup Wizard
Business Area: Health and Welfare Program

Task: View Plan Design
Search by Program

Select Program you want to verify and continue
Expand the Year Periods under Programto view periods associated with Program
Under Program, expand Plans and under each plan expand Year Periods to verify periods associated with each
plan.
Using the same process you can verify the complete Program and Plan Design by expanding each section.
Update Plan Year Periods using Total Compensation Wizard

Using the Total Compensation Wizard, changes to program setup can be made as part of a single
process.
The changes can be made and saved for later with a final review before submission to the
database.

Task: Update a Health and Welfare Program
Enter the Process Name (eg. Change Plan Years)
Effective Date: 01-JAN-2012
Select the Program Name
Select the Appropriate Date Track Mode (in this example Choose the Date Track Mode as Make
changes from effective date onwards since you need to update the plan years)
Choose Appropriate Plan Design Data Copy mode
Click continue
Click On Update Button Under the Program Details Section
Scroll Down to the Area Program and Plan Years
Enter Start of First Year
Enter End of First Year
Also you can enter value in How Many Additional Years
Click Go
Apply the Changes
Submit the Changes in the Next Page
For more information please refer to Roadmap to the Benefits Program Business Area of the Plan Design Wizard
(Doc ID 330033.1)
Add the Scheduled Life Event to the Program
The Open life event must be added to the Program (and any Plans Not in Program that go through
an annual enrollment) with the important dates and enrollment codes for processing.
Audience: OAB
Open Life Event: Processing Dates
Navigation: Total Compensation > Programs and Plans > Program Enrollment Requirements >
Timing > Scheduled > General dropdown box

Enrollment Type: Open
Enrollment or Availability Period: Add your Open Enrollment period.

Example: 01-Nov-2011 to 30-Nov-2011
Assigned Life Event Date: 01-Jan-2012* (see note below)

Defaults Will be Assigned on: 01-Nov-2011**** (See Note Below)
No further processing is allowed after: 15-Dec-2011
Close Enrollment Date to Use: Processing End Date ** (see note below)
Year Period: 01-JAN-2012 to 31-DEC-2012
Period Determination Code: Recommended code: Later of Enrollment Period Start
Date or Future Enrollments Start Date.*** (see note
below)
Notes
*The Assigned Life Event date is important for the consideration of derived factors, such as
imputed income. For imputed income in the United States, the participants age is calculated as
of the end of the current year. So for 2012, the participants age is calculated as of 31-Dec-2012.
If the Assigned Life Event is in late December of 2011 for the 2012 plan year, the persons age will
be calculated as of 31-Dec-2011, which will be incorrect for imputed income purposes.
**Close Enrollment Date to Use: May be set to Processing End Date when there is a time
between the end of the participants enrollment period and the date of the life event (01-Jan).
This allows adjustments to be made before the life event is closed. May also be set to When
Enrollment Period Ends when there are no additional processing days.
*** Period Determination Code: Although Using this code is optional oracle recommends using
code which is suitable for your business requirement. Using this code You can configure how
enrollment periods are determined when an event is backed-out and reprocessed, or when the
event occurs within the enrollment window of another life event. This code enables you to enforce
business rules around the dates on which elections can be made by the participant when colliding
events take place, or an event is backed-out and reprocessed.
See MyOracleSupport Note : 316723.1. After a Life Event is Backed Out, Why is the Enrollment
Period Changed? Or
MyOracleSupport Note 285137.1 - 11.5.10 New Functionality Support Quick Reference -
Determine Enrollment Periods for OAB Life Events for further detail.
Recommended code: Later of Enrollment Period Start Date or Future Enrollments Start Date.
***** Defaults Will be Assigned on:

For Advanced Benefits users, enter a Defaults Will be Assigned on date to specify the date on
which default benefits assignments are made when participants fail to make their choices as part
of this scheduled enrollment. Oracle recommendation is to use First Day of Enrollment Period as
Defaults to assign Date.
***** No further processing is allowed after:

Choose a No Further Processing is Allowed After date to specify the latest date on which the plan
sponsor can apply elections applicable to this enrollment period.

Open Life Event: Coverage and Rate Dates
Navigation: Total Compensation > Programs and Plans > Program Enrollment Requirements >
Timing > Scheduled >
Coverage dropdown box:
Enrollment Coverage Start Date: As of Event Date

Enrollment Coverage End Date: One Day before Event
Rate dropdown box:

Enrollment Rate Start Date: As of Event Date
Enrollment Rate End Date: One Day before Event
Select the codes that meet your business requirements. Note that if running the Open life event
in November for the new January 1 plan year, the Coverage and Rate Start Date Codes can be As
of Event Date. This will use the Life Event Occurred On Date and start coverage and rates on
January 1, if this meets your business requirement.
MyOracleSupport Note 247317.1 Oracle Applications HRMS Compatible Start and End Date
Codes provides the compatible start and end date codes for Enrollment, Rates and Coverages.

Open Life Event: Enrollment Codes
Navigation: Program Enrollment Requirements > Life Event > Program (or Plan Type or Plan) >
Enrollment dropdown box.
Add the Open life event and any desired Enrollment codes.
For example:
Method: Explicit
Enrollment Code: Current, Can Keep or Choose; New, Can Choose
Default Enrollment: New, Defaults; Current, Same Enrollment and Rates
MyOracleSupport Note 455664.1 - Do the Codes Set at Plan Enrollment Requirements

Override Those Set at Program Enrollment Requirements?
Adding Scheduled Life Event to the Program using Total

Compensation Wizard
Using the Total Compensation Wizard you can add the scheduled Life events Such as Open and
Administrative all the changes to program setup can be made as part of a single process.
The changes can be made and saved for later with a final review before submission to the
database.

Task : Update a Health and Welfare Program
Enter the Process Name (eg. Add Scheduled Life Event)
Effective Date: 01-JAN-2012
Select the Program Name
Select the Appropriate Date Track Mode (in this example Choose the Date Track Mode as Make
changes from effective date onwards since you need to update the program enrollment
requirements)
Choose Appropriate Plan Design Data Copy mode
Click continue
Click on Go To Task List
Select the Task Enrollment Timing
Click on Add Scheduling Requirements Under Open Enrollment Region
Add Information in the fields:
Enrollment Period Start Date (Eg. 01-NOV-2011)
Enrollment Period End Date (Eg. 30-NOV-2011)
Plan Year Period (01-JAN-2012 to 31-DEC-2012)
Assigned Life Event Occurred Date (01-JAN-2012)
Choose Close Enrollment Period Code
Assign Defaults Date
Click on Save for Later or Click on Next Task
You can Add the Coverage / Rate Start and end dates by Going to the Area Coverages and Rates
on the Review Page.

For Information Please refer to Note 330033.1 - Roadmap to the Benefits Program Business Area
of the Plan
Design Wizard
Add Reinstatement Codes to the Scheduled Life Event
Audience: OAB ONLY
Attention: Enrollments will not be re-instated if the life event is backed out with
Voided Status. Reinstatement will only work only if the life event was backed out
with Unprocessed Status.
Reinstatement codes were delivered that handle back outs and reinstating elections
(MyOracleSupport Note 333568.1 Reinstatement Functionality Family Pack K and Above). For
the Open life event you may want to configure reinstatement codes so that if open enrolment
event gets backed out i.e.) due to rate change any elections that were made can be reinstated.
You can add codes to Program Enrollment Requirements as well as the Plan Enrollment
Requirements for Plans Not in Program that go through an annual enrollment.
The codes are:
Reinstate all if no electability change for life event
Reinstate if no change for backed out enrollment
Reinstate if electability exists for backed out result
Never Reinstate
Always use overridden rates
Override the rates if no change
1. Reinstate all if no electability change for life event: (default value if no

reinstatement code was choosen)
This code reinstates elections if the application detects no change to a persons electability
when you back out and reprocess a life event. This is how the system currently handles
reinstatement. The Participation Process compares all programs and plans not in program
that are processed as part of the life event and reinstates elections only if the electability
of ALL compensation objects is identical between the backed out and reprocessed event
(i.e. rates, benefit amounts, dates).
2. Reinstate if no change for the backed out enrollment.
This code reinstates elections if the person maintains electability for the backed out
elections, provided that activity rates, coverage amounts, and dependent designation
information has not changed based on the new life event. With this reinstatement code,
the Participation Process reinstates elections if the person has an electable choice and the
backed out and current election data are identical. This code only validates against the
participants original elections and does not reference the other electable choices for the

life event, unlike the Reinstate all if no electability change for life event code where the
application validates all electable choices.
3. Reinstate if electability exists for the backed out result
This code reinstates elections if the person maintains electability for the backed out
enrollment results, even if activity rates, coverage amounts, and dependent designations
change when you process the subsequent life event.
4. Never Reinstate
This code indicates that the Participation Process should never reinstate backed out
enrollment results.
5. Override the rates if no change (Default Code if no Override Code was Chosen)
This code reinstates any overridden data from backed out results only if there is no change
in the backed out and current electable choice data. For example, a benefits administrator
processes an election and overrides the activity rate, then backs out the enrollment result.
If the enrollment rate for the reprocessed life event is different than the rate for the backed
out life event, the Participation Process reinstates the election using the newly calculated
enrollment rate and ignores the overridden value. If there is no change in the data, the
Participation Process reinstates the prior election and applies the override value.
6. Always use overridden rates
This code reinstates any overridden data from backed out enrollment results even if there
is a change in the backed out and current electable choice data. For example, a benefits
administrator processes an election and overrides the activity rate, then backs out the
enrollment result. When you reprocess the backed out event, the Participation Process
reinstates the election using the newly calculated enrollment rate, then applies the
overridden value.

Open Life Event: Reinstatement Codes
Navigation: Total Compensation > Programs and Plans > Program Enrollment or Plan Enrollment
Requirements > Timing > Scheduled > General drop down box-> Reinstatement
Reinstatement Code:
Select the codes that meet your business requirements by reviewing the whitepaper note below
from MyOracleSupport Webite.
For example:
Reinstatement Code: Reinstate if electability exists for the backed out result
Notes
*Reinstatement codes are not required. If you do not configure the reinstatement code it will
default Reinstate all if no electability change for life event which means if there is any
change in electable choices for that life event the elections will not be reinstated. Please refer to
white paper published on MyOracleSupport - Note 333568.1 Reinstatement
Functionality.
Assess and Modify Derived Factors and Eligibility
Open Enrollment is an excellent time to assess all derived factors to ensure that any new factors
are added; any existing factors are modified if necessary, and that the determination codes are
correct.
For example:
Length of service may have new requirements
Spousal and/or Child Life may be new benefit offerings and will need Age factors created.
Navigation: Total Compensation > General Definitions > Eligibility/Rate Factors > Derived Factors
This is also an ideal time to assess current eligibility to ensure that participants are eligible for the
correct comp objects.
For example:
If many Participation Overrides are manually being done, review the eligibility profiles for the
comp objects being overridden.
If service areas are changing, modify the existing zip codes and/or service areas accordingly.
Navigation:
Total Compensation > General Definitions > Eligibility/Rate Factors
Total Compensation > General Definitions > Eligibility Profiles

Assess and Modify Derived Factors and Eligibility Using Total
Compensation Setup Wizard
You can define and attach eligibility profiles to a compensation object to restrict participant eligibility using the
total compensation setup wizard Task#4 Eligibility

Business Area: Health and Welfare Program > Update a Health and Welfare Program
Select the Task #4 Eligibility
Specify the level to which you will attach eligibility profiles (Program, Plantype in Program, Plan in Program,
Plan and Option in Plan)
Either Select existing Profile to view and Update or create and add a entirely New Profile.
For more Information Please refer to Note 330033.1 - Roadmap to the Benefits Program Business
Area of the Plan Design Wizard
End Existing Plans That Are No Longer Being Offered
Plans that will not be offered in the new plan year need to be modified so that a participants
enrollment is ended, and no new enrollments are made into this plan.
Procedure A:
Add an eligibility profile to this plan that no participant will meet (example: create a Benefits
Group of No Longer Offered, attach this to the Plan as of the first day of the new plan year. This
may also be attached to a Plan in Program, in the event that a plan is no longer being offered in
one program, but not another.
Example:
1.Date-track to the first day of your plan design to create the eligibility profile.
2.Navigation: Total Compensation >Eligibility/Rate Factors >Benefits Group.
3.Create a new benefits group (example: No Longer Offered)
4. Total Compensation > Eligibility Profiles > Participant
5.Create a new eligibility profile. Add the benefits group under the Other tab.
6.Date-track to the first day of your new plan year (01-Jan-2012)
7.Navigation:Total Compensation > Programs and Plans > Plans > Query the plan >
Plan Eligibility button > Eligibility button > add the name of the eligibility profile created above.
When prompted, save as an Update, not a Correction.
(Note: If using a Coverage or Rate End Date Code of 1 Prior or Event, then date-track to 31-
Dec-2011 to perform the above step. The date to use will depend upon a companys plan design
and must be thoroughly tested.)
OAB: The Open Life Event will recognize that participants will not be eligible, and will end their
coverage.
OSB: Eligibility will be evaluated if the Non-Flex form is opened on 01-Jan-2012 and the
participant will be found ineligible. Another choice is to run the Maintain Participant Eligibility
process on 01-Jan-2012 and this will also find the participant ineligible for this comp object and
coverage will cease. Coverage and Rates (and thus element entries) will end based on the plan
design setup for Coverage End Date and Rate End Date.

Procedure B: You may also use an Enrollment Code of Current Lose Only; New Nothing. This
code can be placed on the Program Enrollment Requirements > General > Plan level with a date
track date of 01-Jan-2012. When the Open life event is processed, all current participants will be
de-enrolled and no new participants will be allowed to make elections into this plan.
Once all participants have been de-enrolled from the plan, set the plan status to Inactive.
(Please refer to Post Open Enrollment Steps Inactivating Plans that are no longer being offered
Section)
The Following script can be used during Mock Open enrollment and while performing Post Open
Enrollment to confirm that all the enrollments are ended before inactivating the plan.
Select * from ben_prtt_enrt_rslt_f

Where enrt_cvg_thru_dt = 31-Dec-4712
And pl_id = <enter pl_id>;
(It should return no rows)
Or
You may run the Eligibility and Enrollment List report to see who is enrolled in a particular plan.
Important!! : Please review the section Review Default Enrollment

Setup
if you are moving the existing enrollments into new plans/options
before end dating any existing plans/options.
Ending Existing Plans Using Total Compensation Setup Wizard

You can also use TCW to End Existing Plans That Are No Longer Being Offered. You Can Select Task
2-Plans and Options - to change status of existing plans and Options after all the de-enrollments
are done Or if you want to use Eligibility method you can use Task 4-Eligibility to modify eligibility.

Setup
End Existing Options That Are No Longer Being Offered

Options that will not be offered in the new plan year need to be modified so that a participants
enrollment is ended, and no new enrollments are made into this option.
Procedure A:
Add an eligibility profile to this option in plan that no participant will meet (example: create a
Benefits Group of No Longer Offered, attach this to the Plan as of the first day of the new plan
year.
Example:
1.Date-track to the first day of your plan design to create the eligibility profile.
2.Navigation: Total Compensation >Eligibility/Rate Factors >Benefits Group.
3.Create a new benefits group (example: No Longer Offered)

5.Create a new eligibility profile. Add the benefits group under the Other tab.
6.Date-track to the first day of your new plan year (01-Jan-2012)
7.Navigation:Total Compensation > Programs and Plans > Plans> Options > Option Eligibility
button > Eligibility button > add the name of the eligibility profile created above. When
prompted, save as an Update, not a Correction.
(Note: If using a Coverage or Rate End Date Code of 1 Prior or Event, then date-track to 31-
Dec-2011 to perform the above step. The date to use will depend upon a companys plan design
and must be thoroughly tested.)
OAB: The Open Life Event will recognize that participants will not be eligible, and will end their
coverage.
OSB: Eligibility will be evaluated if the Non-Flex form is opened on 01-Jan-2012 and the
participant will be found ineligible. Another choice is to run the Maintain Participant Eligibility
process on 01-Jan-2012 and this will also find the participant ineligible for this comp object and
coverage will cease. Coverage and Rates (and thus element entries) will end based on the plan
design setup for Coverage End Date and Rate End Date.
Procedure B: You may also use an Enrollment Code of Current Lose Only; New Nothing. This
code can be placed on the Plan Enrollment Requirements > General > Option level with a date
track date of 01-Jan-2012. When the Open life event is processed, all current participants will be
de-enrolled and no new participants will be allowed to make elections into this option.
Once all participants have been de-enrolled from the option, set the option status to Inactive.
(Please refer to Post Open Enrollment Steps Inactivating Options that are no longer being offered
Section)
The Following script can be used during Mock Open enrollment and while performing Post Open
Enrollment to confirm that all the enrollments are ended before inactivating the option in plan.
***Select * from ben_prtt_enrt_rslt_f

And pl_id = <enter pl_id>
and oipl_id = 'Enter option in plan id ';
(It should return no rows)

Setup
End Existing Options That Are No Longer Being Offered Using Total
You can also use TCW to End Existing Option in plans That Are No Longer Being Offered. You Can
Select Task 2-Plans and Options - to change status of existing plans and Options after all the de-
enrollments are done Or if you want to use Eligibility method you can use Task 4-Eligibility to
modify eligibility.

Setup

Add New Plans
Plans must be active on the first day of the enrollment period (not the first day of the new plan
year) for an event in order to be eligible for election. Therefore, if participants are able to enroll in
a new plan on a date before the plan actually becomes effective, these steps must be followed.
For example:
Plan Year = Calendar Year

Open enrollment = 01-Nov-2011 to 30-Nov-2011
Open life events Occurred On date (event date) = 01-Jan-2012
If a plan is new for the 2012 Plan Year, you cannot add the plan to the Program effective 01-Jan-
2012. The plan will not show up in the list of values (LOV) on any enrollment form. Rather, using
the example above, the plan must be active as of 01-Nov-2011 at a minimum (preferably 01-Jan-
2011 or the beginning date of your plan design (01-Jan-1951) to be considered for the 2012 Plan
Year.
Procedure to add a new plan to a program for the upcoming plan year:
Procedure A: (Recommended)
If you are on HRMS FP K or higher, you may perform the following steps to add new Plan for
upcoming open enrollment:
1. Navigate to Total Compensation > Programs and Plans > Plan form.
Date-track to the beginning of the plan year prior to the plan year in
which the plan become effective (i.e., plan becomes effective
01-Jan-2012, then date track to 01-Jan-2011 to add the plan).
2. Create the new plan with a status of Active.
3. Add Plan Years (Plan > Details) and begin with the new plan year.
(Example: if the new plan is effective 01-Jan-2012, the first plan year
attached to the plan should be 01-Jan-2012 -> 31-Dec-2012.)
4. Navigate to the Total Compensation > Programs and Plans > Program
form. Attach the new plan (and plan type if this is also newly-created)
to the Program (under the Program > Plans and Plan Types button) as of
the first day of the plan year(1-Jan-2011) and attach it in Active status.
Repeat this step for each program that the plan is being added to.
If setting this Plan as Not in Program, this step is not necessary.
5. If OSB, navigate to the Total Compensation > Programs and Plans >
Program Enrollment Requirements form > Plan tab. Select the newly added plan(s). Check
the box for Allows Unrestricted Enrollment. Save.
Procedure B:

1. Navigate to Total Compensation > Programs and Plans > Plan form. Date-track to the
beginning of the plan year prior to the plan year in which the plan become effective (i.e.,
plan becomes effective 01-Jan-2012, then date track to 01-Jan-2011 to add the plan).
2. Create the new plan with a status of Pending.
3. Add Plan Years (Plan > Details) and begin with the first plan year prior to the new plan
year. (Example: if the new plan is effective 01-Jan-2012, the first plan year attached to the
plan should be 01-Jan-2011 -> 31-Dec-2011.) Note: If you are creating the plan as of 01-
Nov-2011, you will not see the 2011 plan year available on this Details form. In this case,
begin with selecting the 2012 plan year period.
4. Navigate to the Total Compensation > Programs and Plans > Program form. Attach the
new plan (and plan type if this is also newly-created) to the Program (under the Program >
Plans and Plan Types button) as of the first day of the plan year prior to it becoming
effective (i.e., 01-Jan-2011) and attach it in Pending status.
Repeat this step for each program that the plan is being added to.
If setting this Plan as Not in Program, this step is not necessary.
5. If OSB, navigate to the Total Compensation > Programs and Plans > Program Enrollment
Requirements form > Plan tab. Select the new plan added. Check the box for Allows
Unrestricted Enrollment. Save.
6. The Pending status should be changed to Active as an update on 01-Jan-2012. This

should be done before Open Enrollment is started, so that the plan will be available in the
list of electable choices for a participant to choose. So add the plan as Pending, then
immediately date-track forward to 01-Jan-2012 and make an Update to Active.
Also do the same for the navigation in Step 4, setting the Plan to Active in each program
that it is attached to. Save as an Update.
Procedure C:
1. Navigate to Total Compensation > Programs and Plans > Plan form.
2. Date-track to the beginning of the plan year prior to the plan year in which the plan
become effective (i.e., plan becomes effective 01-Jan-2012, then date track to 01-Jan-2011
to add the plan).
3. Create the new plan with a status of Active.
4. Add Plan Years (Plan > Details) and begin with the first plan year prior to the new plan
year. (Example: if the new plan is effective 01-Jan-2012, the first plan year attached to the
plan should be 01-Jan-2011 -> 31-Dec-2011.) Note: If you are creating the plan as of 01-
Nov-2011, you will not see the 2011 plan year available on this Details form. In this case,
begin with selecting the 2012 plan year period.
5. Add an eligibility profile to the plan (on 01-Jan-2011) that no participant will satisfy until
the time of open enrollment.
6. Date-track to the first day of your plan design to create the eligibility profile.
7. Navigation: Total Compensation >Eligibility/Rate Factors >Benefits Group.
8. Create a new benefits group (example: Inactive)
10.Create a new eligibility profile. Add the benefits group under the Other tab
11.Date track to 01-JAN-2011 or the Plan Creation Date and Navigate to the Total
Compensation > Programs and Plans > Plan > Eligibility > Eligibility form. Attach the
Eligibility profile which you have created above.

12.Navigate to the Total Compensation > Programs and Plans > Program form. Attach the new
plan (and plan type if this is also newly-created) to the Program (under the Program >
Plans and Plan Types button) as of the first day of the plan year(1-Jan-2011) and attach it
in Active status.
13.Date-track to 01-Jan-2012 and Delete the eligibility profile that was added earlier on Plan
eligibility form and Save as an Update.
Add New Plans/Update Existing Plans Using Total Compensation

Setup Wizard
You can Add New Plans using TCW > Update a Health and Welfare Program> Task 2-Plans and
Options Create plan with an effective date of 01-jan-2011
Or If you want to make any modifications to existing plans you can use TCW > update a Health
and Welfare Program with an effective date of 01-jan-2012.
Add New Options to Existing Plans
If a new Option is being added to an existing Plan, You can use Procedure A or Procedure B :
Procedure A: (Recommended)
1. Navigate to Total Compensation > Programs and Plans > Options form. Date-track to the
beginning of the year prior to the year in which the Option become effective (i.e., option
becomes effective 01-Jan-2012, then date track to 01-Jan-2011 to create new option).
2. Create the new Option.
3. Navigate to the Total Compensation > Programs and Plans > Plan > Options form. Attach
the new Option to the Plan as of the first day of the plan year prior to it becoming
effective (i.e., 01-Jan-2011) and attach it in Pending status.
Repeat this step for each Option that has to be added.
4. The Pending status should be changed to Active as an update on 01-Jan-2012. This

should be done before Open Enrollment is started, so that the plan will be available in the
list of electable choices for a participant to choose. So add the Option as Pending, then
immediately date-track forward to 01-Jan-2012 and make an Update to Active.
Also do the same for the navigation in Step 4, setting the Option to Active in each Plan
that it is attached to. Save as an Update.
Procedure B:
1. Navigate to Total Compensation > Programs and Plans > Option form.
2. Date-track to the beginning of the plan year prior to the plan year in which the plan
become effective (i.e., plan becomes effective 01-Jan-2012, then date track to 01-Jan-2011
to add the plan).
3. Create the new Option.
4. Navigate to the Total Compensation > Programs and Plans > Plan > Options form. Attach
the new Option to the Plan as of the first day of the plan year prior to it becoming
effective (i.e., 01-Jan-2011) and attach it in Active status
5. Add an eligibility profile to the option in plan (on 01-Jan-2011) that no participant will
satisfy until the time of Open Enrollment.

6. Date-track to the first day of your plan design to create the eligibility profile.
7. Navigation: Total Compensation >Eligibility/Rate Factors >Benefits Group.
8. Create a new benefits group (example: Inactive)
10.Create a new eligibility profile. Add the benefits group under the Other tab
11.Navigate to the Total Compensation > Programs and Plans > Plan > Option > Option
Eligibility > Eligibility form. Attach the Eligibility profile that you have created above.
12.Date-track to 01-Jan-2012 and Delete the eligibility profile that was added earlier and
Save as an Update.
Add New Options /Update Existing Options Using Total

You can Add New Options using TCW > Update a Health and Welfare Program> Task 2-Plans and
Options Create Option with an effective date of 01-jan-2011
Or If you want to make any modifications to existing options you can use TCW > update a Health
and Welfare Program with an effective date of 01-jan-2012.
Check Self Service Display on Plan Type (If using SSBEN)

Navigation: Total Compensation > Programs and Plans >Program Enrollment Requirements
>General >Plan Type
Set it to vertical or horizontal depending on the plan design and business requirements. The
default self-service display if nothing is chosen is Horizontal. Review the self service display order
on the standard rates when any change is made to the plan type self service display
Add New Rates to New Comp Objects
Navigation: Total Compensation > Rate/Coverage Definitions > Standard Rates

Navigation: Total Compensation > Rate/Coverage Definitions > Variable Rates
New Standard Rates and variable rates have to be created / added with the same date as the New
Compensation object start date (Program or plan or option) For example, in the above sections
the New Plan and New Options are added as of 01-JAN-2011, so the standard rate and variable
rates have to be added with the same date i.e. 01-JAN-2011.
To verify the rates, run the Benefit Confirmation and Summary Report.
You can only verify the rates AFTER open has been run.
Add New Rates to Plans using Total Compensation Setup Wizard

You can Add New Rates to New Comp Objects using Task 2- Plans and Options of TCW. This is done
as
Part of process to add new plans
Add Premiums to New Comp Objects

Navigation: Total Compensation > Rate/Coverage Definitions > Actual Premiums
New Premiums have to be created / added with the same date as the New Compensation object
start date (Program or plan or option) For example, in the above sections the New Plan and New
Options are added as of 01-JAN-2011, so the new premiums have to be added with the same date
i.e. 01-JAN-2011.
MyOracleSupport Note.256172.1 Additional Information Regarding The Premium Calculation

Process:
MyOracleSupport Note 279562.1 - How to Update Premiums Mid-Year
To verify the rates, run the Benefit Confirmation and Summary Report. If the premiums are new
along with new plans/options, employees must enroll in those plan/options for them to be properly
calculated.
Modify Rates and Premiums on Existing Comp Objects
Update Variable Rates:

(Note: Also see Mass Update of Rate Section Below)
Navigation: Total Compensation > Rate/Coverage Definitions > Variable Rates
1. Update Variable Rate Profiles for any changes to rates, such as on Life Insurance for the New
Plan year.
2. Date-track to the first day of your new plan year (01-Jan-2012). Select the Variable Rate Profile
and make the necessary modification to the calculation. When prompted, save as an Update,
not as Correction. (See Important!!! Below)
3. If Variable Rate Profiles are currently attached to existing Standard Rates, and these Variable
Rates are changing (example: replacing current Variable Rates with new Variable Rates, then end-
date the existing Variable Rates as of 31-Dec-2011 (or of current plan year). Then enter the new
Variable Rates as of 01-Jan-2012 (for the new plan year) - Navigation: Total Compensation >
Rate/Coverage Definitions > Standard Rates > Variable Rate Profiles
Important!!! If you accidentally Save the rate as Correction and have processed any life event
after doing so, you might have to backout the life event that has been processed and correct the
rates and reprocess the life event. Incorrectly saving the rates as correction may lead to loss of
history of previous rates and also data corruption in some cases, so exercise caution when
performing any kind of modification to existing rates.
Update Standard Rates:

Note: Also see Mass Update of Rate Section Below)
1. Update Standard Rates for any changes to rates, such as on Life Insurance.
2. Date-track to the first day of your new plan year (01-Jan-2012) Select the Standard Rate and
make the necessary modification to the calculation and other areas and When prompted, save as
an Update, not as Correction. (See Important!!! Below)
3. If Variable Rate Profiles are currently attached to existing Standard Rates, and these Variable
Rates are changing (example: replacing current Variable Rates with new Variable Rates, then end-
date the existing Variable Rates as of 31-Dec-2011 (or of current plan year). Then enter the new

Variable Rates as of 01-Jan-2012 (for the new plan year) - Navigation: Total Compensation >
Rate/Coverage Definitions > Standard Rates > Variable Rate Profiles
Check Self Service Display Order on Standard rate (If using SSBEN)
For Plan Types with SS Display Format Code set as 'Vertically': The Rate Order Number is the
driving column. So, Rates information will be shown based on the Order Number column in the
following pages
1. Benefit Selection Page
2. Enrollment Overview Page
3. Confirmation Page
4. Current Benefits Page
In other words, the corresponding rates with order numbers 1, 2, 3 and 4 will be displayed in the
corresponding Cost columns.
In all the above 3 pages, the rates (with Display on Enrollment checked) are shown based on the
Tax Type and Activity Type.
The following is the classification.
Column Criteria
Cost1 Tax Type - PRETAX, NOTAPPLICABLE (the latter
handles cases where only one 'Not Applicable'
tax type rate is defined)**
Cost2 Tax Type AFTERTAX
Cost3 Activity Type - Self Service Display
Cost4 Anything other than the above 3 cases
(TAXABLE, NONTAXABLE)
If the 'Self Service Display' set up at the Plan Type level is horizontal, Total Compensation >
Programs and plans > Plan Types then the number "1" will be automatically displayed on the
"Self Service Display Order" from Processing Information tab Standard Rates Form. User will not
be able to update this field.
MyOracleSupport Note.738332.1 - Unable To Display After-Tax Cost In SSBEN:

MyOracleSupport Note.559485.1 - Unable To View List Of Values For Self Service Display Order
Field:
MyOracleSupport Note: 240317.1 Self Service Benefits Errors with the Activity Base Rate
Does Not Exist As Of the Effective Date
Important!!! It is very important to test the self-service issues during mock open enrollment
Update Premium
Navigation: Total Compensation > Rate/Coverage Definitions > Actual Premiums
1. Update Premiums for any changes to the amounts charged by providers.

2. Date-track to the first day of your new plan year (01-Jan-2012). Select the Premium and
make the necessary modification. When prompted, save as an Update, not as
Correction. (See Important!!! Below)

Mass Update of Rates Using Total Compensation Wizard
*(Family Pack K RUP1 and Above)
Navigation : Total Compensation > Total Compensation Wizard > [Select a Business Area] >
Health and Welfare Program > Mass Update of Rates
1. Total Compensation Wizard launches Oracle Applications Framework page.

2. You can also use the HRMS Configuration Workbench responsibility to get to this page
3.Mass Update of Rate allows updating Benefits related standard and variable rates defined with
a calculation method of:
Flat amount
Multiple of Compensation
Multiple of Coverage
No standard values used
Limitation:
1. Currently Premiums and Coverages are not handles by Mass Update of Rates.
2. Also if the variable rates attached to standard rates are changing, after performing the mass
update of variable rates, you need navigate to Standard Rate form from PUI and End date the Old
Variable rate profiles as of 31-dec-2011 and Then enter the new Variable Rates as of 01-Jan-2012
(for the new plan year) - Navigation: Total Compensation > Rate/Coverage Definitions > Standard
Rates > Variable Rate Profiles. Mass Update of rates will not automatically attach the Changed
Variable Rate Profile to the standard rate.
Please refer to following Docs for additional Information:

MyOracleSupport Note.737475.1 Mass Update of Rates Does Not Show All Variable Rates:
MyOracleSupport Note.393547.1 How To Do A Mass Update Of Existing Rates In Benefits?
MyOracleSupport Note.391677.1 Plan Design Wizard Update Rates Does Not Pull All Variable Rate
Profiles:

Modify Elements on Existing Rates
Elements attached to Standard Rates may need to be modified for the new plan year.
Examples:
(1) If elements were generic (such as Medical) and now elements by name or plan (BCBS
or BCBS-EE) are desired;
(2) If new FSA elements are desired for new payroll balances;
(3) if the termination rule used on benefit element is Actual Termination and you need to set
up new elements using Final Process Date; and
(4) if any other changes are needed to elements and/or element links that will require a new
element on the Standard Rate.
Date-track to 01-Jan-2012 of the new plan year. Query the Standard Rate to be changed. Change
the element entry to the new element. Save as an Update, not as Correction. (See
Important!!! Below)
Note: If calculation method of standard rate is Enter Value at Enrollment and if the employee is
not making any changes to the plan during the open enrollment (i.e. saving without making any
changes) the new element which was updated / attached to standard rate will not be carried
forward and you will see the old element on the person element entry screen
Modify Links on Existing Elements
Important: Payroll department should work in Sync with Benefits department before modifying
any existing element links, as it has serious implications in benefits module. There should be a
communication process defined between both the departments to send the information prior to
the modification of any existing element links. Benefits department need to review the links and
perform necessary tasks from benefits side (listed below) before approving the change to the
element link, not doing so can result in data corruption in benefits and payroll.
1. The existing Element Links may also require update. For example, you may wish to update
the existing Medical element link from Costed to Not Costed, by navigating to Total
Compensation Basic Link.
2. If an Element is already in use, and therefore element entries exist in employee payroll,
then an Open or Administrative life event MUST accompany this change to update
employee records.
3. You cannot update the link on an element without a life event being processed on the
same update date.
IMPORTANT: By no means, should you end-date an existing (used) Link, create a brand new link,
and not follow this up with an Administrative or Open life event. If you do so, you will risk not
being able to conduct any future Backout of enrollments.

MyOracleSupport Note 455342.1 Administrative Life Event Restarting Benefits Elements:
MyOracleSupport Note 566123.1 OAB Elements Getting End Dated After Assignment Change.
Flex Credits and Benefit Pools
Audience: OAB
Add New Flex Credit

Navigation: Total Compensation > Rate/Coverage Definitions > Flex Credits
1. New Flex credits have to be created / added with the same date as the New Compensation
object start date (Program or plan or option) For example, in the above sections the New
Plan and New Options are added as of 01-JAN-2011, so the new flex credits have to be
added with the same date i.e. 01-JAN-2011.
2. Add the Flex Credits and attach to the new comp object created.
Add the new Flex Credits to a new or existing Benefit Pool

Navigation: Total Compensation > Rate/Coverage Definitions > Benefit Pool.
1. You may be add the new flex credit to the new benefit pool or existing benefit pool
2. If creating new benefit pool, then it has to be created / added with the same date as the
New Compensation object start date (Program or plan or option) For example, in the above
sections the New Plan and New Options are added as of 01-JAN-2011, so the new benefit
pool have to be added with the same date i.e. 01-JAN-2011.
3. You may then add the flex credit created above to the new benefit pool
4. If you are adding the flex credit to the existing benefit pool, date track to 01-JAN-2012 or
new Plan year and add the flex credit and save as update, not correction
Modify existing Flex Credits

Date-track to the first day of your new plan year (01-Jan-2012). Select the Flex Credit and make
the necessary modification. When prompted, save as an Update, not as Correction. (See
Important!!! Below)
End Existing Flex Credits
Date-track to the first day of your new plan year (01-Jan-2012) change the amount on the Flex
Credit form > Calculation tab to zero and when prompted, save as an Update, not as
Correction. (See Important!!! Below)
Note: If you are implementing new flex program, please refer to MyOracleSupport NOTE 209223.1
- Managing Total Compensation Using Oracle HRMS


Review Default Enrollment Setup
Audience: OAB only
After you have added and modified the new/existing compensation objects, you might want to
review the default enrollment setup on these compensation objects and for the entire plan design
as a whole.
1. Pre-Open Enrollment is best time to review your requirement for default enrollment and
add or modify default enrollment codes at level suitable for your business need for the
current year open enrollment
Navigation: TC > Programs and Plans > Program Enrollment Requirement > General or Life
Event > Program/Plan Type/Plan > Enrollment Region Default enrollment Code
Navigation: TC > Programs and Plans > Plan Enrollment Requirement > General or Life Event
> Plan/Option > Enrollment Region Default Enrollment code
It is important to note that the same default enrollment requirements may not be suitable for
the current year open enrollment, hence it is advised to review your setup for default
enrollment code in each open enrollment period and test the codes during the Mock Open
enrollment.
2. You might need to add a fast formula (formula type: Default Enrollment) in case your
business need requires carry forward of existing enrollments into a newly created
compensation object (such as new plan or new option)
Please refer to MyOracleSupport Note 218059.1-Oracle Fast Formula Reference Guide for
Standard and Advanced Benefits for sample formula. For sample default enrollment fast
formula
Review Default Enrollment Setup Using Total Compensation Setup

Wizard
You can Review Default Enrollment Setup using Task 6-Default Enrollment
For More Information Please refer to Note 330033.1
Start New Coverage for Flexible Spending Accounts (FSA)
Coverage in Flexible Spending Account (FSA) plans may need to be restarted each plan year with
the desired election amount explicitly entered. If a participant is currently enrolled, their
coverage should end on 31-Dec and restart on 01-Jan. The procedures are given for both OAB
and OSB.
Optional: The Eligibility and Enrollment List may be run prior to Open Enrollment to obtain a list
of current enrollees in each FSA plan, and their current elected amount. The same report may be
run after the open enrollment period has ended to verify that coverage has been re-elected, or
ended, according to participant elections.
See the Appendix of Sample Reports for the Eligibility and Enrollment List.
Audience: OAB
The plan type (or plan) may be set with an enrollment code to start new coverage for the new
plan year. Also, if a participant with current year coverage should be required to reselect
coverage for the New Year, a default code may be used.

===Example===
Navigation:
Program Enrollment Requirements > select the Program > Life Event > Plan > FSA: Health Care
Coverage
Life Event: OPEN
Enrollment dropdown:
Method: Explicit
Enrollment Code:
Current, Can Keep or Choose But Starts New; New, Can Choose
Default Code: New, Nothing; Current, Nothing
Or
If your plan design includes a default plan or option, such as a Waive Plan or Waive Option)
Default Code: New, Defaults; Current, Defaults
Assign on Default [x]
Other choices for the Enrollment Code and Default Code may be used if the Standard Rate for the
FSA comp object has a default of zero:
Current, Keep or Choose; New, Nothing
Default Code: New, Defaults; Current, Same Enrollment but Default Rates.
===Procedure===
Process Open life event

Enrollment form shows no existing enrollment in FSA:Health Care Coverage
However, it does show existing enrollment in other comp objects, which is expected.
Explicitly select the FSA comp object to re-enroll in from the list of values.
Enter the desired amount.
Coverage Start Date shows 01-Jan-2012
Original Coverage Start Date: 01-Jun-2002
If the user saves without re-electing in the FSA comp object, this message may be received:
Caution: APP-BEN-92161: The participant has enrolled in one or more future-dated plans or has
de-enrolled from one or more future-dated plans. If you continue, the participant will be de-
enrolled from these future-dated
plans. FSA: Health Care Coverage
This message is expected and is stating that the enrollment will be ended unless explicitly elected
again.
If the user re-selects the FSA before saving, the message will not display. Either method is correct
and results in old coverage ending, with new coverage beginning on the first of the new plan year.
Date-track to 01-Jan-2012
View Enrollment Results shows that coverage was ended on 31-Dec-2011 and restarted on 01-Jan-
2012.
Audience: OSB
For FSA comp objects where coverage must start anew each year, participants must explicitly
enroll via Self Service Benefits or the Non-Flex Enrollment form. For participants who are already
enrolled, they will need to be de-enrolled first, and then re-elect.

This can be accomplished by de-enrolling all enrolled participants by the use of a temporary
eligibility profile; then re-setting eligibility as follows:
(1) Set an eligibility profile on the FSA comp object(s) on 31-Dec-2011 that no participant will
meet (example: create a Benefits Group of Coverage End, attach this to the Plan as of the last
day of the current plan year.
Example:
Date-track to the first day of your plan design in order to create the eligibility profile.
Navigation:
Total Compensation > Eligibility/Rate Factors > Benefits Group.
Create a new benefits group (example: Coverage End)
Total Compensation > Eligibility Profiles > Participant

Create a new eligibility profile. Add the benefits group under the Other tab.
Date-track to the last day of your current new plan year (31-Dec-2011)
Navigation:
Total Compensation > Programs and Plans > Plans > Query the plan >
Plan Eligibility button > Eligibility button > add the name of the eligibility profile created above.
When prompted, save as an Update, not a Correction.
(2)(a) Run the Maintain Participant Eligibility process in Rollback Mode on 31-Dec-2011 (current
plan year) for the FSA for several participants who are currently enrolled in FSA. Set the Audit Log
parameter to Yes. Review the audit log and ensure that the FSA plan indicates:
Sample from Audit Log:

Plan in Program FSA: Health Care C (6709) Elg: No Rsn: Inelig No Pass
The person is not eligible to participate, but was previously eligible.
(b) If Rollback mode is successful, now run the Maintain Participant Eligibility process in Commit
mode for all participants. This should determine that no participant is eligible for the FSA plans,
and end coverages. Verify this by viewing the coverage end date on the View Enrollment Results
form.
(3) Once the Maintain Participant Eligibility process has been run in Commit mode and all enrolled
participants have been de-enrolled, the eligibility profile must then be end-dated (or reset to the
actual eligibility profile) on the first day of the new plan year (01-Jan-2012).
Total Compensation > Programs and Plans > Plans > Query the plan >
Plan Eligibility button > Eligibility button > remove the name of the eligibility profile created
above. When prompted, save as an Update, not a Correction
Important for both OAB and OSB:

If any of the rate codes are not meeting your specific requirement you may need a fast formula
(formula type: Rate Start Date), please refer to the MyOracleSupport Note 218059.1-Oracle Fast
Formula Reference Guide for Standard and Advanced Benefits for sample formula.

Due to the variety of Rate Start and End Date Codes, as well as Payroll Description setup,
thoroughly test the FSA enrollment and rates to ensure that the correct amount of deduction is
taken for the entire payroll year.
Important !! Frequency Rules on elements associated with FSA is

currently not supported , so if you are using frequency rules on
elements associated with FSA please review and revise your setup so
that the FSA is calculated correctly.
Additional references for FSA:
MyOracleSupport Note 294798.1 How To Mass End Date Enrollment of FSA Plan and Restart in
Same Plan when Having Different Dates and Different Payroll(s)
MyOracleSupport Note 393219.1 - What are the Suggested Rate Start and End Date Codes for
Open When First Day of the Pay Period and First Check Date are in Different Year Periods?
MyOracleSupport Note.362183.1 - First Element is Rounding/Prorating After Processing Life Event:
MyOracleSupport Note.761348.1 - How to Deduct Benefit Amounts from 24 Instead of 24 Pay
Periods for a Bi-weekly Payroll?
MyOracleSupport Note.168099.1 - Flexible Spending Account (FSA) Amount is Prorating Over Full
Year Instead of Remaining Payroll Periods if Enrolling Mid-Year
MyOracleSupport Note.829447.1 - Proration of Standard Rate Minimum/Maximums for Full Pay
Periods Remaining Does Not Calculate Correctly:
MyOracleSupport Note.737754.1 - After RUP3 Flexible Spending Amount (FSA) Amount s not
Calculating Correctly When Added at Mid Year:

Close Unprocessed Life Events
Audience: OAB
When processing the Open life event via the Participation Process: Scheduled, an Open life event
will not be started if a participant has an existing life event that is not closed (i.e., does not have a
Processed status). It is suggested that these unprocessed life events be resolved prior to
running Open, so that errors do not occur when processing these participants.
These life events may have been detected for participants, but not yet processed. Or the life
events may have been processed, but not closed. A benefits administrator should review each
scenario, since life events in process can interfere with open enrollment.
Life events that are not fully processed may be identified on the Life Event Summary Report. This
report may be run for any user-designated timeframe.
Set a primary sort of Life Event Status
Step 1:
Resolve all life events that are Detected or Unprocessed for participants. These life events may
be analyzed via the Benefit Service Center form > View Person Life Events > Potential Life Events
tab or
People > Total Comp Enrollment > Enrollment Process > Person Life Events >
Potential Life Events tab.
For detected or unprocessed life events, a benefits administrator should review these for each
participant and make the decision to:
a) Process the life events
b) Void the life event if it does not need to be processed by changing
the status from Detected or Unprocessed to Voided
c) Set up a collapsing rule to collapse the life event with the Open
Life event.
Step 2:
Resolve the life events in a Started status.
These are on the Life Event tab of the Person Life Events form.
If the enrollment period has passed, then close the life events. Otherwise, the benefits
administrator may want to hold these participants out; process their life event; allow enrollment if
applicable; and then run Open separately for these participants.
There are two methods of closing any started life:
(1) Benefit Service Center form > View Person Life Events > select the Started life event. Select
the Close Event button and enter the date on which to close the life event (a date within the
enrollment period). This method of closing a life event uses the Force Close method meaning
that the life event will close even if the enrollment period has not passed.
(2) Run the concurrent process 'Close Enrollments Process'

Select the Close Mode parameter value of Normal Close to only close those life events where
the enrollment period has passed. Select the value of Force Close to close all life events
regardless of whether the enrollment period has passed or not.

Note: If a particular life event needs to be re-processed, the 'Back-Out Life Events concurrent
process enables you to back-out the life event for a large group of people and set it to an
Unprocessed, Voided or Manual status. Or use of the Back Out Event button on the Person Life
Events form allows a back out of a participants life event.
If you need to re-open a closed event for a person, you can do so on the Person Life Event form.
Select the most recent processed life event and the form will display a Re-Open Event button.
You should re-open processed life events to simply make changes to the elections for that
particular event or if the persons eligibility and plan design setup does NOT need to be re-
evaluated.
Check and Clean Up for Previously Detected Temporal And Other

Life Events
!!!Important!!! Please read this section carefully to avoid any data loss issues.
As a part of clean up process Before submitting 'Participation Process: Scheduled' for a large
number of Employees or performing batch processing of 'Open', one should first verify whether
any Temporals or any OAB Life Events are in detected state before the Life Event occurred date of
'Open Life Event. If there are Life Events that are detected before the life event occurred date of
'Open' Life Event and are not processed, then customer should take appropriate action before
submitting the request. You should either VOID the Detected Life Event and then submit the
concurrent request or process the Detected Life Events and then submit the concurrent request.
Without VOID'ing out or processing the Detected Life Events, if customer submits the concurrent
request, Detected Life Event will be processed first and all the future Life Events will be backed
out to 'Unprocessed' state. Customer has to manually process all the backed out future Life
Events and then process 'Open'. To avoid this situation we advise you to first find such Potential
Life Events, process/void the potential Life Event and then submit the concurrent request to run
'Open' on the employees.
The below SQL will return the list of Employees for whom there are potential Life Events before
the life event occurred date of 'Open' and not processed.
select ppf.person_id,
ppf.employee_number,
ppf.full_name,
ler.name,
ptnl.lf_evt_ocrd_dt
from per_all_people_f ppf,
per_person_type_usages_f ptu,
per_person_types ppt,
ben_ptnl_ler_for_per ptnl,
ben_ler_f ler
where ppf.person_id = ptu.person_id
and trunc(sysdate) between ppf.effective_start_date and ppf.effective_end_date
and ppf.person_id = ppf.person_id
and ppt.person_type_id = ptu.person_type_id
and ppt.system_person_type in ('EMP','EX_EMP')
and ptnl.person_id = ppf.person_id
and ptnl.ler_id = ler.ler_id
and ler.typ_cd not in ('IREC', 'SCHEDDU', 'COMP', 'GSP', 'ABS')
and ptnl.lf_evt_ocrd_dt <= :p_opn_lf_evt_ocrd_dt
and ptnl.ptnl_ler_for_per_stat_cd in ('DTCD','UNPROCD')

and trunc(sysdate) between ler.effective_start_date and ler.effective_end_date
and ppf.business_group_id = :p_business_group_id
and ppt.business_group_id = :p_business_group_id
and ler.business_group_id = :p_business_group_id
Bind Parameters
:p_business_group_id = Business_group_id of the Business Group
:p_opn_lf_evt_ocrd_dt = LifeEvent Occured date of 'Open' LifeEvent
Review Due Date Setup for the Action Items and Resolve Any
Pending Action items
Review Setup for Action items Due Dates:

Navigation : TC > Programs and Plans > Plan Enrollment Requirements > General > Plan >
Actions (Due Date)
Navigation : TC > Programs and Plans > Program Enrollment Requirements > General > Program
> Actions Types (Due Date)
It is recommended that all the action items have due date specified, not doing so will cause any
unresolved action items to be pending forever and will not be closed even when you run the Close
Action Item process.
Resolve any pending unresolved action items:
To close unresolved Action Items, run the Close Action Items Process.
In order for the Close Action Item Process to work correctly, the Action Item must have a due date.
Action Items are like Life Events in that they have expected close dates, and the process will only
work once you have passed that date.
Refer to
MyOracleSupport Note.279136.1-Close Action Items Process Does Not Close Action Items:
You can determine if the Action Item has a Due Date on it when you view Action Items.
People > Total Comp Enrollment > Enrollment Process > Person Enrollment Action Items
Run the Close Action Item process for that person with the Audit Log flag set to 'Yes'.
Review the audit log for deletion of action item.
The following script can be used to identify the action item related to Designate Beneficiaries
that are left open and you may expand it to include for other action items if necessary.
**************************Beginning of Script*************************
SELECT *
FROM ben_prtt_enrt_actn_f pea,
ben_prtt_enrt_rslt_f pen
WHERE pea.prtt_enrt_rslt_id = pen.prtt_enrt_rslt_id
AND pea.per_in_ler_id = pen.per_in_ler_id
AND prtt_enrt_rslt_stat_cd IS NULL
AND actn_typ_id IN
(SELECT actn_typ_id
FROM ben_actn_typ
WHERE type_cd = 'BNF'
AND business_group_id = :business_group_id)

AND pea.effective_end_date = '31-DEC-4712'
AND pen.effective_end_date = '31-DEC-4712'
AND pen.enrt_cvg_thru_dt = '31-DEC-4712'
AND pea.per_in_ler_id IN
(SELECT per_in_ler_id
FROM ben_per_in_ler pil,
ben_ler_f ler
WHERE --person_id = :person_id
--AND
pil.business_group_id = :business_group_id
AND per_in_ler_stat_cd NOT IN('BCKDT', 'VOIDD')
AND ler.typ_cd NOT IN('IREC', 'COMP', 'GSP', 'ABS')
AND ler.ler_id = pil.ler_id)
AND cmpltd_dt IS NULL
AND pen.business_group_id = :business_group_id;
*******************************End of Script*****************************************
Alternately the concurrent process Temporal Communications (Action Item Reminder) may be
run to process reminders for unresolved Action Items. This requires communication setup that is
beyond the scope of this document.
Please see Chapter 17 of MyOracleSupport Note 209223.1 Managing Compensation Using

HRMS for further information.
Check for Previously Overridden Data (Enrollment Overrides)
If the Enrollments (rate and coverages) were previously overridden without an override thru date,
they need to be updated with the override thru date in case you need the rate or coverage to be
recalculated for the current Open Enrollment Year.
The following script will help you identify enrollments with and override and have no Override
Thru Date on them:
Select
pen.sspndd_flag,
pen.enrt_ovridn_flag,
pen.enrt_ovrid_thru_dt,
pen.prtt_enrt_rslt_stat_cd,
pen.enrt_cvg_thru_dt,
pen.effective_start_date,
pen.effective_end_date,
pen.enrt_cvg_strt_dt,
pen.per_in_ler_id,
pen.pl_id, pl.name,
pen.oipl_id,
pen.person_id,
pen.prtt_enrt_rslt_id, employee_number, full_name
from ben_prtt_enrt_rslt_f pen, per_all_people_f pap, ben_pl_f pl
where enrt_ovridn_flag = 'Y'
and enrt_ovrid_thru_dt is null
and pen.person_id = pap.person_id
and pen.pl_id = pl.pl_id

and sysdate between pap.effective_start_date and pap.effective_end_date
and sysdate between pl.effective_start_date and pl.effective_end_date
**************************End of Script*************************
The following script will help you identify enrollment rates with and override and have no Override
Thru Date on them:
Select prv.rt_ovridn_flag ,
prv.rt_ovridn_thru_dt,
prv.rt_strt_dt,
prv.rt_end_dt,
prv.rt_val,
pen.prtt_enrt_rslt_stat_cd,
pen.enrt_cvg_strt_dt,
pen.enrt_cvg_thru_dt,
pen.effective_start_date,
pen.effective_end_date,
pen.per_in_ler_id,
pen.pl_id, pl.name,
pen.oipl_id,
pen.person_id,
pen.prtt_enrt_rslt_id, employee_number, full_name
from ben_prtt_enrt_rslt_f pen, per_all_people_f pap, ben_pl_f pl, ben_prtt_rt_val prv
where
prv.rt_ovridn_flag = 'Y'
and prv.rt_ovridn_thru_dt is null
and pen.person_id = pap.person_id
and pen.pl_id = pl.pl_id
and pen.prtt_enrt_rslt_id = prv.prtt_enrt_rslt_id
and sysdate between pap.effective_start_date and pap.effective_end_date
and sysdate between pl.effective_start_date and pl.effective_end_date
**************************End of Script*************************
Set Up Collapsing Rules
Audience: OAB
If conflicting life events occur for a participant (more than one life event occurring on the same
day), then a collapsing rule may be set up to combine these life events into one of the life events
triggered or a different life event.
Navigation: Total Compensation > General Definitions > Additional Setup > Collapse Life Events
Another choice is to set the Open life event as an Overriding life event (Navigation: Total
Compensation > General Definitions > Additional Setup > Life Event Reason > query Open >
check the override box. If there are then multiple life events occurring on the same day, but
only Open is checked as the override, the life event will process successfully. If multiple life
events are marked as override and occur on the same day for a participant, a collapsing rule
should be set up.
You can also use life event evaluation or person changes rules to prohibit certain life events from
being triggered or processed in the open enrollment window For example if you dont want to

process an event you can write a life event evaluation rule that sees a life event occurred in the
future and if yes void the event.
It is recommended to set up a standard timeliness value on all events to follow business
processes and procedures.
Setup example:
Navigation: Total Compensation-> Additional Setup->Life event reasons form
Life event : Gain a Child
Timeliness Evaluation: Void Potential Life Event. (You can also set timeliness evaluation to Process
Potential Life Event Manually if you don't wish to void)
Timeliness Days: 30 (can be 60 or 90 or whatever makes sense for your business requirements)
History of events:
Event 1- New hire 1 Oct 2004
Event 2 -Life event Open Jan 1 2005
Event 3 -Relocation event June 2005
Event 5- Gain a child for 1 Mar 2004
Processing event #5 will back out events 1-4 and cause significant reprocessing and re-keying if
not using reinstatement
With above sample setup on gain a child if gain a child gets triggered in past, maybe in error, it
will get picked up and processed and go directly to void. Therefore, protecting all of your other
events in this participants history. You can also consider adding timeliness if your carrier does
not allow retro changes within a boundary as standard setup.
To avoid issues with losing enrollments due to life events that are erroneously processed in the
past please use life event timeliness. These issues can be caused by entering incorrect dates in
the scheduled process and mass backing out participant. Going forward on your scheduled event
and other events you should add timeliness days or period. For example on open event set
timeliness evaluation to Void Potential Life Event and a Timeliness period set to rule or days i.e.)
90.
This way when you run a scheduled in the past it voids the event and does not back out other
processed events. In the log you can see when the results.
The following potential life event currently being processed has been voided:
Life Event : Open
Life Event Occurred Date : Open_OCRD_DT (LF_EVT_OCRD_DT=01-JAN-04)
All potential life events are voided due to timeliness.
Please see MyOracleSupport Note 218059.1 Oracle Fast Formula Reference Guide for Standard
and Advanced Benefits for more information on Life event evaluation and Person Changes Causes
Event rules.
MyOracleSupport Note.294145.1 - How do you use Collapsing Logic with Temporal and Scheduled
Life Events
MyOracleSupport Note.387377.1 BENNEWS Oracle Support Newsletter August 2006 (Look for Life
Event Timeliness )
Processing Temporal Events

Audience: OAB
NOTE: The benefits administrator may run the Participation Process: Temporal in
advance of open enrollment if needed.
Temporal life events are those that are detected with the passage of time (age, length of service,
etc). Whether these life events should detect at the same time as Open Enrollment is a choice
of the Benefits Administrator.
Very Important! Regardless of whether the temporal life events are detected or not, the
participants age, length of service, salary and other temporal factors are evaluated when the
Open Enrollment life event is processed.
This is why it is important to set up Collapsing logic with Open being the winning life event, if your
business requirements require this. In doing so, if a Temporal Event is triggered WHILE Open is
being run, then the Open can win out.
The benefits administrator may also run the Participation Process: Temporal in advance of Open
Enrollment if needed. For example, if salary increases were processed prior to the Open
Enrollment being processed, the participants new salary will be applied. If salary increases occur
throughout the year, the temporal process is run to detect these changes. Temporal life events
may be processed separately, or collapsed into the Open Enrollment life event depending on your
companys business requirements and when the life events occur.
Once the Temporal process is run prior to the Open, then a number of Age Changed, Length of
Service Changed, and other Temporal life events are visible on the employees View Person Life
Events form on DETECTED status. From here, the benefits administrator can manually close or
process the detected temporal life events, based on the business needs. Depending on the date
of the Temporal event (i.e., where it lies between the Open Enrollment RUN date and December
31), you will then need to separately run the Open using an appropriate date just for the group of
participants who were impacted by an intervening Temporal event.
Another possibility is that you may wish to detect all Temporal life events, and have them go
straight to Voided status. If this is the case, please test out a combination of Timeliness
Evaluation and Timeliness Days on the Life Event Reasons form, with the Timeliness Days set
to 1 for all temporal life events. Then Open cannot get backed out when a temporal event
happens, since its gone straight to Voided.
If Temporal life events are triggered (and in a Detected status) before the scheduled process is
run the events can be collapsed using collapsing logic. If the scheduled process triggers the
temporal event, it will not collapse into the open enrollment. Collapsing logic will only work if the
temporal is NOT triggered by the Participation Process : Scheduled.
MyOracleSupport Note 294145.1 How do you use Collapsing Logic with Temporal and Scheduled
Life Events
MyOracleSupport Note 295666.1 Temporals (Age Changed Life Event) are Being Detected in
the Future for Some Employees
Purge Batch Related Tables

Audience: OAB

Each time that one of the following batch processes is run, the system creates an audit log if the
Audit Log parameter is set to Yes:
o Close Action Items Process
o Close Enrollments Process
o Default Enrollment Process
o Participation Process: Life Event
o Participation Process: Scheduled
o Participation Process: Selection
o Participation Process: Temporal
o Temporal Communications (Action Item Reminder)
o Temporal Communications (Emerging Events)
o Temporal Communications (Enrollment Reminder)
o Temporal Communications (Mass Mailing)

Audit log files accumulate until you purge them. You should periodically purge batch related
tables to help the system run more efficiently. If the audit logs become full, the application
prevents you from running any of the processes that create an Audit log. Run the purge process,
and then restart the process that was interrupted when the log became full.
Note: By default, the application sets the Audit Log parameter to No.
The Participation Audit Activity Purge process protects ongoing activities by purging data only
from completed batch processes. Purging the audit logs does not affect life event or election
information.
You can purge the log associated with a single concurrent request ID or purge all logs that were
created for a Business Group on a date you select.
The process purges data from the following tables:
o BEN_REPORTING
o BEN_PERSON_ACTIONS
o BEN_BENEFIT_ACTIONS
o BEN_BATCH_RANGES
Recommendation Delete the information in these tables before open to help with any possible
performance issues.
This can be setup to run automatically and periodically.
Also, run the Purge Backed-Out or Voided Life Events, clean up process before open enrollment.
These two parameters need to be changed to Yes in order for any data to be purged.

If the parameters are left to No, nothing will be purged.
Delete life events Yes
Delete Voided Potential Life Events Yes

Please Note: You need to run it once to purge the backout, and run it another separate time to
purge the voided. It does not purge both at the same time.
For the Backed Out Status parameter, if 'Voided' is used, only those life events in a Voided Status
will be deleted. If the 'Backed Out' value is used, both the Voided and Backed Out life events will
be deleted.
MyOracleSupport Note.369611.1 - Backed-Out Life Events Remain After Purge Backed-Out Or

Voided Life Events Process
Once these processes are run, you will no longer see voided life events or potential life events
that were purged, on the View Person Life Events form.
The button/checkbox for these will be grayed out on the form.
Evaluate Size of Eligibility Tables
Audience : OSB only

Currently there is no concurrent process to clean up / purge rows from BEN_ELIG_PER_OPT_F and
BEN_ELIG_PER_F which build up over a period of time when running the maintain participant
eligibility process.
Please refer to MyOracleSupport Note.330534.1and run the scripts clean_elig_per_f.sql and

clean_elig_per_opt_f.sql to cleanup these tables. The script will
delete records historical records in ben_elig_per_f.sql & ben_elig_per_opt_f table .
Note.467162.1 - Performance Issue With Maintain Participant Eligibility:
Note.330534.1 - How To Clean Records In BEN_ELIG_PER_F And BEN_ELIG_PER_OPT_F
Generated By Running Maintain Participant Eligibility And Recalculate Participant Values:
Note.750054.1 - What is the Impact of Scripts clean_elig_per_f.sql and
clean_elig_per_opt_f.sql:
Set Max errors
Scenario: Processing Scheduled process for Open life event for the entire participant population
completes with an error:
ORACLE error 20001 in FDPSTP

Cause: FDPSTP failed due to ORA-20001: BEN_91665_BENMNGLE_ERRORED: N,
ORA_ERRCODE, -20001
ORA-6512: at "APPS.FND_MESSAGE", line 61
ORA-6512: at "AP PS.BEN_MANAGE_LIFE_EVENTS", line 3510
The participation process failed due to the maximum number of errors being reached.
Increase Max Errors:

Navigation: Processes & Reports > Batch Process Parameters > select 'Manage Life Events
Process' from the list of values for the Batch Process Name. Set the Max Errors to a higher
number (can be several hundred or thousand). This should allow the process to finish. Then

review the audit log can to see which participants had a problem and then individually review
each person.
Max Errors may also be set for other processes, such as:
Default Enrollment Process
Close Enrollment Process
Unresolved Action Item Process
Review error reports of the process to resolve any errors.
Performance Testing
Audience: OAB and OSB
The recommendation is for all open enrollments using OAB or OSB, to run Open Enrollment in a
mock, or test, mode for the entire participant population. You may choose to run a sample of
participants, which will contain all scenarios that could occur, but in this case you will not benefit
from a full performance test run. Mock open will help your resolve errors in design, setup, self-
issue resolution to the official open enrolment period, which may cause interruption in business
critical processes.
Copy the instance with all of the Pre-Open Enrollment setup into an instance closely resembling
production server for testing purposes.
Maintain a log of the time involved in each step, counts of enrollments by plan, option etc, and
performance metrics for each process. This will assist the benefit administrators in scheduling the
actual Open Enrollment processes.
Also to map out the expected volume of hits in self service and create a plan to direct enrollment
flow. It is important to run a test of the self-service enrollment process along with the mock open
enrollment.
i.e.) send pre-enrollment communication to employee for self-service such as

Person with name ending in A-G please enroll in 1st week
Person with name ending in H-K please enroll in 2nd week ECT
To ensure that everyone does not log in on the last day to enroll.
It is difficult to determine the amount of time it takes to process a single person on-line or in batch
due the variables that may impact performance. These variables include complexity in plan
design, hardware, network usage, optimized table usage, as well as general database tuning. This
is why doing a mock open enrolment will assist you in performance estimations.
When processing life events through the Benefits Service Center form, OAB customers should
anticipate processing times of around 30-40 seconds per person. OSB and OAB customers
processing 'unrestricted enrollments' through an enrollment form may experience slightly slower
times due to network traffic and form queries. We have noticed that poor performance times are
often directly caused non-efficient plan design and by the lack of running table statistics and
strongly encourage customers to run them on a regular basis, as documented below.
Refer to MyOracleSupport Note: 251981.1 Benefits Performance Check Release 11i for further
information. Navigation: Processes & Reports > Batch Process Parameters > select 'Manage Life
Events Process' from the list of values for the Batch Process Name.

Threads Per CPU
At minimum, the Threads should be set to 1 thread per CPU. For example if you have an 8 CPU
box then the threads parameter should be a minimum of 8. Depending on configuration and what
other processes or products are being run on the server this number can be adjusted upward to
increase thru put. Experiment with this setting to determine your best performance.
Chunk size
As a general rule this number is determined by how many rows are being written to the database.
The fewer rows inserted or updated by a process the LARGER the chunk size should be. (I.e.
System Extract is virtually all SQL with few inserts/updates so it would have a high chunk size)
But Participant Processing, Conversion or Annual Enrollments on a heavy plan design i.e. 150+
eligibility rows per participant can insert/update up to 1000 rows per chunk, this is when you
would have a LOW chunk size number.
Run Analyze and Gather Statistics
Responsibility: System Administrator

Navigation Path: Request => Run
In the Name field query on %statistic%
Run the following:

1. Gather Schema Statistics
2. Gather Table Statistics
The first program gathers stats for all the tables in a particular schema and is the recommended
way to gather stats (you should pass only the schema name - BEN - and it should collect stats for
all the tables, indexes and columns (histograms).
In summary, the only thing that should be done is run 'Gather Schema Statistics' for the required
schema.
These must be run by schema, if left blank all schemas will be run.
To find the schema query on dba_objects table. The DBA may run this for
schemas HR, BEN, and APPS.
Recommendation: Run this procedure several times during the open enrollment period to ensure
peak performance:
Prior to running the Participation Process: Scheduled process.

Prior to running the Default Enrollment Process
Prior to running the Close Enrollment Process
Audit Log Flag on Concurrent Processes
When submitting batch processes for the entire participant population (such as Participation
Process: Scheduled or Recalculate Participant Values) this flag should always be turned off. This is

only to be used in test environments or mock Open Enrollment for debugging purposes. When
turned on, the processes create huge audit logs.
Self Service performance Testing
Self-service has to be thoroughly tested for performance and load during the time of mock open
enrollment. It is recommended to test the load on the server when multiple users hit the system
at the same time. The recommendation is for all open enrollments using SSBEN is to test for the
entire participant population. You may choose to run a sample of participants, which will contain
all scenarios that could occur, but in this case you will not benefit from a full performance test run
MyOracleSupport Note.753888.1- Impact of ICX Session Timeout Profile Setting to Avoid

HR_7165_OBJECT_LOCKED Error During Annual Benefits Enrollment in Self-Service

Phase II: Open Enrollment procedures
Considering you have taken the steps above to update, modify, and Mock test your plan design
and resolved all issues you can continue into the open enrollment process with piece of mind.
Process the Open Life Event
Audience: OAB
Important!!! Run the concurrent process in rollback mode and resolve any errors before running
it in the commit mode
Also refer to Check and Clean Up for Previously Detected Temporal And Other Life
Events section to avoid potential data loss issues
Run the concurrent process Participation Process: Scheduled.
Navigation: Processes & Reports>Submit Processes & Reports> Click OK for Single Request>type
Part%Sched% in the name>Tab
This will result in a Started Open life event on each eligible participant. You can view the started
life event from:
Navigation : People>Benefits Service Center>View Person Life Events

OR
People>Total Comp Enrollment>Enrollment Process>Person Life Events
Key parameters to be considered:
Effective Date: The first day of your Open Enrollment period

(01-Nov-2011 in our example).
Detect Temporal: See discussion under Processing Temporal Events
Person Type: May want to select Employee or Participant to exclude

terminated or non-Cobra enrolled dependents
Life Event
Occurred Date: Select the date that corresponds with your Open
life event (example: 01-Jan-2012).
Audit Log: If running for your entire participant population, set

this parameter to No.
Note: To limit the Participation Process to major eligibility areas, you may select parameters
such as Payroll or Benefits Group, write a Person Selection Rule, or choose from many other
parameters.
The Participation Summary Report is one of the reports produced by the Participation Process:
Scheduled process. It provides an overall summary of the participants that processed
successfully vs. those that had an error.

PROCESSING SUMMARY
Number of participants successfully processed 8600

Number of participants processed in error 60
Number of participants unprocessed 10
==========
Total number of participants selected 8670
The Life Events Summary Report may be printed at this time to examine the number of Open
life events in Started status. See the Appendix of Reports for information on this report.
Processing Open Life event for single person from Benefits Service
Center
Navigation : People > Benefits Service Center
You can add function Process Open Enrollment to your benefits service center under desktop
activities and use the function to process open life event for single person from benefits service
center.
Please refer to
MyOracleSupport Note 148714.1 - How To Setup Desktop Activities on the Benefits Service Center
Form (Benauthe).
You need to select the correct life event occurred date from the list of values available while
processing open enrollment from benefits service center.
Once processed the open life event will be assigned in started state for the employee chosen on
the benefits service center.

Maintain Participant Eligibility
Audience: OSB
This process evaluates eligibility and calculates all derived factors used by plan design variable
rate profiles. It then stores the new derived factor values in eligibility tables. The administrator
may then submit the Recalculate Participant Value process that will use the new derived factor
amounts when calculating the variable rate profiles.
Schedule this process to run against your employee population close to the date the plan design
changes go into effect (01-JAN-2012 per our plan design in this document which is the event
date). If following the procedure on End Existing Plans That Are No Longer Being Offered, this
process will end employees coverage as of 31-dec-2011. Since new enrollment is effective on
01-January, the employees coverage in the ending plan will cease on 31-Dec. and begin in new
elections on 01-Jan. (refer to your plan design setup in this case it is event and 1 day before
event)
This process can be run in rollback mode, in order to review the log for errors prior to committing.
Check the log files to verify if de-enrollments are occurring on expected date.
Important!!: There is no rollback mechanism once the process has been run in COMMIT MODE.
If changes need to be made after commit, they must be done manually.
Recalculate Participant Values
Audience: OSB
Customers using OSB can update participant rate, coverage, premium, and imputed income
values by running the Recalculate Participant Values batch process.
If entering participants' enrollment via SSBEN or the enrollment forms, the rates, coverages, etc.
are recalculated when running the Unrestricted Enrollment. But for employees who make no
explicit elections and are defaulted into their current enrollment, this process should be run.
However, to ensure proper values for all participants, run this process for the entire participant
population.
A benefits administrator should run this process when plan design changes for values such as
contributions, premiums and coverages go into effect (such as 01-Jan) to recalculate values for
all enrolled participants who are affected by plan design changes.
This process does not recalculate values based on changes caused by a participant crossing a
derived factor boundary, such as an age change or length of service change. Therefore, you must
run the Maintain Participant Eligibility process to redetermine eligibility and to recalculate derived
factors before you run the Recalculate Participant Values process.
Check for Errors and Resolve

Audience: OAB
By processing Open Enrollment in a mock or test mode prior to actually running the Open
Enrollment, many of the issues should have already been identified and remedied. Therefore, the
number of issues experienced when Open is run in commit mode should be greatly reduced.
However, always check the error reports to identify and resolve any remaining errors.
If there are participants with errors, the participant in all probability does not have the Open life
event started.
After the Participation Process: Scheduled has been run, review one or both of the following:
Participation Error Detail Report by Error Type Shows the error type and the details by
person for each error
Participation Error Detail Report by Person Shows the errors by person.
Each error will need to be analyzed by a benefits administrator to determine the cause and
resolution.
Monitor a Started Process
Any of the batch processes submitted may be monitored for percentage of completion, if desired.
Navigation: Processes and Reports > Monitor Batch Processes
Restart a Failed Process
If the Participation Process: Scheduled fails due to reaching Max Errors or other possible causes,
the process may be restarted by running the Restart Participation Process.
Navigation: Processes and Reports > Submit Processes and Reports >
Single Request > Restart Participation Process
The Benefit Action ID Parameter can be located by running the following SQL query:
select benefit_action_id, request_id from ben_benefit_actions

where request_id = <failed request_id>;
Default Enrollment Process
Audience: OAB
When open has been run and all errors associated corrected you can run the default enrollment
process. The recommendation is to run Default directly after running Open.
The Default Enrollment Process may, based on your plan design:

default the participants into their current enrollment if they make no explicit election
choices;
assign new defaults;
Change elections from current elections to a default election (example: in the case of
Dependent Care Spending where an OAB implementation setup designates that a
current enrollee be defaulted to nothing or into a waive plan or option.
Update Rates and coverages
Running default before allowing people to start enrolling will do additional checks and validations
and help you identify errors before they occur that would not be identified until close process. You
can then analyze the default reports produced by the Default Enrollment Process and resolve any
errors received. The default audit logs provide additional information above what the close
enrollment process provides giving you more information to resolve errors and take action.
The Default Enrollment Process is recommended to be run immediately after running the
participation process:scheduled, especially if using self service so the on the first day of the
enrollment period the self service participant can see any defaults applied to them in self service.
Note:
Default
Navigation: Total Compensation > Programs and Plans > Program Enrollment or Plan Enrollment
Requirements > Timing > Scheduled >
Defaults will be assigned on:
I.e.) if the first day of the enrollment period is 01-Nov-XX the default to assign date should be 01-
nov-XX and default process should be run
For example:
Step 1 Run Participation Process: Scheduled
Step 2 Run Default Enrollment Process

Enter Participants Enrollment Choices
There are various methods for entering a participants elected choices for Open Enrollment:
(1) The participants may elect their own benefit elections via Self Service Benefits.
(2) The benefits department may enter the participants elections via the Non-Flex or Flex
Enrollment form.
(3) If the employee makes no elections, they can be defaulted into the elections as deemed by
the Default Code on the Program (or Plan) Enrollment Requirements form, such as:
Default Enrollment: New, Defaults; Current, Same Enrollment and Rates*
* Note: Interpretation of this default code:

If a participant is new to an electable comp object, they will be assigned the default plan or
option. If they are currently enrolled and make no explicit election changes, they will retain their
same enrollment. Rates, however, will be re-computed based on plan design setup. If the
coverage and/or rate were entered at the time of enrollment then the current benefit and rate
amount for the person will be defaulted.
Most companies are using a combination of all three of the above methods of enrolling. The
majority of the enrollment when the participant makes no explicit elections and is defaulted into
their current benefits. Another common method is when employees using Self-Service Benefits to
make elections. The benefit administrators enroll the special situations using the enrollment
forms.

Date-Tracking in the Enrollment Forms
Audience: OAB
PUI:
Date-track to a time within the enrollment period for Open Enrollment (in our example, this can be
any day between 01-Nov and 30-Nov.
Enter the participants elections. Save. Please note: you will not be able to date track prior to a
date of a previously saved election.
Self-Service Benefits:
Since the Participation Process: Scheduled mode was run, all participants have the Open life event
in process. The opportunity to elect will exist throughout the Open Enrollment Period (01-Nov to
30-Nov in our scenario). No date tracking should be enabled in Self Service Benefits in
production instance during actual open enrollment
Audience: OSB
PUI:
Date-track to the first day of your new plan year (01-Jan-2012).
Process the Unrestricted life event for the participant on the Enrollment form.
Enter the participants elections. Save.
Self-Service Benefits:
The unrestricted processing model does not adopt the concept of an enrollment window, so all
benefit changes become effective as of the session date (which in this case is set to 01/01 on the
self service function)
Since the life event occurred on date for unrestricted enrollments is the session date and annual
enrollment changes are generally made before the new coverage actually takes effect, the
Change Session Date menu parameter must be used to set the month and day of the life event
occurred on date of the enrollment. For the self-service function, you set the month and day of
the life event occurred on date for the annual enrollment election and the system derives the
year. So, unless you change your annual enrollment period, the Change Session Date parameter
only needs to be set once. Without setting this parameter, the life event occurred on date would
change each time the employee went into self-service during the annual enrollment period.
Refer to MyOracleSupport Note: 211557.1 Implementing Oracle Self-Service Human Resources

(SSHR) 4.2, Chapter 17 on Setting the Effective Date of a Scheduled Enrollment in SelfService
Processing Life Events That Occur Within the Open Enrollment

Period
It is possible that life events will continue to occur during the annual enrollment (Open) period.
The benefits administrator should closely monitor the life events either being detected from data
changes or being reported to the benefits department.

The Life Events Summary Report may be printed at this time to examine the number of life
events in Detected status. See the Appendix of Reports for information on this report.
It is up to the benefits administrator on how to address these intervening life events. Some life
events may affect the Open Enrollment choices; some may not. These events must be handled
on a case-by-case basis.
Scenario 1: A participant elects their benefits for 2012 during the Open life event period.
Coverage and Rates for these elections will start on 01-Jan. The participant then gains a spouse
on 01-Dec-2011, which may immediately result in the selection of new enrollment, with rates and
coverage effective 01-Dec-2011. New electable choices are now available during the Open
annual enrollment period as well.
Scenario 2: A salary change is made which will affect life insurance coverage, rates and imputed
income. No participant changes to enrollment may be made with this event.
Audience: OAB
If a life event occurs for a participant that will affect their eligibility and the electable choices
available during the Open life event:
a) Process this intervening life event, which will update eligibility and electable choices, as well as
back out the Open life event. Allow the participant to elect the comp objects affected by the life
event and close the life event. Reprocess Open and allow elections to be made.
or
b) Set up a collapsing rule for the intervening life event and the Open life event. Back out and
reprocess the life event for the participant. Note, however, that if Open is reprocessed, the
coverage and rates will not begin until 01-Jan in this scenario, rather than 01-Dec when they
gained a spouse.
These procedures will provide a solution to scenario 1 above. The procedure selected depends on
your company policies.
See the section Set Up of Collapsing Rules for further information.
If a life event occurs for a participant that will not affect their eligibility and electable choices
received during Open Enrollment:
a) View the Participants Enrollment Results and note their elections for Open Enrollment. Then
set up a collapsing rule for the intervening life event and the Open life event. Back out and
reprocess the life event for the participant, re-entering their elections.
or
b) Void the life event if it is not necessary to be processed (such as an Age Change temporal life
event, where the participants age was previously evaluated during the processing of the Open
life event.
These procedures will provide a solution to scenario 2 above. The procedure selected depends on
your company policies.

Audience: OSB
If an event occurs for a participant that will affect what they are eligible for, along with their
electable choices during Open Enrollment:
On the View Enrollment Results form, date-track to the Open event date (01-Jan)
View the Participants Enrollment Results and note their elections for Open Enrollment.
Now date-track to the date of the new event and process an unrestricted enrollment for
the person in the Enrollment form. This will delete all elections and changes that were
made during open enrollment.
Enter the participants new elections
Re-enter the 01-Jan elections if needed or have the participant re-elect in Self-Service
Benefits, if the open enrollment period is still in effect.
If an event occurs for a participant that will not affect their eligible and electable choices received
during Open Enrollment:
Run the Maintain Participant Eligibility process and Recalculate Participant Values process if
eligibility and/or rates are to be updated.
View the Participants Enrollment Results date-track to the Open event date (01-Jan) and
ensure that the participants elections are correct, with updates coverage and/or rates.

Back Out the Open Life Event (if needed)
Audience: OAB
If any life event needs to be backed out for the entire participant population, or a select group of
participants, the Back-out Life Events Process may be run. (Remember elections may be
reinstated when life event is re-processed depending on the reinstatement code used) This
concurrent process offers several parameters for selecting the participants. The resulting status
of the life event may be set to Unprocessed if it will be re-run, or Voided if it will not be rerun.
Important!!! Enrollments will not be reinstated if the life event was backed out with voided instead
of unprocessed status
You can view the results of the Life Event Back-out process in the Process Report. You can also see
the backed out details on the view person life event form. The Summary Report identifies the run-
time parameters you selected and provides the total number of persons for whom the selected
life event was backed-out.
Navigation: Processes and Reports > Submit Processes and Reports > Single Request > Back-out
Life Events Process
Note: Use the Person Life Event window to back-out a life event for a single person.
Navigation: People > Total Comp Enrollment > Enrollment Process > Person Life Events
To reprocess this backed-out life event, select either Process Life Event from the Benefit service
Center form, or choose the concurrent process Participation Process: Life Event and select the life
event of Open.
Audience: OSB
There is a concurrent process to mass backout the enrollments in OSB. If the 01-Jan-2012
enrollment needs to be backed outon a single person, date-track to 31-Dec-2011 or any date
prior to the 01-Jan-2012 enrollment on non-flex program enrollment form and save the election.
This will remove all future dated enrollments (not just Open). Also there is no reinstatement
process in OSB, all the backed out enrollments have to be entered manually.
Open Enrollment Window Modification*

*Available from Family Pack K RUP1 and Above
"Manage Open Enrollment Window" concurrent process allows benefits user to update an existing
Open Enrollment Window's Enrollment Period End Date, Processing End Date, Default Enrollment
Date,
or provide an appropriate # of days of extension. This process is offered in a rollback and commit
mode, to allow for validation and testing. A log file displays the details of the new enrollment
period for all participants.
US HRMS Manager has this process listed in the list of values for concurrent processes, if you do
not see it in LOV , please ask your systems administrator to add it to the responsibility you are
using.

This process can be run for multiple employees at a time, and the employee selection parameters
include:
Person Name
Person Selection Rule
Program Name
Plan Name
Life Event Occurred Date
Life Event Name
Organization
Benefit Group
Location
Postal Zip Range
Legal Entity
Payroll
The end user populates the New Enrollment Period End Date OR the Number of days to be
extended.
The process should also adjust the default dates according to new dates passed as parameters.
Extending an Open Enrollment window, once the Scheduled process was already run.
Users can do a trial run before they make updates using Rollback mode.
Customers have the flexibility to update dates using numerous parameters: for whole population,
a select group of people, etc.
Process will perform basic validations like - Enrollment period start date cannot be adjusted to a
date later than the system-calculated date i.e. you cannot extend the original enrollment period
start date, you can only extend the enrollment period end date.
Customers will benefit from the ability to extend an Open Enrollment Window that is already in
progress.
It's quite conceivable that unexpected delays occur during Open Enrollment, whereby certain
segments of the employee population, or the entire population at large, require additional days to
complete their annual enrollment selections
There is no set up required to use this Process.

To run the Manage Open Enrollment Window process, navigate to
Reports & Processes
Submit Processes & Reports
Single Request (radio button / OK)
Manage Open Enrollment Window
Input Parameters
Submit
MyOracleSupport Note 344304.1 - Oracle Advanced and Standard Benefit Reports
Close the Open Life Event
Audience: OAB
The Close Enrollments Process is the process that completes the open enrollment cycle. After this
process is run, no further modifications can be made to a participants elections.
Run this process in Rollback mode (Validate parameter: Rollback) and optionally set the Audit
Log flag to Yes. Analyze the reports produced by this Close Enrollments Process and investigate
any errors received. Resolve any errors received before running this process in Commit mode.

After any identified errors are resolved from the Rollback mode, run this process in Commit mode
(Validate parameter: Commit).
Note: The Rollback mode of this process is not necessary. The Commit mode may be run solely.
However, if using this process for the first time, the Rollback mode allows an opportunity to
review the results before actually committing to the database.
Reopen life event batch process*

*Available from Family Pack K RUP1 and Above
Reopen Life Events process is which benefits users can reopen large volumes of life events in
Batch. This feature allows for easier benefits administration.
This is very useful process in the event that a close enrollment process was run in batch mode for
a life event that later requires reopening. Previously, the only recourse was to open these life
events manually for 1 person at a time.
This "Reopen Life Events Batch" process can be used in conjunction with the "Manage Open
Enrollment Window" process to extend the annual enrollment window, after reopening a closed
open life event.
There is no set up required to take advantage of this process. It is recommended that you test the
"Reopen Life Events Batch" process in a TEST instance, along with the subsequent close
enrollment, to make sure that both processes complete as expected.
To run the process, navigate to:

Processes & Reports
Submit Processes & Reports
Single Request (radio button / OK)
Select Reopen Life Events Process in the Name field
Select your parameters
Submit
Confirm on select employees that the relevant life event is reopened.
Review audit and error details.

Phase III: Post-Open Enrollment procedures
Verify Enrollment data (new plans, check defaults and automatic)
Now that Open Enrollment has been completed, a verification of this enrollment should be
performed on a number of participants. Review the participants elections via the Enrollment
Results form.
Navigation: People > Total Comp Enrollment > Benefits Enrollment > View Enrollment Results.
The Eligibility and Enrollment List may be printed at this time to examine participants
enrollment. See the Appendix of Reports for information on this report.
Verification to be considered:
Plans no longer offered are no longer enrolled in
Eligibility was evaluated correctly
Rates and Premiums changes are reflected
Element entry values are correct for benefit elements
Defaulted plans or options were defaulted correctly
Coverage was restarted for FSA plans
Any other changes made to plan design were incorporated into the enrollment.
Verify Interim assignments and Suspensions
Verify action items and certifications
Verify the payroll results
Verify third party interfaces
Investigate Incorrect Elections
If any item(s) failed the above verification, a benefits administrator should analyze the issue to
determine if the failure occurred on one participant, many or all.
A review of the setup of the components involved should be done to determine if there was an
oversight in making plan design changes, or whether there were incorrect data on an employee.
Important!!! It is very important to investigate the errors and issues during the mock open
enrollment

Processing Life Events That Occur After the Open Enrollment
Period, but Before the New Plan Year
Events will occur to participants throughout the year that may result in their ability to modify their
benefit elections. How to process these events when they occur during the Open Enrollment
period needs special attention by benefit administrators.
Scenario: Open enrollment is processed on 30-Nov. A subsequent life event (Address Change)
occurs on 10-Dec. The participants address change will result in new eligibility for several comp
objects. Elections chosen during Open Enrollment may no longer apply. Eligibility and electable
choices must be re-evaluated, and elections modified.
This scenario applies to both OAB and OSB. OAB will process the life event; OSB will enter the
Non-Flex Enrollment form to process the participants enrollment changes.
After the open enrollment period, and before the start of the actual plan period, if a participant
has a subsequent Life event, the system will back out the Open Enrollment life event, and the
elections made during this life event.
OAB Procedure:
a) Process the subsequent life event (which will then automatically back out the Open life event
and the elections made therein).
b) Make elections for this life event (and close the event if OAB).
c) Reprocess the Open life event (Participation Process: Life Event.
Choose the Open life event) or Benefit Service Center: Process Life Events.
d) Enroll in the desired electable choices for the Open Enrollment life event.
OSB Procedure:
a) Enter the Non-Flex Enrollment form and date-track to the date of the enrollment change.
b) Enter all enrollment changes. Save.
c) Date-track to 01-Jan and select the desired choices for Open Enrollment.
Scenario: Open enrollment is processed on 30-Nov. A subsequent salary change was made for
the employee population. No new electable choices result with this life event, but coverage and
rate amounts will be impacted.
Life Event Timeliness (OAB only)

You can take advantage of Life Event Timeliness on the life event reasons form. Recommendation
for setting up a standard timeliness value on all events to follow business processes and
procedures.
Setup example:
Navigation: Total Compensation-> Additional Setup->Life event reasons form
Life event : Gain a Child
Timeliness Evaluation: Void Potential Life Event. (You can also set timeliness evaluation to Process
Potential Life Event Manually if you don't wish to void)
Timeliness Days: 30 (can be 60 or 90 or whatever makes sense for your business requirements)
History of events:
Event 1- New hire 1 Oct 2012

Event 3 -Relocation event June 2005
Event 5- Gain a child for 1 Mar 2012
Processing event #5 will back out events 1-4 and cause significant reprocessing and re-keying if
not using reinstatement
With above sample setup on gain a child if gain a child gets triggered in past, maybe in error, it
will get picked up and processed and go directly to void. Therefore, protecting all of your other
events in this participants history. You can also consider adding timeliness if your carrier does
not allow retro changes within a boundary as standard setup.
To avoid issues with losing enrollments due to life events that are erroneously processed in the
past please use life event timeliness. These issues can be caused by entering incorrect dates in
the scheduled process and mass backing out participant. Going forward on your scheduled event
and other events you should add timeliness days or period. For example on open event set
timeliness evaluation to Void Potential Life Event and a Timeliness period set to rule or days i.e.)
90.
This way when you run a scheduled in the past it voids the event and does not back out other
processed events. In the log you can see when the results.
The following potential life event currently being processed has been voided:
Life Event : Open
Life Event Occurred Date : Open_OCRD_DT (LF_EVT_OCRD_DT=01-JAN-04)
All potential life events are voided due to timeliness.
Additional Self-Service Benefit information:
Self-Service Benefits Viewing Past & Future Enrollment Information
On the Current Benefits page, participants are now able to view benefit enrollments made in the
past, as well as elected benefits with future coverage start dates. A drop down menu called
Please show me the benefits af of is added to the page that includes changes to coverage dates
within the previous two years up to a maximum of ten changes. The list of values also shows
dates that the participant has new benefits coverage starting in the future based on the coverage
start date.
Print Enrollment Reports and Confirmation Statements:

You can run the Benefits Reports Wrapper Process that contains 2 reports to print the enrollment
information and the confirmation statements for the elections made
1. Benefits Enrollment Kit Report
2. Benefits Confirmation and Summary Report
Please refer to section on Benefits Enrollment Kit Report and Benefits Confirmation and
Summary Report in Appendix of Sample reports (later in the document)
Confirmation Statements can be printed by individual employees from Self Service Benefits
Confirmation page at the end of the enrollment train when enrolling via self-service.

Inactivate Plans that are no Longer Being offered:
Once the Open Enrollment period has passed and all enrolled participants have been de-enrolled,
the Plans that are no longer being offered can be set to status Inactive
Total Compensation > Programs and Plans > Plans > Query the plan > change Status from Active
to Inactive on 01-Jan-2012. Save as an Update
The Following script can be used to confirm that the enrollments are ended if it returns no rows.
Select * from ben_prtt_enrt_rslt_f

And pl_id = <enter pl_id>;
Or
You may run the Eligibility and Enrollment List report to see who is enrolled in a particular plan.

Frequently Asked Questions
Oracle Advanced Benefits (OAB)
(1)
Question:
Suspended enrollment from Open enrollment is not reinstated if a subsequent life event is
processed, causing Open to be reprocessed.
Answer:
If a different life event took place and there were changes in the enrollment between the first time
Open enrollment ran and the reprocess of Open, the Open enrollment process did not reinstate
the enrollment results from the first run. This is expected behavior. The user needs to explicitly
enroll from the enrollment form.
Reference: Bug: 2614242
(2)
Question:
The Open life event was processed, but new rates did not get applied
Answer:
The Participation Process: Scheduled was processed before the rate changes were actually
entered on the Standard Rate form. When the Scheduled or Life Event process is run, the
standard rates at that time are determined, even though the participant has not yet entered the
enrollment choices. Rates must be updated before any Scheduled or Life Event is processed. To
correct this, back out the Open life event and reprocess.
(3)
Question:
When I process Open enrollment for the entire population of participants - by
running the Participation Process: Scheduled, it triggers Open life event for the participants as
well as some contacts and terminated participants. How can we run this so that only participants
are processed?
Answer:
Set the parameter of "Person Type" to a value of Participant (or other desired person type from
the list of values) when running Participation Process: Scheduled. This should exclude contacts
and ex-participants.
Note that if a life event does get triggered for any person, and there are no electable choices, the
life event will be set to a Processed status immediately.
(4)
Question:
When processing the Open Life Event for a participant, an error is received:
APP-BEN-91711:
The Participant Enrollment Result record was not found in the following
package: ben_election_information.election_information.
Context at time of error.
Participant Enrollment Result ID: xxxxxx

Effective Date: dd-mon-yy
Answer:
There may be a future-dated enrollment that is causing the error.
Run a BENPer.sql script (see MyOracleSupport Note 208923.1 for this script) and locate the
enrollment result id that was given in the error message. Check the coverage start date for this
enrollment result, along with the processed date.
There may have been a past life event that was closed on a future date. If so, back out that past
life event and reprocess. Then reprocess the Open Enrollment life event.
(5)
Question:
How are life events handled that are triggered during Open Enrollment? Participants enroll via Self
Service Benefits. When adding a new dependent during the Open Enrollment, a life event is
triggered for Gain a Dependent and this results in a problem processing Open.
Answer:
Set up a Collapsing Rule to collapse the life events that could occur during the entering of benefit
selections during the Open Enrollment period. Specific life events will need to be analyzed to
determine which life events can collapse, and which life events will need a Benefit Administrator
to process.
For example, you may want to collapse:

Open AND Gain a Dependent or Lose a Dependent or Add a Domestic Partner or Age Change
into Open.
If an Address Change life event occurs within this timeframe, this may need to be manually
processed, so that a determination of whether this life event for the particular participant will or
will not affect their Open Enrollment choices.
(6)
Question:
I am processing the Participation Process: Scheduled and the audit log shows the following error:
Person ID : 51778
Life Event Occurred Date : 30-JUN-03
You can manually void the unwanted life events in the Person Life Event window, defined
collapsing life event rules on the Collapsing Life Event window, or determine that a specific life
event is always the winning event by checking the override check box on the Life Event Reason
window.
This error occurred in ben_evaluate_ptnl_lf_evt.check_and_get_winner.
Answer:
The person has a life event which conflicts with the Open life event. A benefits administrator
needs to review the life event (Navigation: Benefit Service Center form > View Person Life Events)
and determine if the life event should be processed separately, voided, or collapsed into the Open
life event.
The potential life event being processed has a life event occurred date that is after the active life
event.

(7)
Question:
A concurrent process errored (perhaps due to reaching the Max Errors). How can I restart the
process after correcting the Max Errors?
Answer:
There are several concurrent processes that may be restarted if necessary:
Navigation: Processes and Reports > Submit Processes and Reports >
Single Request > Restart .. select the name from below
Restart Closed Enrollment

Restart Default Process
Restart Determine Communications
Restart Participation Process
Restart Unresolved Actn (Action Items)
The Benefit Action ID is needed to restart any of these processes. This can be located by running
the following SQL query:
select benefit_action_id, request_id from ben_benefit_actions

where request_id = <failed request_id>;

Oracle Standard Benefits (OSB)
(1)
Question:
Open enrollment will begin mid-November. What is the correct way to
Set up the Program Enrollment Start and End dates for coverage and rates for benefits that take
effect on January 1st? I see a Beginning of Next year option for Start Date... do I select that?
What do I select for End date?
Answer:
It is suggested to use Coverage and Rate Start/End Date codes such as As of Event and 1 Day
before Event. Then date-track to 01-Jan on the enrollment forms and enter the participants
enrollments.
(2)
Question: There will be changes to plans and rates. Should I be date tracking to January 1, 2012
and updating the rates? What is the best way of changing these rates and keeping data integrity?
Answer:
Yes, date-track to 01-Jan-2012 (the date you want the rate changes to take effect). When saving,
ensure that Update is selected (not Correction).
(3)
Question:
If participants want to keep the same coverages for 2012 as they currently have, what has to be
done so that the system reflects this?
Answer:
Set default codes on each plan type within the Unrestricted program.
Navigation: Program Enrollment Requirements > General > Plan Type > add a default code to
each plan type. For example: New, Defaults; Current, Same Enrollment and Rates

Questions Applicable to both OAB and OSB
(1)
Question:
Our program has 26 bi-weekly pay periods, but all of the rates that are being calculated are being
calculated on 27 pay periods due to this years payroll calendar having an extra payroll period.
The Program's Enrollment Rate/Frequency is Per Pay Period. The issue is that the payrolls do
have 27 pay periods in 2012, but only 26 paychecks. It needs to be calculated per paycheck not
pay period.
The same issue may occur on weekly payrolls, where every few years there are 53 pay periods in
a year.
Answer:
Change your Programs Enrollment Rate/Frequency from Per Pay Period to Estimated Per Pay
Period. This can be saved as a Correction if you were already using Per Pay Period.
Also, on the Standard Rate form > Processing Information tab, set the Value Passed to Payroll to
Estimated Per Pay Period Amount.
(2)
Question:
A participant enrolls in a Flexible Spending Account (FSA) as of 01-Jan-2012.
The enrollment form shows the correct communicated value. However, the persons element
entries show an annual value.
Answer:
There may not be a full payroll calendar for the new year. Please check the payroll calendar to
ensure that it exists through the end of the new year.
(3)
Question:
Where can I find information on using configuration workbench or Need information on using
Configuration workbench for loading Open enrollment data.
Answer:
Please refer to MyOracle Support Note 365034.1 - Oracle Benefits Enrollment Conversion
Questions applicable to SSBEN
Q: ORA-01801: date format is too long for internal buffer

Answer: MyOracleSupport Note.737805.1 - Self-Service Benefits Page Gives Date Format Error

Appendix of Sample Reports
Eligibility and Enrollment List
The Eligibility and Enrollment Summary Report lists the total number of participants who are
eligible and enrolled in plans used for Standard and Advanced Benefits, Individual Compensation
Distribution, and Compensation Workbench. The report also lists recently ineligible and de-
enrolled participants as available.
This report allows the HR professional to:
Reconcile total participant counts with third party providers

Determine the effectiveness of a plan by comparing the number of eligible people to the
actual number of enrolled participants
Monitor trends in changes to the volume of participants currently enrolled
Analyze potential impact to current participants due to changes to plan offerings
Generate mailing lists for currently enrolled participants
ORACLE ADVANCED BENEFITS

Eligibility and Enrollment List
Reporting Start Date 01-OCT-2011

Reporting End Date 31-OCT-2011
Person All
Person Type All
Program
Plan Type CLM Medical
Plan
Display Eligibility and Enrollment Summary Yes
Display Enrolled Participants by Plan Yes
Display All Enrolled Plans by Participant Yes
Summary of Eligibility and Enrollment by Plan Type or Plan

Eligibility and Enrollment by CLM Medical Plan
Eligible Currently Enrolled by Enrolled by Enrolled by Enrolled by Enrolled by Newly De-

Enrolled Automatic Data Load Default Explicit Override Enrolled
------------- ------------- ------------- ------------- ------------- ------------- ------------- -------------
CLM Aetna 464 111 6 105 0

PPO Medical
Plan
CLM Cigna 164 8 8 0

PPO
CLM Kaiser 21 1 1 0
Med
(Florida)
CLM Kaiser 124 4 4 0

Med
(Illinois)

Current Enrollment by CLM Medical Plan
Employee + Employee Only Employee Plus Employee Plus Total

Spouse Children Family
------- -------- ------- -------- ------- -------- ------- -------- -------------------

CLM Aetna PPO 26 23.21% 66 58.93% 10 8.93% 10 8.93% 112 73.68%
Medical Plan
CLM Cigna PPO 0.00% 8 100.00% 0.00% 0.00% 8 5.26%
CLM Kaiser Med 1 100.00% 0.00% 0.00% 0.00% 1 0.66%

(Florida)
CLM Kaiser Med 0.00% 4 100.00% 0.00% 0.00% 4 2.63%

(Illinois)
CLM Kaiser 1 8.33% 9 75.00% 1 8.33% 1 8.33% 12 7.89%

Permanente for
2002
CLM United 2 13.33% 13 86.67% 0.00% 0.00% 15 9.87%

Healthcare
------- -------- ------- -------- ------- -------- ------- -------- --------- ---------
Total: 30 19.74% 100 65.79% 11 7.24% 11 7.24% 152 100.00%
Eligible by Plan & Option
Domestic Employee + Employee Only Employee Plus Employee Plus

Partner Spouse Children Family
--------------- --------------- --------------- --------------- ---------------
ABC Medical 111 111 111 111
Another new 3 3 3 3
plan for
2012
CLM Aetna 71 337 337 337 337

PPO Medical
Plan
CLM Cigna 164 164 164 164

PPO
CLM Kaiser 20 20 20 20
Med
(Florida)
CLM Kaiser 116 124 116 116

Med
(Illinois)

Life Event Summary Report
Audience: OAB
The Life Event Summary Report allows the HR professional to analyze life events occurring to
participants for the entire employee population. This report lists the total number of potential or
active life events and their status for a specified period of time.
As an administrator, you can monitor changes to the employee population to:
Determine the number of participants with detected life events so you can resource for
upcoming administrative needs
Analyze the frequency of a given life event among the employee population
Analyze the status of a life event for participants during a specified period
Compare the number of life events that occurred within the reporting and comparison
periods.
View totals for all life events, by life event status, life event name, and person's primary
assignment location.
For technical details of this change, see MyOracleSupport Note 237456.1 About Oracle HRMS
Family Pack E
Note: Run in landwide mode (Options > Print the Output to: Style: Landwide)
Totals By Life Event Status - Potential
Reporting Period
01-OCT-2011 - 31-OCT-2011
-------------------------
Detected 18
Unprocessed 0
Processed 8
Voided 3
Set to Manual 0
Manual Override 0
---------------------------
Totals: 29
Totals By Life Event Status - Processed
Reporting Period
01-OCT-2011 - 31-OCT-2011
--------------------------
Started 7
Processed 1
Backed Out 2
Voided 1
---------------------------
Totals: 11

Totals by Life Event Name - Potential - 01-OCT-2011 - 31-OCT-2011
Set to Manual
Detected Unprocessed Processed Voided Manual Override Total
-------- ----------- --------- ------ ------- -------- ------
Open 0 0 100 1 0 0 101
-------- ----------- --------- ------ ------- -------- ------

Totals: 0 0 100 1 0 0 101
Totals by Life Event Name - Processed - 01-JAN-2012 - 01-JAN-2012
Started Processed Backed Out Voided Total

--------- ------------- -------------- ----------- ---------
Open 100 0 0 1 101
--------- ------------- -------------- ---------- --------

Totals: 100 0 0 1 101
Person SSN/ Location LE LE LE Date of LE Notified

ID Status Name Type Date
-------- ----- -------- --------- ----- ----- ----------- -----------
CLM 458- CLM Main Started Open Schedu 01-JAN-2012 16-OCT-2011

Open, 00- Location led
9175 Open

Benefits Enrollment Kit Report
This report is available under the Benefits Reports Wrapper Process concurrent request.
The Enrollment Form is an easy-to-read report of all electable choices stored in the Electable
Choice tables on the Person Life Event form. The data displayed on the report is extracted from
Standard and Advanced Benefits data processing model. Not only are plans in which employees
are eligible to enroll included, the report also provides enrollment deadlines and clearly defined
default plans in the event employees fail to make benefits elections on time.
Customers not using Self-Service Benefits may find this report very useful administering annual
enrollment. The Enrollment form can be easily generated for all person's eligible to make
changes to their benefits.
A snapshot view of enrollment opportunities will help employees make informed decisions when
choosing benefits by seeing all electable choices, available flex credits, employee
premiums/rates, and the name of the life event allowing the benefits election (OAB only). So
rather than sorting through stacks of paperwork and checklists, employees can refer to this one
simple form.
A wrapper process was created for use by various seeded benefits reports that will accept
parameters common to all reports in the wrapper, process the parameters and validate any that
are mandatory. The process will then identify the list of persons to be processed and execute the
Person Selection and Compensation Object selection rules.
To run the report, query the Benefits Reports Wrapper Process in processes and reports and select
the Confirmation Statement. You will be able to define the common parameters to narrow your
report results. Only the report name and effective date are mandatory parameters. The common
parameters included in the report wrapper are:
Effective Date
Program
Plan Not In Program
Organization
Location
Person
Life Event
Life Event Occurred Date
Service Area
Assignment Type
Coverage Start Date
Coverage End Date
The report also contains configurable regions that can be included or excluded in the output by
setting the below parameters to YES or NO. These parameters are defaulted to YES.
Display Benefits Selections
Display Flex Credit Summary
Display Covered Dependents
Display Primary Care Providers
Display Beneficiaries

Display Action Items
Display Certifications
Display Electable Choice Flexfields
Display Flexfields
Currently, the opening and closing paragraph text are not configurable. However, once the report
is run, you may export the report into another medium to edit. The report is in a .csv format which
can be converted into the desired file format.
Note: This report output is in a postscript file format. Refer to MyOracleSupport Note 117112.1 -
How to read Postscript File Formats on a MS Windows Operating System and Convert To Another
File Format for information on obtaining a postscript interpreter, if needed.

Benefits Confirmation and Summary Report
This report is available under the Benefits Reports Wrapper Process concurrent request.
The Benefits Confirmation & Summary is an easily generated report of all enrolled benefits stored
in the Enrollment Results and Participant Rate Value tables on the View Enrollment Results form.
The data displayed on the report is extracted from the Standard and Advanced Benefits data
processing model and will include Plan in Program and Plans not in Programs. All enrolled plans
for the participant will be included even if attached to different programs.
Whenever there is a change to a participant's enrollment results, a Benefits Confirmation &

Summary can be generated. By providing a confirmation, the employee is given the responsibility
of checking that all contact information and benefit elections are accurate. In the end, this will
save you time and energy by reducing the number of simple enrollment questions asked and
enrollment errors that need correcting because months after the coverage has been in effect.
This can be run be selecting the Benefits Reports Wrapper Process concurrent request
A wrapper process was created for use by various seeded benefits reports that will accept
parameters common to all reports in the wrapper, process the parameters and validate any that
are mandatory. The process will then identify the list of persons to be processed and execute the
Person Selection and Compensation Object selection rules.
To run the report, query the Benefits Reports Wrapper Process in processes and reports and select
the Confirmation Statement. You will be able to define the common parameters to narrow your
report results. For the Confirmation Statement, only the report name and effective date are
mandatory parameters. The common parameters included in the report wrapper are:
Effective Date
Program Name
Plan Not In Program
Organization
Location
Employee Name
Life Event Name
Life Event Date
Comp Object Selection Rule
Business Group
Reporting Group
Service Area
Assignment Type
Person Type
The report also contains configurable regions that can be included or excluded in the output by
setting the below parameter to YES or NO.
These parameters are defaulted to YES.
Display Benefits Selections
Display Flex Credit Summary
Display Suspended Elections
Display Covered Dependents
Display Primary Care Providers
Display Beneficiaries
Display Action Items

Display Certifications
Coverage Start Date
Coverage End Date
Currently, the opening and closing paragraph text are not configurable.
However, once the report is run, you may export the report into another medium to edit. The
report is in a .csv format that can be converted into the desired file format.
Note: This report output is in a postscript file format. Refer to MyOracleSupport Note 117112.1 -
How to read Postscript File Formats on a MS Windows Operating System and Convert To Another
File Format for information on obtaining a postscript interpreter, if needed.

Reconciliation of Premium Contributions to Element Entries Report
This concurrent manager report speeds up the monthly benefits billing reconciliation
process. The report provides a comparison of monthly premium amounts to standard
rates and element entries by pay period for all participants enrolled during the reporting
period. The data displayed in the report is extracted from the Standard and Advanced
Benefits data processing model and includes Enrollment Results and Participant Rate
Value tables on the View Enrollment Results form for a selected plan.
For technical details of this change, see MyOracleSupport Note: 237456.1 About Oracle HRMS
Family Pack E
Reconciliation of Premium Contributions to Element Entries Report
Reporting Start Date 01-OCT-2011

Reporting End Date 31-OCT-2011
Employee Name All
National Identifier All
Employee Name Format Default
Program CLM Flex Program
Plan CLM Aetna PPO Medical Plan
Person Selection Rule None
Organization All
Location All
Benefits Group All
Reporting Group All
Payroll All
Output Type Text
Display Plan Reconciliation Report Yes
Display Plan Discrepancy Report Yes
Display Life Event Report Yes
Display Plan Participant Details Report Yes
Discrepancy*
Standard Rate Amounts Element Entry (Per Pay Period) !
--------------------------------------- --------------------------------------- !
Particip Payr Employee Employee Employer Employee Employee Employer Actual !
Natio Payro ant oll Pre Tax Post Tax Contribu Pay Pre Tax Post Tax Contribu Total !
Partici nal ll Monthly Freq Contribu Contribu tion Period Contribu Contribut tion Contribu !
pant ID Coverage Premium uenc tion tion Total tion on tion !
y
-------- ----- ----- --------- --------- ----- --------- --------- --------- --------- --------- --------- --------- --------- --
Margolis 666- CLM Semi- 86.22 0.00 0.00 86.22 86.22 0.00 0.00 86.22
, 77- Semi- Month
Arkansas 6666 Monthly
Many 528- CLM Bi- 44.78 0.00 0.00 44.78 44.78 0.00 0.00 44.78
Kids, 99- Bi- Week
0007 Weekly
OAB 359- CLM Semi- 140.22 0.00 0.00 140.22 140.22 0.00 0.00 140.22
Class, 98- Semi- Month
Dee Emp 0157 Month
ly
Test 526- CLM Semi- 90.00 0.00 0.00 90.00 90.00 0.00 0.00 90.00
Dependen 63- Semi- Month
t 3148 Month
Medical ly
Brook , 465- CLM Semi- 97.02 0.00 0.00 97.02 97.02 0.00 0.00 97.02
Dep Cvg 91- Semi- Month
Start 7777 Month
Date ly

Further Information:
MyOracleSupport Note 209223.1 - Managing Total Compensation & Benefits Using Oracle HRMS
MyOracleSupport Note 215159.1 Self-Service Benefits Enrollment with Standard and Advanced
Benefits.
Refer to the Sections entitled:
MANAGING ANNUAL ENROLLMENT IN SELF-SERVICE USING UNRESTRICTED PROCESSING and
ADVANCED BENEFITS USERS MANAGING LIFE EVENT & UNRESTRICTED PROCESSING
SIMULTANEOUSLY
MyOracleSupport Note 211557.1 Implementing Oracle Self-Service Human Resources (SSHR) 4.2
Refer to Chapter 17 for the setup of Self-Service Benefits
MyOracleSupport Note 105642.1 How to Extend Payroll Calendar Periods
MyOracleSupport Note 226987.1 Oracle HRMS & Benefits Tuning & System Health Check
Release 11i
MyOracleSupport Note 218059.1 Oracle Fast Formula Reference Guide for Standard and Advanced
Benefits
MyOracleSupport Note 251981.1 Benefits Performance Check Release 11i
Oracle Applications Online Help

Sample Open Enrollment Checklist OAB
SAMPLE for use in open process
Date Pre-Open Enrollment Comments Complete

Tasks d
Check Payroll Calendars
Check Plan Year Periods
Set up Scheduled Life Event
Add Reinstatement Codes to

the Scheduled Life Event
Assess Derived Factors and
Eligibility
End Plans no longer offered
Add new Plans
Add new Options to existing

Plans
Check Self Service Display on
Plan Type (If using SSBEN)
Add Rates to new comp objects
Add Premiums to new comp
objects
Modify Rates on existing comp
objects
Check Self Service Display

Order on Standard rate (If
using SSBEN)
Modify Premiums on existing
comp objects
Modify Elements on Existing
Rates
Modify Links on Existing
Elements
Modify Flex Credits and Benefit
Pools
Review Default Enrollment
Setup
Set up FSA codes for new
coverage
Close unprocessed Life Events
Review Due Date Setup for
the Action Items and Resolve
Any Pending Action items
Check for Previously
Overriden Data (Enrollment
Overrides)

Set Up Collapsing Rules
Process Temporal Events
(Maintain for OSB)
Set up Collapsing Rules
Process Mock Open
Purge Batch Related Tables
Check Max Errors
Analyze Performance
Date Open Enrollment Tasks Comments Complete

d
Process the Open Life Event
Check for errors and resolve
Run the Default Enrollment

Process
Enter participants enrollment
choices
Monitor other life events
occurring during Open
Enrollment
Run the Close Enrollment Process
Print Life Event Summary and
Enrollment Reports
Date Post-Open Enrollment Comments Complete

Tasks d
Verify enrollment
Investigate incorrect elections

and resolve
Monitor other life events

occurring after Open Enrollment
but before 01-Jan.

Print Enrollment Reports
Inactivate Plans That are no

Longer Being offered:

Sample Open Enrollment Checklist OSB
Date Pre-Open Enrollment Comments Complete

Tasks d
Check Payroll Calendars
Check Plan Year Periods
Assess Derived Factors and

Eligibility
End Plans no longer offered
Add new Plans
Add new Options to existing

Plans
Add Rates to new comp objects
Add Premiums to new comp
objects
Modify Rates on existing comp
objects
Modify Premiums on existing

comp objects
Modify Elements on Existing
Rates
Set up FSA codes for new
coverage
Run Maintain Participant
Eligibility
Test Open Enrollment on a
participant sample
Check Max Errors
Analyze Performance

Date Open Enrollment Tasks Comments Complete
d
Enter participants enrollment
choices
Monitor other events occurring
during Open Enrollment that will
modify elections
Date Post-Open Enrollment Comments Complete

Tasks d
Verify enrollment
Investigate incorrect elections

and resolve
Monitor other events occurring

after Open Enrollment but before
01-Jan. Enter necessary
enrollment; re-enter Open
elections
Resolve Action Items
Resolve Certifications
Make necessary Enrollment

Overrides
Inactivate Plans That are no

Longer Being offered

White Paper Title:
Oracle Compensation and Benefits

Open Enrollment Processing
Oracle Advanced Benefits

Oracle Standard Benefits
October 2010
Author: Oracle Support Services
This document is provided for informational purposes

only and the information herein is subject to change
without notice. Please report any errors herein to
Oracle Corporation. Oracle Corporation does not
provide any warranties covering and specifically
disclaims any liability in connection with this document.
Oracle is a registered trademark and Enabling the
Information Age, are trademarks of Oracle Corporation.
Oracle America Inc

World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Copyright Oracle America Inc 2011

All Rights Reserved.

Open Enrollment White Paper V 1 7

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Open Enrollment White Paper V 1 7

Enviado por

Direitos autorais:

Formatos disponíveis

ORACLE COMPENSATION AND

ORACLE ADVANCED BENEFITS

Open Enrollment White Paper Page 2 of 91

Carol Margolis Oracle Support, Senior Analyst

01-Oct-2011 Carol Margolis 1.0 Creation

Kathryn Tucker Senior Product Manager

Open Enrollment White Paper Page 3 of 91

Open Enrollment White Paper Page 4 of 91

Requested Information While Logging Service Request with Oracle Support................8

Open Enrollment Processing......................................................................................9

Phases of Open Enrollment Processing.....................................................................11

Open Enrollment White Paper Page 5 of 91

Phase II: Open Enrollment procedures.....................................................................69

Phase III: Post-Open Enrollment procedures............................................................85

Frequently Asked Questions....................................................................................91

Appendix of Sample Reports....................................................................................99

Sample Open Enrollment Checklist OAB................................................................113

Sample Open Enrollment Checklist OSB................................................................116

Open Enrollment White Paper Page 6 of 91

Requested Information While Logging Service Request with

Open Enrollment Processing

A companys open enrollment period is an opportunity for eligible participants to:

Enroll in a plan if not currently enrolled

Open Enrollment White Paper Page 7 of 91

This period is also the opportunity for a company to:

Abbreviations Used in this Document

OAB Oracle Advanced Benefits

OSB Oracle Standard Benefits

SSBen Self-Service Benefits

Comp object Any compensation object (Program, Plan Type, Plan or

Enrollment form Any of the available enrollment forms: Flex, Non-Flex,

Open Enrollment White Paper Page 8 of 91

Phase Task Audience

Open Enrollment White Paper Page 9 of 91

Open Process the Open Life Event (Batch OAB

Restart a Failed Process

Open Enrollment White Paper Page 10 of 91

MyOracleSupport Note 124100.1 - Compensation and Benefits Patch List

Open Enrollment elections are effective on January 1.

Coverage begins on January 1

Rates begin on January 1.

In this regard, the Coverage and Rate Start/End Codes are:

Sample Timeline For Open Life Event Processing

October (Two months before actual open enrollment)

Run a Mock open enrollment

Open Enrollment White Paper Page 11 of 91

Defaults are applied (Default Enrollment Process)

Open Enrollment White Paper Page 12 of 91

This mock enrollment offers the ability to:

Self Service Setup for Mock Open Enrollment

Open Enrollment White Paper Page 13 of 91

MyOracleSupport Note: 211557.1 Implementing Oracle Self-Service Human Resources (SSHR)

MyOracleSupport Note:215159.1 Self-Service Benefits Enrollment with Standard and

MyOracleSupport Note.228543.1 - How To Date Track In Self Service Benefits:

Open Enrollment White Paper Page 14 of 91

Total Compensation Wizard provides you ability to:

There are 7 Tasks available to peform the above-mentioned actions:

Note 330033.1 outlines the details of each task.

Phase I: Pre-Open Enrollment Procedures

Check payroll calendar

Open Enrollment White Paper Page 15 of 91

Rates would not calculate correctly, and deductions could be incorrect.

Check plan year periods