Change PeopleSoft Data

What HR/Payroll Administrators should know before changing data in PeopleSoft: Object codes, chart of accounts, effective dating.

Understanding Object Code Defaults in PeopleSoft:
Object Codes are numeric accounting labels that describe the nature of the transaction/ dollar amounts that are charged to the General Ledger. They are one segment of a complete costing string, whose components are defined below and defined here.

For payroll payments, object codes describe the nature of the work performed and who is performing the work, for example, "Senior Faculty Salaries + Wages, GENERAL".

Because object codes are specific to employee types and the type of work performed, it is critical that each transaction charged to the object code has these similar characteristics.

To ensure consistency, PeopleSoft has embedded rules to determine the object code for an employee's pay. The rules determine the object code to charge based on the employee class, and in cases other than regular earnings, earnings code and FICA status of the employee.

The object codes for regular (reg) pay for each employee class are defined in Reg Pay Object Codes by employee class.

For object codes for non-reg earnings, refer to the Earnings Code Table available through the attached link. Earning Code Summary. The table defines the related object codes for the employees who are authorized to charge to each earnings code. A description of each object code is available at Able.Harvard.edu. The Earnings Code Summary also defines the pension impact, FLSA impact, applicable tax rates, and fringe rates that apply to each earnings code and related object code. Note that in some cases, more than one object code can apply to an earnings code. Review the object code descriptions to determine which one applies to your employee.

PeopleSoft will choose the correct object code for your transaction. It is not necessary to enter an object code on your request. However, if you would like to validate that the planned object code and other costing components of your transaction are valid in PeopleSoft, you may enter the string in the chart of accounts validator.

Harvard's Chart of Accounts

Chart of Accounts

Segments

Tub & Org

Whose transaction is it?

Object

What is the nature / classification of the transaction?

Fund

Where does the money come from?

Activity

What is the money being used for?

Subactivity

Tracks discrete components of an activity

Root

The person or building related to the transaction

 

For more details about these segments, go to the Chart of Accounts home page.

Understanding Effective Dating in PeopleSoft
Effective dating in PeopleSoft is a frequently misunderstood concept. For HR purposes, an effective date is the date a transaction is to be effective. As such, PeopleSoft allows any date (past, present, or future) to be entered for the effective date of a transaction, including HR and Payroll transactions. PeopleSoft Payroll, on the other hand, is much like your personal checking account in which you can only make payments today or in the future. While you can write a check today with a date last month, the payment will be made in the near future, not the past. The same is true with PeopleSoft Payroll transactions. Any payroll payments will be made in the current pay cycle (if effective date is within or before the current pay cycle) or future pay cycle (if the effective date is in the future). Understanding these differences is critical for accurate payroll accounting.

What this means is that for all newly-entered payroll transactions with effective dates prior to the current pay-cycle, separate retro-active adjustments must be created and entered in the current or a future pay cycle (depending on the date of the adjustment transaction).

If an employee is due retro-active pay, you should typically submit an Additional Pay request through Payroll to pay the employee for the incremental pay he or she should have received prior to the current pay period. This payment will be made in the current or future pay period defined on the request. The exception is for hourly employees whose retroactive pay relates solely to unpaid hours from prior periods. When those hours are approved, they will be paid at the rate in effect at the time of the payroll. Since those hours should be paid at the current, correct rate, an Additional Pay request is not required

If an employee was correctly paid, but payroll was charged to old costing that was updated on a new, but pre-dated transaction, the department must make an adjustment through Harvard's General Ledger for dollar amounts that relate to payroll prior to the current pay period. Moving paid payroll to different costing can not be done through PeopleSoft transactions.

It is the responsibility of departments to ensure that when predating a PeopleSoft transaction, an employee's pay, and/or costing, is adjusted to match the payroll payments and related accounting that should have been made from the effective date up to the first day of the current pay period for the effected employee.