Running Periodic Processes

This chapter provides an overview of periodic processes and discusses how to:

• Run a periodic process.

• View process results.

• Review processing statistics.

• View processing errors.

• Use the Error table.

Understanding Periodic Processes

This section discusses:

• Periodic processing overview

• Calculation processes

• Noncalculation processes

• Housekeeping processes

• Processing order

• Processing rules

• Employee selection

Periodic Processing Overview

Periodic processing encompasses several processes that you use to maintain pension data. Several of the processes mirror individual calculation components. Other processes calculate plan-specific data that is not available through calculations. There are also two housekeeping processes.

See Also

Running a Periodic Process

Calculation Processes

Some of the system's core functions, listed below, have both Calculation and Periodic Processing modes:

• Plan eligibility

• Participation

• Service

• Vesting

• Cash balance accounts

• Employee accounts

During a periodic processing job, these run in the same order that they do during a calculation. This means that plan eligibility runs first, enabling the system to filter out employees who have never been eligible.

Periodic processing creates a plan history that is independent of a particular calculation or termination date. Unlike calculations, periodic processing does not project into the future.

Depending on which function you use and whether you are running periodic processes or a calculation, you sometimes add onto the existing history or sometimes discard it and start a new one.

Plan Eligibility

The Plan Eligibility process always runs by default. If an employee is not and has never been eligible, processing for that employee ends. If an employee is currently or was previously eligible, processing continues, and the individual processes that you select on the Request Process page run.

The Plan Eligibility process builds a timeline with an employee's eligible and ineligible status. Periodic processing adds onto the existing history. The only way to rebuild eligibility history from the beginning is by selecting the Delete and Rebuild Processing mode.

Warning! If you decide to delete and rebuild eligibility history, do not run any of the other processes affected by processing mode at the same time, unless you want to delete and rebuild those histories, too.

Other periodic processes use eligibility history. For example, if your service rules do not award service credit during periods of plan ineligibility, then the Service process uses the eligibility history to determine when employees are eligible and ineligible.

The calculation process does not use the stored eligibility history in calculations, because it recreates the eligibility history from the beginning.

You view eligibility history on the Review Plan History - Eligibility and Participation page.

Participation

The Participation process evaluates employees according to the participation criteria, typically age and service. After an employee meets the criteria, the participation status does not usually change unless the employee loses service due to a break. Therefore, the participation history consists of a single date on which the employee began participating.

Employees can lose participation status due to withdrawal of contributions or breaks in service. If such an employee later requalifies for participation, the history still consists of only a single participation date (as if the earlier participation date never existed).

The stored participation history can be used if it is referenced by another periodic process. For example, the service rules can exclude time before the participation date. The calculation process never uses the stored history, because it recalculates the date from the beginning.

You view participation history on the Review Plan History - Eligibility and Participation page.

Service

The Service process calculates service according to the plan rules. If you have different service rules in a plan (participation service, vesting service, or service credit), the system processes each of the different service components. Running the Service process also automatically runs the Vesting process.

The Service process results are stored as history. The stored history can be used in other periodic processes. For example, cash balance credits can be based on service. The calculation process never uses the stored history, because it recalculates the entire history from the beginning.

The Service process always runs in Delete and Rebuild mode, so each time you run the Service process, the system deletes prior service histories and recalculates the entire history from the beginning. This enables the system to adjust prior periods if subsequent actions have affected the service amount.

You normally update the service history at the end of each service period. You can calculate service more often; the system includes service as of the process through date that you select.

You view service history data on the Review Plan History - Service History page.

Vesting

Whenever you run the Service process, the system automatically runs the Vesting process.

The Form 5500 participant count extract uses the vesting result and the pension status to categorize participants. Therefore, if you plan to run that extract, be sure to run the Vesting process (and therefore the Service process) immediately beforehand.

You view vesting result on the Review Plan History - Plan Information page.

Cash Balance Accounts

Cash balance accounts are the hypothetical employee accounts used in a cash balance plan to represent employees' accrued benefits. Cash balance accounts consist of credits—calculated as a percentage of employee earnings—and applicable interest.

