EPY: Unconfirm (PSPUNCNF) Information (Master Solution) [ID 609485.1]

  Modified 26-OCT-2010     Type PROBLEM     Status PUBLISHED

 

In this Document  Symptoms  Cause  Solution  References

Applies to:

PeopleSoft Enterprise HRMS Payroll for North America - Version: 8 SP1 and later    [Release: 8 and later]Information in this document applies to any platform.

This document was previously published as Customer Connection Solution 693334

Symptoms

 Is there a  Master Resolution to act as an index to essential information on the Unconfirm process?

Cause

Not Applicable

Solution

●Information on the Pay Unconfirm process (PSPUNCNF):

Run Control Program = PSPUNCNFMain COBOL Program = PSPPYUNC

NOTE:  We consider this process appropriate for emergency use only in Production.  Normal production procedure should be to restore the database to the condition prior to confirm using backup and restore procedures.  

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).

The UNCNFRM

process SELECTS from the following tables for process control:

Record

Action

PS_PAY_CONF_RUNCTL

The process selects the run control record that is added by the user prior

to running the process.

PS_PAY_CALENDAR

Using the Run ID, the process selects the appropriate pay calendar information.

PS_INSTALLATION

The process selects the Balance ID for the calen

dar year.

The UNCONFIRM process UPDATES the following tables:

Record

Action

PS_PAY_CALENDAR

The PAY_CONFIRM_START flag is set to 'N' and the PAY_CONFIR

M_RUN flag is set to 'N'.

PS_PAY_PAGE

The CONFIRMED flag is set to 'N'.

PS_PAY_LINE

The CONFIRMED flag is set to 'N'.

PS_PAY_EARNINGS

The PAY_LINE_STATUS is set to 'C'.

PS_PAY_CHECK

The PAYCHECK_STATUS is set to

'C'. Fields such as LOCATION, CHECK#, CHECK_DT, etc. are blanked out.

PS_CHECK_YTD

The amounts added by CONFIRM are zeroed out (not deleted).

PS_EARNINGS_BAL

The amounts adde

d by CONFIRM are zeroed out (not deleted).

PS_DEDUCTION_BAL

The amounts added by CONFIRM are zeroed out (not deleted).

PS_TAX_BALANCE

The amounts added by CONFIRM are zeroed out

(not deleted).

PS_GARN_BALANCE

The amounts added by CONFIRM are zeroed out (not deleted).

PS_LEAVE_ACCRUAL

The amounts added by CONFIRM are zeroed out (not deleted).

PS_CHECK_YTD

The amounts

added by CONFIRM are zeroed out (not deleted).

PS_CAN_CHECK_YTD

The amounts added by CONFIRM are zeroed out (not deleted).

PS_CAN_ERN_BALANCE

The amounts added by CONFIRM are zeroe

d out (not deleted).

PS_CAN_DED_BALANCE

The amounts added by CONFIRM are zeroed out (not deleted).

PS_CAN_TAX_BALANCE

The amounts added by CONFIRM are zeroed out (not deleted).

PS_INS_EA

The am

RNS_BAL

ounts added by CONFIRM are zeroed out (not deleted).-- Including the goal related tables

PS_BOND_LOG

The rows added by CONFIRM are deleted.

PS_DED_ARREARS

The rows added by

CONFIRM are deleted.

PS_GENL_DEDUCTION

The rows added by CONFIRM are deleted.

PS_GARN_SPEC

The rows added by CONFIRM are deleted.

UNCONFIRM process DELETES fro

m the following table:

Record

Action

PS_PAY_MESSAGE

Messages from the prior run are deleted by company, pay group, pay end date, and off-cycle indicator. Page number is

also used for off-cycle check processing.

PS_PAY_DISTRIBUTN

The rows added by CONFIRM are deleted.

======================

RESTARTING CONFIRM:

CONFIRM updates four flags in the Pay sheet tables and two flags on the Pay Calendar.  These flags are used to make Pay Confirm a restartable process.  Pay Unconfirm should not be used when Pay Confirm fails to complete.  Instead the cause of failure should be resolved and -- when appropritate, Pay Confirm should be restarted.

Pay Confirm first updates Pay_Line_Status on the PS_PAY_EARNINGS records, for all checks in the paygroup, from a "C" (calculated) to an "F" (confirmed).  At the same time it also updates both PS_PAY_PAGE and PS_PAY_LINE as CONFIRMED = 'Y'.  Finally, still at the beginning of the process, PAY_CONFIRM_START is set to 'Y' for the Pay Calendar being processed.  

Then after processing each check, PAY_CHECK_STATUS on PS_PAY_CHECK is updated to "F" and after the last check for the Pay Calendar is process, the CONFIR_RUN flag on the PAY_CALENDAR row is set to 'Y'.

Balance records are updated while paycheck records are being processed.

As with any process, a failure will return all tables to the values established at the last commit.  Pay Confirm will execute a commit after each Pay Calendar processed and also, with in on Pay Calendar grouping,  after the count of checks reaches the Commit After value set on PS_INSTALLATION.

The above values and events are slightly different for Off-Cycle and Reversal processing.

When confirm is restarted, it first checks the Payroll Confirmation Run? flag on the Pay Calendar Table.  If this has not been checked and the "Payroll Confirmation Started?" flag has been checked, Confirm will go through the process of determining where to pick up processing.  It looks for the first record marked as "C".  (There may be other criteria as well.)

=====================

Marking Paysheets "Not OK to Pay":

