Wednesday, March 21, 2012

Oracle OAB Enrollments Conversion Steps

Oracle Standard and Advanced Benefits Conversion Steps:-

 

Pre - Conversion Steps

 

The following pre and post conversion steps apply to all methods discussed in the introduction. You may add more steps to customize to you implementation. These steps will help you prepare for your conversion processing. Some of these items were included in the implementation strategy and planning but are restated here with additional steps to give you a comprehensive picture of the conversion process. Case studies will follow in each section that describe different variations on the conversion process

1.     Choose implementation strategy i.e.) new elections or conversion
2.     Analyze Enrollment Information and Map Source to Target. Determine current benefits. Analyze content and format of source enrollment data. - Identify the meaning and format of existing person enrollment data to be converted and map it to HR OAB data.  Information to consider includes person elections, covered dependents, and beneficiaries.
3.     Analyze Employees and contacts – For the HR conversion of people – if one is needed determine for each employee or former employee to be converted, at what stage the person is in the employment process.  Determine which person contacts need to be added.  Determine if any contacts became employees.  This will determine which HR APIs will be used and the order in which they will be used to create the people being converted in the appropriate employment or contact status and appropriate person types.  Examples:

 
Person Situation
Employment Status
Current Employees (New Hire)
Active Employee
Rehire
Active Employee
Paid LOA
Employee on Paid Leave of Absence
Paid LOA
Employee on Short Term Disability
Unpaid LOA
Employee on Unpaid Leave of Absence
Unpaid LOA
Employee on Long Term Disability
Termination
Terminated Employee
Termination
Terminated with Severance
Termination
Terminated Layoff
Termination
Terminated due to Gross Misconduct
Death
Deceased Employee
Return from LOA
Active Employee
Termination
Terminated Retiree
Employee Spouse
Contact
Employee Child
Contact
Surviving Spouse
Surviving Spouse
Disabled Surviving Spouse
Surviving Spouse
Surviving Child
Surviving Dependent
Former Spouse
Former Spouse
Child of a Divorced Parent
Former Dependent



Note:  If converting contacts, i.e. populating the PER_CONTACT_RELATIONSHIPS table, be certain to populate the following columns: Personal_flag on table – Must always populate this column if intend to designate this contact as a dependent or beneficiary.
Rltd_per_rsds_w_dsgntr_flag or provide an address for the contact.
4.     Gather counts from current enrollments to get total enrollments in programs, plans, plan types, and options. Also record benefit amounts and any other pertinent enrollment data. Prepare a spreadsheet for reference during and after conversion.
5.     Plan processing times and batches related to your total enrolled population. If you run other applications you may need to schedule your batches with the DBA. Running sample or test conversions will help you estimate time to process.
6.     Analyze People with Life Events in Progress - Conversion data is a snapshot of data as of a specific date, whereas people and their benefits may be in transition.  It is necessary to identify which people have a Life Event in progress, e.g. people such as New Hires, Newly Married, and Transfers, who are allowed to make changes to their benefits as of the Conversion Date.  These people may need special treatment or processing i.e.)OSB customers will process these people manually by either having the person make elections before or after the conversion date
7.     Determine the date when the conversion takes place. From this date forward you will use OAB or OSB to administer benefits.
8.     If OAB you must disable the benefits life event triggers before conversion process begins.  A “Disable Life Event Data Triggers” step is described below.  Note that even if no data is attached to the life events that are defined, turning off the triggers will save time in populating the data and later when running the participation processes.  Set the pay_action_parameters to include data_migrator_mode = P to turn off the life event triggers during the conversion process. Navigation:  Processes and Reports > Maintain Process Parameters. The value is then used to check whether the potential life events need to be created or not.
9.      Setup an Administrative life event if OAB on the Program Enrollment Requirements > Timing > Scheduled tab or unrestricted event if OSB. The assigned life event date must be set to the date you want the conversion to take place. Close enrollment date should be When Enrollment Period Ends and the plan year must coincide with your assigned life event date.
10.  Verify that NO default enrollment requirements are defined for the Administrative life or life event being used. This means you will need to make sure no default enrollment requirements are specified. In this conversion you are explicitly choosing what the participant will be enrolled in from the electable choices created by the life event.
11.  Make sure all Person, Assignment, and Contact data is accurately stored in the appropriate HR tables. The participation process can only evaluate date stored in PER tables within Oracle HRMS.
12.  Run the conversion manually on a test sample to ensure all dates and amounts are correct. If all is correct you can proceed to the steps in the appropriate sections.

 

 Post - Conversion Steps


1.     Compare your counts from original enrollments to track down any issues
2.     Close the administrative Life event
3.     Manage Life Events in Progress - Post Conversion. Create Potential Life Events OAB customers who decide to delay processing these peoples’ life events will need to manually create the potential life event for these people; because the change detected that caused the life event happened before conversion.  For example, Tomy moved from Boston to San Francisco on 15-June-2000 and as a result is experiencing a "Relocation" life event which allows him to change medical plans any time between 15-June-2011 and 15-July-2011.  As of the conversion date, 1-July-2011, Tomy is already living in San Francisco.  The customer needs to create a "potential" life event of Relocation for Tomy, so that when processing is done in OAB, Tomy’s Relocation will started and Tomy will be allowed to make new elections as applicable and as determined according to the plan design setup.
a.     To manually create potential life events for persons who had a life event in progress as of the conversion date, use the Person Life Event professional interface form, Potential Life Events tab.  Select the Name of the applicable Life Event.  Enter the Notified Date and Occurred on Date.  Enter the Status as Unprocessed and enter the Unprocessed Date.  Each of these dates is the same as the date the Life Event Occurred.  The customer may want to set the Notified Date to one day after the conversion date and the Enrollment Period Start Date codes such that the person will have more time to make choices.  These potential events will then be evaluated in the subsequent run of the Participation Process.
4.     Turn Life event triggers back on

No comments:

Post a Comment