Setting Up Additional Manage Base Benefits Features

This chapter discusses how to:

Click to jump to parent topicSetting Up Benefits Billing

To set up benefits billing, use the Billing Parameters (BILLING_PARAMETERS) and Billing Calendar (BILLING_CALENDAR) components.

This section provides an overview of setting up Benefits Billing and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding Benefits Billing Set Up

Benefits Billing enables you to bill employees and dependents directly for benefit plan elections instead of paying through the payroll deduction process. Benefits Billing can be used for both regular and COBRA (Consolidated Omnibus Budget Reconciliation Act) benefits.

To set up Benefits Billing:

  1. Set up the rules for billing on the Billing Parameter page.

    You establish only one set of billing parameters for your entire system.

  2. Set up the billing cycle using the Define Calendar page.

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up Benefits Billing

Page Name

Definition Name

Navigation

Usage

Billing Parameter

BILL_PARMS

Set Up HRMS, Product Related, Base Benefits, Billing, Billing Parameters, Billing Parameters

Set up billing parameters.

Define Calendar

BILL_CALENDAR

Set Up HRMS, Product Related, Base Benefits, Billing, Define Calendar, Define Calendar

Set up begin, end, and payment due dates for individual billing periods. Also control billing statement printing and enter comments that appear on statements printed during a particular billing period.

Click to jump to top of pageClick to jump to parent topicSetting Up Billing Parameters

Access the Billing Parameter page (Set Up HRMS, Product Related, Base Benefits, Billing, Billing Parameters, Billing Parameters).

Billing Frequency

Indicate how often to calculate billing amounts.

Days Due

Enter the number of days after the billing period begin date that the payment is due. This value is used to determine the default payment due date on the Define Calendar page.

Note. COBRA requirements mandate at least 30 days for COBRA billing.

Days to Overdue

Enter the number of days past the payment due date that qualify a payment as overdue.

Click to jump to top of pageClick to jump to parent topicSetting Up Payment Due Dates

Access the Define Calendar page (Set Up HRMS, Product Related, Base Benefits, Billing, Define Calendar, Define Calendar).

Billing Period

When you first access the page, you must enter a billing period code that identifies the billing period that you're setting up the calendar for. The code can be any unique four-character combination. Oracle recommends the format YYMM as an identification code for monthly calendars.

Period Begin Date and Period End Date

The system uses the period begin date and the days due value set on the Billing Parameter page to calculate default payment due dates for regular and COBRA Benefits Billing processes.

The system uses the period end date to evaluate effective dates. The period end date is also used as the posting date for billing charges.

Note. The system does not edit the billing frequency to ensure that it matches the begin and end dates.

Payment Due and COBRA Payment Due

The system automatically sets Payment Due and COBRA Payment Due according to the days due values set in the Billing Parameters page and the period begin date that you've defined for this billing period. You can override the default dates if necessary.

Note. You cannot set a COBRA due date that is fewer than 30 days past the begin date.

Comment

(Optional) Enter text to appear on all of the billing statements sent out for this billing period.

Billing Calculation Run and Billing Statements Printed

Indicates the current processing stage for this billing calendar.

Click to jump to parent topicSetting Up Internal Administrative Contact Information

To set up internal administrative contact information, use the Administrative Contacts (BENEF_ADM_CONTACTS) component.

This section discusses how to set up internal administrative contact information.

Click to jump to top of pageClick to jump to parent topicUnderstanding Internal Administrative Contact Information

The Administrative Contacts component is similar to the Vendor component. It is used to record internal contacts for HIPAA (Health Insurance Portability and Accountability Act) and COBRA functions. This internal contact structure enables you to identify a single contact person once and then to reference that contact multiple times throughout the Manage Base Benefits business process.

For HIPAA, the internal administrative contact component is used to record the HIPAA administrator that must be included on all printed HIPAA certificates. The COBRA function uses this component to populate COBRA notification letters.

The contacts that are entered on the Benefits Administrative Contacts page can then be referenced on the Benefits Plan Table page and the Benefit Program Definition page. Note that while only HIPAA and COBRA currently use these contacts, they can be used for all benefit plan types.

Note. HIPAA reports BEN022 and BEN023 now expect to find a HIPAA administrative contact printed on all certificates.

