Multiple Jobs

Workers who hold more than one active job at the same time under one organizational instance create unique requirements in People Soft Human Resources, Benefits Administration, Payroll for North America, and Pension Administration. If your organization allows a worker to hold multiple jobs, you must be able to:

Combine the worker's job data to comply with regulatory requirements.
Determine benefit and pension eligibility.
Calculate deductions and credits for payroll processing.

These topics discuss:

Multiple employment records compared to multiple jobs.
Multiple jobs and PeopleSoft Human Resources.
Multiple jobs and Base Benefits.
Multiple jobs and PeopleSoft Benefits Administration.
Multiple jobs and Payroll for North America.
Multiple jobs and PeopleSoft Pension Administration.

A person can have multiple ERNs without holding multiple jobs.

A person does not have multiple jobs when they have:

A contingent worker and an employment instance.
The two organizational instances have their own job records, each identified by a unique ERN.
A substantive job and a temporary job where the substantive job is suspended.

People have multiple jobs when they have:

More than one active contingent worker or employment organizational instance.
A substantive job and an additional assignment where the substantive job is not suspended.

Note: Multiple jobs processing does not apply to person of interest job records.

Examples of multiple jobs include these methods:

Multiple Job Method	Description
Concurrent Jobs (separate job instances)	Tracks multiple permanent employment relationships. Each instance is entirely separate – terminating one has no affect on the other. There is no linkage between the two employment records. Each instance is created with the `HIR` action (or `ADD` if a contingent worker). Each instance can be of a permanent or a temporary nature. Each instance has its own payroll and compensation data. Either, both, or none can be paid. Benefits data can be combined using the Benefits Rcd Nbr. Both employment record numbers are available for matching processes in PeopleSoft. Both employment records are active.
Additional Assignment	The additional assignment is linked to the permanent job (instance). The new employment record is linked to an existing employment records. The additional assignment is created with the `ADL` action. An additional assignment can only be active if the first instance is active (Active, Leave of absence, Leave with Pay, Suspended, Short Work Break). An additional assignment is automatically terminated when the main instance is terminated. The new employment record can only be active during the time period that the existing employment records is active. An additional assignment can be completed and reactivated at any time during its controlling instance's active status period. An additional assignment must be of the same organizational relationship type as its controlling instance. An additional assignment can be promoted to its own instance if needed (but the history of its linkage to the original instance is lost). Both employment records are available for matching processes in PeopleSoft. Either, both, or none can be paid. Both employment records can be active at the same time.
Global Assignment	Tracks temporary assignments while maintaining the employee's relationship with their home (or permanent) job. Provides additional information tracking for vehicles, dependents, schools, homes, travel details, and additional earnings and deductions. The additional (host) assignment is linked to the home job. The new employment record is linked to an existing employment record. The host assignment is created with the `ASG` action. A host assignment can only be active if the home instance is active. A host assignment is automatically terminated when the home instance is terminated. If the existing employment record is terminated, this new one is terminated as of the same day. A host assignment can be completed and reactivated at any time during its controlling instance's active status period. A host assignment is only available for the Employee relationship. A host assignment can be promoted to its own instance, but the history of its relationship to the original home instance is lost – except within the actual Track Global Assignments Assignment record. Host assignments do not have their own compensation data. Both jobs are available for matching. Both employment records are active.
Temporary Assignment	Enables the tracking of temporary assignments while maintaining the employee's relationship with their permanent job. The original instance is copied to a temporary employment record and is put in a suspended status. Changes can still be applied to this suspended assignment including position incumbent updates – but payroll is never run on this assignment. Only the temporary employment record can be paid. The temporary assignment data is loaded into the original instance employment record. When the temporary assignment ends, the suspended instance data is copied back into the original employment record from its latest effective date (only the latest effective date row is copied – the history of changes made to it are still kept in the suspended employment record, like a mass pay change). The data on the existing employment record is suspended for the duration of the temporary one.

This chart provides information about multiple jobs methods and the relationship between the initial job instance and the concurrent job:

New Assignment Type	Both Jobs Can Be Active	Primary Instance (Home) Must Be Active	Both Jobs Can Be Paid	Job History	Job Status Automation Process	Both Can Be Matched in the Career Matching Processes
New Instance	Yes	N/A	Yes	Separate	No	Yes
Additional Assignment	Yes	Yes	Yes	Separate	Additional job is terminated if the primary instance is terminated	Yes
Global Assignment	Yes	Yes	Home only	Separate	Host is terminated if Home is terminated.	Yes
Temporary Assignment	Yes	No – Temporary assignment only	Temporary only	Temp data is captured in Instance History	Suspended job can be automatically reactivated when the temporary is done.	No

