Understanding Organizational Relationships, Employment Record Numbers, and Multiple Jobs

This chapter provides an overview of organizational relationships and multiple jobs.

Organizational Relationships

Organizations have relationships with a variety of people for a variety of reasons. PeopleSoft enables you to manage the data of those people with whom you have an organizational relationship. A person can have more than one organizational relationship at any one time or can change relationships over time.

Organizational relationships fall into one of the following categories:

• Employee.

  A person who is hired to provide services to the organization and has a legal employee relationship with the organization.

• Contingent worker.

  A person who provides services to the organization and who does not have a legal employee relationship with the organization.

  Note. PeopleSoft Enterprise Payroll for North America does not process payroll for contingent workers.

• Person of interest (POI).

  A person who is not an employee or contingent worker but is of interest to the organization. POIs can be:

  • COBRA participants.

  • Pension payees.

  • Stock - board members.

  • Stock - non-HR administered employees.

  • Global Payroll payees.

  • Campus Solutions persons.

  • External trainees.

  • External instructors.

  • Any person who fits within a POI type you've created.

  • Applicants who require payment through Payroll for North America prior to being hired.

Note. Dependents, beneficiaries, emergency contacts, and health and safety physicians are not captured as POIs.

This chapter refers only to those people with organizational relationships.

Personal Information Data for People with Organizational Relationships

The system requires the same personal information regardless of a person's organizational relationship, so all people with an organizational relationship are added to the system using the Personal Data component (PERSONAL_DATA). This enables you to simplify data entry and maintenance and to use a single, unique identification code for people as you add new organizational instances for them or as their relationships to the organization change.

The generic Add a Person component is on the Administer Workforce menu, but there are additional components on the menus of other applications enabling you to create records for people of interest specifically for that application. For example, you can add PeopleSoft Enterprise Global Payroll payees on the Add a POI Payee component (PERSONAL_DATA) on the Global Payroll & Absence Mgmt, Payee Data menu.

Note. Enter people whose relationship to the organization does not constitute an organizational relationship, such as emergency contacts or beneficiaries, on specialized components throughout HRMS.

The identification number can be labeled as EmplID, Person ID, or ID. These fields all refer to the same identification number. Do not assume that a field labeled EmplID refers to employees only.

See Understanding Identification Assignment.

Organizational Instances

An organizational instance is a single occurrence of an organizational relationship. After you create a personal information record for a person, create an organizational instance to enter and maintain job records. An organizational instance has its own hire date and contains the accumulation of the person's job data records that are associated with that instance.

Use one of the following components to create an organizational instance:

• New Employment Instance (JOB_DATA_EMP).

• New Contingent Worker Instance (JOB_DATA_CWR).

• Template-Based Hire (HR_TBH_EULIST).

  Note. Templates must be created first before the template-based hire component can be used.

• Add Person of Interest Job Relationship (JOB_DATA_POI).

  Note. Access this component from the Administer Workforce menu when you select a POI type that requires a job record. Otherwise, this component is available, under varying names, on the menus of applications that process POIs with jobs.

Note. Hire applicants with data that is in the system by using the Hire component (ER_APP_HIRE_LAUNCH) in PeopleSoft Enterprise Talent Acquisition Manager.

See PeopleSoft Enterprise Talent Acquisition Manager 9.1 PeopleBook.

Note. Update and maintain job data for the instances on the Job Data component (JOB_DATA) or Current Job component (JOB_DATA_CURRENT).

Organizational Instances for People of Interest

PeopleSoft delivers a number of different POI types that you can activate and use as needed. The following types require job records:

• COBRA qualified beneficiaries.

• Pension Payees.

• Stock - board members.

• Stock - non-HR employees.

• Global Payroll payees.

• Student refunds.

Some of the POIs you may want to track will not require a job record. If you are tracking POIs without jobs, you will need to use the Add a Person of Interest component (PERS_POI_ADD) to indicate what kind of POI relationship the person has, as well as to enter any necessary security parameters to control access to the person's data.

