Session 1022 Multiple Jobs Processing in HRMS 8 - Part II March 20, 2001 Dave Dresselhouse PeopleSoft

Session 1022Multiple Jobs Processing

in HRMS 8 - Part II

March 20, 2001

Dave Dresselhouse

PeopleSoft

Agenda

This is Part 2 of a 2-part presentation...

Part I (2:30 - 3:30) Multiple Jobs Basics / Overview HRMS Payroll for North America Pension Administration

Break (3:30 - 3:45)

Part II (3:45 - 4:45) Benefits Enrollment and Deductions Benefits Administration / Eligibility

Agenda

Quick Overview/Review of Multiple Jobs (Benefits)

New Features in PeopleSoft 8 to Support Multiple Jobs Base Benefits Benefits Administration Payroll for North America (deductions)

Tips and Techniques “Insider Information” on how to best use these new

features Things to consider in your implementation Things to avoid

Multiple Jobs - Benefits Overview

How do Benefit Enrollments relate to Jobs? Jobs are grouped into “Benefit Records” for benefits

purposes

EMPLOYMENTEmpl_Rcd: #0




JOBEffdt: 1/1/1999

Action: HIR

JOBEffdt: 2/1/2000

Action: XFR

JOBEffdt: 8/1/2000

Action: DTA

JOBEffdt: 2/1/1999

Action: HIR

JOBEffdt: 4/1/1999

Action: HIR

JOBEffdt: 12/31/1999

Action: TER

JOBEffdt: 2/1/2000

Action: HIR

BENEFIT RECORD #0 BENEFIT RECORD #1

PeopleSoft Base Benefits

Multiple Jobs - Overview

How do Benefit Enrollments relate to Jobs? Enrollments are for a Benefit Record

Data field name is Empl_Rcd, but it’s really populated with

Benefit_Rcd_Nbr


LTD

Life

Health

Savings

FSALife

LTD

Savings


New Features

Primary Job for Benefits One per Benefit Record The Primary Job determines:

Pay/Deduction Frequency in Payroll Pay/Deduction Frequency in BenAdmin Service Date for premiums based upon service Which job carries the deductions and credits for benefits







New Features

Primary Job for Benefits Effective-dated Determined automatically via rules when jobs are

hired/terminated User can re-designate the primary job at any time Maintained in new Primary_Jobs table


New Features

“Include for Eligibility” flag Determines which jobs may, or may not contribute

toward an eligibility evaluation in BenAdmin Determined via rules when jobs are

hired/terminated User can update at any time Maintained on the Primary_Jobs table


New Features

“Include for Deductions (Coverage)” flag Determines which jobs may, or may not contribute

salary (Comp Rate or ABBR) toward salary-based coverage such as Life and Disability

Determined via rules when jobs are hired/terminated

User can update at any time Maintained on the Primary_Jobs table


New Features

Primary Job - “Default Rules” Automatically designates the Primary Job, and sets

the “Include Flags” whenever a job is Hired, Re-Hired or Terminated

Can be configured to implement 7.02/7.51 functionality (lowest active Empl_Rcd)


New Features

Primary Job - “Default Rules” User-configurable workflow notifies you when other

job actions take place Actions that could potentially change the designation of the primary job, requiring Administrator review


New Features

Calculation Rules - Grouping Method Determines the group of jobs that should have their

salaries added together for determining coverage and premiums Subset of all jobs that have their “Include for Deductions” flag turned on

Default is “All in BRN” - same as 7.02/7.51


New Features

Calculation Rules - “Active Jobs Only” flag Further refinement of the group of jobs to be used

for salary aggregation Allows consideration of only those jobs that are active Default is “Consider Active Jobs Only” - same as 7.02/7.51


New Features

Eligibility Rules (Benefits Administration) Grouping Method

Determines the group of jobs that should be evaluated for eligibility purposes

Subset of all jobs that have their “Include for Eligibility” flag turned on

Default is “Primary Job” - same as 7.02/7.51

PeopleSoft Benefits Administration

New Features

Eligibility Rules (Benefits Administration) “Active Only” flag

Further refinement of the group of jobs to be used for eligibility evaluation

