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 one line
!!!OPEN ENROLLMENT SET UP
!!!STEPS TO SETTING UP OPEN ENROLLMENT
At line 5 changed one line
!!Step 1: IBPT – Define Benefit Plan Types
!Step 1: IBPT – Define Benefit Plan Types
At line 7 changed 2 lines
;[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.
;[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 but may be user altered.
At line 13 added one line
At line 15 added one line
At line 17 added one line
At line 14 changed one line
!!Step 2: IMLN- Maintain Lexicons
!Step 2: IMLN- Maintain Lexicons
At line 19 removed 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 22 changed one line
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.
!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.
At line 24 changed one line
!!Step 4: IPPGU / IPPGC – Define US/CDN Pay Categories
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
At line 27 changed one line
!!Step 5: IPPF – Define Processing Frequencies
!Step 5: IPPF – Define Processing Frequencies
At line 30 changed one line
!!Step 6: IBPN – Define Benefit Plans/Coverages
!Step 6: IBPN – Define Benefit Plans/Coverages
At line 42 added one line
At line 44 added one line
At line 35 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 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.
;[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].
At line 39 removed 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 43 changed one line
;[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.
;[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.
At line 50 removed 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 52 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 removed 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 60 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]. 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].
;[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].
At line 63 changed one line
!!Step 7: IBSC – Define Benefit Schedule
!Step 7: IBSC – Define Benefit Schedule
At line 65 removed 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 67 changed one line
!!Step 8: IDGR – Define Groups
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
At line 70 changed one line
!!Step 9: IBET – Define Benefit Event Types
!Step 9: IBET – Define Benefit Event Types
At line 73 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 87 added one line
At line 78 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 83 changed one line
;[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.
;[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].
At line 97 added one line
At line 93 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 [WEBOEE] 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 the [WEBOEE] screen in [IMFD]. The value for the preference must be Y.
At line 102 changed one line
!!Step 11: IMRO – Define Roles
!Step 11: IMRO – Define Roles
At line 124 added one line
At line 112 removed 11 lines
This page (revision-37) was last changed on 26-Nov-2021 10:22 by rforbesTop