Wiki: IBPN

DEFINE PLAN/COVERAGE DEFINITIONS
Plan Details tab
Elections
Remittances
Coverages Tab
Coverages Details tab
Components tab
Rates tab
Waivers tab
Benefit Events tab
Notes

DEFINE PLAN/COVERAGE DEFINITIONS#

Plans and Coverages are created in the Define Plan/Coverage Definitions (IBPN) screen.

Maintain Plan/Coverage Definitions Usages data is stored on the P2K_BE_PLAN_DEFINITIONS, P2K_BE_COVERAGE_DETAILS, P2K_BE_COVERAGE_COMPONENTS, P2K_BE_COVERAGE_RATES, P2K_BE_REDUCTION_RULES and P2K_BE_EVENT_TYPE_USAGES.

Plan Details tab#

Entity: The Entity field identifies the organization to which this plan is restricted. This field may be left blank if there is no restriction.

Plan Type: This field indicates the plan type that categorizes this plan.

Plan: Plan is a user-defined code uniquely identifying the plan to the organization.

Description: This field provides a user-defined description of the benefit plan.

Plan Established: This is the date the plan was first established at the organization.

Plan End Date: This is the date after which dependent coverage or beneficiary.

Calc Seq #: This field determines the order in which the plan will be processed by the benefit calculation.

Policy #: This field supplies the insurance policy number assigned by the insurance carrier.

Calendar: This field provides the user-defined calendar code, which uniquely identifies the calendar by which the plan must be remitted.

Participation: This field indicates whether participation in a benefit plan or coverage is mandatory or optional. The participation rule on the plan definition is used as a default entry to the benefit schedule. Only the participation rule from the benefit schedule is enforced.

Access_Code: Plan Access is a security feature providing the ability to control access to different types of benefits information.

Not Scheduled: If the ‘Not Scheduled’ toggle is ON, then this plan may be added to the Benefit Election form (IBEL) without being placed on the Benefit Schedule (IBSC). If the toggle is OFF, the plan must be on the schedule to allow employee to elect it.

Track Decline: If the ‘Track Decline’ toggle is ON, a form is created in the enrollment file when an employee declines coverage under a plan. If the toggle is OFF declined benefits are not tracked.

Web Document: This field allows a user to specify an html document explaining the benefit policy. This page will be displayed in the WEBEN form.

Election Document: This field allows a user to specify an html document which is available to employees in WEBEL.

Elections#

Plan Election Set: This field stores the plan election set the plan is tied to. This field is only to be used for Open Enrollments. 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.

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 can be enabled at the plan level for IBEL elections. Clients can choose No Approval Required (used by IBEL elections only), Approval Required or Apr Req for Chgs Only (Approval is only required for changes made to elections). 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.

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’. 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.

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.

Remittances#

Remittance Report: Remittance Report is a user-defined code uniquely identifying the report within the organization.

Carrier: This field will populate the Carrier (Employer) tied to the Remittance report.

Remit As Of Day: This field specifies the day of the remittance period on which remittances are assessed.

Plan Remit Seq #: Remittance Sequence determines the order in which each plan will be printed when more than one benefit plan is printed on the same remittance report.

Last Remittance: This field holds the date this plan was last remitted to the insurance carrier (or reconciled for internal plans). Each time the remittance process is run, this date is updated by the system to reflect the latest date processed. When a user runs remittances for a specific time period, the system checks that there are no missing remittance periods since the last run.

: It is recommended that this field be initialized to the end of the remittance period prior to the commencement of parallel testing for testing purposes, and to the remittance period prior to the live date for production purposes.

: Last_Remit_Date is an optional date field will be updated by the system, however you may alter this field.

Remit Date Rule: This field indicates the date at which remittances must be assessed.

Print Zero Rule: This field controls whether employees with zero premium amounts (for any reason) who are enrolled in the benefit plan should get printed on the remittance report.

Remit by State: If the ‘Remit by State’ toggle is ON, the state or province of the employee’s residence separates remittance history records. If the toggle is OFF there is no separation by state or province.

Remit by Unit or Group: If the ‘Remit by Unit or Group’ toggle is ON, remittance history records will be separated by group or unit, based on the employee’s Prime Assignment Information (IEAS) form. If the toggle is OFF there is no separation by unit and group.

Print All Waivers: If the ‘Print All Waivers’ toggle is ON, employees receiving a benefit waiver that reduces their premium to zero will still appear on the remittance report. If the toggle is OFF employees on a waiver with a zero premium will not get printed.

Coverages Tab#

Coverage: Coverage is a user-defined code uniquely identifying the coverage to the organization.

Seq #: Remit Sequence determines the order in which all the Coverages will be printed when more than one benefit coverage is printed on the same remittance report.

