Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
• 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.
• 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?
• Has this problem occurred before? If not, when did it last work? What has changed since
then?
• Use diagnostic tools such as traces and audit programs. See Troubleshooting Tools.
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.
An index, field, or table has been changed or dropped since the command using this object was
stored.
Recreate the stored commands for the database. This procedure is documented in the platform-
specific System Administration documentation.
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.
An index, field, or table has been changed or dropped since the command using this object was
stored.
Recreate the stored commands for the database. This procedure is documented in the platform-
specific System Administration documentation.
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.
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.
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.
• 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.
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
ISSUE: Paycalc error message 000017 "Federal tax data not found for this employee."
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
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.
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.
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.
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:
• If this error is accompanied by errors 17: Federal Tax Data Not Found and 89: Benefit Not
Found, it can indicate:
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.
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.
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.
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.
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.
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.
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.
An index, field, or table has been changed or dropped since the command using this object was
stored.
Recreate the stored commands for the database. This procedure is documented in the platform-
specific System Administration documentation.
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).
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.
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.”
This number represents the number of PS_PAY_LINE records where JOB_CHANGE <> R.
Checks To Calculate
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.
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.
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.
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).
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=: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).
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';
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.
An index, field, or table has been changed or dropped since the command using this object was
stored.
Recreate the stored commands for the database. This procedure is documented in the platform-
specific System Administration documentation.
• On Allbase, the error is “2509: Index uniqueness or unique/primary key constraint violated.”
• 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’ 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;
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.
An index, field, or table has been changed or dropped since the command using this object was
stored.
Recreate the stored commands for the database. This procedure is documented in the platform-
specific System Administration documentation.
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
PSPSQLRT - ERROR IN SELECT SETUP/DATA
STATEMENT=PSPCARRY_S_UGRN
PSPSQLRT - ERROR IN SELECT SETUP/DATA
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.
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.
An index, field, or table has been changed or dropped since the command using this object was
stored.
Recreate the stored commands for the database. This procedure is documented in the platform-
specific System Administration documentation.
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.
An index, field, or table has been changed or dropped since the command using this object was
stored.
Recreate the stored commands for the database. This procedure is documented in the platform-
specific System Administration documentation.
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.
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 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.
• PS_BALANCE_ID_DEF
• PS_BALANCE_ID_QTR
• PS_BALANCE_ID_TBL
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.
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).
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.
The PAY_SHEETS_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.
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.
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.
• 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).
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.
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 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.
• You should back up the database before running CONFIRM. This is necessary, because this
process cannot simply be rerun once it has completed.
• 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).
This process also selects from some employee and pay process tables.
* These tables might be inserted into or updated, depending on the payroll cycle being run.
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.
• 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.
See Also
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).
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.
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.
The UNCONFIRM process does not add these records back. Therefore, we recommend that
you run a backup before you run the CONFIRM process.
backed out.
PS_INS_EARNS_BAL The amounts added by CONFIRM are
backed out (Canadian only).
*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.
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
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.
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 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.
* *
**************************************************************
****
IF RTNCD-END OF SQLRT
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.
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.
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.