Preliminary Payroll Processing

The Preliminary Payroll process can begin once all the necessary timesheets have been submitted for payroll processing. After entering the required batch parameters to run a new preliminary payroll, the preliminary preprocessor takes data from the Pay Period (PERD) table associated to eligible assignments for payroll, creates payroll triggers, and writes the details and summary data to the preliminary tables. These triggers denote that a preliminary preprocessor job was run to keep the process separate from the regular payroll process at this stage. The Preliminary Preprocessor batch job functions the same way as the regular preprocessor, but the output is stored on preliminary tables to keep the data separate from the regular payroll process data. This process also sets the Idle in Prelim Payroll check box to checked on the relevant PERD entries and clears the Run GTN check box. The Idle in Prelim Payroll check box prevents the user from running another payroll, preliminary or regular for the selected payroll number, until this preliminary payroll run has been committed or cleared.

While running the Preliminary Payroll, the user must lock the database by selecting the In Progress check box associated to Prelim Payroll (PPAYROLL) on the System Process (SYSPROC) page in Advantage HRM, thus preventing the data that directly affects the payroll from being updated while the Preliminary Payroll process is in progress. The Preliminary Payroll Commit/Clear jobs may be run when the In Progress check box on SYSPROC page is selected. On completion of the Preliminary Payroll including the Commit or Clear job, the user must manually unlock the database tables by clearing the In Progress check box associated with PPAYROLL on the SYSPROC page.

Upon successful completion of the Preliminary Preprocessor, a Preliminary GTN process is executed using any of the following options for preliminary payroll processing: preliminary regular Gross-to-Net process, preliminary supplemental Gross-to-Net process, or preliminary No Pay Calculation Gross-to-Net process. GTN needs to know that a preliminary payroll process has been selected to run. Therefore, the trigger created as a result of the preliminary preprocessor run tells the preliminary GTN process where to pick up this data. GTN creates entries on the newly defined preliminary tables and stores GTN calculations. All entries are created similarly to the non-preliminary regular GTN process, but are stored on the preliminary tables as opposed to the regular database tables. The results of this batch job can be viewed in the job log. Throughout this process, the Idle in Prelim Payroll flag remains checked on all relevant PERD entries and the database tables remain locked.

Before deciding to commit or clear a Preliminary Payroll run, various reports reflecting this payroll can be reviewed. These reports allow preliminary payroll results to be verified before continuing with either a commit to the database to continue payroll processing, or to clear the results and run a non-preliminary payroll process. Included is a report which compares a preliminary pay cycle to the previous pay cycle, displaying the difference between not only the high level numbers in the cycles, but also down to the bucket (category in HRM) levels. This report can be useful in easily determining that an employee had more overtime this pay cycle then last, for instance.

Preliminary Payroll output available:

• HAB210E – Gross To Net Process Error Report

• HAB2800 – Automated Leave Accrual Statistics Report

• Variance Report – compares current preliminary payroll results to previous payroll results.

• QGTNSTAT – Gross-to-Net Statistics Inquiry

• InfoAdvantage reports

Selecting the Commit/Clear batch job gives the option to commit or clear a particular preliminary payroll GTN run. The Commit process takes the data from a preliminary run currently existing on the Preliminary tables, moves the data to the regular tables, and clears the data from the Preliminary tables. The Clear job eliminates the current Preliminary run from the Preliminary tables. When running Commit/Clear, the user sets the parameters to the selected function (Commit or Clear), and designates a GTN run number on which to act, or selects all GTN run numbers to be cleared.

No Preliminary Payroll data is stored on the preliminary tables after the run has been Committed or Cleared. Once a Preliminary Payroll run is complete, data can be edited, potentially altering the validity of the preliminary run. It is unnecessary to review preliminary data within the system once any data has changed. The user has the ability to print out reports from the run if necessary.

