Académique Documents
Professionnel Documents
Culture Documents
AND
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
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
12-Oct-2010 15-Jul-2011
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
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
Page 7 of 92
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.
Unless noted otherwise by Audience: OAB or Audience: OSB, the procedures included in this document apply to both benefit models.
Page 9 of 92
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
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
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
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.
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
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.
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)
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.
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.
Page 18 of 92
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
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
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.
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
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.
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.
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)
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.
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
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.
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.
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.
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.
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
Page 35 of 92
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.
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
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
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
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.
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*************************
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 )
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
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.
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
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
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.
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 >
Page 59 of 92
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
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
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.
Page 66 of 92
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
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.
Page 69 of 92
Page 70 of 92
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
(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
Page 75 of 92
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
------- -------- ------- -------- ------- -------- ------- -------- ------------------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%
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
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 by Life Event Name - Processed - 01-JAN-2012 - 01-JAN-2012 Started Processed Backed Out Voided --------- ------------- -------------- ----------- --------Open 100 0 0 1 101 Total
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
Page 80 of 92
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
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
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
Date
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
Comments
Complete d
Date
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
Comments
Complete d
Page 90 of 92
Date
Comments
Complete d
Date
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