Loading Employee Data

This chapter provides an overview of the loading of historical data and discusses how to:

• Plan your data conversion.

• Load personal and job data.

• Load payroll data.

• Load service data.

• Load account data.

• Move data to a standalone system.

Understanding the Loading of Historical Data

To use Pension Administration, you must load historical data from an employee’s entire career into PeopleSoft tables. You must do this even are already using PeopleSoft Enterprise HRMS.

You must move two types of historical employee data into Pension Administration:

• General information that is not specific to a pension plan, including descriptive data about employees, their job histories, and their beneficiaries.

• Plan-specific information that consists of values for plan components that are calculated according to plan rules. This category includes service accruals, cash balance accounts, and employee contributory accounts. The tables that hold this data are always keyed to a plan and function result.

Payroll data can go into either category. If you load raw payroll information (such as earnings, hours, and contributions), Pension Administration can consolidate that data using consolidation rules that you define. Alternatively, you can load data that you have already consolidated.

Planning Your Data Conversion

This section provides an overview of history data and discusses how to:

• Protect history data.

• Identify the data that you need.

Understanding History Data

History is the period-by-period data produced during periodic processing. Periodic processing produces history for the following functions:

You can view and modify history for the consolidations functions on the pages in the Review Consolidation Results (CONS_HOURS_HIST) component.

You can view history for the accrual functions on the pages in the Review Plan History (PLAN_HISTORY) component.

The history for the accrual functions includes balances for the end of each period. The balances are the accumulation of credits across periods. The consolidation functions do not need balances.

When working with accruals, you can avoid loading the entire period-by-period history and instead load startup balances. A startup balance is the accrual as of a date that you specify.

History data is always loaded into tables that are specific to functions. Startup balances are always loaded into the PA _STRTUP_HISTO table.

See Also

Maintaining Employee Pension Data

Viewing Employee Data

Protecting History Data

Periodic processing has two modes:

• Normal mode.

  In Normal mode, the system adds new history to the existing rows.

• Delete and Rebuild mode.

  In Delete and Rebuild mode, the system deletes all existing history and recalculates data throughout the employee’s entire career. This can be useful in certain situations. For example, if you discover a problem with your calculation rules, you can correct the rules and recalculate everything at once.

  However, Delete and Rebuild mode is risky. If you load history data as part of your data conversion, the system does not have the source data to replace those rows. For example, if you load consolidated earnings but not the raw payroll data that was the source for the consolidated data, the system removes the consolidated data and cannot recreate it because of the missing source data.

Warning! If you load history for a function, take security measures to ensure that people do not have access to the Delete and Rebuild mode during periodic processing.

The service function always runs in Delete and Rebuild mode. This is necessary because ongoing events affect past service accruals. For example, previously accrued service can be forfeited after a break in service. Never load history for service. Always use startup values or load the job history that is the source data for the service calculation. If you load service history instead of the actual job history (hires and terminations, leaves and returns, and other relevant events), the entire history disappears the first time that you run the service function during periodic processing. The lack of a complete job history compromises the system’s ability to produce accurate service information.

Identifying the Data That You Need

Raw payroll data is used in consolidated data. Consolidated data is used in various functions, including service, cash balance accounts, and employee accounts. The consolidated earnings history also supports final average earnings and social security calculations.

Loading both raw payroll data and consolidated payroll history is redundant. Similarly, loading both consolidated contributions history and a startup balance for employee accounts is redundant. The system never uses the consolidated contributions information before the as of date for the employee accounts starting balance.

When planning your data conversion, you can decide which data to load. Payroll data offers the greatest level of detail and thus increases flexibility for recalculation. Starting balances provide the least amount of detail and flexibility. Consolidated data is in between the two.

When you use consolidated earnings for final average earnings or social security, you cannot use startup balances. In these cases, you must use raw payroll data or consolidated data.

Loading Personal and Job Data

Personal and job data that is unrelated to a plan belongs in PeopleSoft Enterprise Human Resources and the Manage Base Benefits business process records.

Conduct your own analysis to determine the data that your plans require. You might use the following tables:

Loading Payroll Data

This section provides an overview of payroll data and discusses how to:

• Determine how much historical payroll data you need.

• Load raw data.

• Load consolidated data.

Understanding Payroll Data

You can load payroll data in one of two forms:

• Raw data about earnings, hours, and contributions that Pension Administration can consolidate.

• Already-consolidated data.

The advantage of loading raw data is that the system performs your consolidations. For example, if an employee in Plan A transfers to Plan B and Plan B needs earnings data that predates the transfer, Plan B cannot use the consolidated data from Plan A. If the raw data is in the system, you can easily use the Plan B consolidation rules. Loading raw data is also advantageous if you make a correction to your method of consolidating the data.

The system does not use raw data during calculations. Data must be consolidated for the system to recognize the information.

If you currently store your payroll data as consolidated amounts, it might be more efficient to load consolidated data.

Determining How Much Historical Payroll Data You Need

Load earnings data for use with the final average earnings (FAE), cash balance accounts, and social security functions.

• For final average earnings, you must load earnings history only as far back as the FAE function checks. For example, if your FAE definition uses only the final five consecutive earnings periods, load only those periods—or a few more, if there’s a possibility that some periods might be ignored.

• For cash balance accounts, if you load a startup balance, do not load earnings history for periods before the startup balance as of date.

• For social security, if you estimate career earnings based on the current and prior periods only, do not load more than those two rows of earnings data.

