This chapter provides an overview of implementation, and discusses:
Plan setup.
Specific plan components setup.
Miscellaneous plan information setup.
Plan processing order.
Status code creation.
Retiree administration control tables setup.
Data conversion.
The work of implementing Pension Administration falls into three areas:
Defining processing rules
Converting employee data
Testing the implementation
This book focuses on the first area, defining processing rules.
First, determine how to map the existing plans to the Pension Administration system. Take inventory of existing plans, and decide which ones to create in the system. You may decide that you don’t need to set up calculation rules for certain plans.
Even if you are not going to set up calculation rules, you still need to establish the plan in the system if you want to use Pension Administration to administer participants and benefits.
You establish a plan by adding it to a plan table and adding pension-specific information about the plan in the Manage Base Benefits business process of PeopleSoft Enterprise Human Resources.
If you want the Manage Base Benefits business process to deduct pension contributions from employees’ paychecks, there are some additional considerations.
See Also
Entering Benefit Plan Information
This section provides overviews of specific plan components setup, calculation parameters setup, and calculation jobstream setup.
Pension Administration takes a modular approach to setting up calculation rules. Because the modules are heavily interdependent, a key part of your analysis will be diagrams showing the relationships of the modules you need. This is extremely important because it will be impossible for you to create any module until all its prerequisite modules are in place. Use your diagrams as a road map for entering the data in the system.
Note. During implementation, you must keep track of many modular objects. This task easier if you develop a naming standard for pension objects.
See Also
Order the components according to their interdependencies. For example, if you have defined participation as requiring service credit, then the Participation Service component should be placed before the Plan Participation component.
Identify rules you’ve set up to calculate miscellaneous plan information such as the plan’s normal and early retirement dates, the date of first vesting, and the plan’s primary contributory account.
See Also
Creating the Plan Implementation and Plan Aliases
You must give each plan you create a specific processing precedence. The precedence determines the order in which plans run when you perform calculations or periodic processing for multiple plans at once.
Adding plans to the Order Plans page is important for another reason: Many of the fields that prompt against pension plans only recognize plans if they appear in the Order Plans page.
See Also
Pension status codes categorize participants based on pension-related information. Status codes are plan-specific and mutually exclusive. These status codes are more than just informational; they are the foundation for the actuarial valuation extract and for Form 5500 reporting.
See Also
The job record reflects the person’s status as a pension payee. This is the record used to track employee job information; it is used somewhat differently for pension payees.
If you use the Manage Base Benefits business process or PeopleSoft Enterprise Benefits Administration for retiree deductions (for example, to take deductions for retiree medical coverage), then benefits processing must be set up accordingly.
See Also
Establishing Retiree Administration Control Tables
Because pension calculations require a career’s worth of data, you must load a lot of historical data even if you are already using PeopleSoft Enterprise Payroll for North America and PeopleSoft Enterprise Human Resources.
When you move historical employee data into the PeopleSoft system, you are dealing with:
Data that isn’t specific to a particular pension plan.
This is descriptive data about the employees and their job histories.
Data that is plan-specific.
This consists of calculated values for specific plan components, calculated according to specific plan rules. This category includes service accruals, cash balance accounts, and employee contributory accounts.
See Also
Running calculations and periodic processes is the only way to verify that the plan produces the needed results. Be sure to thoroughly test each aspect of the calculations under a variety of conditions: employees with long and short service, with interrupted service, employees who moved in and out of eligibility, and as many other situations as you deem significant. If there are grandfathered rules, or frozen benefits because of regulatory changes, make sure that these are being properly applied as well.
Do not underestimate the importance of thorough testing.