Just a word of thanks for the excellent response on my last query!

We are trying to migrate existing element entries into OAB Flex benefit Plans. Is there any other way other than using the Configuration Workbench to load these (maybe through api's)?

Thanks
Francois

Hello again Francois

Well in a word, 'yes'. There are OAB APIs which will theoretically allow you to set up Flex ben info - if you have access to TOAD or similar, use a 'dictionary' window to look for packages of the form 'BEN%API'. If you do it right, the creation of the participant rate value will automatically generate the element entry. That is sometimes a big IF...

You're probably aware that Metalink has documentation on the subject of migration of OAB. All I would add is this: If you are doing an OAB migration, make sure that you pick the right strategy and stick to it! Also, bear in mind that several of the APIs are, shall we say, 'a little immature'. Check out the various OAB threads in the other topic headings on here...

I'm not sure I've helped here, but maybe some of our other OAB-experts might chip in.

Cheers

Clive

Hi

In addition to the above reply from CT, some stuff from my underground archives :
Author is Lynda Tollefson. OAB product manager in Oracle
Source courtesy : Greg Clark's HRMS US list.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

The first set of Apis mentioned are used to load historical elections please refer to the Converting Election Data into Standard and Advanced Data white paper <Note:217881.1>.

APIs that converts the enrollments, adds dependents and beneficiaries as listed here -

1. Ben_prtt_enrt_result_api.create_prtt_enrt_result (this API procedure
will create an enrollment in a benefit plan)

2. Ben_elig_cvrd_dpnt_api.create_elig_cvrd_dpnt (this API procedure
will attach covered dependents to the primary participant)

3. Ben_plan_beneficiary_api.create_plan_beneficiary (this API procedure
will create designated beneficiary for each plan enrollment)

>>>>>>>

The second set is the method used to convert current enrollment elections from a legacy system and is the recommended method to use for converting elections for OAB.

1. ben_election_information.election_information_w first & then
ben_proc_common_enrt_rslt.process_post_enrt_calls_w

2. ben_elig_dpnt_api.process_depend_w first & then
ben_elig_cvrd_dpnt_api.dpnt_actn_items_w

3. ben_plan_beneficiary_api.create_plan_beneficiary_w

>>>>>>>>

1. What are the advantages/disadvantages of using one set of APIs over the other?

The second method in note 276825.1 Creating Enrollment Results Using Life<> Events for Oracle Advanced Benefits APIs is the recommended approach and the reasons why are below:
* Simplified process. As the number of api's very few.
* This method takes advantage of and validates your setup(biggest plus),
* These are the same api's used in ssben and forms.
* Can be used to supplement any existing data cleaning process
* Allows you to back-out elections loaded by mistake
* Allow you to use the regular program enrollment or override forms to correct or change enrollment as needed
* By processing a life event, you will be able to enroll people into eligible benefits that they are allowed to elect based on the life event.
* Extremely low risk as far as data corruption is concerned.


The Second method is highly desirable and recommended as it as it requires you to process a life event to create enrollment opportunities (electable choices), which are then used to load the enrollment elections via the API calls, due to that a large amount of setup validation is done at the time of conversion, with added value of using seeded forms to make adjustments(backouts, override ect).

>>>>>>>>>>
cheers
Vin

The Second method fits in with are current approach, and looks promising!

Thanks again for your valued contribution!