Do not run UNCONFIRM if the original confirm process did not complete successfully.
The Pay Unconfirm batch process is used to unconfirm a payroll cycle that has been confirmed. That is, it backs all of the detail out of the balance tables and resets the status of paysheet details, so that everything looks like you are ready to run final Pay Calculation, prior to Pay Confirmation. To run UNCONFIRM, access the Pay Unconfirm component in North American Payroll.
Pay Unconfirm reverses out the entire pay run; use Paycheck Reversal/Adjustment for individual checks.
Note the following differences between unconfirm and restoring to prior to confirmation:
1) After you run Pay Unconfirm, you must manually reset the Last Form Number Used field in the Form Table to the last number that was used before you ran Pay Confirmation; Pay Unconfirm does not reset this number automatically.
2) When unconfirm is run for the first confirm of any balance period, the balance records will be updated to zero, but not deleted. If after unconfirm, the next confirmation run will be for a prior period, these remaining balance records must be deleted to prevent duplicate insert errors on confirmation.
3) Since unconfirm will only update records, when the proper record to update is not found, errors will occur. In particular End-of Fetch errors during unconfirm are generally caused by missing or incorrectly ordered balance records.
4) The CONFIRM process deletes paysheet records where OK_TO_PAY = 'N'. The UNCONFIRM process does not add these records back.
5) In Release 9 and beyond, there may be an issue with the Garnishment status if the flag was set by the system in the confirm process. Once the payroll has been confirmed and the garnishment status has been set to complete, there is no way for us to go back and systematically know at what point it was set to complete. The status could have been changed by the confirm process because of either a limit amount or Stop Date that has been reached, or the status could have been manually changed by the customer to "complete". So when the customer wants to run an Unconfirm, we do not know which one of these scenarios applied. In addition to that, the status could have been changed in a prior pay period, we don't currently have the means to figure that out systematically either
======================
DETAILS OF UNCONFIRM PROCESS:
The Pay Unconfirm batch process is used to unconfirm a payroll cycle that has been confirmed. That is, it backs all of the detail out of the balance tables and resets the status of paysheet details, so that everything looks like you are ready to run final Pay Calculation, prior to Pay Confirmation. To run UNCONFIRM, access the Pay Unconfirm component in North American Payroll.
Pay Unconfirm reverses out the entire pay run; use Paycheck Reversal/Adjustment for individual checks.
Note the following differences between unconfirm and restoring to prior to confirmation:
1) After you run Pay Unconfirm, you must manually reset the Last Form Number Used field in the Form Table to the last number that was used before you ran Pay Confirmation; Pay Unconfirm does not reset this number automatically.
2) When unconfirm is run for the first confirm of any balance period, the balance records will be updated to zero, but not deleted. If after unconfirm, the next confirmation run will be for a prior period, these remaining balance records must be deleted to prevent duplicate insert errors on confirmation.
3) Since unconfirm will only update records, when the proper record to update is not found, errors will occur. In particular End-of Fetch errors during unconfirm are generally caused by missing or incorrectly ordered balance records.
4) The CONFIRM process deletes paysheet records where OK_TO_PAY = 'N'. The UNCONFIRM process does not add these records back.
5) In Release 9 and beyond, there may be an issue with the Garnishment status if the flag was set by the system in the confirm process. Once the payroll has been confirmed and the garnishment status has been set to complete, there is no way for us to go back and systematically know at what point it was set to complete. The status could have been changed by the confirm process because of either a limit amount or Stop Date that has been reached, or the status could have been manually changed by the customer to "complete". So when the customer wants to run an Unconfirm, we do not know which one of these scenarios applied. In addition to that, the status could have been changed in a prior pay period, we don't currently have the means to figure that out systematically either
======================
DETAILS OF UNCONFIRM PROCESS:
- Backs out all of the detail from the employee balance tables for the specified payroll cycle. (Note: if balance records were inserted by the CONFIRM process, UNCNFRM will zero these amounts rather than delete the record.)
- Resets the status on the paysheet records to a calculated status.
- Updates the pay calendar to reflect that CONFIRM has not been run.
- The CONFIRM process creates entries in PS_PAY_DISTRIBUTN. The UNCONFIRM process deletes these records.
To run Pay Unconfirm, set up a run control request and run the batch process. As of HRMS 8, there is a separate component -- Pay Unconfirm, which should be used to set up the run request and start the process. As of HCM 8.8, use the Reverse Pay Confirmation menu item to initiate Pay Unconfirm.
UNCONFIRM is frequently used in a testing environment because it allows users to rerun a payroll cycle once it has been confirmed. In a production environment, this process is rarely used. It may be used if there was a high-level table change that requires the recalculation of all paychecks.
It is very important that you understand exactly what UNCNFRM will do in your particular situation before using it. The recovery steps necessary may differ depending on the actual situation. The PS_PAY_FORM_TBL may need to be updated manually so CONFIRM can reassign the check numbers correctly.
Points to consider when running the UNCNFRM batch process:
- After running UNCNFRM, you must rerun CALCPAY. Otherwise, the JOB.LOCATION field on PS_PAY_CHECK will not be repopulated. (Payroll uses the JOB.LOCATION value to sort checks as a sort option for company distribution). It is recommended to run ReCalc ALL after Unconfirm, prior to running the Confirm process again. This will populate the LOCATION field with the LOCATION code on PS_JOB.
- The CONFIRM process deletes paysheet records where OK_TO_PAY = 'N'. The UNCONFIRM process does not add these records back. Therefore, a backup is recommended prior to running the CONFIRM process.
- If there are multiple Paygroups using the same Run ID but only some of the Paygroups need to be Unconfirmed, update the Pay Calendar table by removing the Run ID for any Paygroups tied to this Run ID that are correct , leaving the problem PayGroup(s) tied to the Run ID. This will allow you to Unconfirm only the problem PayGroup(s).
