Troubleshooting a Failed Payroll

Assessment

When a Distribute and Pay Payroll ( PYPADP ) job fails, perform an initial assessment by checking the following items:

• Check the tail sheet to review where the PYPADP job failed.
• Were checks printed?
• Was the EFT file created? If so, does the EFT file look correct?
• How many records in PYUPPH are in DP (Distributed Paid) CK Note status for the pay period that was processed? How many are in WP (Waiting Payment) status?
• Check the BK to review EF or PR records. The number of BK records should match the number of PYUPPH DP records.
• Check the GL. The number of GL records should match the number of PYUPPH DP records.
• If applicable, check the subledger if any records exist for the pay period.
• If applicable, check the EO (hr_eostub) table to determine if check stubs were posted to Employee Online .

Checking the Tail Sheet

The first step is to check the PYPADP tail sheet for error messages. Open the tail sheet in PDF Viewer and search for the word "error" or "fatal." Then look for the program that was launched/run right before the error occurred. If you know the program that issued the error, you can determine where in the PYPADP process the job failed, and what needs to be done to correct this.

When the user runs PYPADP, several programs are run, as can been seen on the JCL tab for the PYPADP mask in the Nucleus Next Question Prompting and JCL ( NUUPJBNQ ) page. For mask PYPADP, review all the different programs on the JCL tab that are run (!RUN) during Distribute and Pay Payroll.

The general order in which the Distribute and Pay Payroll processes are run is as follows:

Understanding the different programs that are run during the PYPADP process and how they interact with the database helps to determine the steps needed to remedy a failed payroll. Keep in mind that the JCL for PYPADP can be modified and customized, so different programs can be listed at different client sites.

Program Naming Conventions

The naming of the programs that update the database during Distribute and Pay Payroll processing often mimic the names of the common codes that can be configured to control those programs. Oftentimes, if you look up a program name in the Common Code listing you can get a general idea of the functionality of the program itself. For example, the py632 program runs the PY to AR Interface, while common code PYFG/PY632C can be configured for the PY to AR Interface.

Similarly, the numbering of the programs that produce reports during PYPADP closely follow the numbering of the programs that update the database. Below is a table that lists the different PYPADP reports and the programs responsible for printing the reports. This list may be useful when reviewing the PYPADP tail sheet, to understand the processes and programs that are run, and where in the process the Distribute and Pay Payroll job may have failed.

Checking Employee Paid History (PYUPPH)

Check the Employee Paid History ( PYUPPH ) page to determine how many employee history records were processed during the Distribute and Pay Payroll job. Prior to running PYPADP, history records to be considered in the payroll were marked with a CK Note of 'WP' (Waiting Payment) by the Force Calc process. During the PYPADP process, processed records will be marked 'DP' (Distributed Paid). 
When a payroll fails, it can result in a failed or partial update of records from WP to DP status.

To determine how many records were successfully updated to a CK Note status of 'DP', find the number of records that have a DP check note for the failed pay period number. If the number of DP records is not the same as the total number of records processed in this payroll, then the process did not complete. 

To determine which records were not updated from WP to DP status, select the records that have a CK Note of 'WP' for the failed pay period.

Checking BK

• Open the BK Update Check/Deposit Info ( BKUPCD ) page.
• In Find mode, enter the PYPADP job number in the Job Number field.
• The total number of EF and PY records must match the number of records found in Employee Paid History ( PYUPPH ) for the same pay period.

Checking the GL

Run the Account Transactions ( GLREFLTR ) report using the 07 (Transaction), 09 (Job Number) Selection Criteria to enter the PYPADP job number.

Checking the EFT File

The EFT file that is created during the Distribute and Pay Payroll process is stored on the App server in the admin/data directory. If the file is missing, the PYPADP job did not complete that portion of the process.

Checking the Subledger

Clients using the Subledger can perform an SQL Query in the Administrative Console to determine if payroll posted to the Subledger. For example, to view Subledger records for pay period 1701060, the SQL query would look like this:

select * from pyg_glt_dtl where pyg_per_cc = '1701060'

Checking EO Pay Stubs

Similar to checking the Subledger table for records, the user can query the EO Stub (hr_eostub) table to determine whether or not the payroll process posted pay stubs to Employee Online. For example, an SQL query for pay period 1701060 would look like this:
select * from hr_eostub where period = '1701060'
Make sure the check dates are the same for all the records.

EO Stub Common Codes

The check stubs that display in Employee Online are read from data in the hr_eostub table. The data is written to the hr_eostub table during the PYPADP process via the PY Check/EFT writer.
To maintain the data in this table, the following common codes should be set up so that the specified standard PY processes will properly handle the data in the hr_eostub table. 

When these common codes are set up with 'EOSTUB' in the third Associated Code field, the system will automatically back out data during a payroll undo, check maintenance, or check reprint.