Load hours data for use with the service function, but only for hours counting methods. If you load a startup service balance, do not load hours data for the periods before the startup as of date.

Load contributions data for use with the employee accounts function. If you load a startup balance for your employee account, do not load contribution data for the periods before the startup balance as of date.

Loading Raw Data

Raw payroll data resides in two places:

• Payroll tables, which are populated by PeopleSoft Enterprise Payroll for North America.

• A set of pension clones, where you can archive the data to protect it from the periodic purging to which the payroll tables are subject.

If you load raw payroll data, do not put the data in the Payroll for North America tables. These tables are managed by Payroll for North America, not by Pension Administration, and they are subject to periodic purging. Instead, load the data into the Pension Administration clones.

During consolidations, Pension Administration first checks the Payroll for North America tables. If those tables do not contain data for the period being consolidated, the system checks the pension clone tables. If the system finds data in the clone tables, it ignores data in the source tables. The system does not compare the data in the two tables; after it determines which tables to use, it ignores the others. If neither set of tables contains data, the consolidation displays zero earnings, hours, or contributions for the period.

Periodic processing enables you to copy data from payroll tables to the pension clones for archiving. In Payroll for North America, you use this process to archive raw data on an ongoing basis.

The data that you need depends on your consolidation definition. For example, if you consolidate hours based on W-2 earnings (which requires you to provide an earnings-to-hours divisor), you need data from the W2_AMOUNTS table.

Note. Consolidated earnings and hours both require PAY_CHECK data as the source of the consolidation accumulate based on date (the earned date, payroll end date, or paycheck date, depending on your consolidation definition).

Loading Consolidated Data

Rather than loading raw payroll data into the system, you might load consolidated amounts. In this case, study the tables where the consolidation processes store their results so that the data you load is consistent with the data that the system’s consolidation processes might create. The following tables contain consolidated data:

Note. When you load consolidated data, the period start and end dates should reflect full periods. For example, if you consolidate by calendar year, the first row for an employee hired in 2001 is dated January 1, 2001, regardless of the actual hire date. (This differs from the way in which the service and account history functions treat the first period.) Use the partial period fraction to indicate the portion of the period that is active.

Loading Service Data

Periodic processing normally adds to existing history data. The service function is unique because it rebuilds an employee’s entire history every time it is processed.

Because of this, never load service history as part of the data conversion. You can:

• Load the job history and the hours data used to calculate service. If you load hours data, you can load either raw hours data or consolidated hours data.

• Load startup balances for all your employees.

Startup data consists of two parts:

• Startup amount

• As of date

The as of date is critical because the service function calculates service only from that date forward. The system adds the startup amount to the calculated amount to determine the total service. During periodic processing, the Delete and Rebuild component of the service function applies only to the calculated amount; the startup amount remains untouched.

An employee’s startup date must not be earlier than the employee’s hire date. Otherwise, the system checks for data for the time period between the startup date and the hire date, and, if no data is available, generates an error.

Warning! Do not load service history during the data conversion. Periodic processing deletes it.

Loading Account Data

Cash balance accounts are based on consolidated earnings. Employee accounts are based on consolidated contributions. To load account accruals, you can:

• Load the raw payroll earnings or contribution data. The system consolidates the data and uses the consolidations to build the account.

• Load consolidated earnings or contribution data.

• Load startup balances for the accounts.

Payroll data offers the greatest level of detail and thus increases flexibility for recalculation. Starting balances provide the least amount of detail and flexibility.

If you load history, load data into the following tables:

The first period in the account history must not have a start date before the initial hire date. For example, if an employee is hired on July 15, 2005, this is the start date of the first period, even if the period is regularly a calendar year. This differs from consolidations, which always start with the normal beginning day of the period.

If you load startup balances, enter a total accumulation and a startup date. You can also provide a credit and interest breakdown of the amount to use as the basis for the running subtotals that the function keeps. For employee accounts, also enter the pretax and posttax breakdown.

As you load account histories, remember:

• If an employee enters a plan in the middle of a period, the period begin date is the plan entry date. For example, if the period is a calendar year and Rose enters the plan on July 1, 2005, the period begin date is July 1, 2005.

• The history must be uninterrupted. Even after an employee leaves a plan, there are rows with interest credits only.

Moving Data to a Standalone System

When you use HRMS, your data is automatically accessible to Pension Administration. Personal and dependent data, payroll data (hours, earnings, and contributions), and action and reason histories are all present. If you modify the database and must retrieve data from a field that you created, a database alias can retrieve that information.

When you use Pension Administration as a standalone system, you also install portions of other PeopleSoft Enterprise applications. Tables and pages for Human Resources, Benefits Administration, and Payroll for North America systems are included in the standalone Pension Administration. However, you do not have the processing modules for these applications. Although you can store and retrieve data, you do not have other functionality offered in these applications.

If you use Pension Administration as a standalone system, you probably have another human resources system. You must transfer data from that system to the HRMS tables. Although everyone should transfer certain information, such as date of birth and date of hire, most of the data that you transfer depends on the data needed for your plan.

Load external data at the time that you run a calculation to ensure that the most current data is available. To load external data for every employee and every calculation, put a user code module directly into the calculation jobstream. If you must load external data only occasionally, use the check box on the calculation page to indicate whether to run the load process.

Alternatively, you can periodically transfer data to Pension Administration so that you do not have to load data at calculation time.