Peoplesoft Payroll For North America

PeopleSoft Payroll for North America
PeopleSoft 8.3 Payroll for North America Troubleshooting Guidelines
37PeopleSoft 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, its 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 Checklist
When 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
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 PeopleSofts 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 Resolution

In 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 platformspecific 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.
stored.
End of Fetch (PSPPYGEM)

The complete error is:
LOAD-JOB (PSPPYGEM)
00001 end of fetch
PAGE#=00001, LINE#=001, EMPLID=99999......
GET-NEXT-JOB (PSPPARRY)
00001 end of fetch
BUILD-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 data
PAGE#=0444, LINE#=00, EMPLID=
,EMPLRCD#=8224
PROCESS-JOB (PSPUPSHT)
SELECT-PAY-CALENDAR (PSPPYSHT)
START-RUN (PSPSTRUN)
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 employees 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 employees 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
employees 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 employees 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 its 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 employees 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 employees 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.
stored.
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.
10
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 isnt 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.
11
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 offcycle 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=:2
Insert the Company, Pay Group, Pay End Date, and Run ID that you are processing in the
associated bind variables (:1, :2, :3, :4).
12
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.
stored.
SQL Error 0805: Non-Unique Data (PSPCBUPD)
Here is an example of the complete error on SQLBase:
INSERT-BALANCE
PAGE#=0001, LINE#=001, SEPCHK=000, EMPLID=0008, EMPLRCD#=0000, NAME=
PROCESS-CHECK (PSPCBUPD)
MAIN (PSPPYUPD)
PROCESS-CONFIRMATION (PSPPYWKS)
This error varies by platform:
On DB2, the error might have the description Insert/update of unique constrained columns
with duplicate data.
13
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 doesnt 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 = [employees 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 WHERE
COMPANY = :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' WHERE
AGENCY = :1 AND PAYGROUP = :2 AND PAY_END_DT = :3;

14
CANNOT EXECUTE
UNCNFRM Process Errors

The following errors might appear when you run the Unconfirm process.
stored.
Error In Select Setup/Data (PSPCARRY)
This error typically occurs on the Oracle platform. This is the complete error:
PSPSQLRT - ERROR IN SELECT SETUP/DATA
STATEMENT=PSPCARRY_S_UGRN
VARIABLE#=015
INVALID CHARACTER IN SETUP=1
STATEMENT=PSPCARRY_S_UGRN
VARIABLE#=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.
15

stored.
CANNOT EXECUTE
REVERSAL Process Errors

You may encounter the following errors while running the Reversal process.
stored.
CANNOT EXECUTE
16
Process Overview
To 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 dont
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
17
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 dont 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 doesnt 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

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
18
paylines.
PS_PAY_LINE
This table contains individual paylines. Each

employee is created on a separate payline during oncycle 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 arent 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:
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.
Updated by operator. A user has updated the record

online since it was originally entered or calculated.
PeopleCode sets this status.
Calculated successfully.
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.
Confirmed successfully.
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
19
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 isnt 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

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
PS_PAY_MESSAGE

processing.
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
20
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 doesnt 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

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

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 arent
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.
22
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 arent
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:
Calculated successfully.
Calculation error. Check for payroll messages or

other errors.
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
PS_PAY_MESSAGE

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
23
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_INSTALLATION
The process selects the Balance ID for

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

PS_PAY_TAX_CAN
Taxes taken for the calendar being

processed are selected (Canadian only).
24
PS_PAY_GARNISH
Garnishments taken for the calendar

being processed are selected.
PS_PAY_DEDUCTION
Deductions taken for the calendar being

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_MESSAGE

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
25
check and advice information.

PS_PAY_MESSAGE
This table is updated with standard payroll

error messages that are encountered
during the process.
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*
PS_CAN_ERN_BALANCE*
Canadian version of
PS_EARNINGS_BAL.
PS_CAN_DED_BALANCE*
Canadian version of
PS_DEDUCTION_BAL.
PS_CAN_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
26
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
PS_PAY_MESSAGE

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

PS_PAY_ONE_TIME

PS_PAY_TAX_OVRD

PS_PAY_CTX_OVRD

PS_PAY_GARN_OVRD

PS_PAY_DEDUCTION

PS_PAY_TAX

PS_PAY_TAX_CAN

OK_TO_PAY = N are deleted. (Canadian version of
PS_PAY_TAX.)
27
PS_PAY_GARNISH

PS_PAY_CHECK

PS_PAY_SPCL_EARNS

PS_PAY_INS_EARNS

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

PS_PAY_ONE_TIME

PS_PAY_TAX_OVRD

PS_PAY_CTX_OVRD

PS_PAY_GARN_OVRD

PS_PAY_DEDUCTION

PS_PAY_TAX

PS_PAY_TAX_CAN

(Canadian version of PS_PAY_TAX.)
PS_PAY_GARNISH

28
PS_PAY_CHECK

PS_PAY_SPCL_EARNS

PS_PAY_INS_EARNS

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

added by the user prior to running the process. This
is the parent record on the run control page.
PS_PAY_CHECK_REVRS

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.
29
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
30
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
PS_PAY_MESSAGE

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

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.
31
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
PS_PAY_MESSAGE

processing.
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.
32
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

PS_PAY_EARNINGS

PS_PAY_OTH_EARNS

PS_PAY_ONE_TIME

PS_PAY_TAX_OVRD

PS_PAY_CTX_OVRD

PS_PAY_GARN_OVRD

PS_PAY_CHECK

PS_PAY_DEDUCTION

PS_PAY_TAX

PS_PAY_TAX_CAN

ID that was entered (Canadian version of
PS_PAY_TAX).
PS_PAY_GARNISH

PS_PAY_SPCL_EARNS

PS_PAY_INS_EARNS

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

PS_PAY_EARNINGS

PS_PAY_OTH_EARNS
33

PS_PAY_ONE_TIME

PS_PAY_TAX_OVRD

PS_PAY_CTX_OVRD

PS_PAY_GARN_OVRD

PS_PAY_CHECK

PS_PAY_DEDUCTION

PS_PAY_TAX

PS_PAY_TAX_CAN

with the Run ID that was entered
(Canadian version of PS_PAY_TAX).
PS_PAY_GARNISH

PS_PAY_SPCL_EARNS

PS_PAY_INS_EARNS

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.
34
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 isnt 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

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 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
PS_TAX_BALANCE
PS_GARN_BALANCE
PS_CHECK_YTD
PS_DED_ARREARS
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
35
amounts added by CONFIRM are backed out.

PS_CAN_DED_BALANCE*
Canadian version of PS_DEDUCTION_BAL. The

PS_CAN_TAX_BALANCE*
Canadian version of PS_TAX_BALANCE. The

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

backed out.
PS_TAX_BALANCE

backed out.
PS_GARN_BALANCE

backed out.
PS_CHECK_YTD

backed out.
PS_DED_ARREARS

backed out.
PS_CAN_CHECK_YTD*

Amounts added by CONFIRM are backed
out.
PS_CAN_ERN_BALANCE*
Canadian version of
PS_EARNINGS_BAL. The amounts
PS_CAN_DED_BALANCE*
Canadian version of
PS_DEDUCTION_BAL. The amounts
PS_CAN_TAX_BALANCE*

36
backed out.
PS_INS_EARNS_BAL

backed out (Canadian only).
Tables From Which the UNCNFRM Process Deletes

PS_PAY_MESSAGE

processing.
*These tables may be inserted into or updated depending on the payroll cycle being run.
Troubleshooting Tools
PeopleSoft 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.
37
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, its 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 fetch
PAGE#=00001, LINE#=001, EMPLID=99999......
GET-NEXT-JOB (PSPPARRY)
00001 end of fetch
BUILD-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.
38
The message data points to the problem. Examples of message data are RunID, benefit plan,
deduction code, and EMPLID. However, sometimes its 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
000064
2. 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
MOVE
MOVE
MOVE
COMPANY OF PSLCT TO COMPANY OF S-CHKCAL

PAYGROUP OF PSLCT TO PAYGROUP OF S-CHKCAL
PAY-END-DT OF PSLCT TO PAY-END-DT OF S-CHKCAL
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)
PERFORM ZZ000-SQL-ERROR
END-IF
TO
ERR-SECTION OF SQLRT
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
39
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_CHKCAL
SELECT
RUN_ID
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)
;
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.
40
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 doesnt 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.
41

Peoplesoft Payroll For North America

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Peoplesoft Payroll For North America

Uploaded by

Copyright:

Available Formats

PeopleSoft Payroll for North America

PeopleSoft 8.3 Payroll for North America Troubleshooting Guidelines

37PeopleSoft 8.3 Payroll for North America

Understanding error resolution.

Determine the Impact of the Problem

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

PeopleSoft Proprietary and Confidential