The online views of Paysheet records select records with Pay Line Status not equal to "F".  This means that once paysheets have been confirmed, they cannot be viewed online.  This also means that these records cannot be marked Not OK to Pay.  To reverse (or void) an issued check the Paycheck Reversal/Adjustment process should be used.  If a client has a problem where a large number of checks were created in error they may want to run Unconfirm, mark the pay lines not "okay to pay" and reprocess calc and confirm.

=====================

ERRORS THAT MAY BE ENCOUNTERED:

Error  805, "Duplicate key on insert" from Confirm Process:

If balance records were created during the CONFIRM process (i.e. new month or quarter), UNCONFIRM will only zero the amounts on these records.  It will NOT delete the records that were created during Confirm.  As a result, if you unconfirm the first payroll in April, and then try to confirm a new off-cycle check in March, you will get an error when confirming the March check.

Confirm compares the month of the check date to the month of the highest dated balance record.  If the two are equal, Confirm will update the balance record.  If the two are not equal, Confirm assumes this is for a new month and inserts a record.  Since a balance record already exists, you get an error '805, Duplicate key on insert'.   The balance tables updated/inserted during CONFIRM are:   EARNINGS_BAL, TAX_BALANCE, DEDUCTION_BALANCE, GARN_BALANCE, CHECK_YTD.

Process abends with "00001 End of Fetch"

The CONFIRM and UNCONFIRM processes share common code.  When determining which balances to update, UNCONFIRM finds the max record and compares the month in the effective date to the month of the pay end date.  If there is a match, it does the update.  If there isn't a match it forces an End-of-Fetch error since there is no balance record to update.  If there are future period balance records, the match will fail and End-of-Fetch error will be issued.

Error 000012 "Already Confirmed - The Pay Calendar entry to be processed has already been confirmed.":

Caused by multiple unconfirm processes--  System can really only do one Unconfirm, not multiple Unconfirm processes.  Unconfirm is meant to be done just for one payroll at a time.  

 "Unconfirm did not finish  -- INSERT-BALANCE(UN)" or

 " Unconfirm is failing in program section-balance return code is 0001-end of fetch error

rollback completed"

The following are some reasons why you might get these errors

a.  Error caused by the tax balance records brought over during conversion.   Locality field should only be 1 blank.  If more than 1 blank is used, it will cause a problem in that UNCONFIRM could not find a matching balance record to roll back, and thus tries to do an INSERT which is not allowed during an UNCONFIRM.  

b. Incorrect key field due to conversion.  Balance Records are key COMPANY, BALANCE_YEAR,BALANCE_QTR, BALANCE_PERIOD. Valid quarters are 1 to 4 and valid periods are 1 to 12.  

c. Leave enrollment process was not run for some employees, so these employees did not have any PS_LEAVE_ACCRUAL records.  Logic in the PSPABUPD program prohibits unconfirm from performing an insert, thus the program forces an error and terminates.  Workaround was to manually insert rows into PS_LEAVE_ACCRUAL for the error employees.

Alternate solution would have been to run the leave plan enrollment process, for a large number of "problem" employees.

======================

EXAMPLES OF PROBLEM ENCOUNTERED WITH UNCONFIRM

Problem 1:  Incorrectly reversed a live check.  Now they cannot input the check.  They tried unconfirming the reversal, but this is not working.

Solution 1:  After cleaning up other corrupted data, unconfirm process still could not be used because other payrolls had since been calculated and confirmed.  After changing the check number on the two offseting entries for the check (reversal and reversed), the customer was able to reenter the manual check with the correct check number.

Problem 2:  Balance ID = 'BY' -- definition for benefit year, was causing problems for confirm.  Some checks had already been confirmed before it was realized that the problem was the incorrect definition of periods.  In this case October, 2000 was defined as year 2000, quarter 1, period 10 even though it was the first month of the benefit year.  

Solution 2:  As a result, the confirm process of the second check for each employee assumed an insert was required since the most current row was 2000,4,9 -- September.  Thus the duplicate on insert.  Unconfirm process only allows update, so it forces and end of fetch error when the most current row found does not match the period of the check.  With some checks confirmed and others not able to be confirmed, the customer was stuck.  

To correctly post future payrolls, change the entry in PSPPYGRP_S_BALDEF to reflect the correct period and year for October.  This will not help for the unconfirm process, because it still will not match the existing balance records.  Thus prior to correcting the calendar definition, you should disable the BY balance id using the following update statement:

UPDATE PS_BALANCE_ID_TBL

SET MAINTAIN_TAX_BAL = 'N'

SET MAINTAIN_EARN_BAL = 'N'

SET MAINTAIN_DED_BAL  = 'N'

SET MAINTAIN_GARN_BAL = 'N'

SET MAINTAIN_CHK_BAL  = 'N'

WHERE BALANCE_ID = 'BY'

Once the unconfirm process for all October paychecks is complete, the BY balance id may be corrected and reactivated for the required balances, and all checks may be confirmed.

References

Document :609064.1     Should a customer run payroll unconfirm in production?Document :607278.1   - INFO: Consolidated details about UNCONFIRM;  Why call support before running UNCONFRM.Document :607134.1   -- Information about Restarting PayCalc and Confirm

RelatedProducts

● PeopleSoft Enterprise > Human Capital Management > North American Payroll > PeopleSoft Enterprise HRMS Payroll for North America

● PeopleSoft Enterprise > Human Capital Management > North American Payroll > PeopleSoft Enterprise HRMS Payroll for North America

Errors ERROR 000012; ERROR 805

Back to top Rate this document 

Article RatingRate this document Excellent Good Poor Did this document help you? Yes No Just browsing How easy was it to find this document? Very easy Somewhat easy Not easy

CommentsProvide feedback for this article. Please use 'Contact Us' for other feedback.Important Note: this feedback is anonymously visible to other customers until processed by Oracle Support.

Cancel