The Commit/Clear job also provides the ability to commit or clear a particular preliminary PAM run. The clear process eliminates the current preliminary PAM run from the payroll journal tables and R_PYRL tables for the indicated GTN Run Number where PRELIM_RUN_FL is set to 1. The commit process sets PRELIM_RUN_FL to 0 on the payroll journal tables and R_PYRL tables for the indicated GTN Run Number. Additionally, commit sets the FIN_PROCESSED_FL to 0 on R_PYRL_HDR. 
The following tables are part of the Preliminary PAM process:

• PYRL_EXPS_JRNL

• PYRL_FRNG_JRNL

• PYRL_LIAB_JRNL

• PAM_STATS

• PAM_ERROR

• R_PYRL_HDR

• R_PYRL_VEND

• R_PYRL_ACTG

The PEND_DED and PEND_PAY tables are not used in the same way with Preliminary GTN as the current Regular GTN process. The P_DED_PARM is only updated when GTN would update the PRNTE_EFFECTIVE_DT of DED_PARM, and P_PEND_PAY is only updated when GTN would recycle a negative payment.

In the Regular GTN process, these two tables are cleared upon successful completion of the run. With the Preliminary GTN process, these tables are not cleared until the Commit or Clear jobs are run. Since Preliminary Payroll shows the user results from a regular payroll process without committing any data, this data stays in pending form until the user decides to make it permanent. In the Regular GTN process, the data from PEND_DED and PEND_PAY are committed as soon as the GTN process is complete. The Preliminary Payroll process does not update any regular tables until the Preliminary run is Committed.

The Commit/Clear job only submits in the following cases.

• The GTN number is for a preliminary payroll run.

• If the GTN run has been committed.

• The preliminary run data has been moved to the regular tables.

• The GTN run continues through the normal payroll process.  

• If the GTN run has been cleared.

• The GTN run number no longer exists within the preliminary table.

• The GTN run number cannot be selected.

Once a Preliminary Payroll run has been committed or cleared, the Idle in Prelim Payroll check box on all relevant PERD entries is unchecked and the Run GTN check box on PERD is reset to checked. This allows another preliminary or regular payroll to be run for the selected payroll number.

If a commit is performed, the preliminary payroll data for that GTN run number is moved from the preliminary tables into the permanent tables, for example permanent Employee Summary tables and Employee Paycheck tables. Selecting commit effectively moves the GTN run out of the preliminary payroll process and into the regular payroll process, including changing the GTN run number designation from ”L” to ”R”. Once committed, the preliminary payroll run is no longer found in the preliminary tables. From this point forward, the GTN run continues along the regular payroll process through to finalization. Once committed, the GTN run cannot be returned to the preliminary payroll process. Committing a preliminary payroll run changes the Idle in Prelim Payroll flags on relevant PERD entries from checked to unchecked and resets the Run GTN check box to checked. This job also advances the PERD entry to the next date range as found on the CYCL table.

Additionally, the Commit job has the ability to run in parallel. This allows large Preliminary Payroll jobs to be multi-threaded and processed more quickly. Multi-threading can be assigned through the Process ID field on the relevant PERD entries.

When a Commit is performed, data for that preliminary run is moved from the preliminary tables to the appropriate regular tables as follows:

P_AACC_QUEUE -> AACC_QUEUE

P_CONTRACT_DETAIL -> CONTRACT_DETAIL

P_CONTRACT_SUMMARY -> CONTRACT_SUMMARY

P_DED_GOAL -> DED_GOAL

P_DED_PARM -> DED_PARM

P_DED_SUMM -> DED_SUMM

P_EMPL_APPT -> EMPL_APPT

P_EMPL_ASGNMT -> EMPL_ASGNMT

P_EMPL_SRVC_HRS -> EMPL_SRVC_HRS

P_EMPL_SVC_HRS_WKY -> EMPL_SRVC_HRS_WKY

P_EMPLYR_FICA -> EMPLYR_FICA

