Troubleshooting Payroll for North America1

PeopleSoft Payroll for North America PeopleSoft 8.3 Payroll for North America Troubleshooting Guidelines

PeopleSoft 8.3 Payroll for North America Troubleshooting Guidelines

What should you do when something goes wrong in your PeopleSoft Payroll system?

We hope that nothing will, of course. But in a complicated process like generating full and accurate paychecks, it’s almost inevitable that you will hit a few snags, from processing sequence errors to difficulties with COBOL configurations. This document will help you identify and resolve problems as they arise during payroll processing.

In this document, we discuss the following:

A troubleshooting checklist.

Understanding error resolution.

Process overview.

Troubleshooting tools.

A Troubleshooting ChecklistWhen troubleshooting, follow these steps:

1. Determine the impact of the problem.

2. Isolate the problem.

3. Diagnose the problem.

4. Fix the problem.

5. Test the solution.

Determine the Impact of the Problem

When determining the impact of the problem, ask the following questions:

Is the problem occurring in the production environment?

What is the business impact?

Who is affected by the problem?

Is there a reasonable workaround?

Isolate the Problem

When isolating the problem, ask the following questions:

Specifically, what is the problem? What is the expected result? What result are you getting?

PeopleSoft Proprietary and Confidential 1


What is the simplest set of conditions that consistently causes the problem to occur? Remove unnecessary variables from the test. Can these steps be duplicated?

Can the problem be replicated in the DEMO database?

Has this problem occurred before? If not, when did it last work? What has changed since then?

Have there been any modifications in this area?

Diagnose the Problem

When diagnosing the problem, do the following:

Compare program file dates and sizes to make sure you are using the correct version.

Use diagnostic tools such as traces and audit programs. See Troubleshooting Tools.

Search in Updates and Fixes in Customer Connection to determine if this is a known problem. Customer Connection is on PeopleSoft’s website.

Fix the Problem

When fixing the problem, do the following:

Correct the data (employee, table setup).

Correct the program and apply the fix.

Test the Solution

When testing the solution, do the following:

Test the fix under relevant conditions.

Test in the development environment.

Test in the production environment.

Understanding Error ResolutionIn this section, we provide descriptions of and solutions for some errors that can occur in your PeopleSoft Payroll system. A number of errors might happen during online procedures, but the majority are inconsistencies that are revealed by payroll processing.

In this section, we discuss:

Online processing errors.

CALENDAR process errors.

PAYSHEET process errors.

CALCPAY process errors.



CONFIRM process errors.

UNCNFRM process errors.

REPRINT process errors.

REVERSAL process errors.

Online Processing Errors

These errors might appear when you are performing actions online.

No Matching Buffer Found For Level (Paysheets)

This error indicates that a child record has been left without a ‘parent’ record (in other words, the record is orphaned).

Run PRECALC.SQU to identify the orphan record. To resolve the problem, delete the orphaned records as well as their associated records. Typically, these are the tables involved:

PS_PAY_LINE

PS_PAY_EARNINGS

PS_PAY_OTH_EARNS

PS_PAY_ONE_TIME

PS_PAY_TAX_OVRD

PS_PAY_GARN_OVRD

PS_PAY_CTX_OVRD

If Pay Calculation has been run, additional tables are affected as well. For assistance with this process, please call the PeopleSoft Global Support Center.

Prompting Earnings Code Returns Too Many Rows on Additional Pay Page

Prompting for the earnings code returns all earnings codes associated with all earnings programs (as opposed to just those earnings codes associated with the earnings program to which the employee is assigned).

This function was designed this way. All codes are displayed, because the earnings code you enter is at level 1 on the page and the Effective Date is at level 2. Therefore, when you enter the code, you have not yet entered the Effective Date. Because the page does not have the Effective Date, it cannot look up the pay group. As a result, it cannot look up the earnings program.

Note. The Effective Date is set at level 2, so general deductions and additional pays can be future-dated.

Prompting Deduction Code Returns Too Many Rows on General Deduction Page

Prompting for the deduction code returns all deduction codes associated with all benefit programs (as opposed to displaying only those deduction codes associated with the benefit program to which the employee is assigned).



This function was designed this way. All codes are displayed, because the deduction code you enter is at level 1 on the page and the Effective Date is at level 2. Therefore, when you enter the code, you have not yet entered the Effective Date. Because the page does not have the Effective Date, it cannot look up the pay group. As a result, it cannot look up the benefit program.

CALENDAR Process Errors

You may encounter the following errors while running the Calendar process.

SQL Error 207: Command Not Found For Retrieval

The stored command was not found when selected.

Recreate the stored commands for the database. This procedure is documented in the platform-specific System Administration documentation.

SQL Error 208: Stored Command Has Been Invalidated

An index, field, or table has been changed or dropped since the command using this object was stored.


USAGE IS INPUT_FILE OUTPUT_FILE

This error occurs on the Oracle platform, if you have linked with an incorrect Oracle library.

CANNOT EXECUTE

This error occurs on the Oracle platform, when trying to run the process from UNIX, if the permissions have not been created for execute purposes.

PAYSHEET Process Errors

The Paysheet process might produce one of the following errors.









End of Fetch (PSPPYGEM)

The complete error is:

LOAD-JOB (PSPPYGEM) 00001 end of fetchPAGE#=00001, LINE#=001, EMPLID=99999......GET-NEXT-JOB (PSPPARRY) 00001 end of fetchBUILD-PAYSHEETS (PSPPYSHT) 00001 end of fetch

This error occurs when the employee is not assigned to a benefit program on the Benefit Program Participation page.

SQL Error 0805: Non-Unique Data (PSPUPSHT)

An example of the complete error is:

INSERT-PAY-LINE 0805 non-unique dataPAGE#=0444, LINE#=00, EMPLID= ,EMPLRCD#=8224PROCESS-JOB (PSPUPSHT) 0805 non-unique dataSELECT-PAY-CALENDAR (PSPPYSHT) 0805 non-unique dataSTART-RUN (PSPSTRUN) 0805 non-unique data

This error occurs if there are one or more employees who have an invalid location.

1. Verify that the employee has a location in the job record.

2. Check the Effective Date of the location table for the employee’s location. It must be the Pay End Date for this payroll cycle.

On the DB2 platform, this error might display itself as a -302 error on PSPUPSHT_I_LINE.



CANNOT EXECUTE


CALCPAY Process Errors

At the beginning of CALCPAY, the Paysheet Update process is executed to update the paysheets with any job changes, and so on. If you receive an error message during this step, review the error messages listed in the PAYSHEET Process section.

CALCPAY processing also has its own set of error messages:

Payroll Error 5: Deduction Code Not Found

The deduction code displayed in the message data was not found in the Deduction Table.

1. Determine the employee’s benefit program.

2. Ensure that this deduction is set up in the Company General Deduction Table and that this table has an Effective Date the Pay End Date of this payroll cycle.

3. Make sure this deduction is set up on the Deduction Table with an Effective Date that is the Effective Date of the benefit program and the Pay End Date of this payroll cycle.



Payroll Error 13: SUT Rate Not Found

The SUT rate for the company and state displayed in the message data was not found in the Company/State Tax Table.

The system assumes you have a quarter 1 record set up, which reflects the SUT rate at the beginning of the year. You only have a different quarter set up in addition to the quarter 1 record if the rate changes mid-year.

Check to see if there is a Quarter 1 record for unemployment set up in the Company/State Tax Table.

The SUT rate for the agency and state displayed in the message data was not found in the Agency/State Tax Table.

Check to see if there is a Quarter 1 record for unemployment set up in the Agency/State Tax Table.

Payroll Error 17: Federal Tax Data Not Found

The federal tax data record was not found for the employee.

1. Check the Effective Date on the employee Federal Tax Data page for the company that you are processing and make sure that it is the check date of this payroll cycle.

2. If this error is accompanied by errors 32: Personal Data Not Found and 89: Benefit Not Found, it can indicate:

a. There are orphaned records in PS_PAY_EARNINGS.

Run PRECALC.SQU to identify the orphaned records. To resolve the problem, you delete the orphaned records as well as their associated parent and child records. Typically, the tables involved are PS_PAY_LINE, PS_PAY_EARNINGS, PS_PAY_OTH_EARNS, PS_PAY_ONE_TIME, PS_PAY_TAX_OVRD, PS_PAY_GARN_OVRD, and PS_PAY_CTX_OVRD. For assistance with this process, please call the PeopleSoft Global Support Center.

b. You are using the COST-based optimizer on the Oracle platform (version 7.0.x).