Cash balance results are stored in a period-by-period history. When you run a calculation, the system uses the stored history (that is, periods completed before the event date) and calculates accrual only for subsequent periods. The history never has gaps. Each time that you run the process, it calculates the next period in an employee's cash balance history. For example, if you miss periodic processing for four periods, you must run the Cash Balance Accounts process four separate times to update the history.

Note. Periodic processing handles only one cash balance period per job.

Process cash balance accounts at the end of each cash balance period. There is no point in processing more frequently because the system processes only complete periods.

Cash balance credits are based on consolidated earnings. Always run consolidated earnings for the period before running cash balances. Define your plan rules so that consolidated earnings appear earlier in the calculation job flow. If you do this correctly, you can run both processes in the same job and consolidations run first.

You view cash balance history data on the Review Plan History - Cash Balance History page.

Employee Accounts

Employee accounts track money that employees have contributed toward their pension benefits. Employee accounts consist of credits—determined by consolidated contributions—and applicable interest.

Employee account results are stored in a period-by-period history. When you run a calculation, the system uses the stored history (that is, periods completed before the event date) and calculates accruals only for subsequent periods. The history never has gaps. Each time that you run the process, it calculates the next period in an employee's account history. If, for example, you miss periodic processing for four periods, you must run four separate periodic processing jobs to update the history.

Note. Periodic processing handles only one employee account period per job.

You process the history at the end of each employee accounts period. There is no point in processing more frequently because the system processes only complete periods.

Employee accounts are based on consolidated contributions. Always run consolidated contributions for the period before running the Employee Accounts process. Define your plan rules so that consolidated contributions appear earlier in the calculation job flow. If you do this correctly, you can run both processes in the same job and consolidations run first.

You view employee accounts history data on the Review Plan History - Employee Account History page.

See Also

Viewing Plan Information

Viewing Eligibility and Participation Information

Viewing Service History

Viewing Cash Balance History

Viewing Employee Account History

Noncalculation Processes

Three processes calculate plan-specific data that is not part of the normal calculation job flow:

• Plan Dates.

  Plan dates are aliases that are resolved during the calculation, but by running them through periodic processing, you populate inquiry pages to access the results even without a calculation.

• Pension Statuses.

  Pension statuses are not processed during a calculation; therefore, it is important to run these processes regularly so that the results, which the calculation uses, remain current.

• Consolidations.

  Like pension statuses, consolidations are not processed during a calculation; therefore, it is also important to run these processes regularly so that the results remain current.

Plan Dates

The Plan Dates process always runs; you cannot select whether to run this process.

Your plan implementation includes aliases that establish the dates on which employees reach:

• Normal retirement age

• Early retirement age

• First vesting

You define these on the Plan Aliases page.

Updating plan dates determines the appropriate dates, based on your definitions. These dates are displayed on the Review Plan History - Plan Information page.

Pension Statuses

Pension status codes categorize participants, based on pension-related information. They are plan specific and effective-dated, enabling you to track an employee's changing status in a plan over time. These statuses are more than just informational; they are also the foundation for the actuarial valuation extract and Form 5500 extracts.

You use periodic processing to maintain the pension statuses for active and terminated employees. You manually update the status when you prepare payments. After you start paying benefits to your pension payees, the payment process automatically maintains pension statuses.

Periodic processing maintains the following pension statuses:

• ANP: Active, not yet participating.

• APR: Active participant.

• AVS: Active, accrue vesting only.

• ANS: Active, not accruing service.

• A70: Active, over age 70 1/2.

• TNV: Terminated, not vested.

• TDF: Terminated, deferred benefit.

Periodic processing evaluates the pension status only for employees with one of these statuses or with no recorded status. Individuals who receive, are about to receive, or have finished receiving pension payments are not affected by status code periodic processing.

If pension statuses are based on the results of service or participation, run those processes during the same job.

Run pension statuses before producing the actuarial valuation extract or the PASPC01 - Form 5500 Participant Count report. The PASPC01 report relies on vesting information and pension status. Vesting runs automatically during periodic service processing; therefore, service processing is the other prerequisite for Form 5500 reporting.