Policy #: Insurance Policy Number for the coverage.

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 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 shows which relation values fall under each of the recipient types.

Contact: Contact Role identifies the contact eligible under this coverage.

The following fields are only used in Benefit Self Service for Open Enrollments

Display Sequence: This will determine the order the coverages are listed within the plans in WEBOEE.

Waiting Period: If there is a waiting period before an employee is eligible for the plan, specify the number of days.

Minimum hrs/wk: 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.

Coverages Details tab#

Description: This field holds a user-provided description of the coverage.

Remit Basis: Remit Basis is the unit of measure in which remittances are stored and sent.

Rate Basis: Rate Basis indicates the unit of measure that coverage rates are stored in for coverage components, plan rates or enrollment tables. All rates entered on the Rates tab must be of the 'Rate Basis' indicated here.

Frequency: Frequency defines the condition under which the benefit is processed. The processing frequencies may be set by month, pay period, type of pay and number of times within a pay period.

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.

ACA Min. Value Self: A toggle to identify if the plan meets Minimum Essential Coverage, as defined by the IRS Rules. You would only toggle on a self-only coverage if it meets that criteria.

ACA Monthly EE Prem: This the cost to the employee for this coverage. It may be the employee deduction rate from the Rates tab, or another value. Note that this value represents a monthly rate.

Components tab#

Coverage Components identify which benefit components are applicable to a particular benefit coverage. They specify the information on the rules, UserCalcs, elements, field values, factors and constants associated with a coverage.

: If there is a component that must be manually entered at the time the employee elects the coverage then the component should have a BC Action of ‘Store on Enroll’ or ‘Store on Line & Enroll’ and have the ‘Allow Value Override’ toggle ON. This ensures that the component will be provided for input in the Process Benefit Elections (IBEL) form. All other components may have the ‘Allow Value Override’ OFF, but still have a BC action of ‘Store on Enroll’ or ‘Store on Line & Enroll’.

A pay component may be indicated in the <PC Code> field if the result is required for Payroll processing or reporting. The BC action must be ‘Store on BE Line’ or ‘Store on Line & Enroll’.

If any of the ‘Convert to Pay Period Amount’ components are to be used ensure that the ‘Week per Year’ and ‘Months per Year’ fields are completed on the Group (IDGR) form in order for the benefit calculation to process the conversion appropriately.

Seq #: Sequence specifies the order in which the Benefits or Payroll Calculation Program will calculate the benefits components.

: For example, in order to calculate the employee deduction to be collected in a pay, it may be necessary to know the premium amount. In order to know the premium, it is necessary to know the coverage amount. Therefore, the sequence of which of these items (Benefits Components) should be found, derived or calculated first is essential for proper benefit enrollment maintenance.

: It is recommended the sequence numbers not be changed without the supervision of a consultant.

BC: BC Code is used to define the benefits component. All BC codes begin with the letter “B” followed by a 4-digit number.

: Definitions of each of the benefits components may be found in the Benefit Components section.

BC Code: The component description is a brief explanation of the benefits component code highlighted. Description defaults in from the benefit code.

Rule: This field is used to describe the possible options available for each benefits component. The rules shown are applicable to the highlighted benefits component in the BC Code field of the form.

Rule Description: The rule description is a brief explanation of the benefits component rule highlighted. The description defaults in from the rule code chosen.

Allow Value Override: If the ‘Allow Value Override’ toggle is ON, the system allows you to see value on IBEL, and update it (must also have ‘enter on enrollment’ ON, and ‘enter on enrollment’). Allows users to override value on IBEN. If the toggle is OFF, a value may not be overridden. Both original values and overridden values are stored. The program will use the original or the override based on this toggle.

Enter Enrollment: If the ‘Enter Enrollment’ toggle is ON, the coverage component value may be overridden on the employee's enrollment form. This allows the user to enter the value when enrolling. Both 'Allow Value Override' and 'Enter Enrollment' must be on, and BC action including ‘Store on Enroll’, in order to see on IBEL. If the toggle is OFF, the component may not be overridden.

Enter Benefit Lines: If the ‘Enter Benefit Lines’ toggle is ON, a benefit line may override the coverage component value.

: This field allows users to enter values on the IBBL to update this component.

: If users ever have to edit the values updated on the IBBL (which updates remittance), they will have to enter a benefit line (IBBL) line. This will happen if a pay reversal is run (does not update benefit line automatically) or if an adjustment is made to a PC after benefits are calculated in UPCALC due to an overpayment/underpayment from a past period. Editing a PC does not update the line.

: Should be ON for any component that updates remittance (Elig $, Covg, Prem, ER, EE), since users may have to add a benefit line to update.

: If the toggle is OFF, the component may not be overridden.

Enter Remit History: If the ‘Enter Remit History’ toggle is ON, the coverage component value may be overridden on the remit history form.

