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 2 lines
!!!STEPS TO SETTING UP OPEN ENROLLMENT
!!!OPEN ENROLLMENT SET UP
At line 6 changed 2 lines
!Step 1: IBPT – Define Benefit Plan Types
!!Step 1: IBPT – Define Benefit Plan Types
At line 9 changed 5 lines
;[Plan Type|PLAN_TYPE_CODE]:This field holds the defined plan type code that uniquely identify the plan type. The Plan Type will be displayed in the [WEBOEE] form so it should be reflective of the plans within the type.
;[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 by High Line but may be user altered.
;[Recipient Type|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. This field is used by the BSS module only. Recipient_Type is a fixed lexicon ([X_PLAN_RECIPIENT_TYPE])
;[Plan Type|PLAN_TYPE_CODE]:This field uniquely identifies the plan type. The Plan Type will be displayed in the [WEBOEE] form so it should be reflective of the plans within the type.
;[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.
;[Recipient Type|RECIPIENT_TYPE]:This field is used by the BSS module only. 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. The type of recipient defined 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 15 removed one line
At line 17 removed one line
At line 14 added 2 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 from the set). The application is able to handle this requirement by grouping these plans into a “[Plan Election Set|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.
At line 17 added one line
Before employees can submit their elections, they may be 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 should populate with suitable decline reasons, unless the client will not be requiring decline reasons in which case the lexicon does not need to be updated.
At line 22 changed 2 lines
!Step 2: IMLN- Maintain Lexicons
;[X_PLAN_ELECTION_SET]: 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 from the set). The application is able to handle this requirement by grouping these plans into a “[Plan Election Set|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.
!!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 25 changed one line
;[X_BE_DECLINE_REASON]: Before employees can submit their elections, they may be 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 should populate with suitable decline reasons, unless the client will not be requiring decline reasons in which case the lexicon does not need to be updated.
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 27 changed 5 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.
!Step 4: IPPGU / IPPGC – Define US/CDN Pay Categories
!!Step 4: IPPGU / IPPGC – Define US/CDN Pay Categories
At line 34 changed one line
!Step 5: IPPF – Define Processing Frequencies
!!Step 5: IPPF – Define Processing Frequencies
At line 37 changed 2 lines
!Step 6: IBPN – Define Benefit Plans/Coverages
!!Step 6: IBPN – Define Benefit Plans/Coverages
At line 40 removed one line
At line 42 removed one line
At line 45 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 48 changed one line
;[Grandfathered|GRANDFATHERED]:This will indicate if the benefit plan has been ‘grandfathered’. This field is currently only supported in Open Enrollments, it is not currently respected in [IBEL]. For Open Enrollments, this will restrict new employees from being elected into the plan. Any grandfathered plans will not be included in the Open Enrollment process.
;[Grandfathered|GRANDFATHERED]:This will indicate if the benefit plan has been ‘grandfathered’. This field is currently only supported in Open Enrollments, it is not currently respected in [IBEL]. 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.
At line 52 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.
;[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 61 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 66 changed 2 lines
;[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].
!Step 7: IBSC – Define Benefit Schedule
;[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].
;[Allow Value Override|ALLOW_VALUE_OVERRIDE|Allow Value Override]: In order for the Employee and Employer Costs to display in [WEBOEE] and [IBPOE], this toggle must be checked ON for [BC-B0840] and [BC-B1040].
!!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 70 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 76 changed one line
!Step 9: IBET – Define Benefit Event Types
!!Step 9: IBET – Define Benefit Event Types
At line 79 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 83 removed one line
At line 85 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 90 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 93 removed one line
At line 101 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 110 changed 4 lines
!Step 11: IMRO – Define Roles
!!Step 11: IMRO – Define Roles
At line 108 added 15 lines
----
![Notes|Edit:Internal.OPEN+ENROLLMENT+SET+UP]
[{InsertPage page='Internal.OPEN+ENROLLMENT+SET+UP' default='Click to create a new notes page'}]
This page (revision-37) was last changed on 26-Nov-2021 10:22 by rforbesTop