3.2.2.2 Benefits Administration Tables


 

Benefits

 

Benefit Administration Tables

The recommendation is to use the Benefits Administration feature of PeopleSoft. This feature automates the processing of benefit enrollment or termination of coverage based on events such as a Hire event or a Termination event. At any given time, a participant may be associated with several events that occurred on different event dates. During a particular run of the Benefits Administration process, the system uses a set of rules to decide how and in what order to process the events. Event rules are rules set up in the Ben Admin tables, which drive the event maintenance process.

Record/Panel

Field

FIT/GAP

Analysis/Description

Installation Table

Ben Admin Start Date

F

Princeton University will use the start date of a couple of years prior to the latest open enrollment date. This will allow Princeton University to capture retroactive corrections and changes. Use the actual enrollment date or 01/01/94, whichever is earliest.

Administer Workforce

Company Seniority Date

N

This field is typically used for the unions. Princeton University prefers to use the Hire Date as the Company Seniority date and not to maintain this field.

 

Service Date/Months/

Days

G

At the time of this printing, it was still not decided how Princeton will calculate the correct Service Date, in order to bridge service, when there’s a break in service. You can override the system generated service date manually but PeopleSoft does not have a place to build rules for adjusting service dates. You could also customize to automatically bridge service. The recommendation is for Princeton University to re-engineer so that all benefits use the same service date to determine eligibility. PeopleSoft uses one service date for all benefit plans.

Different jobs have different eligibility rules. All service may or may not be counted towards benefits. Service awards would use the service date. If both (all) jobs are eligible for the same benefits we can do the following: We can link more than one Job to benefit record 0 and enroll the employee's primary job into benefits. We could also click on Combine Hours for Multiple Job field in the Eligibility Rules table if we use Ben Admin and all hours will count towards defining whether the employee is eligible for benefits based on their hours.

If each Job qualifies for different benefits or one Job is benefit eligible and the other job is not, the employee will have two different benefit records. He would be enrolled in benefits for only the Job where he is eligible for benefits.

Princeton University can also click on Combine Hours for Multiple Job field in the Eligibility Rules table if Princeton University uses Benefits Administration and all hours will count towards defining whether the employee is eligible for benefits based on their hours.

Eligibility Rules Table

All

G

This table defines the groups of employees eligible for a particular benefit(s). See Spreadsheet.

Using the Benefits Administration module, Princeton University can produce an enrollment form for each employee. This shows what benefit the employee is eligible for and the associated cost for the benefit. Princeton University can set up the eligibility rules in PeopleSoft but may want to modify the PeopleSoft delivered form.

 

Elig Config Fields

G

This field could be used to identify employees in Princeton University’s old plan/new plan. You can also choose to use Additional Pay and a unique earning code to store and pay the old plan supplement. If Princeton University uses the Additional Pay and a unique earning code, they can identify these employees by their Additional Pay record. For any reporting or calculations. This calculation is performed manually now and will continue to be manual.

We will use one of the nine elig_config_field to identify J1 employees who are eligible for the J1 medical. A new report will be created to identify employees whose VISA type changed to/from J1 status. The procedure will be to "Insert a job row (Action/Reason = DTA/BEN) and change the config1 field to J1 or blank effective the date of the change in J1 status whenever this VISA change occurs.

We will also use a config field to identify employees on LTD who are receiving the Medicare carveout plan.

 

Empl Class

F

Princeton University may want to assign Tesseract Staff codes to this field or choose to use this field just for driving benefits eligibility for particular groups of employees. Staff codes can be mapped to employee classes but a decision was made to map staff codes to job function. Empl class will be a subset of job functions.

 

Min Standard Hours

G

PeopleSoft gives you the option of using this field to drive benefits eligibility. Princeton University uses duty time instead of standard time. However, we will manually determine eligibility by the reg/temp field.

Change # 62 customization is to add duty time, number of pays, base number of pays and FTE salary to each employee’s record. This customization should automatically calculate standard hours based on the new fields as part of the customization. In that way, the benefit administration process can use standard hours as part of their eligibility rules.

 

Max Std Hours

F

Since Princeton University has no maximum standard hours the default will be set to 99.

 

Reg/Tmp

G

Princeton University will manually select regular or temporary to drive benefits eligibility criteria and will change the label to read Benefits Eligible.

  

FLSA Status

N

Princeton University will not use this field to identify eligible employees for benefits.

 

Empl Type

N

Princeton University can use this field to identify eligible employees for Benefits but has chosen not to.

 

Union Code

F

This field allows you to identify benefits by union. Princeton University will use this field for their unions.

 

Reg Region, State and Location

N

Benefits are not determined by location; therefore, these fields will not be required.

 

Full/PT

N

Princeton University does not want to use this field to determine eligibility for benefits.

 

Min Service Months

N

Duty Time and Number of Pays are the method Princeton University uses to decide on eligibility for benefits. Duty Time and Number of Pays are not fields in PeopleSoft, therefore, service length needs to be defined in PeopleSoft terms or we need to make this a part of the customization #62. We will use the reg/temp field to identify eligibility.

 

Max Service Months

F