Click to jump to top of pageClick to jump to parent topicPage Used to Set Up Internal Administrative Contact Information

Page Name

Definition Name

Navigation

Usage

Administrative Contacts

BENEF_ADM_CONTACTS

Set Up HRMS, Product Related, Base Benefits, Plans and Providers, Administrative Contacts, Administrative Contacts

Record internal contacts for HIPAA and COBRA functions.

Click to jump to top of pageClick to jump to parent topicSetting Up Internal Administrative Contact Information

Access the Administrative Contacts page (Set Up HRMS, Product Related, Base Benefits, Plans and Providers, Administrative Contacts, Administrative Contacts).

Benefits Contact ID

Identifies the individual contact, and assigns the next available contact ID.

Contact Description

This is an alternative contact search description.

Contact Name

Identifies the name of the internal contact. This contact can be a person, a department, or another name. The contact name is unlimited.

Click to jump to parent topicSetting Up COBRA Administration

To set up COBRA administration, use the COBRA Event Rules (CBR_EVENT_RULES) component.

This section lists prerequisites and discusses how to set up COBRA Administration.

Click to jump to top of pageClick to jump to parent topicPrerequisites

Before you can set up COBRA Administration, complete the following steps.

  1. Activate COBRA Administration on the Installation table.

    1. Access the Installation Table - Product Specific page.

    2. Select the COBRA Administration check box under the Benefits Functions group box.

  2. Identify your company's COBRA administrator.

    Identify your COBRA administrative personnel using the Benefits Administrative Contacts page. When you have entered this information, you can reference these COBRA administrators within each benefit program. This is the contact information (name and address) that will be included in printed COBRA notification letters.

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up COBRA Administration

Page Name

Definition Name

Navigation

Usage

Event Rules

COBRA_EVENT_RULES1

Set Up HRMS, Product Related, Base Benefits, COBRA, Event Rules, Event Rules

Identify the events that result in the loss of health plan coverage for a qualified beneficiary.

Administrative Contacts (benefit administrative contacts)

BENEF_ADM_CONTACTS

Set Up HRMS, Product Related, Base Benefits, Plans and Providers, Administrative Contacts, Administrative Contacts

Define the COBRA administrator's name and address. This information will print on COBRA notification, enrollment, and termination letters.

Click to jump to top of pageClick to jump to parent topicLinking COBRA to Benefit Packages

To link COBRA to your benefit package, use the Benefit Program Table to identify:

Also identify any extra charges that you want added to the cost of the benefits for both disabled and nondisabled persons.

See Also

Building Base Benefit Programs

Click to jump to top of pageClick to jump to parent topicIdentifying COBRA-Eligible Benefit Plans

To identify which benefit plans offered within a benefit program are eligible for COBRA administration, use the Benefit Program Table. When you design your benefit program, if you designate Health (1x) and FSA (60) (flexible spending account) plan types as COBRA-qualified plan types, you must designate an option code for those plan types. The system uses the option codes for the enrollment of employees into COBRA benefit plans. This restriction applies only if you do not use PeopleSoft Enterprise Benefits Administration.

In general, only medical and health plan types (plan types 1x and 6x) are designated as COBRA-qualified plan types. However, the PeopleSoft application allows you to identify nonmedical plan types as COBRA-qualified plans if your organization's policy is to offer them to your employees as part of their COBRA coverage. You will need to modify the COBRA COBOL for plan types other than Medical (1x) and FSA (6x) plan types.

For COBRA, medical coverage is a core benefit. COBRA administration defines non-core benefits such as dental and vision care benefits. If your benefits program combines core and non-core benefits, you may have to offer COBRA participants a core option that is not available to other active employees.

Nonqualified medical, dental, and vision plans are not currently supported for COBRA coverage. You should not designate these plans as COBRA-qualified plans.

See Also

Building Base Benefit Programs

Click to jump to top of pageClick to jump to parent topicEstablishing Coverage Codes for COBRA

Coverage codes are created on the Coverage Code page. PeopleSoft software has four coverage codes that work for COBRA Administration. You can add more codes as required by your organization; however, the coverage codes for nonqualified dependents are not for use by COBRA Administration.

