PeopleSoft Pension Administration 9.1 PeopleBook

Understanding Calculation Rules

This chapter discusses:

Calculation rules setup.
Core functions identification.
Modular approach to rules.
Time segments and function results.
Your implementation plan.

Calculation Rules Setup

Pension Administration handles pension calculation rules through 19 core functions. You map plan rules to these functions to construct calculation components for the elements of your plan. You then bring the individual components together to produce a final benefit.

Note. Most pension plans do not use all 19 core functions.

Analysis reveals the ways in which you perform calculations. Effective dating enables you to keep a history of plan provisions through all the changes the plan has seen. Special group processing enables you to match employees to the correct processing rules.

You can use as many sets of rules as you need. You set up rules and employee groups independently, mix and match them, and assign effective dates to the combinations you create.

Core Functions Identification

The three consolidation functions are run only during periodic processing. Consolidations gather payroll data into monthly or yearly buckets that are then available to other functions during calculations. Each of the functions is discussed in a separate chapter.

Modular Approach to Rules

Pension Administration takes a modular approach to setting up calculation rules. Use different modules to establish:

A calculation rule that is based on one of the core functions. This is a definition module.
A calculation rule that is based on who uses the rule. This is a group module.

When you put together a complete rule, you mix and match definitions and groups to specify who uses which calculation method and when.

Illustration of the process to assemble modular rules to create a pension plan calculation, including who uses which calculation method and when

For example, assume that your plan vesting rules change from seven-year step vesting to five-year cliff vesting in 1980. Employees hired before January 1, 1980 can use the better of the two rules; those hired afterwards must use the five-year cliff vesting.

Your complete rules have two effective dates. First, from the inception of the plan until 1980, there's one rule (step vesting) available to all employees. Second, after January 1, 1980, employees hired after the change use the new rule (cliff vesting) while employees hired before the change use the better of the two rules.

You need to set up the following modules:

Vesting definition 1: Seven-year step vesting.
Vesting definition 2a: Five-year cliff vesting.
Vesting definition 2b: Better of the two vesting methods.
Group 1: All employees.
Group 2: Employees hired January 1, 1980 and later.
Group 3: Employees hired before January 1, 1980.

Note. In reality, each of these modules would reference other modules.

Your rule should look something like this, with the effective and vesting dates as in the example below:

Vesting rules example with effective dates and vesting periods

You put all the pieces together on the Function Result page. Function result refers to the complete instructions for calculating the result for a function. Remember, the definition alone isn't enough because several definitions may be used in different situations.

You create function results for all the core functions that apply to your plan. Certain functions normally have just a single function result in the plan. For example, your plan only uses one plan eligibility function result because for each employee, there is only one plan eligibility value.

Other functions may have multiple function results:

If your plan calculates participation service, vesting service, and plan service separately, you would use three service function results: one for each type of service you need to calculate.
Benefit eligibility usually uses several function results: for example, one to determine eligibility for normal retirement, one for early retirement, and one for disability retirement.
The plan may provide more than one benefit amount function, provided by the benefit formula.

Note. During implementation, you must track many modular objects: function results, definitions, and various definition subcomponents. This task is easier if you develop a naming standard for your pension objects. For example, you may want to set aside the first or last characters to identify the object type, ending all function results with "_F" and all definitions with "_D". You may also incorporate a plan code into the name so that you know which plan uses that object. The naming standard has a ten-character limitation.

Time Segments and Function Results

Certain functions sometimes apply different rules over different periods of an employee's career. For example, an employee may have accrued service using an hours counting method until a plan amendment in 1980, then started accruing service using an hours equivalence method. You don't want the system to recalculate the earlier service using the changed rules; rather, you want to add the service accrued under the old rules and that accrued under the new rules. That is, the rules are simultaneously effective, but over different time segments.

The following graphic illustrates the use of rules over different time segments:

Illustration of service function result with different time segments

On the Function Result page, you indicate the applicable time segment using the Start Date and Stop Date fields. The Stop Date for the final time segment is normally the event date, which is the date of separation from service due to termination or retirement.

Only specific functions deal with multiple simultaneously effective time segments:

Function	Example
Consolidated contributions Consolidated earnings Consolidated hours	If consolidation rules change, the consolidated hours, earnings, and contributions for previous years can remain unchanged; the new rules are used only for future periods.
Service	Service accrued prior to the rule change remains unaltered. Additional service accrual is based on the new rules. Results from each time segment are added together.
Cash balance accounts	If the cash balance rules change, the prior balance isn't affected, but future accruals are based on the new rules. Results from each time segment are added together.
Employee accounts	If the employee account rules change, the prior balance isn't affected, but future accruals are based on the new rules. Results from each time segment are added together.
Death coverage factors	If the death coverage rules change, the reduction that the employee has already incurred for coverage up to that point remains and any additional reduction is calculated using the new rules. Results from each time segment are added together.
Participation	If participation rules change, the participation status for prior years remains unchanged. The new rules only apply to future periods.

Other functions don't use time segments to break an employee's career into sections. Therefore, the Start Date and Stop Date fields always use values that define a time segment encompassing the entire life of the plan. For example, all time segments for vesting could use the dates January 1, 1900 to event date.

Your Implementation Plan

Setting up your plan rules is a complex task. During your detailed analysis, you look closely at your existing administration practices.

The analysis should be from the top down. That is, you look at broad functional areas of your rules and map them to the system's 19 core functions. Determine which function results you need and what their processing order is. At the end of this first step, you have a list of the function results you need.

Start with the first function result in your processing order, and analyze the specific plan rules that you are implementing. Continue this process through the entire jobstream. At the end of this step, you have a list of all the definitions and groups you need.

Go back to the beginning and start examining the definition parameters. You'll discover other lower-level modules that are needed. These modules are discussed in "Understanding Pension Variables, Rules, and Tables."

Continue breaking down all the plan components until you have a complete inventory of the modules you need and you understand their interrelationships. After you complete your analysis, use diagrams as a road map for entering the data into the system.

This analysis may have the additional benefit of identifying practices that don't conform to the plan document. It is also an opportunity to codify any administrative practices which are implicit rather than documented.

Note. It is critical to establish the proper sequence for creating the modules so that you have the required objects when you need them.