Open Enrollment White Paper V 1 7

ORACLE COMPENSATION BENEFITS
AND
OPEN ENROLLMENT PROCESSING

AND
PLAN DESIGN MAINTENANCE
ORACLE ADVANCED BENEFITS ORACLE STANDARD BENEFITS
Author: Version: Last Updated:
Oracle Support Services 1.7 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 92
Contributors
Name Carol Margolis Philip Chapman Lynda Tollefson Doug Sterchi Kathryn Tucker Marie Maderis Kathy Marlow Srilatha Shanigarapu David Manoharan Marce Clarkson Deborah Clement Position Oracle Support, Senior Analyst Oracle Development, Senior Product Manager Principal Product Manager Total Compensation Oracle Consulting, Principal Consultant Oracle Consulting, Principal Consultant Oracle Support, Support Engineer Oracle Support, Support Engineer Oracle Support, Principal Technical Support Engineer
Change Record
Date 01-Oct-2011 23-Aug-05 31-Oct-05 15-Aug Author Carol Margolis Kelly McClain Lynda Tollefson Kelly McCLain, Ashton Kawanishi Version 1.0 1.1 1.2 1.3 Creation Added Reinstatement functionality, default modifications, period determination codes, mocks steps, changed mock recommendations. Updated recommended practices for Open 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. Modified the Flow of Document, Added Several New Sections Added Total Compensation Wizard. Check and Clean Up for Previously Detected Temporal And Other Life Events Added Script for identifying pending action items Corrected Run Analyze and Gather Statistics section Review and update of complete document Change Reference
28-Jul-09 29-Aug-2009 16-Sep-2009
Srilatha Shanigarapu Srilatha Shanigarapu Srilatha Shanigarapu
1.4 1.5 1.6
12-Oct-2010 15-Jul-2011
Marce Clarkson Srilatha Shanigarapu
1.6 1.7
Approvers
Name Kathryn Tucker Phil Chapman Lynda Tollefson Position Senior Product Manager Oracle Development; Senior Product Manager Principal Product Manager Total Compensation
Page 3 of 92
Feedback
Name Srilatha.Shanigarapu@oracle.com Position
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.
Page 4 of 92
Table of Contents Contents