The COBRA Coverage Set field on the Coverage Code page is used during COBRA processing to determine the type of coverage to offer a participant. To indicate that a coverage code is to be used during COBRA processing, enter a two-digit code in the COBRA Coverage Set field.

Example:

Assume you have the following coverage codes:

You want COBRA processing to consider only coverage codes A, B, C, and D as eligible codes and you have decided that CO will represent COBRA eligible coverage codes. You will enter CO in the COBRA Coverage Set field for coverage codes A, B, C, and D.

Click to jump to top of pageClick to jump to parent topicDefining COBRA-Qualifying Events

Oracle's PeopleSoft application delivers COBRA Administration with the following qualifying events:

According to federal government guidelines, employees and spouses of employees who undergo voluntary or involuntary termination for gross misconduct are not eligible for COBRA coverage. The PeopleSoft application does not deliver COBRA Administration with the capability to differentiate between terminations for gross misconduct and other termination types, but you can set up action reason codes and add PeopleCode to have the system perform this function.

You should review the set of events provided, change them, and add new events as necessary based on the qualifying events that your organization recognizes. Then, for each valid event:

If you want to set up additional COBRA event rule records for a particular COBRA event classification, insert a new row with a different effective date. The system will always use the record with the effective date that is closest to the current date.

You can set up COBRA event rule records with future effective dates. This allows you to have the definition of a COBRA event classification change on a predetermined date.

Determining COBRA Coverage Period

COBRA coverage begins the day following the last day of regular active coverage and generally extends for 18 or 36 months following a qualifying event. If an employee is terminated on the 15th, COBRA coverage begins on the 16th.

The determination of the COBRA period begin date depends on several factors. The first factor is whether the COBRA period includes alternative coverage. Alternative coverage is the grace period of continued active coverage beyond the date when an employee's active health coverage would normally terminate. Grace periods are provided either manually through the Manage Base Benefits business process or automatically with the Benefits Administration system.

Regardless of whether the COBRA period includes the alternative coverage, the COBRA coverage begin date is always set to the day following the last day of active coverage. The calculation of the COBRA coverage end date depends on the inclusion or exclusion of alternative coverage.

In the case of disabled COBRA participants, however, regulations allow an extension up to 11 months past the original 18 months for termination of employment and reduction in work hours events. You can extend the coverage for disabled participants by completing the Additional Months if Disabled field on the Event Rules page.

The date on which COBRA coverage ends is defined as the COBRA period begin date plus the number of months of coverage plus any additional months if disabled.

Providing Grace Periods

Situations may occur when you want to provide grace periods for your employees that begin on the day following the last day of regular coverage. During these grace periods, your organization pays all or part of the employee benefits premiums. Extending the termination dates of an individual's health benefit plans past the COBRA-qualifying event date sets grace periods. You can do this manually or arrange for it to happen automatically through PeopleSoft Benefits Administration processes. To provide a grace period, select the Include Alternative Coverage check box and specify when you want the COBRA period to begin, which will be the day after the grace period ends. The system includes grace periods in the COBRA coverage period. You can select to have COBRA begin on the day of the event, on the first day of the month after the event, or on the first day of the pay period after the event day.

If you do not want a grace period to be included in the COBRA period, do not select Include Alternate Coverage.The COBRA period begin date will be the same and COBRA coverage will start on the day after the grace period ends. This means that if your organization paid for all or part of the employee premiums during a grace period, the COBRA period does not begin until after the conclusion of alternative coverage. The length of continued coverage from the qualifying event is the length of the grace period plus 18 months of COBRA continuation coverage.

The system calculates the COBRA coverage end date according to a formula derived from the parameters defined in the COBRA event rules.

Here are examples showing how COBRA can calculate COBRA coverage end dates for an employee who experiences a COBRA qualifying event on March 15 and has a pay period on March 22, whose last day of active coverage is on June 30, and who is allowed 18 months of COBRA coverage.

Last Day of Active Coverage

Include Alternative Coverage

COBRA Period Begins Code

COBRA Period Begin Date

COBRA Coverage Begin Date

COBRA Coverage End Date

June 30

N

NA

July 1

July 1

December 31

June 30

Y

Event Date

March 15

July 1

September 14

June 30

Y

Month After

April 1

July 1

September 30

June 30

Y

Pay Period

