EPY: Unconfirm (PSPUNCNF) Information (Master Solution) [ID 609485.

1]

M od ifi ed 26 O C T20 10 Ty pe P R O BL E M St at us P U BL IS H E D 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 = PSPUNCNF Main 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 UN CN FR

M pro ces s SEL EC TS fro m the foll owi ng tabl es for pro ces s con trol : Rec Acti ord on PS _P AY _C ON F_ RU NC TL The pro ces s sel ect s the run con trol rec ord tha t is add ed by the use r pri or

to run nin g the pro ces s. PS Usi _P ng AY the _C Ru AL n EN ID, DA the R pro ces s sel ect s the app rop riat e pay cal end ar info rm atio n. PS The _IN pro ST ces ALL s ATI ON sel ect s the Bal anc e ID for the cal end

ar yea r.

The UN CO NFI RM pro ces s UP DA TE S the foll owi ng tabl es: Rec Acti ord on PS _P AY _C AL EN DA R The PAY _C ON FIR M_ ST AR T flag is set to 'N' and the PAY _C ON FIR M_ RU

PS _P AY _P AG E

PS _P AY _LI NE

PS _P AY _E AR NI NG S

PS _P AY _C HE CK

N flag is set to 'N'. The CO NFI RM ED flag is set to 'N'. The CO NFI RM ED flag is set to 'N'. The PAY _LI NE _S TAT US is set to 'C'. The PAY CH EC K_ ST AT US is set to 'C'. Fiel ds suc

PS _C HE CK _Y TD

PS _E AR NI NG S_ BA L

h as LO CA TIO N, CH EC K#, CH EC K_ DT, etc. are bla nke d out . The am oun ts add ed by CO NFI RM are zer oed out (no t del ete d). The am oun ts add ed by CO NFI RM are zer oed

out (no t del ete d). PS The _D am ED oun UC ts TIO add N_ ed BA by L CO NFI RM are zer oed out (no t del ete d). PS The _T am AX oun _B ts AL add AN ed CE by CO NFI RM are zer oed out (no t del ete d). PS The _G am AR oun N_ ts BA add LA ed NC by E CO

NFI RM are zer oed out (no t del ete d). PS The _LE am AV oun E_ ts AC add CR ed UA by L CO NFI RM are zer oed out (no t del ete d). PS The _C am HE oun CK ts _Y add TD ed by CO NFI RM are zer oed out (no t del ete d). PS The _C am AN oun

_C HE CK _Y TD

PS _C AN _E RN _B AL AN CE

PS _C AN _D ED _B AL AN CE

ts add ed by CO NFI RM are zer oed out (no t del ete d). The am oun ts add ed by CO NFI RM are zer oed out (no t del ete d). The am oun ts add ed by CO NFI RM are zer oed out (no t del

ete d). PS The _C am AN oun _T ts AX add _B ed AL by AN CO CE NFI RM are zer oed out (no t del ete d). PS The _IN am S_ oun EA ts RN add S_ ed BA by L CO NFI RM are zer oed out (no t del ete d). -Incl udi ng the goa l rela ted tabl es PS The

_B ON D_ LO G

row s add ed by CO NFI RM are del ete d. PS The _D row ED s _A add RR ed EA by RS CO NFI RM are del ete d. PS The _G row EN s L_ add DE ed DU by CTI CO ON NFI RM are del ete d. PS The _G row AR s N_ add SP EC ed by CO NFI RM are del ete

d.

UN CO NFI RM pro ces s DE LET ES fro m the foll owi ng tabl e:

Rec Acti ord on PS _P AY _M ES SA GE Me ssa ges fro m the pri or run are del ete d by co mp any , pay gro up, pay end dat

e, and offcycl e indi cat or. Pag e nu mb er is als o use d for offcycl e che ck pro ces sin g. PS The _P row AY s _DI add ST RIB ed UT by N CO NFI RM are del ete d.

====================== 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

Related

Products 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 ERR OR 000 012 ; ERR OR 805

Back to top Rate this document

Articl e Ratin g

Comments Provide 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. Rate this document Not easy Somewhat easy Very easy How easy was it to find this document? Just browsing No Yes Did this document help you? Poor Good

Excellent

Can cel