This optimizer has a bug that causes some SQL statements to be ordered incorrectly, resulting in the above errors. Change to the RULE-based optimizer to see if it resolves the problem. If so, use the RULE-based optimizer until the bug is fixed. For more information about this Oracle bug, please contact Oracle Support

Solution from PS support:

EPY8.x: Message 000017 - Federal tax data not found for this employee

Details: SOLUTION 16900: EPY8.x: Message 000017 - Federal tax data not found for this employee

SPECIFIC TO: Enterprise, North American Payroll, 8.x releases

ISSUE: Paycalc error message 000017 "Federal tax data not found for this employee."



SOLUTION: Do the following, in this order:

1.) Recalc All (with no other action) sometimes resolves this error message.

2.) If Recalc All does not resolve, run Presheet (PAY034.SQR) and Precalc (PAY035.SQR) for data errors.

WORKAROUND: N/A

SEE ALSO: Solution 31467

KEYWORDS: Pay Calc, Errors, SQR .

Payroll Error 18: State Tax Data Not Found

The state tax data record, for the state displayed in the message data, was not found for the employee.

1. Check the Effective Date on the Employee State Tax Data page for the company that you are processing and make sure it is the check date of this payroll cycle.

2. Verify that the state on the paysheet is set up on the employee State Tax Data page and the Effective Date is the check date of the payroll cycle.

The state on the paysheet is derived from the Location Table using the location in the employee’s job record.

Payroll Error 27: Benefit Plan Not Found

The benefit plan displayed in the message data was not found in the appropriate benefit table.

1. Determine the employee’s benefit program.

2. Make sure the Benefit Program Table has an Effective Date that is the Pay End Date of this payroll cycle and that the program includes this benefit plan.

3. Verify that the employee is enrolled in this benefit plan with an Effective Date the Effective Date of the Benefit Program Table.

Payroll Error 31: Rate Coverage Not Found

The coverage code displayed in the message data was not found for the rate schedule specified in the message data.

Check the Rate Schedule Table and make sure that the coverage code and amount are included. Sometimes a customer sets up the rates that are all 0. Therefore, the rate schedule page appears to have rows, because the default values are displayed. However, the record cannot be saved with only default values. Some customers implement it this way, because the deductions are calculated in a different manner.



For example, the carrier sends a tape with the deduction amount, so it is associated with a general deduction. Therefore, no rate set up is required, and it’s left at zero. To prevent this error, you must have saved a row in the PS_RATE_SCHED_COVG table. Enter a row with any value in the amount field in order to save the record.

Payroll Error 32: Personal Data Not Found

Personal data was not found for this employee.

This error occurs when the statement PSPEARRY_S_JOB fails for the employee. Here are examples that cause this statement to fail:

The service date in the employment table (PS_EMPLOYMENT.SERVICE_DT) is null.

The above statement requires this field, because this date is used by the service rate calculations for various benefits. It is also used in the calculation of leave accruals. Currently, service date is not a required field on the employment record, because some customers only have the HR application and might not use leave accruals. To locate all employees whose service date is null, execute the following query:

SELECT EMPLID, SERVICE_DT FROM PS_EMPLOYMENT WHERE SERVICE_DT IS NULL;

The employee does not have a benefit program participation record, or that record is not valid.

If this error is accompanied by errors 17: Federal Tax Data Not Found and 89: Benefit Not Found, it can indicate:

There are orphaned records in PS_PAY_EARNINGS.

Run PRECALC.SQU to identify the orphaned records. To resolve the problem, delete the orphaned records as well as their associated parent and child records. Typically, the tables involved are PS_PAY_LINE, PS_PAY_EARNINGS, PS_PAY_OTH_EARNS, PS_PAY_ONE_TIME, PS_PAY_TAX_OVRD, PS_PAY_GARN_OVRD, and PS_PAY_CTX_OVRD. For assistance with this process, please call the PeopleSoft Global Support Center.

You are using the COST-based optimizer on the Oracle platform (version 7.0.x).

This optimizer has a bug that causes some SQL statements to be ordered incorrectly, resulting in the above errors. Change to the RULE-based optimizer to see if it resolves the problem. If so, use the RULE-based optimizer until the bug is fixed. For more information about this Oracle bug, please contact Oracle Support.

Payroll Error 44: Negative Net

The net pay calculated for this check is negative.

Negative net pay is only allowed on a paysheet for a manual check (MANUAL_CHECK of PS_PAY_LINE = ‘Y’).

Payroll Error 49: Shift Not Found

The shift displayed in the message data was not found.

1. Verify that this shift code is set up on the Shift Table and that the Effective Date is the Pay End Date of this pay cycle.



2. Make sure the SetID specified in the Shift Table is consistent with the SetID specified for this pay group on the TableSet Record Group Controls page. TableSets are discussed in your PeopleTools documentation. You might want to review the DEMO database for an example of how to set up TableSets for the Shift Table.

Payroll Error 51: Manual Check Error

The calculated values for total gross and net pay displayed in the message data do not match the values entered on the manual check.

When you enter a manual check paysheet, you must enter the gross and net pay as well as all earnings, taxes, and deductions. The CALCPAY process uses the values you enter and does a gross-to-net calculation to make sure the gross and net values you enter are correct. The CALCPAY process automatically calculates the employer-paid taxes and deductions, so you do not need to enter them on the paysheet, unless you want to override them.

1. Verify that the gross amount, net pay, and earnings are entered.

2. Using the values you enter, do a manual gross-to-net calculation.

Payroll Error 59: Cannot Calculate for Employee

This check cannot be calculated, because the employee has check(s) that have been calculated and not confirmed. The check(s) calculated are not a part of this run.

The system checks the existence of PAY_CHECK records to determine if the employee has any other calculated checks that have not been confirmed. These checks must be confirmed, or marked Not OK to Pay and recalculated, before you can calculate the current check. To identify the outstanding checks that have been calculated, execute the following query:

SELECT * FROM PS_PAY_CHECK WHERE EMPLID= :1 AND PAY_END_DATE <= :2;Insert the EMPLID and Pay End Date that you are processing into the bind variables (in other words :1, :2). Note the value of the PAYCHECK_STATUS on the rows that are returned.

Payroll Error 86: Cannot Calculate For Employee

This check cannot be calculated, because the employee has another off-cycle check calculated and not confirmed. All outstanding off-cycle checks for an employee must be on the same page. The Page # of the other calculated off-cycle check displays in the message data.

Identify the outstanding off-cycle checks for an employee by executing the following query:

SELECT * FROM PS_PAY_EARNINGS WHERE EMPLID=:1 AND OFF_CYCLE=’Y’ AND PAY_END_DATE <= :2;

Insert the EMPLID and Pay End Date that you are processing into the bind variables (in other words :1, :2). Note the value of the PAY_LINE_STATUS and OK_TO_PAY fields on the rows that are returned.

These other calculated checks must be confirmed, or marked Not OK to Pay and recalculated, before the current check can be calculated. If an employee has off-cycle checks on multiple pages for the same payroll cycle, only one can be marked OK to Pay at a time, until all are calculated. Another option is to combine all paysheets into one and mark the remainder Not Pay.

Payroll Error 92: Local Tax Not Found

The local tax record for the locality defined below cannot be found for this employee.



1. Verify that the locality on the paysheet is set up on the Employee Local Tax Data page and that the Effective Date is the check date of the payroll cycle.

The locality on the paysheet comes from the Location Table based on the location entered in the employee’s job record.

2. Make sure all work localities are tied to the locality using the Other Work Locality field on the Employee Local Tax Data page. See PeopleSoft 8.3 Payroll for North America PeopleBook, “Maintaining Payroll Data,” Entering Local Tax Data.

Payroll Error 112: Tax Status Rates Not Found

The tax status tax rates for the tax entity displayed in the message data cannot be found.

1. Verify that the employee’s tax status is set up in the Federal/State Tax table and that the Effective Date of that table is the check date of the payroll cycle.

2. Make sure that you are using the correct version of the program PSPTCALC and that it is compatible with the other tax calculation programs.







Indiana Local Tax Incorrect

An employee is subject to Indiana local taxes based on the locality in which he or she resides on the first day of the year. If an employee moves to a different locality during the year, he or she is still taxed in the original locality. An employee who is not an Indiana resident on the first day of the year is not subject to local tax for that year. Not all Indiana localities have taxes.

An employee hired mid-year must provide an Indiana employer where he or she lived on the first day of the year. If it was in Indiana, the employer must set up the state and local tax data records with an Effective Date as of January 1, even though the Effective Date of hire is a later date. If the system sees an Indiana local tax record with an Effective Date greater than the first day of the current year, it ignores it. An employee can have two records for the year if the residential status changes (for example, a transfer); there must be one that is valid as of January 1.