There is no maximum service at Princeton University; therefore, we will set the default to 999.

 

Min Age

F

Princeton University does not require a minimum age for benefits. Default to 0. Retiree medical plan has a minimum age of 65 for the Over 65 Plan.

 

Max Age

F

This field will be used to enter maximum age for the age reduction life plans and under 65 retiree medical plan.

 

Service As Of

G

This field will default from Hire. A custom SQR is being considered to populate this field with a new date for bridging employees. At the time of this documentation, the customization was pending approval.

 

Sal Admin Plan

N

Princeton University will not use this field to drive benefits.

 

Company

N

This field is not required, as Princeton University will have only one company in PeopleSoft.

 

Pay Group

F

Princeton University will use this field to identify which Pay Groups are eligible for benefits.

 

Elig Conf ID1

G

J1 VISA will be used for this field so that the Ben Admin process will identify employees who should have J1 medical.

Change #10

Princeton University would like to tie workflow to J1 visa status changes for all interested parties. When a change is made, the system would automatically or the user would manually create a new row with the config field populated with the J1 value. Then a report would be generated weekly.

 

Elig Conf ID2

F

Princeton University could use this field for Grandfathered Retiree Life.

 

Combined Multiple Jobs

F

Most will be set to Y so that the time worked in each job is combined for calculating eligibility.

 

Officer Code

N

This field is not used for benefits.

 

Age as of

U

Princeton University will use the end of the previous calendar year for some benefits and the end of current calendar year for other benefits.

Age Reduction Basic Life Plans changes every year after 60 reducing the employee’s coverage. The system can automate this if we set up 11 different basic life plans but it will take a lot of processing. It can handle 11 different benefit plans and Ben Admin can use passive event to move employees from one plan to the next. Princeton is also considering changing its life insurance benefits.

 

Benefit Status

F

Employees whose status is Active or on Leave except for FMLA will use an Action of Leave Without Pay instead of Leave in order to drive the correct Benefit Status.

Administer Workforce

Annual Benefits Base Rate

F

Annual Benefits Base Rate will be used for Princeton University’s base salary because of the duty-time and number of pays customization.

Event Class Table

Action Reason Table

F

This table is only used for Ben Administration. This table triggers the events that allow an employee to enroll or to revise their benefit elections. PeopleSoft delivers the following event rules – FSC, HIR, TER OE MSC and SNP. Common additions are REH. LOA and RFL.

Retiree survivor spouse

Part A: If a retiree spouse is continuing benefits only after the death of the employee, than the surviving spouse can be added as a non employee on the COBRA side and the benefits enrollment can continue on the COBRA side.

Part B: If the survivor spouse is covered under the Retiree plan, then they will need to be set up in Campus Community.

Princeton University will inactivate the Action Reasons delivered by PeopleSoft that will not be used by Princeton University.

The new events triggered by action reason codes are:

ANN -- Annual LTD enrollment

BAB -- Birth of a baby

BBB -- Begin benefits billing

BEN -- Benefit change

FSA -- FSA enrollment for the next month

FSC -- Family status change

HIR -- New hire

LTD -- Going on LTD

LWB -- Leave of absence with billing

MSC -- Misc. change

REH -- Rehire

RET -- Retirement

RFL -- Return from leave

SBB -- Stop benefits billing

SSP -- Start domestic partner agreement

TDA -- Enrolled in 403(b) plan

TER -- Termination

Event Rules Table

Event Classifications

F

This field maps the event classes to the event rules. See the Events Rules Table in PeopleSoft.

 

Ignore Plan

F

Princeton University will need to define all event classes.

Example: Event Class HIR – N (No, do not ignore plan)

 

Ignore Dep/Ben Edits

F

This field will be set to Event Class HIR – N.

 

Pre-Enter

F

This field will be set to Event Class HIR – N.

 

Ignore Investment Edits

F

Princeton University will need to define all event classes. See the Events Rules Table in PeopleSoft.

 

Election Required

F

Princeton University will need to define all event classes. See the Events Rules Table in PeopleSoft.

 

Use History

F

Princeton University will need to define all event classes. See the Events Rules Table in PeopleSoft.

 

Provide Flex Credits

N

This field is not required since Princeton University does not give flex credits.

 

Default Methods

F

When Princeton has Event Class HIR the following will be set up to occur:

Medical Defaults to Catastrophic, most benefits will default to Waive, Life defaults to BLIFE (Base Life & AD&D), Defaults to BTA, STD default into, LTD will be a passive event and will be set to Ignore on HIR and Waive on LTD.

 

Participate

F

Princeton University will need to define all event classes. See the Events Rules Table in PeopleSoft.

 

Waive

F

Princeton University will need to define all event classes. See the Events Rules Table in PeopleSoft.

 

Coverage Begins, Coverage Ends

F

Princeton University will need to define all event classes. See the Events Rules Table in PeopleSoft.

 

Effect on Billing

F

Princeton University will need to define all event classes. See the Events Rules Table in PeopleSoft.

 

 


Return to the Table of Contents

Go to 3.2.2.3 Benefits Administration Processing

Go to the HRMS Implementation Home Page