Allows consideration of only those jobs that are active

Default is “No” (both Active and Inactive considered) - same as 7.02/7.51


New Features

Eligibility Rules (Benefits Administration) Evaluation Method

Determines “how” the group of jobs should be evaluated - what must meet the criteria?

At least one job All of the jobs The sum of the jobs

Numeric fields only (e.g. FTE, Std Hours)


New Features

Pay System & Benefit System Both are now effective-dated (on Job table) Both can be changed at any time

Benefit System is loosely dependent upon Pay System


New Features

“Single Check” Payroll Feature Greatly reduces the number of checks a Multi-Job employee receives. A single check can pay jobs…

In different Benefit Records In different Paygroups Even in different pay frequencies!

Paysheets for multiple paygroups are combined into a new paysheet for the employee’s Primary Paygroup.


Tips & Techniques- Base Benefits

Tips and TechniquesBase Benefits



Getting Started Change the Search Views for Base Benefits!

Configures search list boxes to return only one entry per Benefit Record.

Prevents you from enrolling an employee under an Empl Record instead of a Benefit Record.

New utility page automates this...



Getting Started Review/Configure the “MultiJob Options” Rules.

Should the Primary Job be re-assigned when a new job is hired into an existing Benefit Record?

Should the Primary Job be re-assigned if it terminates?

Are there any Job Actions that should generate a notification to the Benefits Administrator for Primary Job review?



Getting Started Review/Configure the “MultiJob Options” Rules.

If you want to continue 7.02/7.51 behavior, use the following settings:

Include forEligibility

Include forDeductions

AssignPrimary Job

Hire/Rehire Yes Yes No Change

Terminate Yes No Lowest JobTip:



Primary Jobs Maintenance / Review Conversion will automatically populate

based upon 7.02/7.51 behavior. “Include for Deductions” Flag

Applies only to “salary-based” plans “Earnings-based” plans always use all jobs in

the check for the BRN - this flag is ignored.

Tip: Generally best to leave this checked ON for terminated jobsOnce set OFF, the job can’t contribute

salary to any plan typesUsing the “Active Only” flag on the Calc

Rules gives more granular control



Primary Jobs Maintenance / Review To avoid “double-dipping”, non-earnings-based

benefit deductions are tied to the Primary Job.

Tip:The Primary Job should be an active job if

any other jobs in the Benefit Record are active, and deductions are to be taken.



Calculation Rules Life/AD&D and Disability Plan rules

Should coverage be based upon an accumulation of salaries across jobs?

All combined salaries should be in same currency

1 - Include for Deductions = “Yes” (Primary_Jobs Table)

2 - Included in Calc Rule’s Group Method and “Active Only”

All Jobs in Effect

SalariesAccumulated



Dealing with Multiple Pay Systems Pay System is now effective-dated When combining salaries, jobs in all pay systems

are considered, according to the “Include” flags Think about different currencies!



Benefit Record - Assigning & Changing No longer tied to an Empl_Rcd - use any values you

like! Jobs in different companies should generally be

assigned to different Benefit Records These jobs will always be paid on separate checks

anyway Savings plans generally don’t cross company (legal

entity) boundaries. But remember…coverage and eligibility can be based

on jobs crossing Benefit Records



Benefit Record - Assigning & Changing You may now change a job’s Benefit Record to any

value... Keep in mind: the relationship between a Job

(Empl_Rcd) and a Benefit Record is not effective dated

The system will automatically check the validity of the Primary Jobs table

If this job is (or was) a primary job, you’ll most likely need to adjust primary job information in the Primary Job Maintenance page.



Benefit Record - Assigning & Changing If you change a job’s Benefit Record such that there

are no jobs left in the original Benefit Record, any enrollments for that original Benefit Record will be orphaned The original Benefit Record will no longer exist on any

Employment record The Ben_Prog_Partic will automatically be deleted

Tip: Avoid the “deletion” of Benefit Records If you must... always check to make sure

there are no active plan enrollments prior to moving the last job out of a Benefit Record



General Deductions No longer tied to a Benefit Program

Definitions/Enrollments at the Company level If not to be taken on every check…