As of release 3.01, local tax data must be set up for any employee with a work locality. In prior releases, the system used the U.S. taxing locality in the location table to determine default taxation; an employee who worked in that locality was taxed as a non-resident. This change in setup was a result of Indiana local tax requirements. Users get an error 000092 if the local tax data is missing for an employee.



Note. When setting up Indiana local taxes for employees, remember to only use the 3-digit numeric Indiana local tax IDs from the Local Tax Table. Do not use any of the local tax IDs that contain the 2-letter alpha suffixes (such as CA, CE, and CO).

Employee(s)/Jobs Checked for Update

This counts the number of changes made to the PS_JOB record that affect the PS_PAY_LINE data. This count does not include changes made to tax or deduction data. The program compares the job data between the paysheet and the base table. If it detects a change, it increments the Employee(s)/Jobs Checked for Update counter.

Employee(s)/Jobs Had Their Paysheet Updated

This counts the number of physical paysheets that were modified or updated online. It will not always be synchronized with the updates counter (Employee(s)/Jobs Checked for Update).

If the JOB_PAY flag on PS_PAY_EARNINGS is equal to Y, then the program increments the Paysheet Updated counter.

If the JOB_PAY flag=Y and the paysheet isn’t modified online, then the PAY_EARNINGS rows are updated with the new job data. If JOB_PAY flag=N, then the system assumes that online changes were made and merges the online changes in the PAY_EARNINGS row.

If you make any online change to employee data that affects the calculation of a Pay Check, the JOB_CHANGE flag is set to ‘R,’ “Calculation required.”

Checks Already Calculated

This number represents the number of PS_PAY_LINE records where JOB_CHANGE <> R.

Checks To Calculate

This number represents the number of PS_PAY_LINE records where JOB_CHANGE = R.


This error occurs on the Oracle platform if you have linked with an incorrect Oracle library.

CANNOT EXECUTE


CONFIRM Process Errors

Running the Confirm process can trigger any of a set of error messages.

Note. At the beginning of CALCPAY, the Paysheet Update process is executed to update the paysheets with any job changes, and so on. If you receive an error during this step, review the error messages listed under the PAYSHEET Process Errors section.



Payroll Error 12: Already Confirmed

The pay calendar entry to be processed has already been confirmed.

Check the pay calendar that you are attempting to confirm. The PAY_CONFIRM_RUN flag is probably set to ‘Y,’ indicating that this calendar has confirmed successfully.

Payroll Error 16: Pay Calculation Is Not Final

The pay calculation has not been finalized and therefore cannot be confirmed.

Check the pay calendar that you are attempting to confirm. The Payroll Calculation Run? check box (PAY_CALC_RUN) is not selected, indicating that a final calculation has not been run. To resolve the problem, set up a run control for the CALCPAY process and clear the check box for Preliminary Calculation. This automatically runs a final calculation when you execute the CALCPAY process. You must make sure that there are no errors generated from the final calculation before you can run CONFIRM.

Payroll Error 20: All Checks Not Calculated

None of the checks for the pay calendar have been calculated and therefore cannot be confirmed.

To determine which checks have not been calculated, execute the following query:

SELECT * FROM PS_PAY_EARNINGS WHERE COMPANY = :1 AND PAYGROUP = :2 AND PAY_END_DT = :3 AND OK_TO_PAY = ‘Y’ AND PAY_LINE_STATUS IN (I, U, P, E);

Insert the Company, Pay Group, and Pay End Date that you are processing in the associated bind variables (:1, :2, :3).

The checks selected here must be calculated successfully or marked Not Pay before you can run CONFIRM.

SELECT * FROM PS_PAY_EARNINGS WHERE AGENCY = :1 AND Insert the Company, Pay Group, and Pay End Date that you are processing in the associated bind variables (:1, :2, :3).

Payroll Error 64: Prior Run Not Confirmed

The selected run cannot be confirmed, because a prior run has not been confirmed.

This error indicates that there is an on-cycle run that has not been confirmed, or there are off-cycle checks that are outstanding for this company and pay group. To identify the pay calendar that has not been confirmed, execute the following query:

SELECT * FROM PS_PAY_CALENDAR WHERE COMPANY=:1 AND PAYGROUP=:2 AND PAY_END_DT<=:3 AND RUN_ID<>’ ‘ AND RUN_ID<>:4 AND (PAY_CONFIRM_RUN=’N’ OR PAY_OFF_CYCLE=’Y’)

Insert the Company, Pay Group, Pay End Date, and Run ID that you are processing in the associated bind variables (:1, :2, :3, :4).

SELECT * FROM PS_PAY_CALENDAR WHERE AGENCY=:1 AND PAYGROUP=:2Insert the Company, Pay Group, Pay End Date, and Run ID that you are processing in the associated bind variables (:1, :2, :3, :4).



Payroll Error 65: Reversal Outstanding

Cannot confirm the selected run with an unconfirmed reversal existing for an employee with a calculated check in this run.

Execute the following query to determine which employee has an outstanding reversal:

SELECT * FROM PS_PAY_CHECK WHERE PAYCHECK_OPTION = ‘R’ AND PAYCHECK_STATUS =’C’.

This reversal must be confirmed or deleted before you can confirm the current payroll.

SELECT * FROM PS_PAY_PAGE WHERE AGENCY=:1 AND PAYGROUP=:2 AND PAY_END_DATE <= :3 AND OFF_CYCLE='Y' AND CONFIRMED='N';

Payroll Error 66: Off-Cycle Outstanding

Cannot confirm the selected run with a prior run with off-cycle pages not confirmed.

To identify the off-cycle pages that have not been confirmed, execute the query below:

SELECT * FROM PS_PAY_PAGE WHERE COMPANY=:1 AND PAYGROUP=:2 AND PAY_END_DATE <= :3 AND OFF_CYCLE=’Y’ AND CONFIRMED=’N’;

Insert the appropriate values for the bind variables above, using the data from the run that you are trying to process.

The error is generated from PSPSTUPD.CBL. It occurs if any rows are selected by STORE PSPSTUPD_S_PAGE in PSPSTUPD.WT. It takes the pay calendars selected by STORE PSPSTUPD_S_CAL and then does PSPSTUPD_S_PAGE using these calendars. The select in PSPSTUPD_S_PAGE can be done manually to determine which page has off-cycle checks that are not confirmed.







SQL Error 0805: Non-Unique Data (PSPCBUPD)

Here is an example of the complete error on SQLBase:

INSERT-BALANCEPAGE#=0001, LINE#=001, SEPCHK=000, EMPLID=0008, EMPLRCD#=0000, NAME=PROCESS-CHECK (PSPCBUPD) 0805 non-unique dataMAIN (PSPPYUPD) 0805 non-unique dataPROCESS-CONFIRMATION (PSPPYWKS) 0805 non-unique data

This error varies by platform:

On DB2, the error might have the description “Insert/update of unique constrained columns with duplicate data.”



On Allbase, the error is “2509: Index uniqueness or unique/primary key constraint violated.”

On Oracle, the error is “ORA-00001: Unique constraint violated” or “ORA-00001: Duplicate key in index.”

On Rdb, the error is “-803: %RDB-E-NO_DUP, index field value already exists; duplicates not allowed for Unique Index.”

The CONFIRM process is attempting to insert a check balance record that already exists. Balance records are stored by year, quarter, and month. Typically, this error occurs if you try to post to a previous month after you have posted to the current month. Once you have posted to a month, you cannot post to a previous month. For example, once you have posted an April balance, the system doesn’t allow you to update a March balance. The system attempts to post to the month indicated in the MONTHCD field on the pay calendar.

To determine whether this situation is causing the problem, follow these steps:

1. Review the pay calendar you are trying to confirm and note the month code.

2. Issue the following query:

SELECT * FROM PS_CHECK_YTD WHERE EMPLID = [EMPLID in the error] AND COMPANY = [employee’s company] ORDER BY CALENDAR_YEAR, QTRCD, MONTHCD;

3. Review the query output and determine if there is a balance record for a MONTHCD > than the month code in the pay calendar that you are processing. If so, you are trying to post to a previous month.

To resolve this error, you must mark the paysheet Not OK to Pay and then confirm. If you are unable to access the paysheet online, you need to complete the following steps:

a. Modify the search record for the paysheet page to select records that have been confirmed.

(This check is not fully confirmed yet, because all statuses have not been updated.)

b. Issue the following query to update the pay calendar as if confirm has not been started:

UPDATE PS_PAY_CALENDAR SET PAY_CONFIRM_START = ‘N’ WHERECOMPANY = :1 AND PAYGROUP = :2 AND PAY_END_DT = :3;

c. The bind variables (:1, :2, :3) must be set to the values of the calendar you are processing.

d. You can now mark the paysheet Not Pay, recalculate where needed, and confirm.

CALCPAY and CONFIRM ignore the checks that have confirmed successfully. CONFIRM picks up where it left off and confirms the remainder of the pay run.

e. Reset the search record back to its original state.

AGENCY = [employee's agency] ORDER BY CALENDAR_YEAR, QTRCD, MONTHCD;

UPDATE PS_PAY_CALENDAR SET PAY_CONFIRM_START = 'N' WHEREAGENCY = :1 AND PAYGROUP = :2 AND PAY_END_DT = :3;





CANNOT EXECUTE


UNCNFRM Process Errors

The following errors might appear when you run the Unconfirm process.







Error In Select Setup/Data (PSPCARRY)

This error typically occurs on the Oracle platform. This is the complete error:

PSPSQLRT - ERROR IN SELECT SETUP/DATASTATEMENT=PSPCARRY_S_UGRNVARIABLE#=015INVALID CHARACTER IN SETUP=1PSPSQLRT - ERROR IN SELECT SETUP/DATASTATEMENT=PSPCARRY_S_UGRNPSPSQLRT - ERROR IN SELECT SETUP/DATAVARIABLE#=016

This error is resolved by taking the programs PSPDEDLD.INT, PSPDCLIM.INT, and PSPCARRY.INT from $PS_HOME\INT and copying them to $PS_HOME\BIN (keeping the extension as .INT). Then delete the .GNT versions of these three files.



CANNOT EXECUTE


REPRINT Process Errors

The Reprint process may invoke the following errors.











CANNOT EXECUTE


REVERSAL Process Errors

You may encounter the following errors while running the Reversal process.









CANNOT EXECUTE




Process OverviewTo help you pinpoint faulty processing in the system, this section provides a brief description of each payroll process and the tables that are used. All tables are the same for U.S. and Canada, except where noted. Many of the processes use work tables during processing. We don’t discuss these tables (which begin with PS_WRK) in detail here.

In this section, we discuss the following payroll processes and tables:

CALENDAR

PAYSHEET

CALCPAY

CONFIRM

REVERSAL

REPRINT

PAYUNSHT

UNCNFRM

CALENDAR

You use the pay calendar to schedule payroll cycles for your pay groups. Pay calendars can be created using the CALENDAR (Pay Calendar Creation) process or they can be manually entered online.

Table From Which the CALENDAR Process Selects:

PS_PAY_CBLD_RUNCTL The process selects the run control record that is added by the user before running the process.

Tables From Which the CALENDAR Process Selects Balance ID:

PS_BALANCE_ID_DEF

PS_BALANCE_ID_QTR

PS_BALANCE_ID_TBL

Tables Into Which the CALENDAR Process Inserts:

PS_PAY_CALENDAR This table is updated with the number of pay calendars equivalent to the period of time requested on the run control.

PS_PAY_MESSAGE This table is updated with any standard payroll error messages that are encountered during the process.

PS_PAY_CAL_BAL_ID This table is updated with the Balance ID information



for the calendar.

Tables From Which the CALENDAR Process Deletes:

PS_PAY_CBLD_RUNCTL The run control is deleted after the process is initiated.

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.

PAYSHEET

Before you can run any payroll calculations, you must first create paysheets. Paysheets are normally created using the PAYSHEET (Paysheet Creation) process. However, they can also be created manually online or through a time interface (such as PeopleSoft Time and Labor). PeopleSoft delivers the programs PAYEDIT.SQU and PAYUPDT.SQU to assist you in editing and loading paysheet data using an interface.

Points to Consider When Running the PAYSHEET Process

The PAYSHEET process can be run before or after a time interface.

It depends on whether the time interface is designed to load the majority of the paysheet data or simply other earnings.

Once paysheets are created, you don’t normally rerun this process.

However, it might be necessary if any high-level information on the paysheet changed (for example, earnings code for regular or overtime pay). If you need to recreate paysheets, it is recommended that you run PAYUNSHT first to delete the current paysheets. Otherwise, the process doesn’t recreate a paysheet for an employee who already has one.

If an error occurs during this process, it can be rerun and the process continues processing where it left off (after the last commit to the database).

Tables From Which the PAYSHEET Process Selects:

PS_PAYSHEET_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 calendar year.

Tables Into Which the PAYSHEET Process Inserts

PS_PAY_PAGE This table contains the paysheet pages that are created. Each page may be the parent to several



paylines.

PS_PAY_LINE This table contains individual paylines. Each employee is created on a separate payline during on-cycle processing. Each payline might be the parent to several pay earnings records. These pay earnings records might represent one or more checks.

PS_PAY_EARNINGS This table contains individual pay earnings records. Each paycheck might contain several pay earnings records. Here are some key fields on this table:

SEPCHK Determines whether these earnings are associated with a separate check. Supplemental taxes might be calculated differently on separate checks. This is determined based on the supplemental tax method (SUPPL_SEP_METHOD) specified on the Federal/State Tax Table (PS_STATE_TAX_TABLE). Deductions aren’t taken on a separate check if the separate check indicator (SEPCHK_DED) on the Deduction Table (PS_DEDUCTION_CLASS) is set to ‘N.’

PAY_LINE_STATUS Indicates whether the earnings record is calculated or confirmed successfully. These are the valid values:

I Initial Load. The pay earnings entered but not calculated. A record marked Not OK to Pay remains with an ‘I’ status until it is deleted by the CONFIRM process.

U Updated by operator. A user has updated the record online since it was originally entered or calculated. PeopleCode sets this status.

C Calculated successfully.

E Error. An error occurred in the processing of these earnings. If it is a standard payroll error, it appears on the payroll messages page. Otherwise, the error displays on the screen where the process was executed or in the JCL. Earnings records with this status must be corrected or marked Not OK to Pay before the calculation process completes successfully.

F Confirmed successfully.

P Pay in Progress. The pay processes sets the status to ‘P’ if the record has been selected for processing (that is, for calculation). If an error occurs during processing, some statuses might remain as a ‘P’ until reprocessed.

JOB_PAY Directs the process to update the paysheet with the most current job information. This information might have changed since the paysheet was created or last calculated.

OK_TO_PAY Indicates whether this record should be processed. If this field is set to ‘N,’ the calculation process bypasses



this record.

DED_TAKEN Directs the system how to take deductions. If this field is set to ‘N,’ no deductions are taken for this check.

TAX_PERIODS Indicates the number of tax periods used for the calculation of taxes. This field can drastically affect the amount of tax calculated.

PS_PAY_OTH_EARNS This table contains other earnings records that are added to the paysheet. The PAYSHEET process might generate these records automatically from the additional pay data records under Employee Payroll Data. Records added from additional pay have the ADDL_SEQ field set to a value > 0. Other Earnings records might also be added online or through a time interface. Records added in this manner should have the ADDL_SEQ field set = 0. Otherwise, additional pay isn’t processed correctly. There might be multiple other earnings records for one PS_PAY_EARNINGS record.

PS_PAY_MESSAGE This table is updated with standard payroll error messages that are encountered during the process.

Table That the PAYSHEET Process Updates:

PS_PAY_CALENDAR The PAY_SHEETS_RUN flag on the pay calendar is set to ‘Y’ to indicate that the PAYSHEET process has run successfully.

Tables From Which the PAYSHEET Process Deletes:

The PAY_SHEETS_RUNCTL The run control is deleted after the process is initiated.


See Also

PeopleSoft 8.3 Payroll for North America PeopleBook, “Working with Paysheets”

PeopleSoft 8.3 Application Fundamentals for HRMS PeopleBook, “Setting Up Payroll Tax Tables”

PeopleSoft 8.3 Payroll for North America PeopleBook, “Appendix B: Configuring Batch Processes”



CALCPAY

The CALCPAY (Pay Calculation) process uses the paysheet data to calculate earnings, taxes, deductions, and net pay.

At the beginning of the CALCPAY, a paysheet update process is done. This is similar to the PAYSHEET process and is designed to update the paysheets with any employee changes that were made after paysheets were created. The table information for the paysheet update process has not been duplicated below.

Points to Consider When Running the CALCPAY Process

CALCPAY can be rerun as many times as necessary, until CONFIRM is started.

A preliminary calculation can be run as many times a necessary

However, you must run a final calculation before running CONFIRM. If there are changes to an employee's record that could cause a recalculation, this doesn’t happen when a final calculation is run. Additionally, when running Final Calculation with the Continue With Errors option selected, Final Calculation cannot be run a second time.


Tables From Which the CALCPAY Process Selects

PS_PAY_CALC_RUNCTL The process selects the run control record that is added by the user prior to running the process. The run control might be set up to RECALCULATE ALL or CALCULATE WHERE NEEDED. If the run control specifies RECALCULATE ALL, all records are calculated, even if they were already calculated. If the run control specifies CALCULATE WHERE NEEDED, the system looks at the PAY_LINE_STATUS to determine which records to calculate.

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

PS_PAY_PAGE Pages for the calendar being processed are selected.

PS_PAY_LINE Lines for the calendar being processed are selected.

PS_PAY_EARNINGS Using the PAY_LINE_STATUS on PS_PAY_EARNINGS and the CALC_SELECT field on PS_PAY_CALC_RUNCTL, the system selects the records to be calculated. If the run control specifies RECALCULATE ALL, all records with OK_TO_PAY = ‘Y’ are calculated, even if they were already calculated successfully. If the run control specifies CALCULATE WHERE NEEDED, the system only calculates those records where OK_TO_PAY = ‘Y’ and the PAY_LINE_STATUS is I, P, U, or E.

PS_PAY_OTH_EARNS Other earnings for the calendar being processed are selected.

PS_PAY_ONE_TIME One-time deductions for the calendar being processed



are selected.

PS_PAY_TAX_OVRD One-time taxes for the calendar being processed are selected (U.S. only).

PS_PAY_CTX_OVRD One-time taxes for the calendar being processed are selected. (Canadian only.)

PS_GARN_OVRD One-time garnishments for the calendar being processed are selected.

Tables Into Which the CALCPAY Process Inserts

PS_PAY_CHECK This table is updated with the gross-to-net information for each paycheck.

PS_PAY_DEDUCTION This table is updated with all deductions taken on each check. It is stored by employee, deduction, and pay end date. This table contains the current pay period, as well as previous periods.

PS_PAY_TAX This table is updated with all taxes taken for each check. It is stored by employee, tax class, and pay end date. This table contains the current pay period, as well as previous periods.

PS_PAY_TAX_CAN This table is the Canadian version of PS_PAY_TAX.

PS_PAY_GARNISH This table is updated with the garnishment deductions taken for each check. This table contains current period deductions, as well as prior periods.

PS_PAY_SPCL_EARNS This table is updated with the earnings totals that make up the special accumulators.

PS_PAY_INS_EARNS This table is used by Canadian payroll only. It is updated with Canadian unemployment earnings information for each check. This table contains current period information, as well as prior periods.

PS_PAY_MESSAGE This table is updated with standard payroll error messages that are encountered during the process. If the error that occurred is a high-level error (for example, Deduction Table not found), the error is only reported on the payroll messages for the first employee who meets this condition. Other employees who meet this condition have their PAY_LINE_STATUS set to 'E,' but they aren’t reported in the payroll messages. The assumption is that once the Deduction Table is added, it fixes the error for all employees. This prevents the PAY_MESSAGE table from filling up with duplicate messages. If a low-level error is encountered (for example, employee tax data not found), this error is reported in the payroll messages for all employees who meet this condition.



Tables That the CALCPAY Process Updates

PS_PAY_CALENDAR The PAY_PRECALC_RUN flag is set to ‘Y’ when a preliminary calculation process runs successfully. The PAY_CALC_RUN flag is set to ‘Y’ when a final calculation process runs successfully. You aren’t allowed to run the CONFIRM process until the PAY_CALC_RUN flag is set to ‘Y.’

PS_PAY_PAGE New records might be added to this table as a result of the paysheet update process (in other words, new employees that were hired since PAYSHEET or CALCPAY were last run).

PS_PAY_LINE New records might be added to this table as a result of the paysheet update process (in other words, new employees that were hired since PAYSHEET or CALCPAY were last run).

PS_PAY_EARNINGS The PAY_LINE_STATUS is updated as follows:

C Calculated successfully.

E Calculation error. Check for payroll messages or other errors.

P An error occurred that prevented CALCPAY from completing. This check is recalculated when CALCPAY is rerun. Earnings or other paysheet fields might be updated as a result of a job change or new hires made since paysheets or CALCPAY were last run.

PS_PAY_OTH_EARNS Other earnings might be updated as a result of a change on the Additional Pay Data pages.

PS_PAY_CHECK Earnings, taxes, or deduction amounts might be updated as a result of a change on the paysheet. PAYCHECK_STATUS is set to ‘C’ for calculated.

Tables From Which the CALCPAY Process Deletes

PS_PAY_CALC_RUNCTL The run control is deleted after the process is initiated.

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 in off-cycle check processing.

When a check is recalculated, the process deletes the old entries from the paysheet tables that were inserted into above. It then reinserts into these tables.

See Also

PeopleSoft 8.3 Payroll for North America PeopleBook, “Calculating Pay”



PeopleSoft 8.3 Application Fundamentals for HRMS PeopleBook, “Setting Up Payroll Tax Tables”

PeopleSoft 8.3 Payroll for North America PeopleBook, “Appendix B: Configuring Batch Processes”

CONFIRM

During the Pay Confirmation process, the system updates all balances for earnings, deductions, taxes, garnishments, and arrears. The system also assigns check and advice numbers. In addition, this process deletes all paysheet and paycheck records for those paysheets where OK_TO_PAY = ‘N’ on the PAY_EARNINGS record. No history of these records is kept.

Points to Consider When Running the CONFIRM Process

You should back up the database before running CONFIRM. This is necessary, because this process cannot simply be rerun once it has completed.


Tables From Which the CONFIRM Process Selects

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 Control ID, the process selects the appropriate pay calendar information.


PS_PAY_PAGE Pages for the calendar being processed are selected.

PS_PAY_LINE Lines for the calendar being processed are selected.

PS_PAY_CHECK Paychecks where PAYCHECK_STATUS = ‘C’ are selected.

PS_PAY_EARNINGS Pay earnings where PAY_LINE_STATUS = ‘C’ are selected.

PS_PAY_SPCL_EARNS Special accumulator amounts for the calendar being processed are selected.

PS_PAY_INS_EARNS Unemployment insurable earnings for the calendar being processed are selected (Canadian only).

PS_PAY_TAX Taxes taken for the calendar being processed are selected.

PS_PAY_TAX_CAN Taxes taken for the calendar being processed are selected (Canadian only).



PS_PAY_GARNISH Garnishments taken for the calendar being processed are selected.

PS_PAY_DEDUCTION Deductions taken for the calendar being processed are selected.

This process also selects from some employee and pay process tables.

Tables Into Which the CONFIRM Process Inserts

PS_BOND_LOG* The bond log table is updated with bond deductions taken in the current period.

PS_PAY_DISTRIBUTN The pay distribution table is updated with check and advice information.


PS_PAY_CHECK_DUE This table is updated with the check information that is later used by the check reconciliation process.

PS_CHECK_YTD* This balance table is updated with the current period check information.

PS_EARNINGS_BAL* Earnings balances are updated with earnings and special accumulator data for the current period.

PS_DEDUCTION_BAL* Deduction balances are updated with the current period amounts.

PS_TAX_BALANCE* Tax balances are updated with the current period amounts.

PS_GARN_BALANCE* Garnishment balances are updated with the current period amounts.

PS_CAN_CHECK_YTD* Canadian version of PS_CHECK_YTD.

PS_CAN_ERN_BALANCE* Canadian version of PS_EARNINGS_BAL.

PS_CAN_DED_BALANCE* Canadian version of PS_DEDUCTION_BAL.

PS_CAN_TAX_BALANCE* Canadian version of PS_TAX_BALANCE.

PS_INS_EARNS_BAL Unemployment insurable earnings balances are updated with the current period amounts (Canadian only).

* These tables might be inserted into or updated, depending on the payroll cycle being run.

Tables Into Which the CONFIRM Process Inserts

PS_BOND_LOG* The bond log table is updated with bond deductions taken in the current period.

PS_PAY_DISTRIBUTN The pay distribution table is updated with



check and advice information.


PS_PAY_CHECK_DUE This table is updated with the check information that is later used by the check reconciliation process.

PS_CHECK_YTD* This balance table is updated with the current period check information.

PS_EARNINGS_BAL* Earnings balances are updated with earnings and special accumulator data for the current period.

PS_DEDUCTION_BAL* Deduction balances are updated with the current period amounts.

PS_TAX_BALANCE* Tax balances are updated with the current period amounts.

PS_GARN_BALANCE* Garnishment balances are updated with the current period amounts.

PS_CAN_CHECK_YTD* Canadian version of PS_CHECK_YTD.

PS_CAN_ERN_BALANCE* Canadian version of PS_EARNINGS_BAL.

PS_CAN_DED_BALANCE* Canadian version of PS_DEDUCTION_BAL.

PS_CAN_TAX_BALANCE* Canadian version of PS_TAX_BALANCE.

PS_INS_EARNS_BAL Unemployment insurable earnings balances are updated with the current period amounts (Canadian only).

Tables the CONFIRM Process Updates

PS_PAY_PAGE CONFIRMED flag is set to ‘Y.’

PS_PAY_LINE CONFIRMED flag is set to ‘Y.’

PS_PAY_EARNINGS PAY_LINE_STATUS is set to ‘F.’

PS_PAY_CHECK PAYCHECK_STATUS is set to ‘F.’

PS_DED_ARREARS Deduction arrears balances are updated to reflect the current arrears balances.

PS_ADDL_PAY_DATA Additional pay data is updated to reflect the new goal balance (GOAL_BAL).

PS_GARN_SPEC Garnishment specification data is updated to reflect the new limit balance (GARN_LIMIT_BAL).

PS_GENL_DEDUCTION Employee general deduction data is updated to reflect



the new goal balance (GOAL_BAL).

PS_VACATION_BEN Employee vacation benefit table is updated to reflect the new goal balance (GOAL_BAL).

PS_LEAVE_ACCRUAL Unprocessed data fields are updated on employee leave accrual records. A leave accrual record is inserted, if the employee has not yet been processed through the ACCRUAL process.

PS_PAY_FORM_TBL The LAST_FORM#_USED is updated on the form table.

PS_PAY_CALENDAR The PAY_CONFIRM_START flag is set to ‘Y’ when the process is started initially. The PAY_CONFIRM_RUN flag is set to ‘Y’ when the process runs to completion successfully.

Tables From Which the CONFIRM Process Deletes

PS_PAY_CONF_RUNCTL The run control is deleted after the process is initiated.


PS_PAY_PAGE Records whose PS_PAY_LINE entries are no longer there.

PS_PAY_LINE Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_EARNINGS Records where OK_TO_PAY = ‘N’ are deleted.

PS_PAY_OTH_EARNS Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_ONE_TIME Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_TAX_OVRD Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_CTX_OVRD Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_GARN_OVRD Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_DEDUCTION Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_TAX Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_TAX_CAN Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted. (Canadian version of PS_PAY_TAX.)



PS_PAY_GARNISH Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_CHECK Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_SPCL_EARNS Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted.

PS_PAY_INS_EARNS Records whose PS_PAY_EARNINGS have OK_TO_PAY = ‘N’ are deleted (Canadian only).

Tables From Which the CONFIRM Process Deletes

PS_PAY_CONF_RUNCTL The run control is deleted after the process is initiated.


PS_PAY_PAGE Records whose PS_PAY_LINE entries are no longer there.

PS_PAY_LINE Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_EARNINGS Records where OK_TO_PAY = 'N' are deleted.

PS_PAY_OTH_EARNS Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_ONE_TIME Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_TAX_OVRD Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_CTX_OVRD Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_GARN_OVRD Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_DEDUCTION Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_TAX Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_TAX_CAN Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted. (Canadian version of PS_PAY_TAX.)

PS_PAY_GARNISH Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.



PS_PAY_CHECK Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_SPCL_EARNS Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted.

PS_PAY_INS_EARNS Records whose PS_PAY_EARNINGS have OK_TO_PAY = 'N' are deleted (Canadian only).

See Also

PeopleSoft 8.3 Payroll for North America PeopleBook, “(USF) Setting Up and Processing Agency Interfaces”

REVERSAL

You use the REVERSAL (Paycheck Reversal) process to create a reversal paysheet or a reversal/adjustment paysheet. After creating a reversal/adjustment, you must run the CALCPAY process and the CONFIRM process for the off-cycle reversal/adjustment. If you create a reversal only, you only need to run the CONFIRM process for the off-cycle reversal paysheet.

Points to Consider When Running the REVERSAL Process

You cannot reverse a check that was not confirmed in the PeopleSoft system. In this case, you need to do a manual check to back out the amounts.

All reversals are automatically created as off-cycle checks.

Tables From Which the REVERSAL Process Selects

PS_PAY_CALENDAR The current calendar that the off-cycle reversal is processed with is selected.

PS_PAY_REV_RUNCTL The process selects the run control record that is added by the user prior to running the process. This is the parent record on the run control page.

PS_PAY_CHECK_REVRS The process selects the run control record that is added by the user. This is the child record on the run control page.

PS_PAY_CHECK The check(s) to be reversed or adjusted are selected.

PS_PAY_PAGE The page of the original check is selected.

PS_PAY_LINE The line of the original check is selected.

PS_PAY_EARNINGS The earnings on the original check are selected.

PS_PAY_OTH_EARNS The other earnings on the original check are selected.

PS_PAY_DEDUCTION The deductions taken on the original check are selected.

PS_PAY_TAX The taxes taken on the original check are selected.



PS_PAY_TAX_CAN The taxes taken on the original check are selected (Canadian version of PS_PAY_TAX).

PS_PAY_GARNISH The garnishments taken on the original check are selected.

PS_PAY_ONE_TIME The deduction overrides on the original check are selected.

PS_PAY_TAX_OVRD The tax overrides on the original check are selected.

PS_PAY_CTX_OVRD The Canadian tax overrides on the original check are selected.

PS_PAY_GARN_OVRD The garnishment overrides on the original check are selected.

PS_PAY_INS_EARNS The unemployment insurable earnings on the original check are selected (Canadian only).

PS_PAY_SPCL_EARNS The earnings that updated the special accumulators on the original check are selected.

Tables Into Which the REVERSAL Process Inserts

PS_PAY_CHECK The reversal check is inserted.

PS_PAY_PAGE The reversal is inserted on a new page associated with the current off-cycle calendar.

PS_PAY_LINE The reversal is inserted on a new line associated with the current off-cycle calendar.

PS_PAY_EARNINGS This record is created with the original earnings amounts, but the amounts are negated.

PS_PAY_OTH_EARNS This record is created with the original other earnings amounts, but the amounts are negated.

PS_PAY_SPCL_EARNS This record is created with the original earnings that updated the special accumulators, but the amounts are negated.

PS_PAY_INS_EARNS This record is created with the original unemployment insurable earnings, but the amounts are negated.

PS_PAY_DEDUCTION This record is created with the original deductions taken, but the amounts are negated.

PS_PAY_TAX This record is created with the original taxes taken, but the amounts are negated.

PS_PAY_TAX_CAN This record is created with the original taxes taken, but the amounts are negated (Canadian version of PS_PAY_TAX).

PS_PAY_GARNISH This record is created with the original garnishments taken, but the amounts are negated.

PS_PAY_ONE_TIME This record is created with the original deduction



overrides, but the amounts are negated.

PS_PAY_TAX_OVRD This record is created with the original tax overrides, but the amounts are negated.

PS_PAY_CTX_OVRD This record is created with the original tax overrides, but the amounts are negated (Canadian version of PS_PAY_TAX_OVRD).

PS_PAY_GARN_OVRD This record is created with the original garnishment overrides, but the amounts are negated.

Tables From Which the REVERSAL Process Deletes

PS_PAY_REV_RUNCTL The run control is deleted after the process is initiated.


See Also

PeopleTools PeopleBook: Process Scheduler, “Submitting a Process Request”

REPRINT

The REPRINT (Paycheck Reprint) process enables you to reassign check numbers for one or more checks or advices. Once this is complete, you can run the report that actually reprints the checks (PAY003) or advices (DDP003).

Tables From Which the REPRINT Process Selects

PS_PAY_PRNT_RUNCTL The process selects the run control record that is added by the user prior to running the process.

PS_PAY_CHECK The checks/advices to be reprinted are selected.

PS_PAY_FORM_TBL The LAST_FORM#_USED is selected for each form, so the new check and advice numbers can be assigned.

Tables Into Which the REPRINT Process Inserts

PS_PAY_CHECK_DEAD This table is updated with the FORM_ID, CHECK#, DEAD_CHECK_REASON, and CHECK#_REPLACED_BY information of checks that are reprinted.



Tables That the REPRINT Process Updates

PS_PAY_CHECK This table is updated with the new CHECK# assigned by the REPRINT process.

PS_PAY_DISTRIBUTN This table is updated with the new CHECK# assigned by the REPRINT process.

PS_PAY_FORM_TBL This table is updated with the new LAST_FORM#_USED after check/advice numbers have been reassigned.

Tables From Which the REPRINT Process Deletes

PS_PAY_PRNT_RUNCTL The run control is deleted after the process is initiated.


See Also

PeopleSoft 8.3 Payroll for North America PeopleBook, “Working with Checks”

PAYUNSHT

The PAYUNSHT (Payunsheet) process is an SQR that deletes all records associated with a specified Run ID, including the results of any Pay Calculations run on those paysheets. This process is necessary if you change the Location Table after creating paysheets. To run this process you execute the SQR PAYUNSHT as you would any other SQR.

PAYUNSHT is typically used in a testing environment, because it allows users to rerun paysheets multiple times for the same period. In a production environment, PAYUNSHT is rarely used. It might be used if there is a high-level table change that affects the way paysheets are created.

Note. It is very important that you understand exactly what records are selected for deletion by PAYUNSHT. We recommend that you call the PeopleSoft Global Support Center before running this process in a production environment.

Tables From Which the PAYUNSHT Process Selects

PS_PAY_CALENDAR Using the Run Control ID entered, the process selects the calendar whose paysheet records is deleted.

Tables From Which the PAYUNSHT Process Deletes

PS_PAY_PAGE Records are deleted that are associated with the Run



ID that was entered.

PS_PAY_LINE Records are deleted that are associated with the Run ID that was entered.

PS_PAY_EARNINGS Records are deleted that are associated with the Run ID that was entered.

PS_PAY_OTH_EARNS Records are deleted that are associated with the Run ID that was entered.

PS_PAY_ONE_TIME Records are deleted that are associated with the Run ID that was entered.

PS_PAY_TAX_OVRD Records are deleted that are associated with the Run ID that was entered.

PS_PAY_CTX_OVRD Records are deleted that are associated with the Run ID that was entered.

PS_PAY_GARN_OVRD Records are deleted that are associated with the Run ID that was entered.

PS_PAY_CHECK Records are deleted that are associated with the Run ID that was entered.

PS_PAY_DEDUCTION Records are deleted that are associated with the Run ID that was entered.

PS_PAY_TAX Records are deleted that are associated with the Run ID that was entered.

PS_PAY_TAX_CAN Records are deleted that are associated with the Run ID that was entered (Canadian version of PS_PAY_TAX).

PS_PAY_GARNISH Records are deleted that are associated with the Run ID that was entered.

PS_PAY_SPCL_EARNS Records are deleted that are associated with the Run ID that was entered.

PS_PAY_INS_EARNS Records are deleted that are associated with the Run ID that was entered (Canadian only).

Tables From Which the PAYUNSHT Process Deletes

PS_PAY_PAGE Records are deleted that are associated with the Run ID that was entered.

PS_PAY_LINE Records are deleted that are associated with the Run ID that was entered.

PS_PAY_EARNINGS Records are deleted that are associated with the Run ID that was entered.

PS_PAY_OTH_EARNS Records are deleted that are associated with the Run ID that was entered.

PS_PAY_ONE_TIME Records are deleted that are associated



with the Run ID that was entered.

PS_PAY_TAX_OVRD Records are deleted that are associated with the Run ID that was entered.

PS_PAY_CTX_OVRD Records are deleted that are associated with the Run ID that was entered.

PS_PAY_GARN_OVRD Records are deleted that are associated with the Run ID that was entered.

PS_PAY_CHECK Records are deleted that are associated with the Run ID that was entered.

PS_PAY_DEDUCTION Records are deleted that are associated with the Run ID that was entered.

PS_PAY_TAX Records are deleted that are associated with the Run ID that was entered.

PS_PAY_TAX_CAN Records are deleted that are associated with the Run ID that was entered (Canadian version of PS_PAY_TAX).

PS_PAY_GARNISH Records are deleted that are associated with the Run ID that was entered.

PS_PAY_SPCL_EARNS Records are deleted that are associated with the Run ID that was entered.

PS_PAY_INS_EARNS Records are deleted that are associated with the Run ID that was entered (Canadian only).

UNCNFRM

The UNCNFRM (Pay Unconfirmation) process is used to unconfirm a payroll cycle that has been confirmed. This process completes the following steps:

1. Backs out all of the detail from the employee balance tables for the specified payroll cycle.

2. Resets the status on the paysheet records to a calculated status.

3. Updates the pay calendar to reflect that CONFIRM has not been run.

To run this process, you set up a run control using the Pay Confirmation Run Control page. This is the same page you use to set up a run control to run CONFIRM. Next, you execute the process for UNCNFRM.

UNCNFRM is typically used in a testing environment, because it enables users to rerun a payroll cycle once it has been confirmed. In a production environment, this process is rarely used. It might be used if there is a high-level table change that requires the recalculation of all paychecks.



Important! It is crucial that you understand exactly what UNCNFRM does in your particular situation before using it. The recovery steps necessary might differ, depending on the actual situation. The PS_PAY_FORM_TBL might need to be updated manually, so CONFIRM can reassign the check numbers correctly. We recommend that you call the PeopleSoft Global Support Center before running this process in a production environment.

Points to Consider When Running the UNCNFRM Process

After running UNCNFRM, you must rerun CALCPAY.

Otherwise, the location field on PS_PAY_CHECK isn’t repopulated.

The CONFIRM process deletes paysheet records where OK_TO_PAY = ‘N.’

The UNCONFIRM process does not add these records back. Therefore, we recommend that you run a backup before you run the CONFIRM process.

Tables From Which the UNCNFRM Process Selects

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.


Tables the UNCNFRM Process Updates

PS_PAY_CALENDAR The PAY_CONFIRM_START flag is set to ‘N’ and the PAY_CONFIRM_RUN flag is set to ‘Y.’

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#, and CHECK_DT are blank.

PS_EARNINGS_BAL The amounts added by CONFIRM are backed out.

PS_DEDUCTION_BAL The amounts added by CONFIRM are backed out.

PS_TAX_BALANCE The amounts added by CONFIRM are backed out.

PS_GARN_BALANCE The amounts added by CONFIRM are backed out.

PS_CHECK_YTD The amounts added by CONFIRM are backed out.

PS_DED_ARREARS The amounts added by CONFIRM are backed out.

PS_CAN_CHECK_YTD* Canadian version of PS_CHECK_YTD. Amounts added by CONFIRM are backed out.

PS_CAN_ERN_BALANCE* Canadian version of PS_EARNINGS_BAL. The



amounts added by CONFIRM are backed out.

PS_CAN_DED_BALANCE* Canadian version of PS_DEDUCTION_BAL. The amounts added by CONFIRM are backed out.

PS_CAN_TAX_BALANCE* Canadian version of PS_TAX_BALANCE. The amounts added by CONFIRM are backed out.

PS_INS_EARNS_BAL The amounts added by CONFIRM are backed out (Canadian only).

Tables the UNCNFRM Process Updates

PS_PAY_CALENDAR The PAY_CONFIRM_START flag is set to 'N' and the PAY_CONFIRM_RUN flag is set to 'Y.'

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#, and CHECK_DT are blank.

PS_EARNINGS_BAL The amounts added by CONFIRM are backed out.

PS_DEDUCTION_BAL The amounts added by CONFIRM are backed out.

PS_TAX_BALANCE The amounts added by CONFIRM are backed out.

PS_GARN_BALANCE The amounts added by CONFIRM are backed out.

PS_CHECK_YTD The amounts added by CONFIRM are backed out.

PS_DED_ARREARS The amounts added by CONFIRM are backed out.

PS_CAN_CHECK_YTD* Canadian version of PS_CHECK_YTD. Amounts added by CONFIRM are backed out.

PS_CAN_ERN_BALANCE* Canadian version of PS_EARNINGS_BAL. The amounts added by CONFIRM are backed out.

PS_CAN_DED_BALANCE* Canadian version of PS_DEDUCTION_BAL. The amounts added by CONFIRM are backed out.

PS_CAN_TAX_BALANCE* Canadian version of PS_TAX_BALANCE. The amounts added by CONFIRM are



backed out.

PS_INS_EARNS_BAL The amounts added by CONFIRM are backed out (Canadian only).

Tables From Which the UNCNFRM Process Deletes


*These tables may be inserted into or updated depending on the payroll cycle being run.

Troubleshooting ToolsPeopleSoft provides a variety of tools to help with your troubleshooting. This section provides an overview of how you can use these tools.

In this section, we discuss:

Audit programs.

Traces.

Tracking payroll errors.

Audit Programs

These programs check the validity of the employee data and the table setup for payroll and benefits. They are especially useful for identifying missing tables and orphaned records.

DDDAUDIT.SQR

This SQR reports inconsistencies between the PeopleTools tables (for example, PSRECDEFN and PSPNLDEFN) and the System Tables (such as, SYSTABLES and SYSCOLUMNS). Such inconsistencies can cause online errors as well as errors in the payroll processes. DDDAUDIT is discussed in more detail in your PeopleSoft PeopleTools documentation.

SYSAUDIT.SQR

This SQR reports inconsistencies within the PeopleTools tables. Exceptions reported here should be reported to the Global Support Center for resolution. SYSAUDIT is discussed in more detail in your PeopleSoft PeopleTools documentation.

Traces

These tools for tracking errors are found at several levels your system architecture.



PeopleCode Trace

This trace captures all PeopleCode that is executed online by the client. It is useful in determining whether the PeopleCode being executed is correct. You activate this trace by navigating to PeopleTools, Utilities, Use, Trace PeopleCode and selecting the level of trace you require. Typically, the default settings are sufficient for tracing the PeopleCode activity. Normally this trace is turned on right before you execute the transaction that you want to trace. This way, you minimize the size of the trace.

You do not have to turn it on at the beginning of your PeopleSoft session. When reviewing the output of the trace, it’s useful to start at the end of the trace and work your way back to the beginning.

SQL Trace

A SQL trace captures all SQL statements that are executed during an online session. It is used to determine exactly what data is being selected, inserted, updated, and deleted from the database. You activate this trace by navigating to PeopleTools, Utilities, Use, Trace SQLPeopleCode and selecting the level of trace you require. You would initiate the trace from the page right before you execute the transaction you want to trace. The trace stays on until you turn it off or close all PeopleSoft menus.

See Also

PeopleTools PeopleBook: Data Management, “Trace PeopleCode”

PeopleTools PeopleBook: Data Management, “Trace SQL”

Tracking Payroll Errors

Finding the reason for the error may involve identifying and reviewing the relevant program code. At times, though, erroneous data can mimic a programming problem. Following are some considerations on finding and debugging payroll errors.

Interpreting the Error

Sometimes when you receive an error, it references many programs. How do you know which program actually generated the error? Below is an example of an error:

LOAD-JOB (PSPPYGEM) 00001 end of fetchPAGE#=00001, LINE#=001, EMPLID=99999......GET-NEXT-JOB (PSPPARRY) 00001 end of fetchBUILD-PAYSHEETS (PSPPYSHT) 00001 end of fetch

In the above error, three programs are identified: PSPPYGEM, PSPPARRY, and PSPPYSHT. The program that generates the error is PSPPYGEM, and the procedure that is executing is LOAD_JOB. The other programs are listed because they are called prior to PSPPYGEM.

Debugging Standard Payroll Error Messages

It is common to receive standard payroll error messages when running a payroll process. You receive the “Check Messages” message. When a standard payroll error occurs, you receive a Message ID, message description, and message data.



The message data points to the problem. Examples of message data are RunID, benefit plan, deduction code, and EMPLID. However, sometimes it’s difficult to determine the exact conditions that cause a standard payroll error, if the message data does not provide enough information. One way to determine what is causing the error is to check the COBOL program that issues the error. Using the steps below, you can track the cause of these errors.

1. Locate the error message number on the MSGIDPAY.XRF COBOL cross-reference report. Alternatively, you can look up the message in COBOL copy member PSCPYMSG.CBL and then scan your COBOL code for the 88 level name for that error message.

This gives the program(s) that generates this error. As an example, here is the information for Payroll Error 64 - Prior Run Not Confirmed:

PSPPYGRP NOT-CONFIRMED 0000642. Review the COBOL program(s) to find what condition from Step 1 above causes the error.

Typically it is the result of a SQL statement. For error 64, this is the COBOL calling this error:

***************************************************************** * * JD000-CHECK-CONFIRM SECTION. JD000. * * ******************************************************************

MOVE COMPANY OF PSLCT TO COMPANY OF S-CHKCAL MOVE PAYGROUP OF PSLCT TO PAYGROUP OF S-CHKCAL MOVE PAY-END-DT OF PSLCT TO PAY-END-DT OF S-CHKCAL MOVE RUN-ID OF PSLCT TO RUN-ID OF BIND-DATA OF S-CHKCAL

CALL ‘PTPSQLRT’ USING ACTION-SELECT OF SQLRT SQLRT SQL-CURSOR-COMMON OF SQLRT SQL-STMT OF S-CHKCAL BIND-SETUP OF S-CHKCAL BIND-DATA OF S-CHKCAL SELECT-SETUP OF S-CHKCAL SELECT-DATA OF S-CHKCAL IF RTNCD-ERROR OF SQLRT

MOVE ‘CHECK-CONFIRM(SELECT)’ TO ERR-SECTION OF SQLRT PERFORM ZZ000-SQL-ERROR END-IF

INITIALIZE SELECT-DATA OF S-CHKCAL

CALL ‘PTPSQLRT’ USING ACTION-FETCH OF SQLRT SQLRT SQL-CURSOR-COMMON OF SQLRT IF RTNCD-ERROR OF SQLRT

IF RTNCD-END OF SQLRT

SET RTNCD-OK OF SQLRT TO TRUE ELSE MOVE ‘CHECK-CONFIRM(FETCH)’ TO ERR-SECTION OF SQLRT



PERFORM ZZ000-SQL-ERROR END-IF ELSE SET MSGID-NOT-CONFIRMED OF PYMSG TO TRUE MOVE RUN-ID OF SELECT-DATA OF S-CHKCAL TO MSGDATA1 OF PYMSG PERFORM ZM000-MESSAGE SET RTNCD-USER OF SQLRT TO TRUE END-IF

. CHECK-CONFIRM-EXIT.

The error occurs when the statement PSPPYGRP_S_CHKCAL returns one or more rows.

3. Review the SQL stored statement to determine what condition is being met.

On the SQLBase platform, these statements are stored in the SYSCOMMANDS table by statement name. For all other platforms, these statements are stored in the PS_SQLSTMT_TBL by statement name. Here is the SQL statement that generates error 64:

STORE PSPPYGRP_S_CHKCALSELECT RUN_IDFROM PS_PAY_CALENDARWHERE COMPANY=:1 AND PAYGROUP=:2 AND PAY_END_DT<=:3 AND RUN_ID<>’ ‘ AND RUN_ID<>:4 AND (PAY_CONFIRM_RUN=’N’ OR PAY_OFF_CYCLE=’Y’);

4. You can then execute this statement manually using a query tool such as SQLTalk.

You need to fill in the bind variables based on the information you are processing. In this example, you specify the company, pay group, and pay end date of the calendar you are processing.

Debugging SQL and Database Errors

These errors are the most difficult to track down. At times, they can only be resolved by reviewing the COBOL and possibly adding display statements. However, many times they are caused by erroneous data that the program is not designed to trap, for example, erroneous data that was converted from an SQR that did not perform the normal online edit checking.

Below are some things you can do to narrow down the condition that is causing the error:

1. Run the audit programs described in this section.

They are designed to identify erroneous data. Correct all exceptions that are reported.

2. Run a trace that identifies the SQL statement that is executing when the error occurs.

The trace may give the values of the bind variables that identify the employee on which the error is occurring. You can then look more closely at this employee. Or you may decide to mark this employee Not Pay. This prevents holding up the payroll for one employee, and you can research it after the payroll is complete.



3. Review the error and determine the program and procedure that is executing when the error occurs.

This might show exactly what SQL statement is executing. However, sometimes the SQL statement is executed in a previous program, and the data doesn’t cause a problem until the current program uses it.

Key Status Fields

There are four fields that determine the overall status of a paycheck:

PAY_LINE_STATUS of PS_PAY_EARNINGS

PAYCHECK_STATUS of PS_PAY_CHECK

CONFIRMED of PS_PAY_LINE

CONFIRMED of PS_PAY_PAGE

The programs to determine what has been processed so far and what still needs to be processed use these fields. This is what enables the processes to be run again and to continue where they leave off if an error occurs. In some cases, after an error occurs, some of statuses will have been updated and others will not have been updated.

For example, if you get a “duplicate on insert” in CONFIRM when updating balances, only the PS_PAY_CHECK table still shows the check as calculated. The other tables show that the check is confirmed. It is useful to query these status fields to get an overall picture of where the payroll process is for one or all checks.


PeopleSoft Proprietary and Confidential

Documents

Troubleshooting Payroll for North America1