See Multiple Jobs.

Example: A Person with Multiple Jobs

Jan Smith's job records from May 1, 1996 to February 1, 2000

When a worker holds multiple jobs, each job must have its Job Data record. When you enter an additional job, you need to make two decisions:

For reporting purposes, which of the worker's jobs is the primary job.
You don't have to designate a primary job, but you may want to, to ensure accurate affirmative action statistics and other data that is required for government reporting.
Whether the worker's jobs will share a benefits program or have separate benefits.
The system provides flexibility in mixing and matching jobs and benefits programs.

In other ways, PeopleSoft Human Resources treats an additional job the same way that it treats the worker's first job.

Maintain Multiple Concurrent Military Ranks

PeopleSoft enables customers to track multiple and concurrent job employment through Administer Workforce job data. For military organizations this means the system maintains and manages multiple concurrent ranks for a single service member with concurrent jobs. This functionality enable organizations to track multiple jobs and ranks through one of or a combination of the following examples:

Concurrent jobs or new instance – two or more separate permanent employment instances not related to each other.
For example, a service member has responsibilities in two separate departments: two positions in two departments. This is common in staff positions.
Additional assignments – the new employment record is linked to an existing employment record where the additional job is only active if the primary employment instance is active.
For example, a Maritime Patrol Aircraft service member is also Safety Officer within the same unit. Here the member has two jobs in the same department; this is referred to as "collateral duty."
Temporary assignments – track temporary assignments while maintaining the employee's relationship with their permanent job which is copied to a temporary employment record and put on a suspended status. When the temporary assignment ends, the suspended instance resumes as it did before the temporary assignment began.
For example, a service member goes out for an assignment or training and then comes back to the original, permanent duty station job.

Some of the issues regarding the PeopleSoft Human Resources Base Benefits business process and multiple jobs are:

Which job is the worker's main, or primary, job?
Which jobs do you look at for benefits eligibility, and how should they be evaluated?
Which jobs are used for calculating deductions and contributions?
How are the deductions or contributions calculated?
When do you take deductions and when do you apply credits?

Designate the Primary Job for Benefits

You may want to base a worker's eligibility for benefits on a single job. This is called the primary job (not to be confused with the primary job for PeopleSoft Human Resources reporting purposes). The system also uses the primary job to associate payroll deductions for benefits with a specific job. Each benefit record number (group of jobs) that you designate for a worker has one job designated as the primary job.

When you create a job record for a person, the system flags that job as primary based on rules that you have set up. This flag is stored in the Primary Jobs Flag page (BN_PRIJOBS_MAINT). As you create other Job Data records for a person, the system turns this flag on or off based on the rules that you have established.

For example, here is what the Primary Job Flag page would look like for an employee who is a professor and dean at a university and a doctor at the university hospital:

Job Title	Employee Record Number	Benefit Record	Primary Job?
Professor	0	0	Yes
Dean	1	0	No
Physician	2	1	No

The primary job flag is used throughout the system to:

Determine when a deduction should be taken.
Identify the job that will provide the service date and the termination date.

The designation of a worker's primary job is effective-dated and can be changed anytime from a data maintenance page. Also, because the action of starting a new, concurrent job or terminating an existing job usually affects the determination of the worker's primary job, you can define rules that redesignate the primary job when one of these job actions is entered into the system.

For other actions (such as a job moving from full-time to part-time status), you can also indicate whether the system sends a work list entry to the Benefits Administrator through PeopleSoft Workflow for review.

Group Jobs to Determine Benefit Eligibility

When workers hold multiple jobs, they may be eligible for different offerings of benefits, based on the combination or mix of the jobs that they hold. Conversely, they may be eligible for certain offerings based solely on the fact that they hold a particular job.

Multiple jobs introduce the concept of a benefit record number. If an worker is eligible for multiple sets of benefits (or possibly multiple benefit programs), then you enroll the worker in those benefits according to the set of benefits that corresponds to a grouping of one or more jobs. The benefit record number is the mechanism that is used to group concurrent jobs for benefits eligibility and enrollment purposes.

All enrollments for benefits are specific to a benefit record number.

Maximum Number of Concurrent Jobs

A worker can hold a maximum of 50 concurrent jobs across all benefit record numbers. PeopleSoft Payroll for North America can process only 50 benefit record numbers on one paycheck.

Calculate Benefit Deductions

The same grouping method that is used to determine eligibility can be used to calculate deductions. You can group jobs to calculate a deduction that is based on the worker's salary. Typically this involves calculating coverage and related premiums for Life and Disability plans that are based on the worker's salary or compensation rate. You calculate the coverage and deduction based on:

The salary of the primary job.
The summed salaries from a group of jobs.