You view service pension status data on the Identify Pension Status page.

Consolidations

A pension calculation uses vast amounts of historical data. Earnings histories, for example, can cover 20 years and more. If every calculation involved looking up each paycheck that an employee received during the period, processing would not be very efficient. You would also have to keep all that data available indefinitely, rather than eventually archiving it.

A more efficient way to deal with this data is to use the periodic Consolidation process. This gathers paycheck data and stores monthly or yearly totals. By separating the Consolidation process from the rest of the calculation, you can schedule this time-consuming operation for a convenient, off-peak time.

Your calculation accuracy depends on the availability of up-to-date consolidation information from periodic processing. The following are suggestions for handling consolidations:

• Keep consolidations current.

  When you produce year-end benefit statements, always run your calculations after running consolidations.

  When you run individual calculations, particularly final calculations, run ad hoc consolidations beforehand so that the very latest payroll information is included. If you run calculation estimates based on projected hours and earnings, it is not as important to consolidate first; the system starts the projection with the last available data. However, still use as much actual data as is available.

• Manage the final consolidation period.

  Calculations use the consolidation history up to, and including, the consolidation period that contains the event date (the date of termination or retirement).

  For example, suppose you consolidate yearly. If Gilbert terminates on November 12, 2006, his calculation has access to consolidated data up to December 31, 2006.

  If Gilbert's final paycheck is dated November 30, 2006, data from that check is available as long as you process his consolidations again after the payroll information is recorded in the PeopleSoft Payroll for North America tables. However, if the check with his fourth quarter commission is dated January 15, 2007 and if you consolidate based on the check date, that final paycheck data is stored in the 2007 consolidation period. Because Gilbert terminated during the 2006 period, that data is not considered in the calculation. In this case, you might want to manually override the consolidation history.

  If you allocate earnings based on the earned date, then the bonus check data goes into the 2006 consolidation and you do not have to use a manual override. However, you must still run consolidations after the payroll run.

• Rebuild consolidations.

  Consolidations produce effective-dated results. Each effective-dated set of results contains multiple periods. By effective-dating the results, you can rerun consolidations without overwriting existing results. This is useful if, for example, you corrected or otherwise altered an employee's payroll data or your calculation rules, but you want to keep the prior consolidation results because you distributed benefit statements based on those results.

  Alternatively, you can reconsolidate and remove the earlier results if you do not need the earlier results.

  Periodic processing's normal mode is to continue to add segments to the existing effective-dated history. Use either a Delete and Rebuild mode or a Create New Consolidations mode when you set up a periodic job.

See Also

Viewing Plan Information

Maintaining Pension Status Codes

Adding Plan Alias Parameters

Running a Periodic Process

Maintaining Consolidated Payroll Data

Housekeeping Processes

The Payroll History and Delete Calc Results (delete calculation results) processes do not impact calculation results. They are housekeeping processes that help you manage your data.

Payroll History

The Payroll History process copies payroll data for each eligible employee from payroll tables (which are subject to periodic purging) to pension tables, where you keep the data available for future consolidations or reconsolidations. Only data that is more than one year old is copied.

The process copies data from payroll tables to pension tables, as follows:

Delete Calc Results

The Delete Calc Results process permanently deletes results for calculations that are not specifically protected from deletion and that have a deletion date earlier than the periodic processing date. The deletion date is part of the calculation inputs.

You use the Define Calculation - Main Page to delete results.

See Also

Setting Up Employee Information and Processing Parameters

Understanding the Processing Order

When you run multiple processes in one job, the processes run in the following order:

1. Calculation functions and consolidations (the order comes from the plan implementation).

2. Pension status codes.

3. Plan dates.

4. Payroll history.

5. Calculation deletion.

Note. You cannot run a periodic process if you just deleted calculation results. You can run the delete process only if you also run other processes in the same run.

Processing Rules

Periodic processes rely on plan rules that you create. Rules for calculation functions, consolidations, and pension status codes are set up on definition pages and applied on the Function Results page.

The following are the navigational paths to the definition pages:

Note. All of the processes except Pension Statuses use rules that are defined on the Function Result - Function Result page.

