Contract Retro Processing

Contracts can retroactively change between the time they start and the time they end. For example, pay rates, schedules, or funding sources may need to change mid-year and have a retroactive effect. The changes may be the result of negotiated agreements or simply corrections for errors in the original setup. When required changes are discovered after-the-fact, the Contract Retro Utility must be run to recalculate earnings and pay for the appropriate retro time-frame. The mechanism used in BusinessPlus Payroll for those retro calculations is a process that compares the corrected setup for each employee against the transaction record for the retro time-frame. The retro differences for both earnings and for pay are written out to a special Retro Timecard Batch to be included in the next regular or supplemental payroll.

Retro Exceptions

If data in the employee's pay line retroactively changes, exception entries on the old pay lines will need to be moved to a new pay line. Exceptions that affect patching must all be moved to assigned lines before the Retro Earnings can be calculated correctly. An attempt will be made to move all exceptions regardless of their effect on patching. Once a pay line changes, it is not possible to have a link between the new and old pay lines. A pay string matching pattern can be set up to allow for this link. The matching pattern must be a combination of pay string parts that points to a unique pay string assigned to the employee. These parts would be made up of data that would not retroactively change. For example: Fiscal Year, Sequence Number, and GL Key.  If a match is found, the exception entry will be retro'ed. The process will back out the old pay line activity and create a new transaction under the new pay line. Refer to common code PYFG/PY214C for matching pattern setup, and for available processing options when match is not found.

Retro Effect on LWOP Request

The LWOP Request hour is used in increase of the LWOP balance. Assuming the LWOP is set up as an exception hour to be included in the retro process, the retro utility can make rate adjustments to LWOP transactions in order to change the original LWOP Request. Hours per day changes associated with the contract will not be picked up in the retro process. A daily timecard entry for the hours change will be required to increase the LWOP Request.

Retro Earnings

When retroactively effecting Earnings, the transaction history is compared against earnings patched under the current pay assignments in order to derive any differences. There is no requirement to retain the old pay assignments as retro uses SYSTM batch data to derive all previous num codes associated with the contract ID in question. Two major advantages to this approach are that it is (1) simpler and more intuitive to set up, and (2) that it can handle more complex cases involving overlapping combinations of retro changes. Users may simply fix pay assignments to conform to what should have been and run the retro process over the affected date range. When the pay line changes it will result in the full amount patching on the newly assigned line and the old transactions, which no longer have corresponding assignments, to back out.

Retro Pay

Pay assignments are fixed to look as they should when applying retroactive pay changes. The salary the employee should have been paid at any particular time can be determined by looking at information on active pay assignments in the period. Contract Pay and Retro Pay will follow assigned lines. Amounts paid on lines no longer assigned or active, in a given period, will be backed out.

Retro Effect on Escrow Payout

Calculation for the escrow amount that should have been paid in each escrow payout period is done on the HR Pay Assignment page. The escrow amount to be paid on the line is written to an HR Pay Assignment Misc Value field specified in the HRPY/CNTRCTIDcommon code. When stopping the contract and paying out the escrow in a lump sum, using the PF Payout Type code, the paid dates on the HR pay assignment not be sent to Payroll. If spreading the escrow amount of the paid date time frame, using the PS Payout Type code, the paid dates keep the assignment active, so the escrow amount specified can be paid during the paid date timeframe. The amount that should have been paid (as specified in the Misc Value field) will be compared to the PY transaction amounts. A difference will result in a retroactive escrow payout transaction. All escrow payout transactions will occur on the Contract Pay CDH.

Retro Pay Payout Options

The Retro Tp field on the HR pay assignment is used to indicate if the retro pay amount should be spread over the life of the contract or paid out in a lump sum amount. If the Retro Tp Field is set to RS, any retro pay on the contract should be spread across the remaining periods on the contract. A blank Retro Tp Field will indicate that any retro pay amount generated on the contract should be paid out in the current period as a lump sum amount. Special setup is required in order to spread retro pay. The employee's pay class must contain the Retro Pay Request and Retro Pay Spread CDHs. The Retro Pay Request CDH is generated by the Retro utility and is written to the RETRO timecard set. The Retro Pay Spread CDH calc code determines the amount of retro pay to be taken in the period during the force calculation process, based on client-defined business rules. See the CDH Setup Guide for detailed CDH setup information.

Retro Pay Spread Calc Code