When you designate the primary job for a benefit record, the system ties all deductions for the benefits that are associated with this benefit record to this job. Benefits deductions are taken only from checks by which the associated primary job is paid. This assures that deductions are taken at the proper frequency when the individual jobs in a group are paid on different frequencies or on separate checks.

When jobs are combined into a single check for all benefits record numbers, the benefits deduction for the different benefit record numbers is printed as separate detail lines.

Apply Regulatory Contribution Limits

When applying regulatory limits to contributions for savings plans, the system takes into account all earnings and deductions that the worker has across multiple jobs, not just the job or jobs that are associated with the plan that is being limited.

The Retro Deduction and Imputed Income Adjustment processes reevaluate deductions over a specified period of time. Using the current state of the database (benefit and general deduction enrollments, job history and primary job assignment), the system recalculates deductions and compares them to the deductions that were originally calculated and taken.

The primary job indicators play an important role in the calculation of deductions. If changes are made to the primary job history that affect confirmed pay periods, and these changes involve a shift of pay frequencies, then the system might calculate a different deduction amount for this period than it originally calculated. During Retro Deduction and Imputed Income Adjustment processing, the system drives the calculation off the primary job history for the adjustment period.

Percent of Gross Deduction Limits

Calculation rules can be set up with a percent of gross limit applied to a benefit deduction. Also, rate tables can specify the portion of a deduction that is subject to this percent of gross limit. Now that earnings from multiple jobs with different benefit record numbers can be combined into a single check, this can result in a different gross earnings amount being calculated than when these jobs were not combined into a single check.

When applying the Percent of Gross limit to a deduction, the system uses the entire gross earnings from the check, as opposed to just the gross earnings that are attributable to the jobs with the same benefit record number as the enrollment for the deduction that is being limited. This can result in different deduction amounts being calculated than were previously calculated.

The major impact that multiple jobs have on PeopleSoft Benefits Administration is on benefit eligibility and event triggering. Considerations are:

Which jobs do you look at for benefits eligibility, and how should they be evaluated?
If a change affects one job, how do you determine the effect that it has on the other jobs?

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:

Field or Control	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:

Field or Control	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.

The multiple job functionality has the following effect on PeopleSoft Payroll for North America:

Primary Pay Group
When an worker has jobs in more than one pay group, you can designate a primary pay group that controls when deductions are taken from the worker's earnings and when instructions for deduction overrides apply. The worker's primary pay group is also the pay group for which a consolidated paysheet is built, if you activate the single check feature described below.
Single Check
If you activate the Single Check for Multiple Jobs feature in PeopleSoft Payroll for North America, you can produce a single check for workers with multiple jobs across pay groups within the same company. During the Paysheet Calculation process, the system creates a consolidated paysheet for the worker's primary pay group. The paysheet includes all of the worker's FLSA (Fair Labor Standards Act) calculations, taxes, benefits, and general deductions for all jobs with the same period end date; check date; FLSA period, if applicable; and payroll cycle (on- or off-cycle). Pay run IDs and pay frequencies that are associated with the jobs can differ.
Deduction Limits
Limits for general deductions and benefit deductions can vary by job. PeopleSoft Payroll for North America adjusts the Current Goal Balance for the appropriate jobs when deductions are taken.
Union Dues
Union dues are deducted from earnings only when the job that's assigned the corresponding union code is paid.
FLSA Overtime Rules
PeopleSoft Payroll for North America fully complies with FLSA overtime rules for non-exempt workers. If a non-exempt worker has other exempt or non-exempt jobs in the same organization, the system calculates the correct overtime for any extra hours worked.

PeopleSoft Pension Administration supports the use of multiple concurrent jobs, instead of relying on Employment Record number 0 for much of the information that is used in the pension benefit calculations.

Multiple Jobs and the Eligibility Process

The eligibility process always produces two primary results:

Confirmation of whether a worker has ever been eligible for pension benefits.
Time line showing the periods of eligibility and ineligibility.

For a single-job environment, producing these results is a matter of examining a worker's only job record history. If a worker has multiple, concurrent jobs, the system determines plan eligibility based on all jobs. The system considers the worker to be eligible for a particular period if any of the jobs are eligible.

Multiple Jobs and the Primary Job Record

The system examines all of a worker's records and selects a primary record by choosing the first record that it finds in the following prioritized order of categories:

Overrides
Covered Active
Covered Inactive
Any Active
Any Inactive

If it finds more than one of any of these categories, it selects the lowest-numbered record in that category.

You can accept the system-calculated primary record or override it with your own definition of which job record should be the primary record. Do this by configuring your definition of which actions make a job active or inactive or by using the Primary Job Overrides page to designate a record of your own choosing as the primary record.