Before Changing PeopleSoft Data
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 in able.harvard.edu.
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 empl 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 Empl 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
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
|Tub & Org
||Whose transaction is it?
|| What is the nature / classification of the transaction?
||Where does the money come from?
||What is the money being used for?
||Tracks discrete components of an activity
||The person or building related to the transaction
For more details about these segments, go to the Chart
of Accounts home page located at Able.Harvard.edu
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.