Multiple Jobs and PeopleSoft Benefits Administration

Determine Eligibility with Multiple Jobs

The system uses Eligibility Rules to determine if a worker meets the organization's rules for enrollment in a benefit program or option. Eligibility Rules comprise three major components:

Eligibility Criteria.
Grouping Method.
Evaluation Method.

Each component is tied to an Eligibility field within an eligibility rule. The Eligibility Criteria field defines the data values that determine eligibility or ineligibility. The status of the worker's Primary Job indicator and Include for Eligibility check boxes on the Primary Jobs table, together with the Grouping Method and Consider Active Jobs Only fields, define which jobs should be evaluated. Finally, the Evaluation Method component defines how the group of jobs should be evaluated.

With multiple jobs, you specify a grouping method. Grouping methods enable you to define which jobs to include when the system is evaluating the benefits for which an employee is eligible:

Term	Definition
All Flagged Jobs	Groups all jobs with the Include for Eligibility selected on Primary Jobs that are selected for all benefit record numbers.
Flagged Jobs in Benefit Record	Groups all jobs with the Include for Eligibility selected on Primary Jobs that are selected within the benefit record number of the event.
Primary Job in Benefit Record	Looks at only the primary job within the benefit record number of the event.

When determining which jobs should be grouped, the Consider Active Jobs Only check box from the eligibility rule is also used. If this check box is selected, then only those jobs with an active Empl_Status (employee status) of A, L, P, W, or S are included when the grouping method is All Flagged Jobs or Flagged Jobs in Benefit Record.

Another component of the eligibility rule is Evaluation Method. Evaluation methods enable you control how the jobs that are selected from the grouping method are evaluated against the eligibility criteria, when determining whether the employee satisfies the eligibility rule:

Term	Definition
One or More in Group	At least one job in the group must satisfy the rule.
All in Group	All jobs in the group must satisfy the rule.
Sum	The sum of the eligibility field's data value from all jobs in the group must satisfy the rule.

For example, the table below lists the eligibility of the employee with three jobs when processing an event for Benefit Record 0 and the Eligibility Rule for the FTE file is:

Minimum FTE must equal 1.
Grouping Method is All Flagged Jobs.
Consider Active Jobs Only check box is selected.

Job	Employee Record #	Benefit Record #	Primary Job	Include for Eligibility	Include for Deductions	FTE
Professor	0	0	Yes	Yes	Yes	.50
Dean	1	0	No	Yes	Yes	.25
Physician	2	1	Yes	Yes	Yes	.25

All jobs are active, so the group consists of all the jobs. The FTE adds up to 1.0 across these jobs, so this employee meets the eligibility rule.

Suppose that the Grouping Method is All Flagged BR. Then the group of jobs you evaluate is Empl_Rcd (employee record) 0 and Empl_Rcd 1. The sum of these FTE fields is .75, which does not meet the eligibility criteria.

Benefits Credits and the Primary Job

PeopleSoft Benefits Administration posts credits for benefits to the Additional Pay tables under the employee record number that is equal to the benefit record number. During a pay calculation, the system loads deductions for benefits only if the primary job for the benefit record is being paid on the check that is being calculated. Likewise, when loading additional pay for benefits credits, the credits posted under any employee records number for a particular benefit record are loaded to the paysheet of the primary job only for that benefit record.

This means that during a pay calculation, the system (while processing a particular job) determines whether this is the primary job for the associated benefit record number. If it is, the system searches for the additional pay data, looking for benefits credit entries, for example Add'l Pay Reason = 'BAS' for any Empl_Rcd that is assigned to this benefit record.

All entries found are loaded to the paycheck. If this is not the primary job, no benefit credits are added to the check. This ensures that there is no "double dipping" of deductions and that the credits for benefits always appear on the same check as the corresponding deductions.

Trigger Events with Multiple Jobs

The primary job drives the processing of an event for a specific benefit record number. This job must have a benefit system flag set to BA - Benefits Administration. The primary job provides the company ID and the BAS Group ID data for the processing schedule.

There are three main categories of events:

Events that are triggered though a direct change to employee data.
Events that are inserted into the system manually on the BAS Activity page.
Passive events.

If changes are made to a worker's job data that impacts the worker's primary job designation, Include for Eligibility flag, or Include for Deduction flag, the system generates an entry into the BAS Activity Table for a new type of trigger, the (MJ) MultiJob trigger. These triggers are generated with a Bas_Action code of MJC (MultiJob Change), which resolves to the system Miscellaneous Event, if a specific Event Class is not set up for this Bas_Action code. Events that are created as a result of a change to the Primary Jobs table process through the system as (MSC) Miscellaneous Events.

Some of these trigger types may affect a worker's eligibility for benefits across all Benefit Records. For example, the (TP) trigger (Pers_Data_Effdt) is generated when you change a worker's address. Because the Employee Address is not related to any particular job (or benefit record), this change could affect the eligibility for benefits across all of that worker's benefit records. Changes to the worker's age are not specific to a particular job. Because these types of changes can affect all benefit records for a worker the system creates an event for each benefit record that is held by the worker when it processes one of these triggers. This is also true for Passive Birthdate (PB) triggers that are generated as a result of processing Passive Events.

The system explodes the original trigger into a set of new triggers, one for each benefit record. You won't see these exploded triggers in the BAS Activity Table, because they're normally processed in the same Event Maintenance run in which they're created. Each exploded trigger generates a new event that has the same event class as the original trigger.

Other expanded triggers are generated as a result of the options that you configure. Because you can define eligibility rules with grouping methods that cross benefit record boundaries, you can't assume that the data changes that generate other types of triggers won't affect other benefit records.

For example, suppose that you change the example employee (professor/dean/physician) from Full Time to Part Time in one job. The three concurrent jobs provide multiple benefit records. As a result of changing the Full/Part Time indicator, the system generates a (TJ) Job trigger in the BAS Activity Table. This trigger contains the employee record and the corresponding benefit record of the job that is changed. If any eligibility rule uses a Grouping Method of All Flagged, meaning that jobs from any benefit record can contribute eligibility information for this benefit record, you need to expand these triggers. Carefully consider whether you want to activate this trigger explosion. It creates some overhead for the system to maintain and process. If you have eligibility rules that cross benefit record boundaries, then you should select Job Triggers, Passive Service Triggers, and Multi-Jobs Triggers in the Explode activity triggers to all Benefit Records group box on the Multiple Jobs Options page. If you have no such eligibility rules in your system, you can safely turn off the explosion for each trigger type.

Passive Events and Multiple Jobs

Service-based eligibility is based on the service date for the primary job. Because jobs outside of specific benefit records can be grouped, eligibility that is based on the service date can come from the primary job or from any other job in or outside a benefit record number. Therefore, the system creates a BAS Activity trigger for each job that it finds during Passive Event processing that meets the passive service evaluation. These are called PS triggers.

Mark Events for Reprocessing

The system can now better identify events that should be considered for reprocessing. In prior versions, events were flagged for reprocessing consideration when a Bas_Activity trigger was processed, and events existed that used a later Job or Pers_Data_Effdt row for eligibility purposes. In the prior versions, only one Job row could contribute to eligibility, so in the event that Standard Hours was changed on the "non-primary" Job row, and standard hours accumulation was used for eligibility, the system would not detect that existing events may need to be re-processed. This flagging mechanism searches for, and flags all events for the employee that may have used the Job row indicated in the trigger. Although the system can't be sure that the Job row was used for eligibility purposes, it eliminates the risk of not flagging an event that should be considered for reprocessing.