See Also

Setting Up Function Results

Setting Up Earnings Consolidations

Setting Up Hours Consolidations

Consolidating Contributions

Calculation Processes

Using Pension Statuses

Employee Selection

Use periodic processes to maintain data about your active employees:

• Pension statuses.

• Consolidated payroll information.

• Service accruals.

• Balances for cash balance accounts and employee contributory accounts.

Your processing population should always include all of the active employees currently participating in a plan.

You might also need to process active employees who are no longer plan participants. For example, if a plan calculates vesting service based on all hours worked at your organization, not just hours worked while eligible for the plan, you must continue processing consolidated hours for employees who transferred out of the plan due to a job change. Conversely, if an employee transfers into the plan, you must retroactively process consolidated hours for the time spent at your organization before the transfer.

Sometimes you must also run processes for inactive employees. In particular, if employees receive additional pay after their retirement or termination date (vacation pay, bonuses, commission, or any type of deferred compensation), you must ensure that additional earnings, hours, and contributions are included in the consolidation history. Then, ensure that the consolidated information is included in service, cash balance, and employee contributory accounts. Therefore, you might continue processing employees who are no longer active, at least for a short time after they separate from service. If you have started paying pension benefits based on an earlier calculation that did not incorporate this information, you must recalculate the benefit, adjust the pension payments accordingly, and make retroactive payments for previous underpayment.

Running a Periodic Process

This section lists the page used to run a periodic process and discusses how to run a periodic process.

Page Used to Run a Periodic Process

Running a Periodic Process

Access the Request Process page (Pension, Periodic Processes, Request Process, Request Process).

As of Date	Because plan rules are effective-dated, the as of date identifies the appropriate plan rules to use. Typically, this is the system date, but if you rebuild the history using past plan rules, you can change this. If you use a date other than the system date, Pension Administration still uses the system date as the process-through date.
Periodic Cycle	Select Annual Cycle, Monthly Cycle, or Quarterly Cycle. The system compares this date to the system date to determine the last complete period that it can process. Some processes produce results only for complete periods; other processes produce results for partial periods.
Processing Mode	The periodic processing mode that you select affects only the processes displayed in this group box. Normal Processing: Adds new rows to the current history. Delete and Rebuild: Deletes the existing history and builds new rows, beginning with an employee's original hire date. Consolidations, which effectively date the rows in the history, use the hire date as the effective date for the newly built rows. Use this option if you made corrections to an employee's personal or payroll data, causing the old history to be invalid. Warning! Do not use Delete and Rebuild mode if the history contains information that was loaded at implementation time, and thus cannot be recalculated based on other data stored in the system. Create New Consolidations: Applies only to the three consolidation processes. You typically do not run other processes when you select this option, but if you do, they run in Normal Processing mode. This option leaves the existing consolidation history intact while creating a completely new set of history data. The effective date of the new data is the as of date (which is not necessarily the current date). This option enables you to keep a record of the previous data while generating new values based on corrections to either plan rules or employee payroll data. Note. If permanent overrides are present in the current consolidations, you cannot use Delete and Rebuild or Create New Consolidations mode. You must first remove the overrides.
Population	Select the employee or employees to include in the process: All Employees Individual: An Empl ID (employee ID) field appears, in which you identify the individual. Pre-defined Employee List: A List Name field appears, in which you enter the name of the list to process. A list is a set of employees identified by their employee IDs. Create employee lists online by selecting Calculation Group List. However, if you have large populations of employees, populate this page using an SQR or other batch process, rather than manually entering individual employee names and IDs. Pre-defined Group: A Group Name field appears, in which you enter the name of the group that you want to process. A group is a set of employees identified by criteria that they must meet. You create groups for periodic processing on the Group Definition page. You construct group definitions through custom statements. These can become complex, so read about custom statements before attempting to create a group. When you use a group, the system evaluates each employee in the system against the criteria to determine whom to process. This is a very slow process, and PeopleSoft does not recommend that you use it on a regular basis. Instead, use predefined employee lists, which process the employees on the list without evaluating other employees. Note. List processing is much more efficient than group processing. A group defined as all employees belonging to Plan A takes exponentially longer to process than a list consisting of the exact same employees. It is worthwhile to use SQRs to create and maintain lists for periodic processing. For example, to process all employees who are paid monthly, do not create a group. Instead, create an SQR that selects employees who are paid monthly and creates a calculation group list consisting of those employees. Run that SQR again before each periodic processing to keep your lists up to date.
Plan	Select the plan to run.
All Plans	Select to indicate that the system should complete processing for all plans. When you enter an individual plan in the Plan field, you can no longer select this check box.
External Employee Data	Select this check box to load data from an external human resources system using your own user-coded data transfer. Use this option if you have a standalone system. If you check this option, the system executes your data-loading module before running individual processes.