Contributors..........................................................................................................3 Change Record.......................................................................................................3 Approvers..............................................................................................................3 Feedback...............................................................................................................4 CONTENTS...........................................................................................................................................................5 Minimum Baseline Patching Requirement ..................................................................8 Requested Information While Logging Service Request with Oracle Support................8 Open Enrollment Processing......................................................................................8 Phases of Open Enrollment Processing.....................................................................10 Sample Timeline For Open Life Event Processing...................................................12 Mock Open Enrollment..........................................................................................14 Self Service Setup for Mock Open Enrollment........................................................14 Using Total Compensation Wizard To Review /Modify and Update Program and Plan Design.................................................................................................................16 Check payroll calendar.........................................................................................16 Check plan year periods........................................................................................17 Verifying Plan Year Periods and Complete Plan Design using Total Compensation Wizard.................................................................................................................17 Update Plan Year Periods using Total Compensation Wizard...................................18 Add the Scheduled Life Event to the Program........................................................18 Adding Scheduled Life Event to the Program using Total Compensation Wizard......21 Add Reinstatement Codes to the Scheduled Life Event ..........................................22 Assess and Modify Derived Factors and Eligibility..................................................24 Assess and Modify Derived Factors and Eligibility Using Total Compensation Setup Wizard.................................................................................................................25 End Existing Plans That Are No Longer Being Offered.............................................25 Ending Existing Plans Using Total Compensation Setup Wizard...............................26 End Existing Options That Are No Longer Being Offered.........................................26 End Existing Options That Are No Longer Being Offered Using Total Compensation Setup Wizard.......................................................................................................27 Add New Plans.....................................................................................................28 Add New Plans/Update Existing Plans Using Total Compensation Setup Wizard.......30 Add New Options to Existing Plans........................................................................30 Add New Options /Update Existing Options Using Total Compensation Setup Wizard ...........................................................................................................................31 Check Self Service Display on Plan Type (If using SSBEN).......................................31 Add New Rates to New Comp Objects....................................................................31 Add New Rates to Plans using Total Compensation Setup Wizard............................31 Add Premiums to New Comp Objects.....................................................................31 Modify Rates and Premiums on Existing Comp Objects ..........................................32 Check Self Service Display Order on Standard rate (If using SSBEN).......................33 Mass Update of Rates Using Total Compensation Wizard .......................................35 Modify Elements on Existing Rates........................................................................36 Modify Links on Existing Elements.........................................................................36
Page 5 of 92
Flex Credits and Benefit Pools...............................................................................37 Review Default Enrollment Setup..........................................................................39 Review Default Enrollment Setup Using Total Compensation Setup Wizard.............39 Start New Coverage for Flexible Spending Accounts (FSA).....................................39 Close Unprocessed Life Events..............................................................................43 Check and Clean Up for Previously Detected Temporal And Other Life Events..........44 Review Due Date Setup for the Action Items and Resolve Any Pending Action items ...........................................................................................................................45 Check for Previously Overridden Data (Enrollment Overrides)................................46 Set Up Collapsing Rules........................................................................................47 Processing Temporal Events.................................................................................48 Purge Batch Related Tables .................................................................................49 Evaluate Size of Eligibility Tables..........................................................................51 Set Max errors.....................................................................................................51 Performance Testing............................................................................................52 Phase II: Open Enrollment procedures.....................................................................55 Process the Open Life Event..................................................................................55 Processing Open Life event for single person from Benefits Service Center.............56 Maintain Participant Eligibility..............................................................................57 Recalculate Participant Values .............................................................................57 Check for Errors and Resolve................................................................................57 Monitor a Started Process.....................................................................................58 Restart a Failed Process.......................................................................................58 Default Enrollment Process...................................................................................58 Enter Participants Enrollment Choices..................................................................60 Processing Life Events That Occur Within the Open Enrollment Period....................61 Back Out the Open Life Event (if needed)..............................................................64 Open Enrollment Window Modification* ..............................................................64 Close the Open Life Event.....................................................................................65 Reopen life event batch process*..........................................................................66 Phase III: Post-Open Enrollment procedures............................................................67 Verify Enrollment data (new plans, check defaults and automatic)..........................67 Investigate Incorrect Elections..............................................................................67 Processing Life Events That Occur After the Open Enrollment Period, but Before the New Plan Year......................................................................................................68 Print Enrollment Reports and Confirmation Statements:.........................................69 Inactivate Plans that are no Longer Being offered:.................................................70 Frequently Asked Questions....................................................................................71 Oracle Advanced Benefits (OAB)............................................................................71 Oracle Standard Benefits (OSB).............................................................................74 Questions Applicable to both OAB and OSB............................................................75 Questions applicable to SSBEN..............................................................................75 Appendix of Sample Reports....................................................................................76 Eligibility and Enrollment List ...............................................................................76 ..........................................................................................................................77 Life Event Summary Report ..................................................................................78 ..........................................................................................................................80 Benefits Enrollment Kit Report..............................................................................80 Benefits Confirmation and Summary Report .........................................................82 Sample Open Enrollment Checklist OAB.................................................................87
Page 6 of 92
Sample Open Enrollment Checklist OSB.................................................................90
Page 7 of 92
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 EBusiness 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
Page 8 of 92
year)
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 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 OSB SSBen Comp object Enrollment form PUI TCW Oracle Advanced Benefits Oracle Standard Benefits Self-Service Benefits Any compensation object (Program, Plan Type, Plan or Option) Any of the available enrollment forms: Flex, Non-Flex, Miscellaneous, Savings Plan Professional User Interface or Forms Total Compensation Setup Wizard
Unless noted otherwise by Audience: OAB or Audience: OSB, the procedures included in this document apply to both benefit models.
Page 9 of 92
Phases of Open Enrollment Processing

Open Enrollment procedures can be divided into three phases: Pre-Open Enrollment Open Enrollment Post-Open Enrollment
Phase
Pre-Open Enrollment
Task
Audience
Check Payroll Calendars Check Plan Year Periods Add the Scheduled Life Event to the Program
Add Reinstatement Codes to the Scheduled Life Event
OAB and OSB OAB and OSB OAB OAB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB and OSB OAB OAB OAB and OSB note the separate procedures OAB OAB
Assess and Modify Derived Factors and Eligibility End Existing Plans That Are No Longer Being Offered Add New Plans to the Programs 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 and Premiums on Existing Comp Objects
Check Self Service Display Order on Standard rate (If using SSBEN) Mass Update of Rates Using Total Compensation Wizard
Modify Elements on Existing Rates

Modify Links on Existing Elements
Modify Flex Credits and Benefit Pools

Review Default Enrollment Setup
Start New Coverage for Flexible Spending Accounts (FSA) Close Unprocessed Life Events
Check and Clean Up for Previously Detected Temporal And Other Life Events Review Due Date Setup for the Action Items and Resolve Any Pending Action items Check for Previously Overriden Data
OAB OAB and OSB

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