Taken from Primary Paygroup’s check -or- Taken from “highest Paygroup Priority” check

If for Union Dues… Taken only from checks paying the Union job



Tip: Turn ON “Take on all Paygroups” if the deduction is based upon a % of earnings. Turn OFF for flat amount deductions.


Tips & Techniques- BenAdmin

Tips and TechniquesBenefits Administration

PeopleSoft BenefitsAdministration


BenAdmin and the Primary Job Determines the employee’s pay frequency during

cost calculations via the job’s paygroup Provides the Service Date for cost calculations using

a Service Rate table Provides the Service and Termination dates for

eligibility evaluation Provides “Job” information for reporting, forms, etc



Configuring Multi-Job Options (BenAdmin) Do you have eligibility rules that cross Benefit

Record boundaries? Trigger Explosion parameter settings

Should new/terminated jobs be included for Elig?



Configuring Eligibility Rules Review/Update your Eligibility Rules with an eye

towards evaluating eligibility across multiple jobs Defaults for Group Method, Evaluation Method and “Active Only” mirror 7.02/7.51 behavior



Configuring Eligibility Rules Step 1: Express it in words...

“The employee is eligible if the Primary job is Full-Time”

Simple Rules:

“The employee is eligible if all active jobs in this Benefit Record are Full-Time”

“The employee is eligible if any job, in any Benefit Record is Full-Time”



Configuring Eligibility Rules Step 2: Parse it according to the parameters

“The employee is eligible if any active job (in any Benefit Record) is Full-Time”

Example:

Eligibility Field = Full/Part-Time Status

Group Method = “All Flagged Jobs”

Active Only = “Yes”

Eval Method = “1 or More”



Configuring Eligibility Rules

1 - Include for Eligibility = “Yes” (Primary_Jobs Table)

2 - Benefit System = “Benefits Administration” (JobTable)

3 - Included in Elig Rule’s Group Method and “Active Only”

Remember: There are 3 levels to determining

which job(s) contribute eligibility

information...

All Jobs in Effect

Job(s)Evaluated



Configuring Eligibility Rules When using Benefit Status, avoid turning on

the “Active Only” flag Terminated jobs won’t be evaluated

A,L,P,S,W are the only Empl Status codes considered Important if you’re using special benefit programs or

plans for inactive employees (like retirees), and/or Benefit Status “Term w/Benefits”

Tip:



Configuring Eligibility Rules Program-level rules

Try to use a Group Method of “Primary Job” or “Flagged in BRN” to avoid duplicate eligibility Evaluation Method of “At Least One” in combination with

Group Method of “All Flagged (all BRNs)” will most likely lead to duplicate eligibility at the program level

Tip:



Configuring Eligibility Rules

If you just want to continue basing eligibility on the Primary Job (now under your control), you probably won’t need to update your current eligibility rules.

Tip:For Upgrading



Configuring Event Rules Avoid setting the Default Method of a TER

event class to “Terminate Coverage” This will terminate the employee’s coverage when the event is finalized, even if they retain eligibility due to other jobs in the Benefit Record remaining active

Just as with single job implementations, always try to use loss of eligibility as the mechanism to terminate benefits

Tip:



Configuring Event Rules Avoid setting the Default Method of a HIR event

class to “Option & Coverage” or “Lowest Eligible Option” When a concurrent job is added to the Benefit Record,

we don’t necessarily want to replace the current elections (from the original Hire) if the “Add Concurrent” event is defaulted.

Tip: Use one of the “Current/Else…” methods because you want to carry-forward any existing election.

Tip: Consider making the HIR event a “Use History” event!



Multiple Pay and Benefit Systems You may not assign a “Global Payroll” job to

BenAdmin No Paygroup / Pay Calendar

You may assign a job managed by “Other” pay system, to BenAdmin

If the primary job is managed by “Other” pay system, you are responsible for ensuring that it is assigned to a paygroup with a pay calendar

NAPY/PI

Pay System

Global

“Other”

Benefit System

Base or BenAdmin

Base Benefits

Base or BenAdmin



Multiple Pay and Benefit Systems When processing eligibility, we look only at jobs