P_FED_TAX_QRT_SUM -> FED_TAX_QRT_SUM

P_FICA -> FICA

P_PAY_SUMM -> PAY_SUMM

P_PEND_DED -> (delete)

P_PEND_PAY -> (delete)

P_RECYCLED_DED_LOG -> RECYCLED_DED_LOG

P_RESERVE_SUMMARY -> RESERVE_SUMMARY

P_RUN_HIST -> RUN_HIST

P_WEEKLY_PAY_SUMM -> WEEKLY_PAY_SUM

P_DED_DETL -> C_DED_DETL

P_DED_DETL_EXT -> C_DED_DETL_EXT

P_PAY_CHECK -> C_PAY_CHECK

P_PAY_CHECK_EXT -> C_PAY_CHECK_EXT

P_PAY_CHK_DED_SUMM -> C_PAY_CHK_DED_SUMM

P_PAY_CHK_PAY_SUMM -> C_PAY_CHK_PAY_SUMM

P_PAY_DETL -> C_PAY_DETL

P_PAY_DETL_EXT -> C_PAY_DETL_EXT

P_REG_TRIGGER -> REG_TRIGGER

After moving the data from the preliminary tables to the regular tables, the data is cleared from the preliminary tables. Supplemental triggers and No Pay Calc triggers that were picked up are deleted on Commit.

If there are payroll journal table records with the PRELIM_RUN_FL set to 1 for the indicated GTN Run Number, the Commit process sets the prelim flag to 0. If there are records on R_PYRL_HDR with PRELIM_RUN_FL set to 1, the flag is set to 0 and FIN_PROCESSED_FL is set to 0. The records will remain on the same tables, and they may now be used in the regular PAM process. 

If the option to clear the results is desired, the Clear batch process must be invoked to clean the data from the run that was written to the preliminary tables. The clear option can be selected for a preliminary payroll run that has moved through the preliminary preprocessor and preliminary GTN, but has not yet been committed. Once a preliminary payroll run has been cleared, it can no longer be selected or searched against. The Clear batch job does not affect any data in the regular data tables as it is only clearing tables affected by the preliminary payroll process, which have their own tables. Clearing a preliminary payroll run changes the Idle in Prelim Payroll flags on relevant PERD entries from checked to unchecked and resets the Run GTN check box on PERD to checked. Supplemental triggers and No Pay Calc triggers that were picked up are left alone on Clear. If there are payroll journal table records with the PRELIM_RUN_FL set to 1 for the indicated GTN Run Number, they are deleted as part of the Clear process. If there are R_PYRL_HDR records with PRELIM_RUN_FL set to 1, those records and all associated records on R_PYRL_VEND and R_PYRL_ACTG are deleted.

The purpose of the Idle in Prelim Payroll check box on the Pay Period (PERD) pages is to prevent changes to data in the system that would cause a Preliminary run to be inaccurate or incorrect upon Commit. If a regular payroll is run for the same payroll number while a Preliminary payroll is in process, the preliminary run could not be completed due to numerous data inconsistencies in the regular database. For this purpose, when a Preliminary Payroll run completes the Preliminary Preprocessor, this check box is checked.  When either of the Commit or Clear jobs are completed, the Idle in Prelim Payroll check box is reset to unchecked and the Run GTN check box is reset to checked.

While Idle in Prelim Payroll check box is checked the following actions cannot be taken:

• Run a payroll for the selected payroll number.

• Run an additional Preliminary payroll for the selected payroll number.

• Submit any transaction that updates employee information.

Transactions that would update employee information can be saved to submit at a later time. For example, submitting an OCHK while an employee is currently a part of a Preliminary run would advance their pay period. This would create an issue when trying to submit a payroll for the pay period that has just moved forward for that employee due to the OCHK. Submitting an ESMT could change the pay parameters currently in use for the employee in the Preliminary run, causing the system to be unable to commit any Preliminary data to the employee. 

Business Process Diagram