This page (revision-37) was last changed on 26-Nov-2021 10:22 by rforbes

This page was created on 26-Nov-2021 10:22 by JEscott

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
37 26-Nov-2021 10:22 20 KB rforbes to previous BSS_EVIDENCE_REQ(System_Preference) ==> BSS EVIDENCE REQ(System_Preference)
36 26-Nov-2021 10:22 20 KB jmyers to previous | to last BSS D REASON REQ ==> BSS D REASON REQ(System_Preference)
35 26-Nov-2021 10:22 20 KB jmyers to previous | to last BSS_EVIDENCE_REQ ==> BSS_EVIDENCE_REQ(System_Preference)
34 26-Nov-2021 10:22 20 KB jmyers to previous | to last
33 26-Nov-2021 10:22 20 KB jmyers to previous | to last
32 26-Nov-2021 10:22 20 KB jmyers to previous | to last
31 26-Nov-2021 10:22 29 KB jmyers to previous | to last
30 26-Nov-2021 10:22 32 KB jmyers to previous | to last
29 26-Nov-2021 10:22 35 KB jmyers to previous | to last
28 26-Nov-2021 10:22 37 KB jmyers to previous | to last
27 26-Nov-2021 10:22 37 KB jmyers to previous | to last
26 26-Nov-2021 10:22 38 KB jmyers to previous | to last
25 26-Nov-2021 10:22 39 KB jmyers to previous | to last
24 26-Nov-2021 10:22 43 KB jmyers to previous | to last
23 26-Nov-2021 10:22 43 KB jmyers to previous | to last
22 26-Nov-2021 10:22 43 KB jmyers to previous | to last
21 26-Nov-2021 10:22 43 KB jmyers to previous | to last

Page References

Incoming links Outgoing links
OPEN ENROLLMENT SET UP
OPEN ENROLLMENT SET UP

Version management

Difference between version and