Check for Errors and Resolve Monitor a Started Process Restart a Failed Process
Run Default Enrollment Process Enter Participants Enrollment Choices Processing Life Events That Occur Within the Open Enrollment Period
Open Enrollment Window Modification*(If Needed)
OAB OAB and OSB OAB and OSB (note the separate procedures) OAB OAB and OSB (note the separate procedures) OAB OAB and OSB OAB and OSB OAB and OSB (note the separate procedures) OAB and OSB OAB and OSB
Back Out the Open Life Event (if needed) Close the Open Life Event Post-Open Enrollment Verify enrollment Investigate and Correct Elections Process Events That Occur After the Open Enrollment Period, but Before the New Plan Year Inactivate Plans that are no Longer being offered Print Enrollment Reports
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.
Page 11 of 92
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 selfservice 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.
Page 12 of 92
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.
Page 13 of 92
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, selfservice, 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 selfservice, 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. It is very important to verify that Self Service Benefits is set up correctly for employee enrollments.
Page 14 of 92
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 selfservice 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:
Page 15 of 92
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.
Page 16 of 92
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 31Dec-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
Page 17 of 92
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. Navigation: Total Compensation > Total Compensation Setup Wizard Business Area: Health and Welfare Program 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
Page 18 of 92
Enrollment Type: Enrollment or Availability Period:
Open 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.
Page 19 of 92
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: Enrollment Coverage End Date: Rate dropdown box: Enrollment Rate Start Date: Enrollment Rate End Date: As of Event Date One Day before Event As of Event 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.
Page 20 of 92
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. Navigation: Total Compensation > Total Compensation Setup Wizard Business Area: Health and Welfare Program 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.
Page 21 of 92
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
Page 22 of 92
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.
Page 23 of 92
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
Page 24 of 92
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 Navigation: Total Compensation > Total Compensation Setup Wizard 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 31Dec-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.
Page 25 of 92
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 deenrollments are done Or if you want to use Eligibility method you can use Task 4-Eligibility to modify eligibility.
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)
Page 26 of 92
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> 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 31Dec-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 Where enrt_cvg_thru_dt = 31-Dec-4712 And pl_id = <enter pl_id> and oipl_id = 'Enter option in plan id '; (It should return no rows)
End Existing Options That Are No Longer Being Offered Using Total Compensation Setup Wizard
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 deenrollments are done Or if you want to use Eligibility method you can use Task 4-Eligibility to modify eligibility.
Page 27 of 92
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-Jan2012. 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-Jan2011 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:
Page 28 of 92
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 01Nov-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. 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 01Nov-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) 9. Total Compensation > Eligibility Profiles > Participant 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.
4.
Page 29 of 92
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.
Page 30 of 92
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) 9. Total Compensation > Eligibility Profiles > Participant 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 Compensation Setup Wizard
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
Page 31 of 92
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) Navigation: Total Compensation > Rate/Coverage Definitions > Standard Rates 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
Page 32 of 92
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.
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 Cost1 Cost2 Cost3 Cost4 Criteria Tax Type - PRETAX, NOTAPPLICABLE (the latter handles cases where only one 'Not Applicable' tax type rate is defined)** Tax Type AFTERTAX Activity Type - Self Service Display 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.
Page 33 of 92
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)
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.
Page 34 of 92
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:
Page 35 of 92
Modify Elements on Existing Rates

Navigation: Total Compensation > Rate/Coverage Definitions > Standard 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 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.
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. 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. 1. 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.
Page 36 of 92
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 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. 1. 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 Navigation: Total Compensation > Rate/Coverage Definitions > 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) 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.
End Existing Flex Credits Navigation: Total Compensation > Rate/Coverage Definitions > 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
Page 37 of 92
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.
Page 38 of 92
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.
Page 39 of 92
===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 deenrolled 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-Jan2012. Audience: OSB
Page 40 of 92
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:
Page 41 of 92
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:
Page 42 of 92
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.
Page 43 of 92
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 reevaluated.
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')
Page 44 of 92
and and and and
trunc(sysdate) between ler.effective_start_date and ler.effective_end_date ppf.business_group_id = :p_business_group_id ppt.business_group_id = :p_business_group_id 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)
Page 45 of 92
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: **************************Beginning of Script************************* 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
Page 46 of 92
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: **************************Beginning of Script************************* 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
Page 47 of 92
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 4 -Life event Open Jan 1 2006 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
Page 48 of 92
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
Page 49 of 92
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 o o o o o o o o o o Close Action Items Process Close Enrollments Process Default Enrollment Process Participation Process: Life Event Participation Process: Scheduled Participation Process: Selection Participation Process: Temporal Temporal Communications (Action Item Reminder) Temporal Communications (Emerging Events) Temporal Communications (Enrollment Reminder) 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 o o o BEN_REPORTING BEN_PERSON_ACTIONS BEN_BENEFIT_ACTIONS 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.
Page 50 of 92
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
Page 51 of 92
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, selfservice, and performance long before the official open enrollment begins. Not doing so will defer 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.
Page 52 of 92
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
Page 53 of 92
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
Page 54 of 92
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: Detect Temporal: Person Type: Life Event Occurred Date: Audit Log: The first day of your Open Enrollment period (01-Nov-2011 in our example). See discussion under Processing Temporal Events May want to select Employee or Participant to exclude terminated or non-Cobra enrolled dependents Select the date that corresponds with your Open life event (example: 01-Jan-2012). 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.
Page 55 of 92
PROCESSING SUMMARY Number of participants successfully processed Number of participants processed in error Number of participants unprocessed ========== Total number of participants selected 8670 8600 60 10
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.
Page 56 of 92
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
Page 57 of 92
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:
Page 58 of 92
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 01nov-XX and default process should be run For example: Step 1 Run Participation Process: Scheduled Step 2 Run Default Enrollment Process
Page 59 of 92
Enter Participants Enrollment Choices