March 22

July 1

September 21

The coverage end date will always be equivalent to the COBRA period begin date plus the months of coverage for each plan type, with two exceptions:

Setting Rules for Secondary COBRA Events

Secondary COBRA-qualifying events are events that extend the amount of time a participant is eligible for COBRA coverage

An event must fulfill the following basic qualifications for it to qualify as a COBRA secondary event:

For example, suppose a married employee is terminated. The employee and his spouse will receive 18 months of COBRA coverage after the termination. If the employee and spouse divorce, the divorce would be considered a secondary event for the ex-spouse. If the divorce occurred before the termination, the termination would not be a secondary event for the ex-spouse.

The classification of the event determines the amount of time for which coverage is extended and the method by which coverage is extended. In the previous example, the secondary event would cause the coverage of the ex-spouse to be extended from 18 to 36 months from the coverage begin date of the initial event. In general, even with secondary events, a dependent's coverage cannot exceed 36 months.

The exception would be a case in which the secondary event is a Medicare entitlement. When a qualified COBRA beneficiary turns 65, and is Medicare entitled, COBRA coverage ceases. In this case, the system adds the 36 months to the COBRA event date (the Medicare entitled date), thereby extending the dependent's COBRA coverage past 36 months.

COBRA-Qualified Beneficiary

The following chart illustrates how the Benefit Lost Level and COBRA-Qualified Beneficiary relate to one another. For each COBRA Event Classification, it displays the Benefit Lost Level and COBRA-Qualified Beneficiaries typically associated with that event.

COBRA Event Classification

Benefit Lost Level

COBRA-Qualified Beneficiaries

TER, RET, RED, MIL

Employee

Employee, Spouse, Child

DEA, MED

Employee

Spouse, Child

OVG, DEP

Dependent

Child

DIV

Dependent

Ex-spouse

See Also

Creating Event Rules

Click to jump to top of pageClick to jump to parent topicIdentifying COBRA Events

Access the Event Rules page (Set Up HRMS, Product Related, Base Benefits, COBRA, Event Rules, Event Rules).

COBRA Event Rules

Effective Date

Enter or select the date on which this COBRA event goes into effect. The system always uses the record with the effective date that is closest to but not past the current date.

Status

Select whether this COBRA event is Active or Inactive.

Description

Enter a description of the COBRA event using up to 30 characters.

Short Description

Enter a brief description of the COBRA event using up to 10 characters.

Response Days Allowed

Specifies the maximum number of days that a beneficiary has to elect coverage from the date of notification. COBRA eligibility expires after the response period.

Days to Notify of Event

Identifies the number of days an employee or dependent has to notify the organization following a qualifying COBRA event.

Payment Grace Days

Enter the number of payment grace days employees will be given to submit a payment after they send in an election.

Manual Events Allowed

Select if you want to allow manual entry of the event.

Waive COBRA Surcharge

Select if, for this event classification, you want the system to disregard the COBRA surcharge percentages defined in the Benefit Program Table.

Benefit Lost Level

Define whether the COBRA event affects the employee only, the dependent only, or both. Values are Employee, Dependent (a COBRA-qualified beneficiary), and neither.

COBRA Period Determination

Months of Coverage

Identifies how long coverage will extend for a particular qualifying event. COBRA coverage generally extends for 18 or 36 months following a qualifying event.

Additional Months if Disabled

Enter the extension for disabled participants. Regulations allow an extension up to 11 months past the original 18 months for termination of employment and reduction in work hours events for disabled participants.

Include Alternate Coverage

Select to set up a grace period.

COBRA Period Begins

Select a value to define when COBRA coverage begins. Values are:

On the Event Date: The COBRA period begin date is the same as the day of the event. COBRA coverage actually begins the day after the event date or the day after the grace period ends.

On Month-Begin After Event: The COBRA begin date is on the first day of the month after the event.

On PayPeriod Begin After Event: The COBRA begin date is on the first day of the pay period after the event day.

Secondary Event Rules

Secondary Event Role

Indicates whether the displayed COBRA event classification can be considered a secondary event. Values are:

Succeeding Second Event (S): This indicates that the COBRA event classification is a secondary event.

Preceding Initial Event (P): If this field has a value of P, then the other two secondary event rules fields will be unavailable for data entry.