At line 2 changed 3 lines
!!!STEPS TO SETTING UP OPEN ENROLLMENT
!!Open Enrollment Setup
!!!OPEN ENROLLMENT SET UP
At line 7 changed one line
!Step 1: IBPT – Define Benefit Plan Types
!!Step 1: IBPT – Define Benefit Plan Types
At line 10 changed 4 lines
;[Sequence|CALCULATION_SEQUENCE]:The Calculation Sequence field determines the order in which this plan type will be processed by payroll. This sequence is also used by the BSS module to determine the order the plan types are displayed to the employee in the election form ([WEBOEE]). If a sequence is not defined, the plan types will display in alphabetical order. Calculation_Sequence is a 5-digit numeric field provided but may be user altered.
;[Sequence|CALCULATION_SEQUENCE]:The Calculation Sequence field determines the order in which this plan type will be processed by payroll. This sequence is also used by the BSS module to determine the order the plan types are displayed to the employee in the election form ([WEBOEE]). If a sequence is not defined, the plan types will display in alphabetical order. This sequence is automatically provided, but may be altered.
At line 19 changed 13 lines
;Sequence:A sequence should be defined as this will determine the order the plan types are displayed to the employee in the election form. If a sequence is not defined, the plan types will display in alphabetical order.
;Recipient Type:This can be used to define a recipient type if all of the plans linked to the plan type allow the same type of recipient to be enrolled. If an employee is only allowed to elect themselves in the plan, ‘Not Applicable’ should be used. If the plans allow for different participant types a recipient type can be defined at the coverage level.
;Plan Type URL:A URL can be defined to provide the employees with a link to external documentation that may provide additional information on each plan within the plan type, or to a carrier’s website. This will be displayed on the SS election form beneath the Election Intro ext.
;Description:Ensure a description has been defined and is reflective of the plans within the plan type as this will be visible in WEBOEE. Basic HTML tags can be used to tailor the look of the text.
;Election Intro Text:This field is used to include introductory text to the plans. This can be used to provide additional instructions to employees. Basic HTML tags can be used to tailor the look of the text.
!Step 2: IMLN- Maintain Lexicons
!!Step 2: IMLN- Maintain Lexicons
At line 19 added 2 lines
!!Step 3: IMST – Define Client Site Information
By default decline reasons are required; however, if it is a client’s policy not to require reasons for declines, the site preference [BSS D REASON REQ|BSS D REASON REQ(System_Preference)] must be defined in [IMST] with a value of N.
At line 37 changed 2 lines
!Step 3: IMST – Define Client Site Information
By default decline reasons are required; however, if it is a client’s policy not to require reasons for declines, the site preference [BSS D REASON REQ] must be defined in [IMST] with a value of N.
The site preference [BSS EVIDENCE REQ(System_Preference)] may be defined with a value of Y to force an employee to provide Evidence/Documentation during the Open Enrollment before they can submit their elections. If this is defined with a Y a validation message will be displayed to the employee. If a value of N is provided, the employee will still be prompted to submit evidence however they will still able to submit their elections if no evidence is uploaded.
At line 40 changed 3 lines
The site preference [BSS_EVIDENCE_REQ] may be defined with a value of Y to force an employee to provide Evidence/Documentation during the Open Enrollment before they can submit their elections. If this is defined with a Y a validation message will be displayed to the employee. If a value of N is provided, the employee will still be prompted to submit evidence however they will still able to submit their elections if no evidence is uploaded.
!Step 4: IPPGU / IPPGC – Define US/CDN Pay Categories
!!Step 4: IPPGU / IPPGC – Define US/CDN Pay Categories
At line 45 changed one line
!Step 5: IPPF – Define Processing Frequencies
!!Step 5: IPPF – Define Processing Frequencies
At line 48 changed 2 lines
!Step 6: IBPN – Define Benefit Plans/Coverages
!!Step 6: IBPN – Define Benefit Plans/Coverages
At line 51 removed one line
At line 53 removed one line
At line 56 changed 2 lines
;[Open Enroll Allowed |OPEN_ENROLLMENT_ALLOWED]:If the benefit plan is to be included in the Open Enrollment process then the Open Enroll Allowed field must be populated with either ‘Always Open’ or ‘OE Periods Only’. Always Open will ensure that the benefit plan is always open to employees to elect into. OE Periods Only ensures that the benefit plan is only open during the OE Period. If the benefit plan is never to be used by the Open Enrollment process then select ‘Never Open’. This field is tied to the lexicon [X_BE_OE_ALLOWED].
;[Approval Required|APPROVAL_REQUIRED]:Approval logic can be enabled at the plan level. Clients can choose No Approval Required, Approval Required (Approval is required for Open Enrollments with new elections, existing elections with changes and declined elections.), or Apr Req for Chgs Only (Approval is only required for changes made to elections). This field is tied to the lexicon [X_BE_APPROVAL].
;[Open Enroll Allowed |OPEN_ENROLLMENT_ALLOWED]:If the benefit plan is to be included in the Open Enrollment process then the Open Enroll Allowed field must be populated with either ‘Always Open’ or ‘OE Periods Only’. 'Always Open' will ensure that the benefit plan is always open to employees to elect into. 'OE Periods Only' ensures that the benefit plan is only open during the OE Period. If the benefit plan is never to be used by the Open Enrollment process then select ‘Never Open’. This field is tied to the lexicon [X_BE_OE_ALLOWED].
;[Approval Required|APPROVAL_REQUIRED]:Approval logic is required for Open Enrollments and can be enabled at the plan level. All employee Open Enrollments must be first approved before they can be processed into enrollments in [IBEN]. The approval is made at the employee Open Enrollment level, not at a benefit election level meaning that the Administrator will not be approving each election change but the employee’s overall participation in the Open Enrollment.\\ \\However, should there be the need to have the approval process be different for certain plans within the Open Enrollment, the Administrator can tailor the approval process using where clauses that take this field into account. For example, the client may decide that a specific plan requires approval for changes only.\\ \\This field is also taken into account by [IBEL] when elections are made outside of the Open Enrollment process.\\ \\Clients can choose:\\No Approval Required - This is used in [IBEL] to indicate an election into the plan does not need approval.\\Approval Required – Approval is required for Open Enrollments with new elections, existing elections with changes and declined election\\Apr Req for Chgs Only – Approval is only required for changes made to elections.\\ \\If no plans in the employee’s open enrollment require approval, then no specific approval process will be called. However, since the enrollment must still be approved in order for it to be processed, a generic approval process will display.
At line 39 added one line
;[Do Not Split Enrollment When No Change| ]:When toggled, this indicates to [UBPOE] to not create an effective record in [IBEN] when the employee does not make any changes to their enrollment of the plan/coverage. If an employee makes a change or if there are rate changes, the system will create a new effective record.\\ \\If an employee only makes a change to their elected recipients, regardless of this toggle being toggled on or off, the system will not create a new effective record in [IBEN]. This is due to the Recipient table (BBR) not being configured in the database to support date effective changes.
At line 63 changed 2 lines
;[Recipient Type|RECIPIENT_TYPE]:This field determines the recipient eligible for the coverage. This field is used for Open Enrollments. Recipient_Type is a fixed lexicon ([X_PLAN_RECIPIENT_TYPE]). If the coverage is only available to the employee, ‘Not Applicable’ must be selected. The type of recipient defined at the coverage will filter the list of benefit recipients available to the employee for that plan during the election period. The filtration is done by comparing the recipient type lexicon values to the stored values of the [relation lexicon|X_RELATION] in [IECT]. The system will check for a recipient type at the coverage first, if none are found it will then check the plan type to see if one has been defined at that level. If the system cannot locate a recipient type for either the coverage or plan type, all of the employee’s contacts defined in [IECT] will be listed for the employee to elect. The page [Benefit Recipient Matrix for Open Enrollment|BENEFIT RECIPIENT MATRIX FOR OPEN ENROLLMENT] shows which relation values fall under each of the recipient types.
;[Recipient Type|RECIPIENT_TYPE]:This field is used for Open Enrollments and determines the type of recipient eligible for the coverage. If the coverage is only available to the employee, ‘Not Applicable’ must be selected. The type of recipient defined at the coverage will filter the list of benefit recipients available to the employee for that plan during the election period. The filtration is done by comparing the recipient type lexicon values to the stored values of the [relation lexicon|X_RELATION] in [IECT]. The system will check for a recipient type at the coverage first, if none are found it will then check the plan type to see if one has been defined at that level. If the system cannot locate a recipient type for either the coverage or plan type, all of the employee’s contacts defined in [IECT] will be listed for the employee to elect. The page [Benefit Recipient Matrix for Open Enrollment|BENEFIT RECIPIENT MATRIX FOR OPEN ENROLLMENT] shows which relation values fall under each of the recipient types.
At line 50 added one line
;[Max. Disabled Age|MAXIMUM_DISABLED_AGE]:If the coverage is open to dependents and there is an age restriction in place for disabled members, this field is used to store the maximum age allowed for disabled members. If there is no age restriction, 999 may be entered as the age. The election process will verify the recipient’s age based on their birth date defined in [IECT]. The disabled recipient must have the Disabled Indicator toggled ON in [IECT].
At line 72 changed one line
;[Estimated Costs|ESTIMATED_COSTS]:If the EE and ER costs are based on estimated earnings the Estimated Costs toggle should be checked ON. With this ON there will be a notation displayed for the coverage’s cost in [WEBOEE].
;[Estimated Costs|ESTIMATED_COSTS]:If the EE and ER costs are based on estimated earnings the Estimated Costs toggle should be checked ON. With this ON there will be a notation displayed for the coverage’s cost in [WEBOEE].
At line 55 added 3 lines
\\Coverage Details
;[Description|DESCRIPTION]:The description of the coverage is displayed in the [WEBOEE]. Ensure the description is descriptive of the coverage and is not too long.
;[OE Questions| ]:This field allows the Benefit Administrator to select an assessment from [IBAS]. Assessments may now be linked to a coverage allowing questions to be asked and responded to during on Open Enrollment period. If an employee elects a coverage with an assessment, an assessment event will be scheduled automatically. If there are mandatory answers within the assessment the employee will not be able to submit until the mandatory questions have been answered.
At line 77 changed one line
;[OE Enter Elections|ENTER_ELECTION]: This is only used in BSS for Open Enrollments. This toggle must be checked if an employee must submit information before electing a coverage, such as a Deduction amount for a Flex Spending account. This will prompt the employee for the necessary information. Again, if the BC is not visible in [IBEN] then the BC will not be visible in [WEBOEE]. The Allow Value Override toggle must also be checked in order for the BC to display in [WEBOEE].
;[OE Enter Elections|ENTER_ELECTION]: This is only used in BSS for Open Enrollments. This toggle must be checked if an employee must submit information before electing a coverage, such as a Deduction amount for a Flex Spending account. This will prompt the employee for the necessary information. Again, if the BC is not visible in [IBEN] then the BC will not be visible in [WEBOEE]. This field is not to be used to allow employee’s to override a system calculated amount. Its intent is to only allow employees elect a dollar amount of their choosing.\\The Allow Value Override toggle must also be checked in order for the BC to display in [WEBOEE].
At line 80 changed one line
!Step 7: IBSC – Define Benefit Schedule
!!Step 7: IBSC – Define Benefit Schedule
At line 65 added one line
\\ \\New to the [IBSC] are the [Waiting Period (Days)|WAITING_PERIOD] and [Minimum Hrs/Week|MINIMUM_HOURS_PER_WEEK] fields. Any data supplied here will override what has been defined for the coverage.
At line 83 changed 4 lines
New to the [IBSC] are the [Waiting Period (Days)|WAITING_PERIOD] and [Minimum Hrs/Week|MINIMUM_HOURS_PER_WEEK] fields. Any data supplied here will override what has been defined for the coverage.
!Step 8: IDGR – Define Groups
!!Step 8: IDGR – Define Groups
At line 89 changed one line
!Step 9: IBET – Define Benefit Event Types
!!Step 9: IBET – Define Benefit Event Types
At line 92 changed one line
Clients are required to define event types that will suit their needs, this is done in the [IBET] form. Common event types are Mass Open Enrollment, Birth of Child, Marriage, Adoption, Divorce, New Hire, Termination etc..
Clients are required to define event types that will suit their needs, this is done in the [IBET] form. Common event types are Mass Open Enrollment, Birth of Child, Marriage, Adoption, Divorce, New Hire, Termination etc.
At line 96 removed one line
At line 98 changed one line
;[Open Enroll Type |OPEN_ENROLLMENT_TYPE]:This determines if the event is a life/work event, a mass open enrollment, an ad hoc event or an event that is Always Open.
;[Open Enroll Type |OPEN_ENROLLMENT_TYPE]:This determines if the event is a life/work event, a mass open enrollment, an ad hoc event or an event that is Always Open.
At line 103 changed one line
;[Standing|STANDING]:Standing is used to indicate the status of the event type, it may be frozen, obsolete, active. Standing is tied to the lexicon [X_STANDING].
;[Standing|STANDING]:This allows the BE Administrator to define which events are available to use and which ones are no longer in commission. The lexicon options are Active, Frozen and Obsolete.
At line 106 removed one line
At line 114 changed 2 lines
!Step 10: IMFD – Maintain Form Definitions
In order for the employees’ election choices to be automatically saved when entered in [WEBOEE] the Auto Commit preference must be added to the [WEBOEE] screen in [IMFD]. The value for the preference must be Y.
!!Step 10: IMFD – Maintain Form Definitions
In order for the employees’ election choices to be automatically saved when entered in [WEBOEE] the Auto Commit preference must be added to [WEBOEE] in [IMFD]. The value for the preference must be Y.
At line 123 changed 4 lines
!Step 11: IMRO – Define Roles
!!Step 11: IMRO – Define Roles
At line 133 removed one line
At line 113 added one line
At line 144 removed 23 lines
Step 2: IMLN- Maintain Lexicons
A common requirement of benefit elections is that an employee is eligible to a set of plans that are offered from different carriers and are mutually exclusive of one another (the employee is only allowed to elect one plan out the set). We are now able to handle this requirement by grouping these plans into a “Plan Election Set”. A plan set code is used to group these plans together. The plan set code is user defined in a lexicon called X_PLAN_ELECTION_SET in IMLN. The plan set code should be reflective of the type of plans included in the set. The plan set code is then added to IBPN to each of the plans to be included in the set.
Before employees can submit their elections, they are prompted for a decline reason for the elections they declined. This decline reason is based on the lexicon X_BE_DECLINE_REASON. This is a user defined lexicon which clients must populate with suitable decline reasons.
Step 3: IMST – Define Client Site Information
By default decline reasons are required; however, if it is a client’s policy not to require reasons for declines, the site preference BSS D REASON REQ must be defined in IMST with a value of N.
The site preference BSS_EVIDENCE_REQ may be defined with a value of Y to force an employee to provide Evidence/Documentation during the Open Enrollment before they can submit their elections. If this is defined with a Y a validation message will be displayed to the employee. If a value of N is provided, the employee will still be prompted to submit evidence however they will still able to submit their elections if no evidence is uploaded.
Step 4: IPPGU / IPPGC – Define US/CDN Pay Categories
In order to determine which pay frequency detail record to use to calculate the EE and ER period/monthly/annual calculations, a new pay category is required with the type ”Open Enrollment”. This category will not be used by any payroll calculations.
Step 5: IPPF – Define Processing Frequencies
The new pay category must be added to all of the pay frequencies that are used by the benefit plans associated to the Events for Open Enrollment. The Times Per Year field for this category must be populated with the number of times per year that the benefit plan is to be processed by payroll. This number will be used in conjunction with the rate basis for the category in the EE and ER calculations.
Step 6: IBPN – Define Benefit Plans/Coverages
New fields have been added to IBPN to accommodate the Open Enrollment process. These new fields are listed below:
Plan Details
Description
The description of the benefit plan should be descriptive of the plan as this will be displayed to the employees.
Plan Election Set
Specify a plan set code if the benefit plan is part of a Plan Election Set. The plans within the Plan Election Set must be part of the same plan type. Since Plan Election Sets are used when plans are mutually exclusive of one another, they can only be implemented if the client already restricts the employees to only enroll into one plan. If employees are currently enrolled in multiple plans that are to be included in the same plan election set, the enrollments for these plans must be first declined before the plans can be tied to a plan election set, otherwise there will be errors when the OE period is generated.
Open Enroll Allowed
If the benefit plan is to be included in the Open Enrollment process then the Open Enroll Allowed field must be populated with either ‘Always Open’ or ‘OE Periods Only’. Always Open will ensure that the benefit plan is always open to employees to elect into. OE Periods Only ensures that the benefit plan is only open during the OE Period. If the benefit plan is never to be used by the Open Enrollment process then select ‘Never Open’.
Approval Required
Approval logic is required for Open Enrollments. All employee Open Enrollments must be first approved before they can be processed into enrollments in IBEN. The approval is made at the employee Open Enrollment level, not at a benefit election level meaning that the Administrator will not be approving each election change but the employee’s overall participation in the Open Enrollment.
However, should there be the need to have the approval process be different for certain plans within in the Open Enrollment the Administrator can tailor the approval process using where clauses that take this field into account. For example, the client may decide that a specific plan requires approval for changes only.
This field is also taken into account by IBEL when elections are made outside of the Open Enrollment process.
At line 168 removed 4 lines
Clients can choose:
• No Approval Required - This is used in IBEL to indicate an election into the plan does not need approval.
• Approval Required – Approval is required for Open Enrollments with new elections, existing elections with changes and declined elections.
• Apr Req for Chgs Only – Approval is only required for changes made to elections.
At line 173 removed 10 lines
If no plans in the employee’s open enrollment require approval, then no specific approval process will be called. However, since the enrollment must still be approved in order for it to be processed, a generic approval process will display.
Display Sequence
A display sequence is used to determine the order the benefit plans are listed in the WEBOEE form in Self Service.
Grandfathered
This will indicate if the benefit plan has been ‘grandfathered’. Employees who are currently enrolled in a grandfathered plan will have the ability to change coverage within the plan, as long as the plan is set up for Open Enrollment. Employees not enrolled in a grandfathered plan will not see the plan in their election options.
Do Not Split Enrollment When No Change
When toggled, this indicates to UBPOE to not create an effective record in IBEN when the employee does not make any changes to their enrollment of the plan/coverage. If an employee makes a change or if there are rate changes, the system will create a new effective record.
If an employee only makes a change to their elected recipients, regardless of this toggle being toggled on or off, the system will not create a new effective record in IBEN. This is due to the Recipient table (BBR) not being configured in the database to support date effective changes.
Required Documents
Any documents that are required to be uploaded by the employee during the Open Enrollment must be listed here. This field will be visible in the third tab in WEBOEE to indicate to the employee what documents are needed for each plan. If none of the coverages in the plan require documentation, this field should be left blank.
At line 184 removed 150 lines
Coverages
Recipient Type
Specify the type of recipient eligible for the coverage. If the coverage is only available to the employee, ‘Not Applicable’ must be selected. The type of recipient defined at the coverage will filter the list of benefit recipients available to the employee for that plan during the election period. The filtration is done by comparing the recipient type lexicon values to the stored values of the relation lexicon in IECT. The system will check for a recipient type at the coverage first, if none are found it will then check the plan type to see if one has been defined at that level. If the system cannot locate a recipient type for either the coverage or plan type, all of the employee’s contacts defined in IECT will be listed for the employee to elect. A matrix of the recipient types vs the relations can be seen further in this chapter.
Display Sequence
This will determine the order the coverages are listed within the plans in WEBOEE.
Waiting Period (Days)
If there is a waiting period before an employee is eligible for the plan, specify the number of days
Minimum Hrs/Week
Used when an employee must work a minimum number of hours per week to qualify for the plan
Max. # Recipients
If the coverage is only available to a specific number of recipients, define the maximum number allowed.
Max. Child Age
If the coverage is open to children and there is an age restriction, state what the maximum child age is. The election process will verify the recipient’s age based on their birth date defined in IECT.
Max. Student Age
If the coverage is open to students and there is an age restriction, state what the maximum student age is. The election process will verify the recipient’s age based on their birth date defined in IECT. This will only be in effect for those recipients who are defined as Students in IECT.
Max. Disabled Age
If the coverage is open to dependents and there is an age restriction in place for disabled members, this field is used to store the maximum age allowed for disabled members. If there is no age restriction the user may enter 999 as the age. The election process will verify the recipient’s age based on their birth date defined in IECT. The disabled recipient must have the Disabled Indicator toggled ON in IECT.
Evidence Required
If evidence is required before an employee can be enrolled into a plan, then this should be toggled ON.
Estimated Costs
If the EE and ER costs are based on estimated earnings the Estimated Costs toggle should be checked ON. With this ON there will be a notation displayed for the coverage’s cost in WEBOEE.
Pre Tax
With this toggle checked ON, this will identify to the employee in WEBOEE if the coverage is Pre Tax or Not.
Exclude from OE
A coverage may be excluded from an Open Enrollment by checking this toggle ON.
Coverage Details
Description
The description of the Coverage is displayed in the WEBOEE. Ensure the description is descriptive of the coverage and is not too long.
OE Questions
This field allows the Benefit Administrator to select an Assessment from IBAS. Assessments may now be linked to a coverage allowing questions to be asked and responded to during on Open Enrollment period. If an employee elects a coverage with an assessment, an assessment event will be scheduled automatically. If there are mandatory answers within the assessment the employee will not be able to submit until the mandatory questions have been answered.
Components
OE Enter Elections
Required if an employee must submit information before electing a coverage, such as a Deduction amount for a Flex Spending account. This will prompt the employee for the necessary information in WEBOEE. If the BC is not visible in IBEN then the BC will not be visible in WEBOEE.
This field is not to be used to allow employee’s to override a system calculated amount. Its intent is to only allow employees elect a dollar amount of their choosing.
Step 7: IBSC – Define Benefit Schedule
If new plans have been defined, ensure they have been added to the benefit schedule.
New to the IBSC are the Waiting Period (Days) and Minimum Hrs/Week fields. Any data supplied here will override what has been defined for the coverage.
Step 8: IDGR – Define Groups
Clients can determine which set of employees are eligible for Open Enrollment by checking ON the toggle Enable OE Elections in IDGR. Only employees tied to a group with this ON will be able to process Open Enrollments.
Step 9: IBET – Define Benefit Event Types
Open Enrollment is triggered by events whether those are life, work, mass open enrollment or ad hoc events.
Clients are required to define what event types suit their needs. Common event types are Mass Open Enrollment, Birth of Child, Marriage, Adoption, Divorce, New Hire, Termination etc..
Tied to each event type are the benefit plans that employees will be eligible to elect into or make changes to.
Event Types
Event Type
This is the Event Type code used to classify events, whether those are life events, work events, mass open enrollment or ad hoc events. These are user defined.
Open Enroll Type
This determines if the event is a life/work event, a mass open enrollment, an ad hoc event or an event that is Always Open.
Description
This provides a brief description of the event. This description will be carried over to IBOE when an OE period is created. If a description is provided in UBOE it will override the description in IBOE. This is also what is displayed to the employees in WEBEV for the life/work events.
Days Open
This states how long the enrollment is to be left open. This is used to calculate the Open Enrollment End Date for life / work events.
Proof Required
If employees are required to submit proof that the event took place, this toggle should be turned ON. For example, some carriers require a birth certificate or a marriage license.
Allow Auto Open Enrollment
This toggle allows an open enrollment period to be automatically generated if a life/work event is recorded in WEBEV / IBEV. This is only used for life/work events. If the toggle is not checked for any plans associated to the event, an Open Enrollment will not be created and the Administrator is responsible to create the Open Enrollment period for the employee.
Standing
This allows the BE Administrator to define which events are available to use and which ones are no longer in commission. The lexicon options are Active, Frozen and Obsolete.
Event Type URL
This field allows clients to include a URL for employees to gain more information on the event.
Event Type Text
This field allows for more information to be posted on the actual event type. This will also respect basic HTML tags. Again, this will be carried over to IBOE.
Plans Affected
Plan Election Set
If there are Plan Election Sets that are to be included in the event, users can specify the Plan Election Set instead of listing each plan individually. This will group the plans within the plan set together.
Plan
Plans that are not part of a Plan Election Set but should be included in the enrollment should be listed individually.
Description
This is the benefit plan description which will default in once the plan has been selected.
Election Required
This is used to force the employee to elect a coverage from a plan. This toggle will default as checked ON if the plan’s participation rule is ‘Required’. For Plan Election Sets, if one plan in the set has ‘Required’ defined as the participation rule, then the toggle will be checked ON. This can be used to override the Participation rule for Open Enrollments by selecting or unselecting the toggle.
Step 10: IMFD – Maintain Form Definitions
In order for the employees’ election choices to be automatically saved when entered in WEBOEE the Auto Commit preference must be added to the WEBOEE screen. The value for the preference must be Y.
Headers and Footers can be used to tailor the WEBOEE screen. If headers and/or footers are to be used, the preferences Header and/or Footer should be added to the screens in IMFD.
If birth certificate, marriage license or health questionnaire do not meet your business needs, the form item name prompts for these documents may be translated to something else. These media are used in WEBOEE, IBPOE and in VBOEE.
Additional media may be added to the WEBOEE form if documents other than birth certificate, marriage license, or health questionnaire are required. Media codes must first be defined in IMEC for P2K_HR_IDENTITIES. These new media codes would need to be added to the form definition for WEBOEE, IBPOE and VBOEE. The three existing media codes in WEBOEE can be used as an example.
Step 11: IMRO – Define Roles
In order for employees to make use of Open Enrollment execution rights for the Open Enrollment, forms and reports must be given to the appropriate execution type roles.
Since there are two My Benefit Elections forms, WEBEL and WEBOEE, ensure that execution rights are granted to only one of the forms. To make use of Open Enrollment, employees must have access to WEBOEE.
Access to the following new forms and reports should be granted to the appropriate users: IBET, IBOE, IBPOE, VBOEE, IBEV, RBET, RBOE, UBOE, UBPOE.
Approvals in Open Enrollment
• Approvals in the Benefit Open Enrollment facility are done at the Open Enrollment level, not at a plan level. Therefore, the Benefit Administrator will be approving an employee’s Open Enrollment in IBPOE; he/she will not be approving each individual plan election.
• The approval processes for Benefit Open Enrollment must be defined with a type of Open Enrollment EEs. The function the processes are tied to is IBPOE.
• The process can consist of a single or multi-stepped sequence.
• Approval processes for different events can be handled via where clauses. The where clause would filter the open enrollments based on event type.
• All Open Enrollments must be approved before they can be processed.
• If no approval process is defined or the employee’s Open Enrollment is not filtered to a specific Open Enrollment approval process a system generated generic approval process will be used.
• The Sample Approval section provides sample approval processes that may be defined.
• For further information on setting up Approvals please review the EP-WP-Approvals white paper.
Open Enrollment Messages
• There are many messages in the Benefit Open Enrollment facility that are portrayed to the users in both the Professional and Self Service side of Personality. These messages can be translated to a different language or edited to suit your business needs.
• Messages are only created once they have been issued to the users in Personality, therefore they will only display in IMMS once they have been created (issued to a user). Once the message code and text display in IMMS they can be translated.
• Please review the WSA manual for more information on how to use the translations functionality.
• The following are the message codes, their descriptions and where they are used in the Open Enrollment facility.
Message Code Message Text Displayed In
BBR_00002 Your elected student <<CONTACT_NAME>> is older than the coverage's Maximum Student Age restriction of <<MAXIMUM_STUDENT_AGE>>. WEBOEE & IBPOE
BBR_00003 Your elected child <<CONTACT_NAME>> is older than the coverage's Maximum Child Age restriction of <<MAXIMUM_CHILD_AGE>>. WEBOEE & IBPOE
BBR_00004 Coverage requires that <<CONTACT_NAME>> be a child recipient. WEBOEE & IBPOE
BBR_00005 This coverage requires benefit recipients be elected. WEBOEE & IBPOE
BBR_00006 <<CONTACT_NAME>> for plan <<PLAN_CODE>> has a future dated recipient record. The recipient record will not be updated with this Open Enrollment. Please review <<EMPLOYEE_NAME>>'s election changes and update the recipient record accordingly IBPOE & UBPOE
BBR_00007 <<CONTACT_NAME>> for plan <<PLAN_CODE>> cannot be changed. Please review <<EMPLOYEE_NAME>>'s election changes and update the recipient record accordingly IBPOE & UBPOE
BBR_00008 Your elected recipient <<CONTACT_NAME>> is older than the coverage's Maximum Disabled Age restriction of <<MAXIMUM_DISABLED_AGE>>. WEBOEE & IBPOE
BEPS_00001 This Coverage allows a maximum of <<BCG_ID.NUMBER_RECIPIENTS>> benefit recipient(s) to participate. WEBOEE & IBPOE
BEPS_00002 A required plan cannot be declined. IBPOE
BEPS_00003 This coverage requires an answer to all of the mandatory questions in the <<ASSESSMENT_DESCRIPTION>> in order to pass the validation process WEBOEE & IBPOE
BEPS_00004 This coverage requires you to answer the questions in the <<ASSESSMENT_DESCRIPTION>> in order to pass the validation process and submit your elections WEBOEE & IBPOE
BEPS_00005 This coverage requires an amount to be specified WEBOEE & IBPOE
BEPS_00006 Evidence Required for this coverage. Please upload the required documents WEBOEE & IBPOE
BEPS_00007 Grand Total WEBOEE
BET_00001 Enter life event information. WEBEV
BEV_00001 The Event Date is too far into the past. Please contact your Benefit Administrator to discuss an Open Enrollment Period WEBEV & IBEV
BEV_00002 Your event has been recorded. This type of event requires proof, please navigate to the Pending Proof tab to upload the required documentation. Your Benefit Administrator will be in contact to discuss an Open Enrollment Period. WEBEV & IBEV
BEV_00003 Event <<BET_ID.BE_EVENT_TYPE_CODE>> has been submitted. WEBEV & IBEV
BEV_00004 A record has already been created for Event Type: <<BE_EVENT_TYPE_CODE>> Employee: <<PERSON_CODE>> and Event Date: <<BE_EVENT_DATE>> IBEV & WEBEV
BEV_00005 The Election Opened and Closed Dates for the corresponding Open Enrollment will also be updated with the new Event Date. IBEV
BOEE_00002 A decision must be made for the plan set <<DRV_PLAN_ELECTION_SET_CODE>>. WEBOEE & IBPOE
BOEE_00003 A decision must be made for the plan <<DRV_PLAN_ELECTION_SET_CODE>>. WEBOEE & IBPOE
BOEE_00005 By submitting your benefit elections you will no longer be able to make changes to your elections. Please ensure that all of the information is correct before pressing submit. WEBOEE & IBPOE
BOEE_00006 You cannot submit the open enrollment until all of the election options are valid. WEBOEE & IBPOE
BOEE_00007 All of the elections have passed the validation process. You may now submit the open enrollment. WEBOEE & IBPOE
BOEE_00008 One or more elections have failed the validation process. Please review each plan for any indicated corrections you need to make. WEBOEE & IBPOE
BOEE_00009
Press OK to re-open all of the plans for the current Open Enrollment. IBPOE
BOEE_00010 You cannot submit the open enrollment until you provide a reason for decline WEBOEE & IBPOE
BOEE_00011 Open Enrollment for <<FIRST_NAME>> <<LAST_NAME>>, ( <<PERSON_CODE>> ) Event Type: <<BE_EVENT_TYPE_CODE>> Coverage Effective: <<COVERAGE_EFFECTIVE>> has a stage of <<ELECTION_STAGE>> IDVAR
BOEE_00012 Benefit elections have been successfully submitted WEBOEE & IBPOE
BOEE_CONTEXT <<EEM_ID.EID_ID.FIRST_NAME>> <<EEM_ID.EID_ID.LAST_NAME>> has an Open Enrollment for the Event Type <<BOEE.BOE_ID.BET_ID.BE_EVENT_TYPE_CODE>>
IBPOE
Open Enrollment Questions
Open Enrollments may now be configured to ask questions within the WEBOEE screen. Questions may be asked using the Assessment logic.
Questions are defined in IBAS, a new assessment screen strictly for benefit open enrollments. Questions may be single answer or text.
The open enrollment assessment must have a type of ‘Benefit Open Enrollment’. Only assessments of this type are visible in the IBAS, and only these types of assessments are picked up for benefit processing. If the employees are allowed to change their answers, the toggle ‘Allow Question Review’ must be checked ON in IBAS. If this is not turned on then the employee will not be able to re-open the OE Questions/Assessment Event to change their responses.
Once an assessment is created in IBAS the Assessment Code may be selected in IBPN in the Coverage Details tab. Only one Assessment Code may be tied to a Coverage, however each Coverage within a plan may have a different Assessment Code.
In WEBOEE when an employee elects a coverage with an associated Assessment, a link/button called OE Questions will appear (below the list of recipients) allowing the employee to click on the button to open the assessment screen. The employee will be navigated through the questions, once the questions are answered the Complete button will appear in the assessment screen, once pressed the screen will close and the employee may carry on with their benefit elections. If the assessment has mandatory questions, the employee will not be able to submit the Open Enrollment until the questions have been answered. A validation message has been added to notify the employees of any mandatory unanswered questions.
When an employee elects a Coverage with an associated Assessment, an Assessment Event is created. The status of the event will be set to ‘Planned, Conf’. The status will change to ‘Completed’ once the employee has finished answering the questions and pressing the ‘complete’ button within the assessment window. If the employee needs to change their answers to the questions they may press the ‘ReOpen Questions’ button beneath the ‘OE Questions’ button. The reopen button will change the status of the assessment back to ‘Planned, Conf’, the previous responses will remain visible and any changes the employee make will update the original assessment.
The questions and responses may be seen in IBPOE and in VBOEE in the OE Questions tab. The Administrator cannot change the employee’s answers here. If the Administrator needs to take the assessment on behalf of the employee, the Administrator must use the WABPOE screen as Assessments cannot be taken within the Professional side of ePersonality.
Once an Open Enrollment is processed, the assessment and its responses will be tied to the employee’s enrollment detail record in IBEN. This is so the Administrator can report off of the responses.
The VBOEE screen has also been enhanced with the OE Questions tab to show the questions and responses affiliated to an elected coverage.
This page (revision-37) was last changed on 26-Nov-2021 10:22 by rforbesTop