PeopleSoft Financials Project

Labor Allocation Module (LAM) Bolt-on

Updated 1/13/03

Purpose

The purpose of the Labor Allocation Module (LAM) is to spread salaries to the proper distributions each pay within the PeopleSoft Financials system.

This application will be a bolt-on application to lessen the impact to future upgrades to the PeopleSoft product. It will be developed in PeopleTools to populate tables in PeopleSoft. This will reduce the payroll accounting entries from multiple account codes from the HR system. Instead the entries will be done within the accounting system. Units around the campus will change the distributions for their employees on a PeopleSoft web page that will feed a PeopleSoft table. The distributions will be done on a percentage basis, not on a dollar distribution basis. The information from this table will then be used to relieve the single default chartfield string and charge employees’ salaries correctly for that pay period. The accounting feed from PS HRMS will go directly to the LAM, where the distribution for each affected employee will be revised to reflect the desired distribution. All other pay entries will pass through this filter application untouched. The output product will be a PS journal passing full payroll accounting transactions to the general ledger.

There will an additional process that will change the Source chartfield of certain employees who are State Funded. The Budget Office will maintain a table that stores the specific chartfield combinations that will need this additional change.

The first stage is the distribution process and will only be utilized for semi-monthly line item employees’ regular salaries. All hourly (including AFSCME), student, overload, overtime, supplements, and S-contract pay will carry the proper PeopleSoft chartfield string through the HR system and on to the general ledger. All pay transactions (both semi-monthly and bi-weekly) will pass through the second state funding process.

Advantages

1. Quicker turnaround time for salary funding changes. Units around the campus will be able to change the distributions on their employees right up until the date that the Journal Generator is run (normally on a few days prior to the pay date), rather than at the beginning of the pay period as is now the case in HR. It would allow the salary distribution change deadline to be as much as two weeks later than the current HR deadline.

2. Relieving the HR system of some of its heavy workload. Input through HR would be reduced by the volume of transactions that are solely salary distribution changes.

3. Reduce the number of retro journals needed to accommodate late notices of award by federal and other sponsors.

4. Clearing Accounts and cumbersome salary JVs used by colleges would no longer be necessary. They would simply enter new distributions in the LAM for each of their employees as needed and the accounting transactions would be processed centrally through Journal Generator.

5. Easier Budget Turnaround for HR. While funding distributions would still have to be collected during the BTA process, only one line of "default" funding would be fed into HR, thus relieving this very busy unit of the need to make funding corrections. HR could concentrate on their main focus – ensuring proper UD personnel policies are followed and processing payroll.

6. More timely information regarding funding distributions than is now the case.

7. With the decision to do matching, it will be easy to add those changes to a distribution file and takes concerns about HR workload and volume out of the decision.

Possible Future Purposes for LAM

Salary Encumbrance/Disencumbrance
System-generated retroactive funding changes. This capability that was lost with PeopleSoft HR.
Using the LAM for Effort Reporting.
Permanent Budget

Disadvantages

1. A distribution must be present for each semi-monthly line item employee paid. A report run from each system once per pay along with a suspense procedure may suffice to resolve this issue.

2. Security for this web page will be required when additional features are added to the LAM for retro salary processing. Extra technical resource time will be needed if existing security cannot be directly utilized.

3. Audit trail reports will need to be developed since the primary purpose for pay distributions relates to direct and indirect costs on federal funds, and all such changes are subject to audit under A-133 and DOD indirect cost procedures.

Labor Allocation Module Specs

Table Specs:

LABOR_ALLOC_EMP

empl_id (char11)

ssn(char9)

dept(char10)

name(char50)

update_date(date)

extract_date(date)

oper_id(char30)

LABOR_ALLOC_DIST

empl_id(char11)

gl_speedtype(char10)

gl_class(char3)

gl_acct(char10)

gl_user1(char10)

gl_pct(numeric3)

LABOR_STATE_APPROP

gl_speedtype(char10)

gl_acct(char10)

gl_class(char3)

gl_source(char10)

Labor Allocation Maintenance Interface

The Budget Office will be responsible for adds/changes/deletes. The JED process will trigger the Budget Office to add and employee to the allocation system. A user written report will determine deletes. They should be able to make a change to any existing employee in the LABOR_ALLOC_* tables. The security for this interface should be limited to the Budget Office.

After selecting Add, the user will be presented with an input for Employee ID.

Screen 1

Employee ID:____________

Validate the empl_ID against the JED form data in Oracle. Validate that the empl_id does not exist in the LABOR_ALLOC_EMP table(empl_id is unique in this table). If valid, then present the user with the following screen.

Screen 2

Employee ID:_________ Last Date of Update:________

Name:_______________ SSN:_______ Department:________________

Salary Allocation

PS Speed Type PS Account PS Class PS User Tag Percent

__________ __________ __________ __________ ___

Total: ___

The ID, name, ssn, department will be populated from the JED Oracle data. The user will then add up to 10 salary allocations for the employee. Validate that each PS chart field is active, PS Speed Type, PS Account, PS Class are required, percents are numbers, and percents add to 100. Update update_date with current date and oper_id of person updating.

The Budget Office will also need to add and delete data in the LABOR_STATE_APPROP table. Maintenance to this table is done on an annual basis, with no change some years. The suggested method for maintaining this table will be an upload of a CSV formatted file. The upload will replace the table each time. Average number of rows for this table is 2000. The validation at upload time will be chartfield values are valid and that each row is unique.

Labor Allocation Campus Interface

The University will use this module to allocate salary across multiple PS department/account combinations. Users will be presented with a search dialogue box for empil_id and name to select a person. Then they will be presented with a page that displays the information on top of Screen 2(empl_id, update_date, name, ssn, dept) as non-modifiable. Under this data, they will be presented with the 10 allocations that exist along with the same allocations in a modifiable format. Users will make their changes under New Salary Allocation.

Existing Salary Allocation New Salary Allocation

PS Speed Type PS Account PS Class PS User Tag Percent PS Speed Type PS Account PS Class PS User Tag Percent

xxxxxxxx xxxxxx xxxxx xxxxxxxx xxx aaaaaaaaa aaaaaa aaaaa aaaaaaaa aaa

Validate that each PS chart field is active, PS Speed Type, PS Account, and PS Class are required, percents are numbers, and percents add to 100. Update update_date with current date and oper_id of person updating. There is no need to have security for this function because they are not able to make a change to total dollars.

HR to GL Interface

The current HR to GL interface will need to be modified to accommodate this new process. The interface will look for people(empl_id) with the following chart field string:

FUND: OPBAS

PROGRAM: INST1

PSDEPT: 00175

PURPOSE: UNIV999999

ACCT: 1269999999