Second Event Additional Months

If Secondary Event Role is selected, the Second Event Additional Months field defines the number of months that the original COBRA coverage will be extended.

Secondary Event Add Mode

Defines whether the system adds second event additional months to the original coverage begin date of the initial event or to the COBRA event date of the secondary event.

In the event classifications that the PeopleSoft application delivers, the Death, Divorce, Married Dependent, and Overage Dependent events have a Second Event Add Mode value of E (Extended) while the Medicare Entitlement event has a Second Event Add Mode value of A (Added).

Note. For the Divorce COBRA Event Classification, the sole-defined COBRA qualified beneficiary is X (Ex-Spouse).

COBRA Qualified Dependents

Covered Person Type

Select from the following values to define the relationship you have to the dependent.

Child, Domestic Partner, Employee, ExSpouse, Non-Qualified Dependent, Other Qualified Dependent, Spouse.

Click to jump to parent topicSetting Up HIPAA Tables

To set up HIPAA, use the EDI Trading Partners (BN_EDI_PARTNERS) and EDI 834 Transaction Map Table (BN_834_MAP_TBL) components.

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up HIPAA Tables

Page Name

Definition Name

Navigation

Usage

EDI Trading Partners

BN_EDI_PARTNERS

Set UP HRMS, Product Related, Base Benefits, EDI Trading Partners, EDI Trading Partners

Define the information needed for the EDI Interchange Control segments for each partner receiving 834 transaction transmissions.

EDI 834 Transaction Map Table

BN_834_MAP_TBL

Set Up HRMS, Product Related, Base Benefits, EDI 834 Transaction Map Table, EDI 834 Transaction Map Table

View the delivered code maps or set up new code maps for any new codes you have added to the system.

Click to jump to top of pageClick to jump to parent topicDefining EDI Trading Partners

Access the EDI Trading Partners page (Set UP HRMS, Product Related, Base Benefits, EDI Trading Partners, EDI Trading Partners).

Name

Enter the name of the EDI trading partner.

A trading partner can be one of your health care providers but doesn't have to be.

External Partner ID

Identify the receiving partner.

This ID must be agreed upon by both the sender and receiver.

Internal Partner ID

Identify the sending partner.

This ID must be agreed upon by both the sender and receiver.

Application Receiver's Code

Enter a value.

Application Sender's Code

Enter a value.

Use Alternate Group Number for Trans Set Identifier Code

Select to enter a value in the Alternate Group Number field.

Alternate Group Number

If you selected the Use Alternate Group Number for Trans Set Indenitfier Code field, then you must enter a value. The system uses the alternate group number in place of the external partner ID when creating the concatenated transaction set identifier code.

Security Password Required

Select to enter a value in the Password field. This indicates there is security information associated with the HIPAA file.

Password

If you selected the Security Password Required field, then you must enter a 10-character password. The systems sets the ISA03 value to 01 in the ISA segment and then sends the password value in position ISA04.

Master Policy Number

Enter a value.

In the header of the HIPAAA file, the system includes a new REF segment (Transaction Set Policy Number) with a reference ID qualifier of 38 along with the master policy number that you entered in this field.

Subscriber Number

Select from the following values:

EmplID: The HIPAA process uses the emplID of the subscriber as the REF02 value in the REF*0F segment in loop 2000.

SSN The HIPAA process uses the social security or national ID number of the subscriber instead of the emplID. The records for dependents also use the subscriber's ID number for the REF02 value.

Note. If you select SSN and the subscriber does not have a social security number, the file uses the emplID for that subscriber and his or her members' records.

Last Control Number

The system increments this number with each transmission to the partner.

Initially the control number is set to 0. You can manually reset the control number, if necessary.

Field Separator

Enter the character to use to separate fields in each segment of the EDI file.

The default value is an asterisk (*), which is the value suggested by the reporting standard.

Segment Terminator

Enter the character to use to mark the end of each segment of the EDI file.

The default value is a tilde (~), which is the value suggested by the standard.

Subelement Separator

Enter the character used to separate component data elements within a composite data structure of the EDI file.

The default value is a colon (:), which is the value suggested by the standard.

Note. This delimiter is not used in PeopleSoft-delivered 834 transaction segments.