Audience: OAB and OSB 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.
Page 60 of 92
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 (01Nov 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.
Page 61 of 92
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.
Page 62 of 92
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.
Page 63 of 92
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 > Backout 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.
Page 64 of 92
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.
Page 65 of 92
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.
Page 66 of 92
Phase III: Post-Open Enrollment procedures

Verify Enrollment data (new plans, check defaults and automatic)
Audience: OAB and OSB 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

Audience: OAB and OSB 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
Page 67 of 92
Processing Life Events That Occur After the Open Enrollment Period, but Before the New Plan Year
Audience: OAB and OSB 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
Page 68 of 92
Event Event Event Event
2 -Life event Open Jan 1 2005 3 -Relocation event June 2005 4 -Life event Open Jan 1 2006 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.
Page 69 of 92
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 Where enrt_cvg_thru_dt = 31-Dec-4712 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.
Page 70 of 92
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
Page 71 of 92
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.
Page 72 of 92
(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 Restart Restart Restart Restart Closed Enrollment Default Process Determine Communications Participation Process 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>;
Page 73 of 92
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
Page 74 of 92
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
Page 75 of 92
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 deenrolled 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 Enrolled by Automatic Enrolled by Data Load Enrolled by Enrolled by Enrolled by Newly DeDefault Explicit Override Enrolled
------------- ------------- ------------- ------------- ------------- ------------- ------------- ------------CLM Aetna PPO Medical Plan CLM Cigna PPO CLM Kaiser Med (Florida) CLM Kaiser Med (Illinois) 464 111 6 105 0
164 21
8 1
8 1
0 0
124
Page 76 of 92
Current Enrollment by CLM Medical Plan

Employee + Spouse Employee Only Employee Plus Employee Plus Children Family Total
------- -------- ------- -------- ------- -------- ------- -------- ------------------CLM Aetna PPO 26 23.21% 66 58.93% 10 8.93% 10 8.93% Medical Plan CLM Cigna PPO CLM Kaiser Med (Florida) CLM Kaiser Med (Illinois) CLM Kaiser Permanente for 2002 CLM United Healthcare Total: 1 0.00% 1 100.00% 0.00% 8.33% 9 8 100.00% 0.00% 4 100.00% 75.00% 1 0.00% 0.00% 0.00% 8.33% 1 0.00% 0.00% 0.00% 8.33% 8 1 4 12
112
73.68%
5.26% 0.66% 2.63% 7.89%
13.33%
13
86.67%
0.00%
0.00%
15
9.87%
------- -------- ------- -------- ------- -------- ------- -------- --------- --------30 19.74% 100 65.79% 11 7.24% 11 7.24%
152
100.00%
Eligible by Plan & Option Domestic Partner Employee + Spouse Employee Only Employee Plus Children Family Employee Plus
--------------- --------------- --------------- --------------- --------------ABC Medical Another new plan for 2012 CLM Aetna PPO Medical Plan CLM Cigna PPO CLM Kaiser Med (Florida) CLM Kaiser Med (Illinois) 71 111 3 111 3 111 3 3 111
337
337
337
337
164 20
164 20
164 20
164 20
116
124
116
116
Page 77 of 92
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
Page 78 of 92
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 --------- ------------- -------------- ----------- --------Open 100 0 0 1 101 Total
--------- ------------- -------------- ---------- -------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
Page 79 of 92
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 Person Selection Rule 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
Page 80 of 92
Display Display Display Display
Action Items Certifications Electable Choice Flexfields 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.
Page 81 of 92
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 Person Selection Rule 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
Page 82 of 92
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.
Page 83 of 92
Page 84 of 92
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 Semi86.22 0.00 0.00 86.22 86.22 0.00 0.00 86.22 , 77- SemiMonth Arkansas 6666 Monthly Many Kids, 528- CLM 99- Bi0007 Weekly BiWeek 44.78 0.00 0.00 44.78 44.78 0.00 0.00 44.78
OAB 359- CLM Class, 98- SemiDee Emp 0157 Month ly Test 526- CLM Dependen 63- Semit 3148 Month Medical ly Brook , 465- CLM Dep Cvg 91- SemiStart 7777 Month Date ly
SemiMonth
140.22
0.00
0.00
140.22
140.22
0.00
0.00
140.22
Semi90.00 Month
0.00
0.00
90.00
90.00
0.00
0.00
90.00
Semi97.02 Month
0.00
0.00
97.02
97.02
0.00
0.00
97.02
Page 85 of 92
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
Page 86 of 92
Sample Open Enrollment Checklist OAB

SAMPLE for use in open process
Date
Pre-Open Enrollment Tasks

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)
Comments
Complete d
Page 87 of 92
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

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
Comments
Complete d
Date
Post-Open Enrollment Tasks

Verify enrollment Investigate incorrect elections and resolve Monitor other life events occurring after Open Enrollment
Comments
Complete d
Page 88 of 92
but before 01-Jan. Print Enrollment Reports Inactivate Plans That are no Longer Being offered:
Page 89 of 92
Sample Open Enrollment Checklist OSB

Date Pre-Open Enrollment Tasks
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
Comments
Complete d
Page 90 of 92
Date
Open Enrollment Tasks

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

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 Print Enrollment Reports Inactivate Plans That are no Longer Being offered
Comments
Complete d
Page 91 of 92
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.
Page 92 of 92

Open Enrollment White Paper V 1 7

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Open Enrollment White Paper V 1 7

Uploaded by

Copyright:

Available Formats

ORACLE COMPENSATION BENEFITS

OPEN ENROLLMENT PROCESSING

PLAN DESIGN MAINTENANCE

ORACLE ADVANCED BENEFITS ORACLE STANDARD BENEFITS

Author: Version: Last Updated:

Oracle Support Services 1.7 July 15, 2011

Open Enrollment White Paper

28-Jul-09 29-Aug-2009 16-Sep-2009

Srilatha Shanigarapu Srilatha Shanigarapu Srilatha Shanigarapu

1.4 1.5 1.6

Marce Clarkson Srilatha Shanigarapu

Open Enrollment White Paper

Open Enrollment White Paper

Table of Contents Contents

Open Enrollment White Paper

Open Enrollment White Paper

Sample Open Enrollment Checklist OSB.................................................................90

Open Enrollment White Paper

Minimum Baseline Patching Requirement

Requested Information While Logging Service Request with Oracle Support

Open Enrollment Processing

Open Enrollment White Paper

Abbreviations Used in this Document

Open Enrollment White Paper

Phases of Open Enrollment Processing

Modify Elements on Existing Rates

Modify Flex Credits and Benefit Pools

OAB OAB and OSB

Open Enrollment White Paper

(Enrollment Overrides) Set Up Collapsing Rules

Recalculate Participant Values

Open Enrollment White Paper

Sample Timeline For Open Life Event Processing

Open Enrollment White Paper

Open Enrollment White Paper

Mock Open Enrollment

Self Service Setup for Mock Open Enrollment

Open Enrollment White Paper

Open Enrollment White Paper

Phase I: Pre-Open Enrollment Procedures

Check payroll calendar

Open Enrollment White Paper

Check plan year periods

Open Enrollment White Paper

Update Plan Year Periods using Total Compensation Wizard

Add the Scheduled Life Event to the Program

Open Life Event: Processing Dates

Open Enrollment White Paper

Enrollment Type: Enrollment or Availability Period:

Open Add your Open Enrollment period. Example: 01-Nov-2011 to 30-Nov-2011

Open Enrollment White Paper

Open Enrollment White Paper

Open Enrollment White Paper

Add Reinstatement Codes to the Scheduled Life Event

Open Enrollment White Paper

Open Enrollment White Paper

Open Life Event: Reinstatement Codes

Assess and Modify Derived Factors and Eligibility

Open Enrollment White Paper

End Existing Plans That Are No Longer Being Offered

Open Enrollment White Paper

Ending Existing Plans Using Total Compensation Setup Wizard