Payroll-Related Tables

Payroll for North America is a set of input tables, processes, and output tables. You set up your input tables, run a process, and the process, in turn, writes new data to the output tables.

This table lists examples of Payroll for North America input tables with their associated processes and output tables

Running Payroll for North America processes might be labeled a quiet task. The processes start, run, and stop, rarely putting out more than five or ten lines of output, which typically consist of messages to the effect that the process began at a certain time, a certain pay group is being processed, and finally, that the run has finished.

The system writes all results of the Payroll for North America processes back into the database. Any tangible outputs from these processes, such as paychecks, are all reports based on database tables. To get the physical paychecks, for example, you run an Structured Query Report (SQR) against the database.

So what does a typical Payroll for North America process do? It reads some input from various tables, writes new data back into the database, and goes away. A process might send a message that says "Check Messages!!!". That means it wrote at least one message into the message table. In that case, you must go back and run a report against the message table to get the messages, or view the messages online on the Paysheets page, Payroll Messages page.

Employee data input tables can be classified as employee jobs, benefits, and deductions. Online, some of these tables are found in the Workforce Administration menu, others in the Employee Pay Data menu, and some in the Benefits menu.

You hire employees and set up their job data; enroll them in benefits programs and set up their benefits data; set them up for general deductions and enter this information on the database. You insert rows into their various job, benefits, and deduction tables:

This table lists the Payroll for North America employee data input tables and the pages where you enter the data.

Employee data tables all have EMPLID as a key, so if you must find them all, a good way to start is to look at those tables containing EMPLID. To do this, use the Records and Fields PeopleTools Cross Reference Report (XRFFLRC).

One of the advantages of Payroll for North America is that you can use PeopleTools to easily configure the payroll tables. However, you keep in mind how any changes you make might move through the database, particularly considering the interdependency not only of tables, but also of the batch processes that call them.

Suppose you decide you have to add a column (a field) to PERSONAL_DATA. PeopleSoft batch processes never issue a SQL SELECT statement against a table. The system always selects only the columns that it wants from the table. If it wants to retrieve or update rows of the employee names, for example, it specifically asks for the NAME. It never makes an assumption about what columns are on that table.

Consequently, if you add a column to PERSONAL_DATA, it doesn't affect batch payroll processes, because if a batch process wants something from PERSONAL_DATA, such as the employee's address, it asks for the address by column name. So, in effect, you can add multiple columns, and if you do not need or want your new columns to affect batch processing, that's OK, because the processes ignores them. Any tables that you modify, of course, are maintained by the online system, so you must modify and store the appropriate records (and possibly pages).

You must be more careful when modifying existing columns that are used by the batch processes. For example, you might decide to alter the HOURLY_RT column on the JOB table. You need seven decimal places instead of the six provided in PeopleSoft. Now, the batch Payroll system is set up to read the HOURLY_RT column from the JOB table; and when it does so, it makes the assumption that it's reading the HOURLY_RT as defined in the standard application. In this case, modifying an existing column affects payroll processing, because the COBOL programs must know the format of the data to be mapped. Because the HOURLY_RT column is used by Payroll, you also have to modify some of the batch processes.

Remember also that if you change the name of the HOURLY_RT column, the batch processes won't be able to find it unless you modify the batch processes accordingly.

Some of the tables—particularly the output tables—are maintained by batch processes (DEDUCTION_BAL, the Deduction Balance table, for example). During normal processing, the system inserts, updates, and possibly even deletes individual rows. When you add new or modify existing columns on these tables, you have to make the corresponding COBOL changes.

For payroll process input tables, you set up much of the controlling information for running payrolls, information having to do with the specifics of particular earnings, deductions, or taxes. You can find these tables online in the Set Up HCM > Product Related > Payroll for North America menu, unless otherwise indicated.

The fact that an employee works in the state of New York is employee-level data stored in the employee data input tables. But to calculate that employee's taxes, the system checks the appropriate pay process input table that defines tax rates for employees who work in New York:

This table lists the Payroll for North America payroll process input tables and the pages where you enter the data

Paycheck output tables are result tables written to and maintained by the batch processes. Some paycheck output tables are, in turn, inputs to other batch processes:

This table lists the Payroll for North American payroll input tables (paysheets) and their corresponding output, or balance, tables.

The tables on the left are payroll input tables. Often, they are populated with data during the Create Paysheet process, so in that sense they are output tables. But after they are created, they serve as inputs to the other payroll batch processes, such as Pay Calculation and Pay Confirmation. Create Paysheet is a process that goes through the database and forms a proposal to pay someone; it creates the paysheets. When you view paysheets online, you're looking at data from the payroll input tables. When you make one-time tax, deduction, or garnishment changes to an employee's paysheet, you are writing data to these tables, data that the batch processes uses in the next step of converting input to output.

The tables on the right are payroll output tables; most of them also have corresponding balance tables. These tables are the result of running one of the payroll batch processes. These tables are maintained by the Payroll for North America system. That is, these are tables that the system uses to write back to the database during processing.

Notice that the PAY_EARNINGS table functions both as a payroll input table and as a payroll output table. The Create Paysheet process initially generates information in PAY_EARNINGS. Your online users might then update the table. However, the Pay Calculation and Pay Confirmation processes subsequently write results back into PAY_EARNINGS, because PAY_EARNINGS also serves as the history record of the employee's earnings.

PAY_EARNINGS before and after pay confirmation is the same table, but there is a difference. The PeopleCode behind the data-entry paysheets pages doesn't read any data that you've already confirmed. That is, the system considers information on a confirmed PAY_EARNINGS row ineligible to display on a paysheet. The information, however, is still there; it exists until you purge it.

PAY_OTH_EARNS is treated in a similar fashion.