File Name

Enter the name for the EDI file.

File Directory

Enter the directory where the file will be created.

If this field is left blank, the file will be created in the directory PS_SERVDIR.

Click to jump to top of pageClick to jump to parent topicCreating Transaction Map Tables

Access the EDI 834 Transaction Map Table page (Set Up HRMS, Product Related, Base Benefits, EDI 834 Transaction Map Table, EDI 834 Transaction Map Table).

Some of the codes required by the ASC X12.834 Implementation Guide need to be mapped from PeopleSoft codes or customer-defined codes. Oracle delivers the mapping for existing PeopleSoft codes. If you add your own codes, you need to map those codes to EDI 834 codes.

Default EDI Code (default electronic data interchange code)

Each plan type has one default EDI code used in the HIPAA file, for example, HLT for Plan Type 10.

Note. If you do not enter a value in the EDI Insurance Line Code field on the Benefit Plan Table page, the system uses the mapped value for the plan type as the Default EDI Code value in the HIPAA file.

Original Description

The description of the code that is being mapped.

EDI 834 Value

The ASC X12.834 value corresponding to the PeopleSoft code or customer-defined code.

EDI 834 Description

The ASC X12.834 code description.

Click to jump to parent topicSetting Up Multiple Jobs

To set up multiple job features, use the Multiple Job Options (BAS_MJ_OPTIONS_PGP) component.

This section provides and overview of multiple jobs and discusses how to set up rules for multiple jobs.

Click to jump to top of pageClick to jump to parent topicUnderstanding Multiple Jobs

Many organizations have employees who work in more than one job at the same time. The system needs to know how to process these employees with more than one job. Rules need to be created to answer questions such as:

Click to jump to top of pageClick to jump to parent topicPage Used to Set Up Multiple Jobs

Page Name

Definition Name

Navigation

Usage

Multiple Jobs Options

BAS_MJ_OPTIONS

Set Up HRMS, Product Related, Base Benefits, Multiple Jobs Options, Multiple Jobs Options

Define employee-level multiple jobs options to use automatically whenever a new job is entered into the system, or whenever an existing job is rehired or terminated through the Administer Workforce pages.

Click to jump to top of pageClick to jump to parent topicSetting Up Rules for Multiple Jobs

Access the Multiple Jobs Options page (Set Up HRMS, Product Related, Base Benefits, Multiple Jobs Options, Multiple Jobs Options).

When a Job is Hired, Re-Hired or Added

Eligibility and Deductions

Set default rules for whether new concurrent jobs are included or excluded during deduction processing and for Benefits Administration users to determine benefit eligibility.

If assigned to an existing Benefit Record

If an employee is hired into a concurrent job and the job is linked to an existing benefit record number, indicate whether the new job should be designated as the primary job.

When a Job Terminates

Eligibility and Deductions

Set default rules for whether terminated jobs should continue to contribute information during deduction processing and for Benefits Administration users to determine benefit eligibility.

If the Primary Job terminates

Indicate how to reassign the primary job designation if the terminating job is the primary job. Values are:

No Change: Don't reassign the primary job designation.

Lowest Active Job: Reassign the primary job designation to the lowest active employee record number. If no jobs are active, the job with the lowest employee record number is designated as the primary job.

Highest Active Job: Reassign the primary job designation to the highest active employee record number. If no jobs are active, the job with the highest employee record number is designated as the primary job.

Explode activity triggers to all Benefit Records

Job Triggers, Passive Service Triggers, and Multi-Job Triggers (multiple job triggers)

For Benefits Administration users only.

Select these options when you have an eligibility rule that applies to all benefit programs and that crosses benefit record numbers.

For example, suppose that an employee holds four jobs, is enrolled in two benefit programs, and has two benefit records.

If the employee experiences a job data change for one job, and eligibility rules cross benefit records, an event must be created for all benefit records. A change to a job in benefit record A might affect the employee's eligibility for benefits in benefit record B if any eligibility rule in the benefit program for benefit record B contains a grouping method of All Flagged.

Click to jump to parent topicSetting Up Retroactive Benefits and Deductions

To set up retroactive benefits and deductions, use the Retro Ben/Ded Program (RETRO_DED_TABLE) and Retro Ben/Ded Mass Request (RETRODED_MASS_RQST) components.