Select Processes and Processes affected by Mode

These group boxes lists the processes that you can run. Three periodic processes do not have check boxes: Plan Eligibility and Plan Dates, which always run; and Vesting, which runs whenever you run the Service process.

Processes that are affected by mode are as follows:

Running the Process

Click the Run button to run this request. Process Scheduler runs the Periodic Processing process at user-defined intervals. Periodic processing typically runs on the server. Select Batch Periodic Process Program and click OK to put the job into the Process Scheduler queue.

Use the Run Recurrence parameters to schedule regular recurrences of your periodic processing.

See Also

Using Custom Statements and Spouse Eligibility Statements

Understanding Periodic Processes

Viewing Process Results

To find consolidation results, use the Review Consolidation Results component. There you can also update the data by entering overrides. For example, if there were errors in the original payroll data, you can override the consolidation, rather than correcting the data in the payroll tables (to which you might not have access) and rerunning the process.

To view all other results, see the Review Plan History component. These results are not editable. However, you can enter manual adjustments for employee accounts, cash balance accounts, and service by selecting Update Employee Plan Data. Adjustments are incorporated into the history during the next periodic processing run.

See Also

Maintaining Consolidated Payroll Data

Maintaining Employee Plan Data

Viewing Plan-Related Information

Reviewing Processing Statistics

This section lists the page used to review processing statistics and discusses how to review processing statistics.

Page Used to Review Processing Statistics

Reviewing Processing Statistics

Access the Review Process page (Pension, Periodic Processes, Review Process, Review Process).

Run Date and Periodic Run Status	Indicates whether the job ran and whether it was completed successfully.
Employee ID	Displays an employee ID and name, a group name, a list name, or an indicator that you processed all employees.
Employees with Errors	If this text box is empty, then there were no errors. If there are employees with errors, research those errors on the Review Processing Messages page.

Next to each of the individual processes that are available during periodic processing, the system displays Y (yes) or N (no), indicating whether you ran that process.

Note. The process instance appears at the bottom of the Periodic Process page while the process is running.

Viewing Processing Errors

You view processing errors on the Review Processing Messages page. To view periodic processing errors:

1. In the Process Instance field, enter the process instance displayed at the top of the Review Process page.

2. Select the Show Program Names check box if you want to see the name of the COBOL program that issued each message.

3. Click the Search button.

   All processing errors for the selected job appear in the Messages group box. The DateTime / Program Name field includes the name of the COBOL program (if you selected the check box).

   Each row also includes a text box containing the error message. The employee ID and other identifying information appear at the end of the message.

4. Click the More button next to the message to view additional explanatory text.

See Also

Reviewing Processing Statistics

Viewing Calculation Messages

Using the Error Table

When periodic processing encounters erroneous or missing data for an individual, it stops processing for that individual and continues with the next available individual. Examples of data errors include:

• Missing date of birth

• Missing date of hire

• Unresolved date alias

When data errors occur, the system writes a row of data to the PS_PA_EE_ERR_TBL table. This table contains seven fields:

• EMPLID

• BENEFIT_PLAN

• ASOFDATE

• RUN_CNTL_ID

• PGM_NAME

• PARA_NAME

• ERR_MSG

You can use this information to troubleshoot and correct the data error. After the data is corrected, you can delete the rows in PS_PA_EE_ERR_TBL and rerun periodic processing for the affected individuals.