[{TableOfContents }]
\\
__Pay reversals__ are performed when it is necessary to 'back out' an individual employee's pay that has been issued, either because it was issued in error or because it is being replaced with a different pay.

The reversal feature is NOT used to issue a replacement check; voiding the original outstanding check and entering a manual outstanding check will do this.

Only 'Closed' pay headers may be reversed.

A reversal must be entered under the same pay period as the pay that is being reversed.

A reversal pay header and pay category is entered on the IPPH form. The pay number of the pay being reversed must be entered in the Reversal Pay field.

A reversal pay cannot be reversed.

A reversal may not be issued in the current year if the original pay was issued in the prior year.

All pay component amounts will be negated, but no calculations are performed.

Arrears will be reinstated as Sundry transactions. They may need to be deleted if they are not required.

A reversal will not touch 'replace' type statistics pay components. If they are being used, the pay calculation exception report issues an exception message to remind the user to adjust any statistical values manually, if required.

----
!!REVERSAL PAY SETUP
;Pay Category - IPPGU/IPPGC
;:Create a pay category called 'REVERSAL'
;:The pay category does not require a separate pay point.
----

!!REVERSAL PAY PROCESS
The Payroll process should be run the same as for a regular pay header.
# Go to Pay Header ([IPPH]) form and chose the employee who's prior pay needs to be reversed. Note the pay # and pay period to be reversed.
# Add a new pay header.
# Enter the batch number.
# Make the period the same as the pay to be reversed.
# Enter ‘Reversal’ as the category.
# Go to the Reversal Pay field and enter the pay # for the pay to be reversed. A List of Values is available.
# Run UPAUDT as usual, this will reverse all of the Transactions and Pay amounts from the Closed Pay.
**From this point the pay cycle is continued as normal through to [UPCLOZ].
**[UPCALC] will indicate the fact that it has not made any Attendance or Benefit adjustments.

----
!!REVERSALS AND ATTENDANCE
Due to the fact that users may be reversing a pay that has had other pays run in between, the Reversal process in ePersonality does not make any adjustments to the Attendance application data.

If the reason for the reversal is due to the fact that the employee was paid for vacation time instead of sick time, then a reversal is not necessary. The next pay header created for the employee can have pay lines entered for the offsetting amounts
i.e. Suppose 2000-18 had 8 hours of Vacation entered on the 15-May-2000 instead of Sick. In that case, 2000-19 can have 8 hours of Vacation entered on 15-May-2000 (even though it's prior to the pay period start date) and 8 hours of Sick entered for the same date.

The reversal pay will have created no leave lines.

This process is to be followed after the reversal is closed and before any other pay has been
started.

# Go to the leave line(s) in [IAAL] for the time entered.
# Make the value in the Overall Time field negative (-).
# Change the Accrual Status to 'Not Updated'.
# Turn off the Payroll Complete toggle.
# Ensure the Amount for A300 in the Leave Line Details is also negative.
# Run [UACALC] for the Pay Period End date that you have reversed.
**Only run [UACALC] for the employee(s) that you have reversed!
**[UACALC] will not give leave entitlement again or any pay that is issued to replace the reversal, as the entitlement date on the Leave Accrual ([IALA]) form will already indicate that an entitlement has been given.
# Verify the data on [IAAL] (the original leave lines should have a status of 'Update In Progress') and [IALA] (there will be 'Unofficial' records for the accruals that have been calculated).
**If good, run [UACLOZ].
**If bad, run [UAUNDO], make changes, and rerun [UACALC].
----
!!REVERSALS AND BENEFITS
Due to the fact that users may be reversing a pay that has had other pays run in between, the Reversal process in [{$applicationname}] does not make any adjustments to the Benefits application data.

!PROCESSING FREQUENCY WITH 'FIRST PAY IN PERIOD' OFF
This frequency means that the benefit will be calculated for all pay headers entered in the same pay period.
;__Re-issuing the check__
;:The Benefit Component amounts in the benefit lines created on [IBBL] should be made '0' for the period that has been reversed.
;Remitting from Pay Amounts
;:If you are creating remittance reports based on Pay Amounts then there is no other maintenance to be done, as the amounts will be correct in the Pay Amounts.
;Remitting from Benefit Lines
;:If you are running the remittance reports through Benefits then there is no other maintenance to be done, as the amounts will be correct on the Benefit Lines.
;:Re-issuing the pay will update the Benefit Enrollment ([IBEN]) form with the data from the 'reissued' pay.
;:If this is a BOND plan, then the Benefit Enrollment ([IBEN]) form must have BC1320 - Amount Available for Bond Purchase updated to reflect the fact that the original deduction was not taken. This is due to the fact that BOND information is accumulative not replacing.

\\
;Not Re-issuing the check
;:The Benefit Component Amounts in the Benefit Lines created on [IBBL] should be made '0' for the period that has been reversed.

;:Not re-issuing the pay will mean the Benefit Enrollment ([IBEN]) form will still reflect the 'reversed' pays benefit data. The Benefit Components on [IBEN] should be updated with the previous periods calculated amounts from the Benefit Lines ([IBBL]).

;Remitting from Pay Amounts
;:If you are creating remittance reports based on Pay Amounts then there is no other maintenance to be done, as the amounts will be correct in the Pay Amounts.
;Remitting from Benefit Lines
;:If you are running the remittance reports through Benefits then there is no other maintenance as the amounts will be correct on the Benefit Lines.

!PROCESSING FREQUENCY WITH 'FIRST PAY IN PERIOD' ON
This frequency means that the benefit will not be re-calculated for pay headers entered in the same pay period.
;Re-issuing the check
;:All benefits related to pay components must be entered either in the Sundry ([IPSN]) form or as a pay line in [IPPH] before auditing ([UPAUDT]) the pay header.
*Ensure that the pay components are set up to allow data entry.
;:Not re-calculating the benefits will mean the Benefit Enrollment ([IBEN]) and Benefit Lines ([IBBL]) will still reflect the 'reversed' pays benefit data.
*If the information does not change for the 're-issued' pay, then no further changes are needed.
*If the amounts are different for the 're-issued' pay, then the Benefit Components in [IBEN] and [IBBL] should be updated with the correct amounts for the period that was re-issued.
;Remitting from Pay Amounts
;:If you are creating remittance reports based on Pay Amounts, then there is no other maintenance to be done as the amounts will be correct in the Pay Amounts.
;Remitting from Benefit Lines
;:If you are running the remittance reports through Benefits then there is no other maintenance as the amounts will be correct on the Benefit Lines.
\\
;Not Re-issuing the check
;:The benefit component amounts in the Benefit Lines created on [IBBL] should be made '0' for the period that has been reversed.
;:Not re-issuing the pay will mean the Benefit Enrollment ([IBEN]) form will still reflect the 'reversed' pays benefit data. The Benefit Components on [IBEN] should be updated with the previous periods calculated amounts from the Benefit Lines ([IBBL]).
;Remitting from Pay Amounts
;:If you are creating remittance reports based on Pay Amounts then [IBEN] should be updated with the previously calculated amounts from [IBBL].
;Remitting from Benefit Lines
;:If you are running the remittance reports through Benefits then there is no other maintenance as the amounts will be correct on the Benefit Lines.