that are managed by BenAdmin If the system encounters a situation in which no

jobs are evaluated during eligibility processing, the employee is considered ineligible for that rule This can happen if the job(s) managed by BenAdmin

have the “Include for Eligibility” flag turned off, or if all Evaluation Methods specify “Primary Job” and the primary job is not managed by BenAdmin

This can be changed by commenting a single line of Cobol code in PSPBAELG



Multiple Pay and Benefit Systems Simple rules to avoid confusion and potential

problems: If any jobs in the Benefit Record are managed by BenAdmin, then the primary job for that Benefit Record...

must not be paid by Global Payroll must have a valid paygroup & calendar should also be managed by BenAdmin

Not an absolute requirement , but strongly recommended!

If not, eligibility Group Method of “Primary Job” will fail.



Multiple Pay and Benefit Systems An even simpler (and recommended) rule:

Try not to mix jobs with different Pay Systems and Benefit Systems in the same Benefit RecordTip:



Trigger “Explosion” Refers to the automatic generation of Bas_Activity

triggers across all Benefit Records Occurs during EM processing

In 7.51, Address Change, Passive Age and Manual triggers were exploded

Address Change

Bas_Activity

Address Change

Address Change

Address ChangeBenefit

Record 0

BenefitRecord 1

BenefitRecord 2



Trigger “Explosion” In 8.0, we optionally explode other triggers...

User configured Job, Passive Service & MultiJob Changes

Manual Triggers can be set to explode / not explode (Employee level / Job level)

We only explode triggers out to Benefit Records whose primary job is managed by BenAdmin

Tip: If any Eligibility Rules cross Benefit Record boundaries, the “Explode Trigger” parameters (MultiJob Options) should be turned on, otherwise turn them off



Trigger “Explosion” Exploded Job and Passive Service triggers are

assigned the System Default Event Class (MSC) This should be a “Use History” event class in

order to avoid unwanted events that stop at “Prepared”

The resulting events are assigned a Bas_Action Source of (EX) to easily identify them if an eligibility change has resulted.

Job Change (TER)

Bas_Activity

EX / MSC

EX / MSC

TJ / HIRBenefit

Record 0

BenefitRecord 1

BenefitRecord 2

Benefit Record 0

Tip:



Trigger “Explosion”

Trigger Type Trigger Level Trigger Source Event Date Basis BRN/ERN Basis Bas_Action Explosion? Exploded Trigger Attributes

TJ (Job) Job Row Job row change Effdt of Job row BRN/ERN of triggersource.

FromAction/Reason

According toMJ_OPTIONS.

BRN: All other BRNs with primaryjob managed by BenAdmin

ERN: Primary Job

Event Class: System Default

BAS Action Source: EX

TP (Address Change) Employee Pers_Data_Effdtrow change

Effdt ofPers_Data_Effdt

Updated during triggerprocessing. Update BRNto lowest BRN with aPrimary Job managed byBenAdmin. Update ERNto the ERN of the PrimaryJob in this BRN.

Always ‘ADR’ Always. BRN: All other BRNs with primaryjob managed by BenAdmin

ERN: Primary Job

Event Class: Inherited from originaltrigger

BAS Action Source: TP

See supporting documentation posted with this presentation for a complete description of triggers and trigger explosion...


Changing a job’s Benefit Record If you change a job’s Benefit Record such that there

are no jobs left in that Benefit Record, any existing events for that Benefit Record will be “dead in the water” There will no longer be a primary job for this Benefit

Record These events cannot be processed or re-processed

Tip: Review (finalize or void) any associated BenAdmin events in progress before removing the last job from a Benefit Record

Multiple Jobs in Benefits

Eligibility&

Enrollments

Coverage and Deductions

Jobs&

Benefit Records

Tip:Final Think in 3 dimensions!

Session 1022Multiple Jobs Processing

in HRMS 8 - Part II

March 20, 2001

Dave Dresselhouse

PeopleSoft

Documents

Session 1022 Multiple Jobs Processing in HRMS 8 - Part II March 20, 2001 Dave Dresselhouse PeopleSoft