Setting Up Additional Base Benefits Features

This chapter discusses how to:

Set up Benefits Billing.
Set up COBRA administration.
Set up HIPAA tables.
Setup internal administrative contact information.
Set up multiple jobs.
Set up retroactive benefits and deductions.

Setting Up Benefits Billing

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:

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

You establish only one set of billing parameters for your entire system.
Set up the billing cycle using the Billing Calendar page.

This section discusses how to:

Set up billing parameters.
Set up payment due dates.

Pages Used to Set Up Benefits Billing

Page Name	Object Name	Navigation	Usage
Billing Parameter	BILL_PARMS	Set Up HRMS, Product Related, Base Benefits, Billing, Billing Parameters	Define billing parameters.
Billing Calendar	BILL_CALENDAR	Set Up HRMS, Product Related, Base Benefits, Billing, Define Calendar, Billing 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.

Setting Up Billing Parameters

Access the Billing Parameter page.

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

Setting Up Payment Due Dates

Access the Billing Calendar page.

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 may be any unique four-character combination. PeopleSoft recommends 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, 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 less 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, Billing Statements Printed	Indicates current processing stage for this billing calendar.

Setting Up COBRA Administration

This section explains how to set up COBRA Administration.

Understanding COBRA Administration Set Up

COBRA legislation requires employers to offer continued health coverage to employees and their dependents who loose coverage under certain conditions or events.

This section discusses how to:

Activate COBRA.
Link COBRA to your benefit packages.
Identify COBRA eligible benefit plans.
Establish coverage codes for COBRA.
Define COBRA qualifying events.
Identify COBRA events.
Identify the COBRA Administrator.

Pages Used to Set Up COBRA Administration

Page Name	Object 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.
Benef Administrative Contacts (benefit administrative contacts)	COBRA_ADMINISTRATR	Set Up HRMS, Product Related, Base Benefits, Plans and Providers, Administrative Contacts, Benef Administrative Contacts	Define the COBRA administrator’s name and address. This information will print on COBRA notification, enrollment, and termination letters.

Activating COBRA

This section explains how to activate COBRA administration.

To activate COBRA:

Access the Installation Table - Product Specific page.
Select the COBRA Administration check box under the Benefits Functions group box.

Linking COBRA to Benefit Packages

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

The age at which a dependent is no longer considered a dependent.
The age at which a dependent is no longer considered a student.
Whether a disabled person is excluded from the age limits.
Whether dependents are ineligible for regular benefits, if married.

You will also identify any extra charges that you want added to the cost of the benefits for both disabled and non-disabled persons.

See Also

Building Base Benefit Programs

Identifying 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) 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 only applies 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, PeopleSoft allows you to identify non-medical 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) or 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.

Currently, 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

Establishing Coverage Codes for COBRA

Coverage codes are created on the Coverage Code page. PeopleSoft 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:

Let's say you have the following coverage codes:

1 — Employee only
2 — Employee + spouse
3 — Employee + dependents
4 — Family
A — Employee only
B — Employee + spouse
C — Employee + dependents
D — Family

You want COBRA processing to only consider 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.

Defining COBRA-Qualifying Events

PeopleSoft delivers COBRA administration with the following qualifying events:

Voluntary termination.
Involuntary termination.
Reduction of hours.
Death of an employee.
Divorce and legal separation.
Loss of dependent status (due to marriage or arrival at the age limit for benefit coverage).
Medicare eligibility.
Retirement.

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. PeopleSoft 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:

Define when COBRA coverage begins and how long it will last.
Define any grace periods.
Define when the employee has to notify the organization of the event and when the organization has to notify the employee of COBRA benefits.
Define the qualified beneficiaries for the event.
Define the secondary event rules for the 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 is dependent on several factors. The first factor is whether or not 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 Base Benefits 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. It is the calculation of the COBRA coverage end date that is dependent 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

There may be situations where 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 actually 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, has a pay period on March 22, whose last day of active coverage is on June 30, and 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:

For employees and spouses, COBRA coverage will end before the scheduled coverage end date on the date that the employee or spouse turns 65 and becomes eligible for Medicare.
For dependents of employees who become eligible for Medicare, the COBRA coverage end date will be the latter of the COBRA period begin date or the employee’s Medicare entitlement date plus 36 months.

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 in order for it to qualify as a COBRA secondary event:

The initial COBRA event must be a COBRA event classification associated with a change to an employee’s job status, such as a reduction in hours, termination, or retirement.
The employee and dependent must currently be participating in an active initial COBRA event and have COBRA coverage.
The secondary event must be one of the COBRA event classifications that involves loss of coverage for the employee’s dependent, such as divorce, marriage of dependent, overage dependent, death of employee, or a Medicare entitlement.

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 where 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, Son, Daughter
DEA, MED	Employee	Spouse, Son, Daughter
OVG, DEP	Dependent	Son, Daughter
DIV	Dependent	Ex-spouse

See Also

Creating Event Rules

Identifying COBRA Events

Access the Event Rules page.

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 this check box if you want to allow manual entry of the event.
Waive COBRA Surcharge	Select this check box if, for this event classification, you want the system to disregard the COBRA surcharge percentages defined in the Benefit Program Table.

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 this check box to set up a grace period.
COBRA Period Begins	Select a value to define when COBRA coverage begins. Choose from the following valid values: On the Event Date: The COBRA period begin date will be 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 or not the displayed COBRA event classification can be considered a secondary event. You can choose from the following valid values: 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 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 PeopleSoft 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).
Benefit Lost Level	Define whether the COBRA event affects the employee only, the dependent only, or both. You can choose from the following valid values: Employee, Dependent (a COBRA-qualified beneficiary), or neither.

Identifying a COBRA Administrator

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

Setting Up HIPAA Tables

This section discusses how to:

Define EDI trading partners.
Create transaction map tables.

Pages Used to Set Up HIPAA Tables

Page Name	Object 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.

Defining EDI Trading Partners

Access the EDI Trading Partners page.

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.

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

Creating Transaction Map Tables

Access the EDI 834 Transaction Map Table page.

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

Original Description

The description of the code that is being mapped.

EDI 834 Value

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

EDI 834 Description

The ASC X12.834 code description.

Setting Up Internal Administrative Contact Information

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

Understanding Internal Administrative Contact Information

The internal administrative contact component is similar to the Vendor component, and 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 provides flexibility for you to reference that contact multiple times throughout the Base Benefits system.

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 actually be used for all benefit plan types.

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

Page Used to Set up Internal Administrative Contact Information

Page Name	Object Name	Navigation	Usage
Benef Administrative Contacts (benefits administrative contacts)	BENEF_ADM_CONTACTS	Set Up HRMS, Product Related, Base Benefits, Plans and Providers, Administrative Contacts, Benef Administrative Contacts	Record internal contacts for HIPAA and COBRA functions.

Setting Up Internal Administrative Contact Information

Access the Benef Administrative Contacts page.

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.

Setting Up Multiple Jobs

This section explains how to set up multiple jobs.

Understanding Multiple Jobs

Many organizations have employees that 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:

Which jobs should contribute salary information for calculating deductions that are based on the employee's earnings?
Which jobs should provide paygroup information, hire date, and termination date?

Page Used to Set Up Multiple Jobs

Page Name	Object Name	Navigation	Usage
Multiple-Job Optns (multiple job options)	BAS_MJ_OPTIONS	Set Up HRMS, Product Related, Base Benefits, Multiple Jobs Options, Multiple-Job Optns	Define employee-level multiple jobs options used automatically whenever a new job is entered into the system, or whenever an existing job is rehired or terminated through the Administer Workforce pages.

Setting Up Rules for Multiple Jobs

Access the Multiple-Job Optns page.

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

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.

Workflow for Job Actions

While the multiple jobs rules are automatically applied for hires, rehires and terminations, you can automatically notify a benefits administrator to review the situation for any job action.

For example, a change to the full-time/part-time status of a concurrent job might affect the determination of the primary job.

To configure this function:

Locate the action/action reason combinations that should generate a workflow notification,
Select the Notify Benefits Administrator check box.

Whenever a job action is entered into the system for one of these combinations, a worklist entry is generated for the benefits administrator.

Selecting the worklist entry accesses the Administrator to the Primary Jobs Maintenance page for that employee.

Setting Up Retroactive Benefits and Deductions

This section discusses how to:

Activate retroactive benefits and deductions.
Define retroactive benefit and deduction programs.
Defining the parameters for mass retroactive benefit and deduction requests.

To set up retroactive benefits and deductions, you:

Activate retroactive benefits and deductions on the Installation page.
Define retroactive benefits and deductions programs.
If you are creating mass requests, define the retroactive benefit deduction selection criteria.

The Retroactive Benefit and Deduction Mass Request feature gives you the ability to create a large number of requests via 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:
- Deduction Table.
- General Deduction Table.
- Most benefit plan design tables (such as the Life and AD/D Plan Table).
- Calculation Rules Table.
- All rate tables.

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.

Pages Used to Define Retroactive Benefit and Deduction Programs and Mass Requests