This section lists prerequisites and discusses how to:

To set up retroactive benefits and deductions, you:

  1. Activate retroactive benefits and deductions on the Installation page.

  2. Define retroactive benefits and deductions programs.

  3. If you are creating mass requests, define the retroactive benefit deduction selection criteria.

    The Retroactive Benefit and Deduction Mass Request feature enables you to create a large number of requests using a batch process. This is necessary when you retroactively update system-level pages that affect multiple employees. Changes to the following system-level pages could generate mass retroactive benefit and deduction requests:

Note. Because the Retroactive Benefit and Deduction feature involves PeopleSoft Enterprise Payroll for North America processes in the calculation of retroactive benefits and deductions and the loading of retroactive benefit and deduction totals to payroll, it is unavailable to those users who do not currently implement Payroll for North America

Deductions based on earnings (such as garnishments or savings plan deductions) are not included in the retroactive benefits and deductions process. They are handled as part of the Payroll for North America adjustment process.

Click to jump to top of pageClick to jump to parent topicPrerequisites

Before you can define retroactive benefits and deduction programs, you must:

  1. Activate retroactive benefits and deductions on the Installation table.

  2. Set up core tables and benefit plans.

See Setting Up and Installing PeopleSoft HRMS.

See Setting Up Base Benefits Core Tables.

See Setting Up Benefit Plans.

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up Retroactive Benefit and Deduction Programs and Mass Requests

Page Name

Definition Name

Navigation

Usage

Retro Ben/Ded Program (retroactive benefit/deduction program)

RETRODED_PGM_TBL

Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Ben/Ded Program, Retro Ben/Ded Program

Define high-level information for your organization's retroactive benefit and deduction programs.

Retro Ben/Ded Mass Request (retroactive benefit/deduction mass request)

RETRODED_MASS_RQST

Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Ben/Ded Mass Request, Retro Ben/Ded Mass Request

Set up your mass retroactive benefit and deduction programs by assigning them a Mass Retro Request ID and by defining detailed information.

To set up a new mass retroactive deduction and benefit program, enter a Mass Retro Request ID to open the page. The system uses the Mass Retro Request ID to generate mass retroactive benefit and deduction requests and to calculate the retroactive benefit and deduction earnings based on those requests.

Click to jump to top of pageClick to jump to parent topicDefining Retroactive Benefit and Deduction Programs

Access the Retro Ben/Ded Program (retroactive benefit/deduction program) page (Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Ben/Ded Program, Retro Ben/Ded Program).

Program Definition

Retro Program ID (retroactive program identification)

When you first select this page from the menu, enter a new or current Retro Program ID. This ID links the retroactive benefit and deduction requests to a specific retroactive benefit and deduction program, which helps the system identify which benefits or deductions are eligible for retroactive processing.

Retro Program Type (retroactive program type)

The system assigns each retroactive benefit and deduction program a Retro Program type of Individual or Mass.

Individual programs apply to all of the employees and companies in your database; therefore, define only one individual program for that database.

Mass programs apply to different groups of employees; therefore, you can define multiple mass programs with different Retro Program IDs for the same database.

Warning! If you change the Retro Program ID after retroactive benefit and deduction processing begins, improper retroactive benefit and deduction calculations will result.

Refunds Paysheet Processing

Off Cycle

This check box enables you to manage your onetime deduction refunds. In the event of a refund, the Off-Cycle field controls whether the retroactive benefit and deduction calculation program will create new onetime deduction refunds as an off-cycle deduction or an on-cycle deduction.

Generally, use off-cycle or separate check processing of retroactive benefits and deductions only when you are processing retroactive pay in the same cycle as regular pay. If you select Off-Cycle, the system treats each retroactive deduction associated with this program as an off-cycle onetime deduction refund, and delivers the refunds to your employees in checks that are separate from their regular paychecks.

If you do not select Off-Cycle, the system treats the retroactive deductions associated with the program as on-cycle deductions and combines employee refunds with their regular paychecks.

Note. When you load your retroactive benefits or deductions to employee paysheets, the On-Cycle or Off-Cycle selection for the Retro Ben/Ded Payroll Load run control must match the On-Cycle or Off-Cycle selection for this field.

