Beruflich Dokumente
Kultur Dokumente
A troubleshooting checklist.
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.
Specifically, what is the problem? What is the expected result? What result are you getting?
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?
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.
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.
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.
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
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:
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.
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.
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.
Recreate the stored commands for the database. This procedure is documented in the platformspecific System Administration documentation.
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).
11
12
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 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.
14
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.
15
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
PS_BALANCE_ID_DEF
PS_BALANCE_ID_QTR
PS_BALANCE_ID_TBL
PS_PAY_MESSAGE
PS_PAY_CAL_BAL_ID
17
PS_PAY_MESSAGE
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
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).
PS_PAY_CALENDAR
PS_INSTALLATION
18
paylines.
PS_PAY_LINE
PS_PAY_EARNINGS
SEPCHK
PAY_LINE_STATUS
Calculated successfully.
Confirmed successfully.
JOB_PAY
OK_TO_PAY
19
this record.
DED_TAKEN
TAX_PERIODS
PS_PAY_OTH_EARNS
PS_PAY_MESSAGE
PS_PAY_MESSAGE
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
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).
PS_PAY_CALENDAR
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_EARNINGS
PS_PAY_OTH_EARNS
PS_PAY_ONE_TIME
21
are selected.
PS_PAY_TAX_OVRD
PS_PAY_CTX_OVRD
PS_GARN_OVRD
PS_PAY_DEDUCTION
PS_PAY_TAX
PS_PAY_TAX_CAN
PS_PAY_GARNISH
PS_PAY_SPCL_EARNS
PS_PAY_INS_EARNS
PS_PAY_MESSAGE
22
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_EARNINGS
Calculated successfully.
PS_PAY_OTH_EARNS
PS_PAY_CHECK
PS_PAY_MESSAGE
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.
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).
PS_PAY_CALENDAR
PS_INSTALLATION
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_CHECK
PS_PAY_EARNINGS
PS_PAY_SPCL_EARNS
PS_PAY_INS_EARNS
PS_PAY_TAX
PS_PAY_TAX_CAN
24
PS_PAY_GARNISH
PS_PAY_DEDUCTION
This process also selects from some employee and pay process tables.
Tables Into Which the CONFIRM Process Inserts
PS_BOND_LOG*
PS_PAY_DISTRIBUTN
PS_PAY_MESSAGE
PS_PAY_CHECK_DUE
PS_CHECK_YTD*
PS_EARNINGS_BAL*
PS_DEDUCTION_BAL*
PS_TAX_BALANCE*
PS_GARN_BALANCE*
PS_CAN_CHECK_YTD*
PS_CAN_ERN_BALANCE*
PS_CAN_DED_BALANCE*
PS_CAN_TAX_BALANCE*
PS_INS_EARNS_BAL
* 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*
PS_PAY_DISTRIBUTN
25
PS_PAY_CHECK_DUE
PS_CHECK_YTD*
PS_EARNINGS_BAL*
PS_DEDUCTION_BAL*
PS_TAX_BALANCE*
PS_GARN_BALANCE*
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
PS_PAY_LINE
PS_PAY_EARNINGS
PAY_LINE_STATUS is set to F.
PS_PAY_CHECK
PAYCHECK_STATUS is set to F.
PS_DED_ARREARS
PS_ADDL_PAY_DATA
PS_GARN_SPEC
PS_GENL_DEDUCTION
26
PS_LEAVE_ACCRUAL
PS_PAY_FORM_TBL
PS_PAY_CALENDAR
PS_PAY_MESSAGE
PS_PAY_PAGE
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_DEDUCTION
PS_PAY_TAX
PS_PAY_TAX_CAN
27
PS_PAY_GARNISH
PS_PAY_CHECK
PS_PAY_SPCL_EARNS
PS_PAY_INS_EARNS
PS_PAY_MESSAGE
PS_PAY_PAGE
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_DEDUCTION
PS_PAY_TAX
PS_PAY_TAX_CAN
PS_PAY_GARNISH
28
PS_PAY_CHECK
PS_PAY_SPCL_EARNS
PS_PAY_INS_EARNS
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.
PS_PAY_REV_RUNCTL
PS_PAY_CHECK_REVRS
PS_PAY_CHECK
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_EARNINGS
PS_PAY_OTH_EARNS
PS_PAY_DEDUCTION
PS_PAY_TAX
29
PS_PAY_TAX_CAN
PS_PAY_GARNISH
PS_PAY_ONE_TIME
PS_PAY_TAX_OVRD
PS_PAY_CTX_OVRD
PS_PAY_GARN_OVRD
PS_PAY_INS_EARNS
PS_PAY_SPCL_EARNS
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_EARNINGS
PS_PAY_OTH_EARNS
PS_PAY_SPCL_EARNS
PS_PAY_INS_EARNS
PS_PAY_DEDUCTION
PS_PAY_TAX
PS_PAY_TAX_CAN
PS_PAY_GARNISH
30
PS_PAY_TAX_OVRD
PS_PAY_CTX_OVRD
PS_PAY_GARN_OVRD
PS_PAY_MESSAGE
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
PS_PAY_FORM_TBL
31
PS_PAY_DISTRIBUTN
PS_PAY_FORM_TBL
PS_PAY_MESSAGE
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.
32
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
PS_PAY_GARNISH
PS_PAY_SPCL_EARNS
PS_PAY_INS_EARNS
PS_PAY_LINE
PS_PAY_EARNINGS
PS_PAY_OTH_EARNS
33
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
PS_PAY_GARNISH
PS_PAY_SPCL_EARNS
PS_PAY_INS_EARNS
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.
PS_PAY_CALENDAR
PS_INSTALLATION
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_EARNINGS
PS_PAY_CHECK
PS_EARNINGS_BAL
PS_DEDUCTION_BAL
PS_TAX_BALANCE
PS_GARN_BALANCE
PS_CHECK_YTD
PS_DED_ARREARS
PS_CAN_CHECK_YTD*
PS_CAN_ERN_BALANCE*
35
PS_CAN_TAX_BALANCE*
PS_INS_EARNS_BAL
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_EARNINGS
PS_PAY_CHECK
PS_EARNINGS_BAL
PS_DEDUCTION_BAL
PS_TAX_BALANCE
PS_GARN_BALANCE
PS_CHECK_YTD
PS_DED_ARREARS
PS_CAN_CHECK_YTD*
PS_CAN_ERN_BALANCE*
Canadian version of
PS_EARNINGS_BAL. The amounts
added by CONFIRM are backed out.
PS_CAN_DED_BALANCE*
Canadian version of
PS_DEDUCTION_BAL. The amounts
added by CONFIRM are backed out.
PS_CAN_TAX_BALANCE*
36
backed out.
PS_INS_EARNS_BAL
*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.
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
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
TO
ERR-SECTION 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