Setting Up Retro Pay Processing
To set up retro pay processing, use these components: Retroactive Pay Program (RETROPAY_PGM_TBL), Retro Pay Monitored Fields (PY_RETROTBL_DEF), Retro Pay Trigger Values (RETRO_TRG_VALUES), Retro Pay Trigger Program (PY_RETROTRG_DEF), and Retro Pay Cancellation Reason (PY_RETROCNL_TBL).
|
Page Name |
Definition Name |
Usage |
|---|---|---|
|
RETROPAY_PGM_TBL |
Describe a retro pay program and specify paysheet processing options. |
|
|
RETROPAY_PGM_DEF |
Establish the earnings codes for which the retro pay program calculates retro pay and those used for paying retro pay earnings. Valid earnings codes for these fields are only those that you specified as eligible for retro pay or used to pay retro on the Earnings Table - General page. |
|
|
PY_RETROTBL_DEF |
List the job and additional pay fields that are available to use when you define the triggers that create retro requests. |
|
|
RETRO_TRG_VALUES |
Define a set of field changes that trigger retro requests. Each set can include fields from either the job record or the additional pay records. |
|
|
PY_RETROTRG_DEF |
Define a retro pay trigger program that encompasses up to two sets of triggers: one for the job record and one for the additional pay record. |
|
|
PY_RETROCNL_TBL |
Set up the cancellation reasons that users can use when manually canceling a retro pay request. |
This overview discusses retro pay programs and retro pay trigger programs.
Note: Mass retro and deduction retro do not use retro pay trigger programs.
Retro Pay Processing
Retro pay programs are designed to process retroactively-dated changes to the employee’s job record and additional pay pages. That is, use retro pay processing to calculate and pay employees when a raise (or subtraction) has been put into th system with an effective date that is earlier than or equal to the pay end date of the last check paid to the employee.
Retro pay only calculates on confirmed checks. Paysheets must be created prior to loading calculated retro payments to paysheets. Manual check are not included in retro pay calculations.
Note: After each upgrade, verify that the EOEN_MSG service operation for event notification in Event Framework is active. If it is inactive, retro pay will not trigger. See Events and Notifications Framework Implementation,PeopleTools: Integration Broker,PeopleTools: System and Server Administration.
Retro Program Setup
To set up retro processing, you must define these two types of retro programs for each pay group:
Retro pay programs define the earnings codes on which retro pay can be calculated as well as the earnings codes used to pay the retro pay earnings.
Retro pay trigger programs control which record and field changes create retro requests.
To set up a retro pay trigger program:
Identify fields on the job record (JOB) and on the additional pay data record (ADDL_PAY_DATA) that trigger retro requests when changed.
Perform this task on the Retro Pay Monitored Fields page. The fields that you list on this page are the only fields that are available for retro triggers.
Note: If the delivered data for this page meets your needs, you can skip this step.
Define retro triggers—the specific field changes that trigger retro requests.
Perform this task on the Retro Pay Trigger Values page, where you assign Retro Pay Trigger Value IDs that you can use to reference the different sets of retro triggers.
On this page, list all of the retro trigger conditions for the record (though you configure the JOB and ADDL_PAY_DATA records separately).
Define a retro pay trigger program and identify its Retro Pay Trigger Value IDs.
Retro pay programs include up to two Retro Pay Trigger Value IDs: one for the job record, and one for the addition pay data record.
The following diagram illustrates the steps for defining retro programs and associating them with pay groups:
Image: Steps for setting up retro programs
This example illustrates the fields and controls on the Steps for setting up retro programs.
Retro Pay Programs
Retro pay program definitions include some general settings such as the tax method to use for the retro earnings and whether to pay the retro earnings on a separate check. They also include a list of retro earnings codes.
Certain settings in the earnings code definition control which earnings codes you can include in the retro pay program:
When you define the earnings codes that are eligible for retro pay, you can select only earnings codes that are marked as Eligible for Retro Pay.
When you define the earnings codes for the corresponding retro pay earnings, you can select only earnings codes that are marked as Used to Pay Retro.
Retro Pay Trigger Programs
Retro pay trigger programs provide information about the field changes that trigger retro requests. The job (JOB) record and the additional pay data (ADDL_PAY_DATA) record are the only records that support retro pay triggers.
When you configure triggers for the additional pay data record, you can optionally limit the trigger based on the earnings code in the additional pay record.
Trigger Processing
Trigger processing begins when a change (update, insert, or deletion) occurs in a job or additional pay record.
Both online changes (including those made through manager self-service) and changes that are made through a component interface create triggers. Online changes can be made in add, update/display, or correction mode.
Retro pay triggers include:
FLSA_Status
Std_hours
COMPRATE
Comp_frequency
EMPL_STATUS
Shift_Rt
Shift_Factor
Effdt
Effseq
(Any changes to Additional Pay)
Note: Changes that you make using SQL are not recognized as triggers. To create retro requests for such changes, run the Retroactive Pay Mass Process (PSPRPMSS) COBOL SQL process to create retro requests for payees who meet your selection criteria. The Retroactive Pay Mass Process is unaware of the specific changes that you made using SQL; it simply creates retro requests based on the criteria you specify, and it is up to you to specify criteria that includes the right employees. When the Retroactive Pay Calculations (PSPRPEXT) COBOL SQL process processes the request, it uses the data in the source tables to calculate retro pay.
When an online action or a component interface makes a change in the job or additional pay record, PeopleSoft Integration Broker passes the before and after information to PeopleSoft Event Manager. Event Manager handles the message asynchronously: the system processes and saves the primary transaction normally, even if there is a problem with event processing.
Event Manager passes the messages to the event handler, which performs the following tasks:
Evaluates whether the change is a valid retro trigger:
If the change is not a valid retro trigger, no further processing occurs. To be a valid retro trigger, the change must meet these conditions:
The effective date of the change is earlier than or equal to the pay end date of the last check paid to the employee.
The change is configured as a trigger in the employee's retro pay trigger program (as defined for the employee's pay group).
(Additional pay data changes only) The additional pay earnings code is in the employee's retro pay program (as defined for the employee's pay group).
Creates a new retro request if there is not already an open retro request for the employee and job number, or updates the existing open retro request.
A retro request is considered open if its retro pay process flag (its status) is Not Processed, Calculated, Recalculate Request, Action Required, Suspended, or Extracted.
A retro request is considered closed if its retro pay process flag is Loaded to Paysheets, Manually Loaded to Paysheet, Confirmed Payment, Paycheck Reversed, or Cancelled/Withdrawn
Creates a trigger detail row in the employee's open retro request.
When the retro pay calculation processes a retro request, it uses the actual job and additional pay data. It does not use the trigger details to calculate retro pay. The system saves the trigger data for audit purposes only.
Note: Event Framework uses the Integration Broker message EOEN_MSG to pass the data across. Event Framework uses the Integration Broker messages RETROPAY_JOB and RETROPAY_ADDLPAY to transform the rowset data into the EOEN_MSG message. Accordingly, the RETROPAY_JOB and RETROPAY_ADDLPAY messages do not have routings, channels, and so on, within the Integration Broker configuration.
This overview discusses cancellation reasons for manual and automated cancellations of retro requests.
Manual Cancellations
Users can manually cancel retro requests on the Request and Trigger Summary page. This option is available only for requests where the process flag (the request status) is Not Processed, Suspended, or Action Required.
When users manually cancel retro requests, they can optionally indicate the reason for the cancellation by selecting from the cancellation reasons that you configure.
Automated Cancellations
Oracle delivers three cancellation reasons that are reserved for system use. These are not available for selection when a user manually cancels a request.
The delivered reasons are:
SC (system generated cancellation): the system canceled the request because the original triggering action was reversed.
For example, consider a retro request that is the result of adding a new job data row with a new compensation rate. If a user employs correction mode to delete that job row, the system cancels the retro request and uses the SC cancellation reason.
UC (user cancelled): a user cancelled the request by running the Retroactive Pay Undo (PSPRPUND) process from the Change Retro Pay Process Flag page.
ZR (zero retro – $0.00 to be paid): the Retroactive Pay Load Paysheets (PSPRPPSH) Application Engine process cancelled the request because there is nothing to be paid.
Note: Do not delete these delivered cancellation reasons. You cannot delete them using the online system, and it is important that you do not use SQL to delete them either.
Retro requests are generated through the Components Event Framework. Make sure that the RetroPayJobChange and RetroAddlPay events and their associated event handlers are active and that Integration Broker has been set up.
Use the Program Table page (RETROPAY_PGM_TBL) to describe a retro pay program and specify paysheet processing options.
Navigation
Image: Program Table page
This example illustrates the fields and controls on the Program Table page.
|
Field or Control |
Definition |
|---|---|
| Retro Pay Program ID |
This ID identifies the retro pay program when you associate the program with a pay group. |
| Offset Earnings Type |
Select an offset earnings type for any negative earnings that are generated by the retro pay calculation. To avoid negative checks, link this earnings code to a payback deduction code. The system deducts the amount from subsequent paychecks of applicable employees. |
Off Cycle
|
Field or Control |
Definition |
|---|---|
| Off Cycle |
Select to create retroactive pay that is associated with this program as off-cycle earnings. If you deselect this check box, the system creates retroactive pay that is associated with this program as on-cycle earnings. After the system calculates retro pay, but before you load the retro pay to paysheets, you can change this setting on the Retro Pay Calculation Results page under Retroactive Payroll. |
| Separate Check |
Select to load the earnings that are associated with this program to a separate check on the paysheets. |
| Tax Method |
Select a tax method to load to the paysheet line for the earnings in this program. |
| Tax Periods |
Enter the number of tax periods to load to the paysheet line for the earnings in this program. |
Use the Program Definition page (RETROPAY_PGM_DEF) to establish the earnings codes for which the retro pay program calculates retro pay and those used for paying retro pay earnings.
Navigation
Image: Program Definition page
This example illustrates the fields and controls on the Program Definition page.
Assignments/Ranges
Create a row of data for each earnings code that is eligible for retro pay.
|
Field or Control |
Definition |
|---|---|
| Earnings Type for Retro Pay |
Select the earnings code that is eligible for retro pay. |
| Retro Pay Earnings Type |
Enter the earnings code to use for the retro payment. |
Use the Retro Pay Monitored Fields page (PY_RETROTBL_DEF) to list the job and additional pay fields that are available to use when you define the triggers that create retro requests.
Navigation
Image: Retro Pay Monitored Fields page
This example illustrates the fields and controls on the Retro Pay Monitored Fields page.
|
Field or Control |
Definition |
|---|---|
| Record |
Oracle delivers definitions for the JOB record and the ADDL_PAY_DATA record. These are the only supported records for retro pay triggers. |
| Field Name |
The fields in the Field Definition grid are the only fields that are available for use in retro triggers. Oracle delivers field lists for both the JOB and ADDL_PAY_DATA records. You can add and delete entries to change which fields are monitored. You cannot delete entries for fields that are used in current retro pay trigger value definitions. |
Delivered JOB Fields
The delivered configuration for the JOB record includes these fields:
COMPRATE (compensation rate)
COMP_FREQUENCY (compensation frequency)
EMPL_STATUS (employee status)
FLSA_STATUS (FLSA status)
SHIFT (shift)
SHIFT_FACTOR (shift factor)
SHIFT_RT (shift rate)
STD_HOURS (standard hours)
STD_HRS_FREQUENCY (standard hours frequency)
Delivered ADDL_PAY_DATA Fields
The delivered configuration for the ADDL_PAY_DATA record includes these fields:
ADDL_PAY_SHIFT (additional pay shift)
COMP_RATECD (compensation rate code)
EARNINGS_END_DT (earnings end date)
GOAL_AMT (goal amount)
GOAL_BAL (goal balance)
HOURLY_RT (hourly rate)
OTH_HRS (other hours)
OTH_PAY (other pay)
PAY_PERIOD1, PAY_PERIOD2, PAY_PERIOD3, PAY_PERIOD4, and PAY_PERIOD5 (pay periods 1-5)
Use the Retro Pay Trigger Values page (RETRO_TRG_VALUES) to define a set of field changes that trigger retro requests. Each set can include fields from either the job record or the additional pay records.
Navigation
Image: Retro Pay Trigger Values page: JOB record
This example illustrates the fields and controls on the Retro Pay Trigger Values page: JOB record.
Image: Retro Pay Trigger Values page: ADDL_PAY_DATA record
This example illustrates the fields and controls on the Retro Pay Trigger Values page: ADDL_PAY_DATA record.
|
Field or Control |
Definition |
|---|---|
| Retro Pay Trigger Value |
This ID identifies the set of retro pay trigger values when you associate it with a retro pay trigger program. |
| Record |
JOB and ADDL_PAY_DATA are the only supported records for trigger values. |
Retro Pay Trigger Fields
|
Field or Control |
Definition |
|---|---|
| Field Name |
Select one of the fields that the system is monitoring for changes. These are the fields that appear on the Retro Pay Monitored Fields page for the selected record. When you select a value, the Field Name field immediately becomes read-only. To change the value, you must delete the row and add a new one. |
| Earnings Code and All Earnings Codes |
Note: These fields appear only for the ADDL_PAY_DATA record. Use these fields to choose which additional pay earnings codes produce retro requests when the selected field changes. To create retro requests for all retro-eligible earnings codes, select the All Earnings Codes check box. The system hides the Earnings Code field when the check box is selected. To create retro requests for a single earnings code, deselect the check box and enter a value in the Earnings Code field. To create retro requests for some, but not all, earnings codes, you can create multiple rows of data for the same field and enter different earnings codes for each row. Earnings code processing relies on the use of certain delivered codes that populate the Earnings Code field when you do not explicitly select a code. For JOB fields, the system uses the $NA (not applicable) earnings code, and for ADDL_PAY_DATA fields that affect all earnings codes, the system uses the $AC (all codes) earnings code. Therefore, it is critical that you do not modify, remove, or inactivate these two delivered earnings codes. |
| Dependent on Field Value |
To create a retro request for any change to the selected field, leave this check box deselected. To create a retro request only when the field changes to one or more specific values, select this check box and enter the values in the Field Values grid that appears. |
Field Values
|
Field or Control |
Definition |
|---|---|
| Set ID |
If the selected field is setID-controlled, you must enter a setID before you can select specific values. If the selected field is not setID-controlled, this field is not enterable |
| <Field Type> Value |
Enter the values that create retro requests. For example, in the JOB record, you might create retro requests for certain employee status changes to Active or Leave of Absence, but not when it changes to any other value. Depending on the field type, the label for the field value column is Character Value, Numeric Value, or Date Value. |
Use the Retro Pay Trigger Program page (PY_RETROTRG_DEF) to define a retro pay trigger program that encompasses up to two sets of triggers: one for the job record and one for the additional pay record.
Navigation
Image: Retro Pay Trigger Program page
This example illustrates the fields and controls on the Retro Pay Trigger Program page.
|
Field or Control |
Definition |
|---|---|
| Retro Pay Trigger Program ID |
This ID identifies the retro pay trigger program when you associate it with a pay group. |
Retro Pay Trigger Records
|
Field or Control |
Definition |
|---|---|
| Record Name |
Create rows for the JOB record and the ADDL_PAY_DATA record. These are the only records that support retro pay triggers. |
| Trigger Level and Retro Pay Trigger Value ID |
Select Field as the trigger level. Selecting Field makes the Retro Pay Trigger Value ID field appear so that you can select the retro pay trigger value ID that identifies those specific field changes. Note: Do not select Record. Triggering retro pay based on record-level changes (a new row, or changes to any field) is not currently supported. |
Use the Retro Pay Cancellation Reason page (PY_RETROCNL_TBL) to set up the cancellation reasons that users can use when manually canceling a retro pay request.
Navigation
Image: Retro Pay Cancellation Reason page
This example illustrates the fields and controls on the Retro Pay Cancellation Reason page.
Note: All fields are read-only when you view the SC (system generated cancellation), UC (cancelled by user), and ZR (zero retro - $0.00 to be paid) cancellation reasons.