: This field allows users to enter adjusting values (lines, similar to IBBL lines) to remittance history form (IBRH).

: Edits on IBRH might be necessary to fix historical values, however these amounts should be updated by the B1400’s series of components, whose purpose is to make adjustments to previous remittance period.

: If the toggle is OFF, the component may not be overridden.

: Enter_Remit_History is an optional toggle; the value of which is provided for each benefits component.

Update Remit History: If the ‘Update Remit History’ toggle is ON, the coverage component value will be picked up during the Update Remittance History process. If the toggle is OFF, the component will not be entered into remittance history. Update_Remit_History is an optional toggle; the value of which is provided for each benefits component.

OE Enter Elections: 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.

Value: This field allows you to enter a value for the benefit component.

BC Action: This is the action to be performed by the benefits component.

: You may move a component action forward from ‘Calculate’ to ‘Log to BE line’ or ‘Store on Enroll’ but may not move backwards.

PC Code: Users may select a pay component where the result of the component may be stored. In this manner, amounts calculated for benefit lines or enrollments may be recorded in Payroll, available for the Pay Register, employees’ pay stub and/or financial ledgers (as required).

Element: Users may enter an element to calculate the benefits component. The rules for the benefits component must include a “Use an Element” rule for this field to be used. .

PC Abbrev.: Abbreviation is a description of the pay component chosen.

User Calc: You may specify a usercalc to calculate the benefits component amount, date, etc. This field is appropriate for those benefits components for which the Rule 00 – “Use UserCalc” is defined. UserCalcs may also be used to verify or change the component amount calculated.

Rates tab#

Coverage Rates specify the set of rates applied to a specific step within the coverage detail. If using BC550, the rate steps must be 1, 2, 3, etc. not 01, 02, AA, BB etc. The Benefit Calculation routine expects all rates to be for the rate basis indicated on the Coverage tab.

Step: Coverage Step is a user-defined code uniquely identifying a set of rates for a coverage. Codes may be numeric (e.g. 01, 02, 03...) or alphanumeric (e.g. A, B, C, FS, MN, A1, A2...).

: If you are using component BC500, the rate steps must be 1, 2, 3,4, not 01, 02, AA, BB etc.

Description: This field describes the rate step.

Up to Limit: Up to Limit (up to but not including) specifies the upper limit to which the step applies when the rates vary based on age, salary or other range criteria. Used for component B0500, Rule 05, 06, 08 and 09.

Next Step: Next Step code indicates the next set of rates that will apply when rates are stepped based on a date.

Flex Amount: This field provides the amount of the flex fund credit being contributed by the organization; used for component B0810, Rule 07.

Premium 1 Rate: This is the regular premium rate used in normal premium calculations; used for component B0600, Rule 02.

Premium 2 Rate: Additional premium rate used when a second premium rate must be applied after a coverage limit is reached (e.g. $0.50 per $1,000 on 1st $50,000 coverage, $1.00 per $1,000 for any coverage in excess of $50,000). Used for component B0610, Rule 02.

ER Contribution Rate: This is the rate used in the employer's contribution calculation; used for component B0800, Rule 02.

EE Deduction Rate: This field provides the rate used in the employee's deduction calculation; used for component B1000, Rule 02.

Taxable Benefit Rate: This is the rate used in the taxable benefit calculation; used for component B1200, Rule 02.

User 1 Rate: This field provides the first user-defined rate.

User 2 Rate: This is the second user-defined rate.

User 3 Rate: This is the third user-defined rate.

Waivers tab#

Waiver and Reduction Rules govern the way an employee will be processed when they are either in a special employment status that causes premiums to be waived, or when they reach an age limit that triggers a reduction in benefit coverage.

Employment Status: The employment status of an employee may be pending approval, active, on a leave of some type, or terminated.

Up to Limit: This field indicates the highest age for which this reduction rule applies, if applicable.

Waiver Method: This field indicates who pays the premium amount when an employee is on a benefit waiver.

Coverage Reduction %: This field indicates by how much the coverage/benefit amount is reduced.

Premium Reduction %: This field indicates by how much the premium is reduced.

EE Reduction %: This field indicates by how much the employee deduction is reduced.

ER Reduction %: This field indicates by how much the employer contribution is reduced.

Benefit Events tab#

The information displayed in this tab is view only and will only display if the plan is tied to a Benefit Event used in Benefit Self Service for Open Enrollments.

Event Type: The event type that the plan is associated to will be displayed here. Event Types are defined in IBET.

Description: The description of the benefit event will display here to provide more information on the event.

Allow Auto Open Enrollment: If the event is defined to automatically create an open enrollment for an employee when the event is recorded, this toggle will be checked.

Notes #

Click to create a new notes page

Table of Contents