This chapter discusses how to:
Set up Benefits Billing.
Set up internal administrative contact information.
Set up COBRA administration.
Set up HIPAA tables.
Set up multiple jobs.
Set up retroactive benefits and deductions.
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:
Set up billing parameters.
Set up payment due dates.
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 Define Calendar page.
Page Name |
Definition Name |
Navigation |
Usage |
BILL_PARMS |
Set Up HRMS, Product Related, Base Benefits, Billing, Billing Parameters, Billing Parameters |
Set up billing parameters. |
|
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. |
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. |
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. |
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.
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.
Page Name |
Definition Name |
Navigation |
Usage |
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. |
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. |
Child Support Indicator |
Indicate whether an employee is required by court order to provide benefits to dependents and/or beneficiaries. If so, indicate whether the employee is the primary or secondary provider. |
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.
Link COBRA to your benefit packages.
Identify COBRA eligible benefit plans.
Establish coverage codes for COBRA.
Define COBRA-qualifying events.
Identify COBRA events.
Before you can set up COBRA Administration, complete the following steps.
Activate COBRA Administration on the Installation table.
Access the Installation Table - Product Specific page.
Select the COBRA Administration check box under the Benefits Functions group box.
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.
Page Name |
Definition Name |
Navigation |
Usage |
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_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. |
To link COBRA to your benefit package, use the Benefit Program Table to identify:
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.
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
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 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
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:
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 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.
Oracle's PeopleSoft application 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. 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:
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 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.
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:
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 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 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
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. |
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:
Define EDI trading partners.
Create transaction map tables.
Page Name |
Definition Name |
Navigation |
Usage |
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. |
|
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. |
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. |
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. |
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.
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:
Which jobs should contribute salary information for calculating deductions that are based on the employee's earnings?
Which jobs should provide pay group information, hire date, and termination date?
Page Name |
Definition Name |
Navigation |
Usage |
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. |
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. |
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:
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 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:
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 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.
Before you can define retroactive benefits and deduction programs, you must:
Activate retroactive benefits and deductions on the Installation table.
Set up core tables and benefit plans.
See Setting Up and Installing PeopleSoft HCM.
See Setting Up Base Benefits Core Tables.
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.
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
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.