<<Contract Retro Spread >>
CVAR1 := " "
CVAR3 := " "
CVAR9 := "EBUG"
NVAR1 := 0
NVAR6 := 0
DO
NVAR1 := NVAR1 + 1
LOAD(CTFC.CLS,NVAR1)
IF MSCX.STATUS = "FAILED"
GOTO LABEL1
ENDIF
NVAR6 := 0
CVAR1 := " "
CVAR8 := " "
<<Load all assignments and look for the one with the end >>
<< date that matches the contract end date since it >>
<< will have our Retro Type Code >>
DO
NVAR6 := NVAR6 + 1
LOAD(PYPX.CLS,NVAR6)
IF MSCX.STATUS = "FAILED" OR CVAR3 = "DONE"
GOTO LABEL2
ENDIF
IF CTFC.CTID = PYPX.CNTID AND PYPX.FROM = 'P'
<< If we find the pay assignment that matches >>
<< contract end date then let's not load any more >>
<< assignments after this one. However, go ahead and >>
<< process all assignments until we do find it, just in >>
<< case we don't find it all for some strange reason >>
IF PYPX.PAYEND = CTFC.END
CVAR3 := "DONE"
ENDIF
IF PYPX.RETRTP = "RS"
IF PERM.TYPE = "SUPP"
CTFC.CDHAMT := CTFC.RTRBAL / (CTFC.PPRDR + 1)
CTFC.CDHPAY := CTFC.RTRBAL / (CTFC.PPRDR + 1)
ELSE
CTFC.CDHAMT := CTFC.RTRBAL / CTFC.PPRDR
CTFC.CDHPAY := CTFC.RTRBAL / CTFC.PPRDR
ENDIF
CVAR1 := PYPX.RETRTP
ELSE
CTFC.CDHAMT := CTFC.RTRBAL
CTFC.CDHPAY := CTFC.RTRBAL
ENDIF
LABEL2
ENDIF
UNTIL MSCX.STATUS = "FAILED"
IF CVAR9 = "DEBUG"
WARN("Contract ID: ",CTFC.CTID)
WARN(" Retro Bal: ",CTFC.RTRBAL)
WARN(" Retro Payout type: ",CVAR1)
WARN(" Periods Remaining: ", CTFC.PPRDR)
WARN(" Retro Spread Amt: ",CTFC.CDHAMT)
WARN(" ")
ENDIF
MSCX.STATUS := "FLUSH"
LABEL1
UNTIL MSCX.STATUS = "FAILED"

Retro Pay

The retro pay that has been paid is added to the regular contract pay that has been paid to get the total pay amount for the period. This amount is compared to the salary on the PY pay assignment and retro pay transactions are generated if differences are found.

Running the Retro Utility

Contract Retro Utility Output

The retro transaction generated by the Contract Retro Utility is written to a standard batch name "RETROnnnnnnn" where "nnnnnnn" is the current pay period. Each time the process runs, all retro records for an employee are deleted and recreated. The utility also updates the Contract Accumulator record with the current period's pending retro values. Once the current period is paid, the Pending Retro amounts are added to the Retro amounts on the Accumulator record. Running a recompute of contract accumulators (PYUTRC) prior to paying the period will zero out the pending retro amounts, but any retro transaction in distributed timecard batches will be paid.

Employee Selection Criteria

The user can select employees using standard PY Selection Criteria to process through the Retro utility.

Contract Selection

Two dates are available to (1) select contracts for processing, and (2) indicate the retro start date at which retroactive changes will be processed

• The Retro Process (PYUTRTRP) prompts for the Retro Date (Enter the As Of Date). This question identifies how far back we want the retro utility to process.  In addition, only contracts ending after the Retro As Of date will be included.  Contracts that begin after that Retro As Of date will be run for the full Contract date range.  Contracts starting before the Retro Period will be run only from the Retro Period forward. Late and early patching scenarios will be considered.  For example, if a contract starts in the Retro Period specified and has an early patch date that falls prior to the Retro Period, the early patch date will be used as the Retro Begin date.

• Retro cutoff date. A Retro cutoff date can be set in common code PYFG/PY214C, Associated Code 1. If the pay assignment begins prior to the Retro cutoff date, it will not be considered for retro. The purpose of this date is to allow the As Of Date entered at the time of processing to overlap last year's contracts, but last year's contracts are not included in the Retro Processing. This will allow for faster Retro Processing and eliminate unwanted corrections on last year's contracts.

Contract Modified Switch 7

Switch 7 on the Employee Definition page (PYUPEM), Switches Tab, is the Contract Modified switch.

Retro Processing Options

Lump Sum Payout

• After saving and sending a retroactive pay assignment change to Payroll, generate a Lump sum retro payout by running the Retro utility (PYUTRTRP) to pick up Retro earnings and payments.

• On the pay assignment, notice that the Retro Earnings and Retro Payments display in the Pending Retro line.

• After the period is paid, retro now moves up to the Retro line.

Retro Spread over Life of the Contract

It is most common to spread retro pay over the life of the contract in a negative Retro situation. If you wish to spread the payments over the life of the contract, further changes are required on the HR Pay Assignment records prior to sending the assignment to payroll.

• After making the retroactive change (i.e., step change from 01 to 02) set the Retro Tp to RS on the Miscellaneous tab.

• Set RS on all HR Pay Assignment records on the contract and send all of the assignments to payroll.

• Run the Retro utility (PYUTRTRP) to pick up Retro earnings and payments.

Retro Spread over User-Defined Number of Periods

The standard Retro Spread calc code does not support this option. Calc code changes are required. Contact Customer Support for information on the Calc Code.

If you wish to spread the payments over a user-defined number of periods, further changes are required on the HR Pay Assignment records prior to sending the assignment to payroll.

• After making the retroactive change (i.e., step change from 01 to 02) set the Retro Tp to RS on the Miscellaneous tab.

• Set RS on all HR Pay Assignment records on the contract and send all of the assignment to payroll.

• On the assignment with the latest contract changes, on the Miscellaneous tab, set Special Cd 5 to the number of periods to spread the retro over, and set Special Cd 6 to the number of periods remaining on the contract at the time of data entry.

• Run the Retro utility (PYUTRTRP) to pick up Retro earnings and payments.