Sep Check (separate check)

Select to indicate that the onetime deduction refund records associated with the retroactive benefit or deduction will be loaded to a separate check on the employee paysheets.

Deductions Tab

Base Flag

Select to have the system process retroactive benefits or deductions when the request is triggered by a change in the annual benefits base rate.

Job Flag

Select to have the system process retroactive benefits or deductions for individual retroactive benefit and deduction programs when the request is triggered by a change in the compensation rate or any of its related fields.

Mass Retro Override Tab

If you are setting up a mass retroactive benefit and deduction program, complete the Start Date Ovrd for Mass Retro (start date override for mass retroactive benefit/deduction) and End Date Ovrd for Mass Retro (end date override for mass retroactive benefit/deduction) fields to override the process start date and process end date for the requests that are created.

Refunds Versus Deductions

The system loads refunds to employee paysheets only. In situations in which the retroactive benefit and deduction process finds that employees owe additional payments, the system collects these funds through the PeopleSoft Payroll for North America arrears adjustment process. The system drops all employee retroactive benefits and deductions into the arrears balance using arrears adjustments. If enough money is available, the system collects the amounts during the current payroll run, according to the arrears rules that you defined for that deduction.

See Also

Processing Retroactive Benefits and Deductions

Setting Up Deduction Codes

Click to jump to top of pageClick to jump to parent topicDefining the Parameters for Mass Retroactive Benefit and Deduction Requests

Access the Retro Ben/Ded Mass Request (retroactive benefit/deduction mass request) page (Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Ben/Ded Mass Request, Retro Ben/Ded Mass Request).

Description

Enter a description that explains the purpose of this mass retroactive benefit and deduction ID.

Retro Ded Program ID (retroactive deduction benefit/deduction program ID)

Select an appropriate ID from the list. Only those retroactive benefit and deduction programs defined for Mass processing appear.

Process Start Date and Process End Dt (process end date)

Define the period during which the mass request calculates retroactive benefits or deductions. The process end date is automatically set to today's date when a new mass request ID is created. The process start date becomes the effective date of the generated requests, except for cases in which the selected employee begins to meet the criteria at some point after the start date, in which case that latter date is used as the effective date of the request.

Selection Start Date and Selection End Dt (selection end date)

During the processing period set up by the process start and end dates, the system searches employee records that are active between the selection start and selection end dates for the information specified in the Selection Criteria group box.

First Hire Date

(Optional) Use to select employees who have a hire date on the Employment Table that is before or equal to this date. If this field is blank, the system creates requests for employees who have a hire date before or equal to the selection end date.

Service Date

Functions the same way as the Hire Date field except that it refers back to the Employment Table's Service Date field.

Delete Request

Use this check box to stop the mass retro benefit and deduction process if you have not yet run the calculation process for your Mass Retro ID. When you run the Mass Retro batch process, it deletes every Mass Request ID and related request that has this check box selected and has not yet been through the calculation process.

Comments

Describe the need for the particular mass retroactive benefit and deduction program that you are creating.

Selection Criteria

The fields in this group box define the types of employees that the Mass Retro batch process looks for. You can set up multiple rows of selection criteria for your mass retroactive benefit and deduction program to open up a new one.

Company

Use this required field to indicate the company whose employees you want to process. You can have multiple rows of selection criteria with the same company if you want to change the values of the other fields.

Mass Sequence Number

Each time that you enter a new row of selection criteria, the mass sequence number will be incriminated by one.

Business Unit

You must define a business unit before entering Department, Job Code, and Location Code values.

Department, Job Code, and Location Code

These fields are linked to the Business Unit field.

Reg/Temp (regular/temporary), Full/Part Time, Employee Type, Employee Class, and Pay Status

(Optional) Specify additional selection criteria using valid values from the list boxes.

Enter the other selection criteria as necessary. Values for all selection criteria fields that are blank will be selected by the system. If you want to use more than one of the available values of a particular field in your selection request, enter an additional row.

The three Elig Cal Days (eligible calculation days) fields are linked to the Job Code, Location Code, and Union Code fields. They each enable you to create selection requests for employees who have been assigned a specific job code, location, or union code for a specific number of days. For each Elig Cal Days field, the system looks at the effective date of the selected job record.