Understanding Periodic Processes

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.

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.

You can update cash balance accounts as often as necessary; the system includes data as of the process through date that you select.

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.

You can calculate employee account balances as often as necessary; the system includes data as of the process through date that you select.

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.

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.

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.