Page Name	Object Name	Navigation	Usage
Retroactive Ben/Ded Program (retroactive benefit/deduction program)	RETRODED_PGM_TBL	Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retroactive Ben/Ded Program, Retroactive Ben/Ded Program	Define high-level information for your organization’s retroactive benefit and deduction programs.
Retro Ded Mass Rqst Criteria (retroactive deduction mass request criteria)	RETRODED_MASS_RQST	Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Ben/Ded Mass Request, Retro Ded Mass Rqst Criteria	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.

Page Name

Object Name

Navigation

Usage

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

RETRODED_PGM_TBL

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

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

Retro Ded Mass Rqst Criteria (retroactive deduction mass request criteria)

RETRODED_MASS_RQST

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

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.

Activating Retroactive Benefits and Deductions

You must activate Retroactive Benefits/Deduction before using the Retroactive Benefit and Deduction facility.

To activate Retroactive Benefits and Deductions:

Access the Installation Table - Product Specific page.
Select the Retroactive Benefit and Deduction check box in the Benefits Functions group box.

Defining Retroactive Benefit and Deduction Programs

Access the Retroactive Ben/Ded Program (retroactive benefit/deduction program) page.

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 one-time deduction refunds. In the event of a refund, the Off-Cycle field controls whether or not the retroactive benefit and deduction calculation program will create new one-time deduction refunds as an off-cycle deduction or an on-cycle deduction.

Off-cycle or separate check processing of retroactive benefits and deductions generally is used 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 one-time deduction refund, and delivers the refunds to your employees in separate checks from their regular paychecks.

If you do not select the 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-or Off-Cycle selection for the Retro Ben/Ded Payroll Load run control must match the On- or Off-Cycle selection for this field.

Sep Check (separate check)

Select to indicate that the one-time 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, fill in 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 only loads refunds to employee paysheets. In situations where the retroactive benefit and deduction process finds that employees owe additional payments, the system collects these funds through the Payroll for North America arrears adjustment process. The system drops all employee retroactive benefits and deductions into the arrears balance via arrears adjustments. If there is enough money, the system will collect the amounts during the current payroll run, according to the arrears rules that you defined for that deduction.

Setting Up Deduction Codes

Defining the Parameters for Mass Retroactive Benefit and Deduction Requests

Access the Retro Ded Mass Rqst Criteria (retroactive deduction mass request criteria) page.

Description

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

Comments

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

Process Start Dt (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 Dt 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 where 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.

Retro Program ID (retroactive benefit/deduction program ID)

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

Selection Start Dt (selection start date) Selection End Dt (selection end date)

During the processing period set up by the Process Start and End Dates, the system searches employee records active between the Selection Start and Selection End Dates for the information specified in the Selection Criteria group box.

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.

Hire Date

(Optional.) Use to select employees that have a hire date on the Employment Table that is less than or equal to this date. If this field is blank, the system creates requests for employees that have a hire date less than or equal to the Selection End Dt.

Service Date

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

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 Seq# (mass sequence number)	Each time that you enter a new row of selection criteria, the Mass Seq# will be incremented forward by one.
Department, Job Code, and Location Code	These fields are linked to the Business Unit field.
Business Unit	You must define a business unit before entering Department, Job Code, and Location Code values.
Reg/Temp (regular/temporary), Full/Part Time, Employee Type, Employee Class, and Employee 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 takes a look at the effective date of the selected job record.

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

Original Description	The description of the code that is being mapped.
EDI 834 Value	The ASC X12.834 value corresponding to the PeopleSoft or customer defined code.
EDI 834 Description	The ASC X12.834 code description.

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.

Description	Enter a description that explains the purpose of this mass retroactive benefit and deduction ID.
Comments	Describe the need for the particular mass retroactive benefit and deduction program that you are creating.
Process Start Dt (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 Dt 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 where 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.
Retro Program ID (retroactive benefit/deduction program ID)	Select an appropriate ID from the list. Only those retroactive benefit and deduction programs defined for Mass processing will appear.
Selection Start Dt (selection start date) Selection End Dt (selection end date)	During the processing period set up by the Process Start and End Dates, the system searches employee records active between the Selection Start and Selection End Dates for the information specified in the Selection Criteria group box.
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.
Hire Date	(Optional.) Use to select employees that have a hire date on the Employment Table that is less than or equal to this date. If this field is blank, the system creates requests for employees that have a hire date less than or equal to the Selection End Dt.
Service Date	Functions the same way as the Hire Date field except that it refers back to the Employment Table’s Service Date field.