Example: A Person with Three Organizational Instances

Mario Estevez needs to successfully complete training with a third-party vendor before starting his new position. To reimburse Mario for the cost of the training, he needs a job record. The human resources administrator adds him in the system by using the Add a Person component and assigns him the ID 1234. The administrator then creates a POI job record for him by using the Add Person of Interest Job component.

After Mario completes his training, he joins the company as an employee. The human resources administrator terminates his POI instance (by using the Job Data component) and creates an employment instance by using the Add Employment Instance component.

A little more than a year after joining the company, Mario is given the opportunity to participate in a short-term project. The human resources administrator creates a contingent worker instance for him on the Add Contingent Worker Instance component.

Mario is later transferred and promoted in his employee job, and a new job data row is inserted for each of these changes. The historical job records accumulate under the organizational instance in which they are created. The human resources administrator updates the job records for the employment and contingent worker instances by using the Job Data component.

This table lists the changes to Mario's job records over a four-year period:

This diagram illustrates how the system stores Mario's data: under the person record, there are separate employee, contingent worker, and POI organizational instances, each with its own event history:

Mario's employee, contingent worker, and POI instances and the job records that are associated with those instances

Employment Record Numbers

Employment record numbers (ERNs), in combination with a person's ID, uniquely identify a person's job data records. The system distinguishes between a person's organizational instances by using a new ERN when you create a new instance.

The system also creates a new ERN when you create a job data record in the following circumstances:

Example: A Person with Multiple ERNs

Jan Smith is hired to work in the sales division of Sutter Enterprises. After two years of outstanding performance, she starts a six-month temporary assignment in a subsidiary company to assist with the launch of a new application. At the end of the assignment she returns to her original job, but three months later she takes on a consulting role at the subsidiary in addition to her sales job. This table lists the changes to Jan's job records over the three-year period:

This diagram illustrates Jan Smith's job records under the organizational relationships. Under the person record, there are separate employee and contingent worker organizational instances. There are two ERNs under the employment instance and one ERN under the contingent worker instance. Each ERN has its own event history:

Jan Smith's employee and contingent worker instances and the ERNs that are associated with those instances

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.

This section discusses:

• Multiple employment records compared to multiple jobs.

• Multiple jobs and PeopleSoft Enterprise Human Resources.

• Multiple jobs and Base Benefits.

• Multiple jobs and PeopleSoft Enterprise Benefits Administration.

• Multiple jobs and Payroll for North America.

• Multiple jobs and PeopleSoft Enterprise Pension Administration.

Multiple Employment Records Compared to Multiple Jobs

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 job include these methods:

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

See Multiple Jobs.

Example: A Person with Multiple Jobs

As of February 1, 1999, when Jan Smith begins her contingent worker relationship with the organization, Jan Smith does not have multiple jobs. She has an active employment job record and an active contingent worker job record, distinguished in the system by their ERNs.

On February 1, 2000, when Jan has held the consulting job at the subsidiary company as a contingent worker for a year, management decides to make the job permanent. This requires creating a new employment job record in addition to the original job record. Jan Smith now has multiple jobs.

This diagram illustrates Jan Smith's organizational relationships and job records after the changes of February 1, 2000. A second employment instance has been added alongside the existing employment instance and contingent worker instances. The new employment instance has its own ERN and event history:

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

Multiple Jobs and PeopleSoft Human Resources

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.

Multiple Jobs and Base Benefits

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:

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.

See Also

Managing Multiple Jobs

Multiple Jobs and PeopleSoft Benefits Administration

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:

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:

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.

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.

See Also

Managing Multiple Jobs

Setting Up Eligibility Rules

Multiple Jobs and PeopleSoft Payroll for North America

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.

See Also

PeopleSoft Enterprise Payroll for North America PeopleBook

Multiple Jobs and PeopleSoft Pension Administration

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:

1. Overrides

2. Covered Active

3. Covered Inactive

4. Any Active

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

See Also

PeopleSoft Enterprise Pension Administration PeopleBook