Background

Job “stacking” is a terminology used in the PeopleSoft database to reflect how a campus develops an employment history record for a given employee over time. Typically, when an employee is appointed to their first position at the campus, that initial employment record over time, is expanded to document the various employment events that have occurred with that employee and position. It reflects a linear, sequenced chronicle of that individual’s employment events, e.g., reassignments, reclassifications, promotions, demotions, salary increases, probationary changes, and various other events in accordance with the respective Memorandum of Understanding (MOU) for employees under representation, or California State University (CSU) policy for non-represented employees, as appropriate.

In other circumstances, however, assigning multiple or distinct Employee Record Numbers (ERNs) in the HR database is appropriate due to the nature and/or category of the appointment. These requirements are identified in the “Recommendations” section of this document.

The HR database in PeopleSoft differs from the Personnel Information Management System (PIMS) in a number of ways. Employment records in PIMS had the advantage of adapting the structure applied to state civil service agencies, modified to be CSU-specific for comparable employment related transactions. Agencies and campuses are required to adapt to the structure made available by our pay agent, which further defined how employment records would be stored in PIMS.

The implementation of CHRS will require campuses to standardize certain processes that were created in their separate HR database based upon their specific campus needs, such as the various ways that employment records have been structured and maintained in PeopleSoft which differ from one campus to another.

The goal in the combined CHRS database is to minimize the creation of new ERNs as appropriate, based upon the nature of the position.

Issue

Due to the differences in how campuses stack jobs at their campuses, standardization rules are needed to ensure that systemwide data is uniform and consistent post conversion. Protocols need to be established with respect to student workers, regular employees and special payment types for rostered and non-rostered positions. We must also consider the requirements of our pay agent in making these determinations, to ensure that the job stacking strategy works in harmony and corresponds with uniform state payroll system considerations and requirements.

Security access must be in compliance with the roles and responsibilities established at the campus and systemwide levels. ERNs that are job stacked across multiple employee categories (e.g., Faculty to a Management Personnel Plan [MPP] or California State University Employees Union [CSUEU] to Confidential) provide disclosure of all job history records for that ERN. Campuses must ensure that security access is not compromised.

Analysis

Different job codes have specific requirements. These stacking rules have been determined to minimize the number of ERNs while maintaining data integrity and consistent processes across the CSU.

Recommendations

Creating a new Employee Record when switching campuses

• When an employee is employed at a different campus where no current Job Data record exists at the new campus a new ERN should be created for that employee at the new campus.
• A new ERN should not be created at a campus in the instance where the employee has an inactive ERN. In that instance, it should be reactivated by stacking the new employee instance on the inactivated ERN (as long as the new employee instance and the old ERN does not fall under one of the exceptions below). See rules below for clarification and exceptions.
• Exceptions to the rules above:
  • For a Tenure Track position, the first occurrence should always be a HIR row (due to reporting requirements).
  • An Immediate Pay can be stacked ONLY with another Immediate Pay (PIMS rule)
  • Security issues for decentralized users may necessitate creating additional ERNs. (Student, Immediate Pay).
  • R11 and E99 students should be maintained separately since the R11 transactions will be processed in the Temporary Academic Employee module.
  • There are special stacking rules for E99 employees; see rules below.
  • Department chairs require a separate Job stack. They should not be stacked on the existing Faculty record. The business reasons for this recommendation are to track the chair and instructional faculty (IF) dates of employment separately, to ensure that row-level security is enforced when the IF and chair’s positions are in different departments, and to simplify ad hoc reporting for campus users.

Job Stacking at the Campus Level - Staff and MPP

• At a campus, when an employee is appointed to their first position at the campus, that initial employment record over time, should be expanded to document the various employment events that have occurred with that employee and position. Each employment record, for each category of employee (Staff, Student, Faculty, Immediate/Special Pay) should reflect a linear, sequenced chronicle of that individual’s employment events, e.g., reassignments, reclassifications, promotions, demotions, salary increases, probationary changes, and various other events in accordance with and across respective MOU’s. (The exceptions stated above apply here as well.)
• When the employee has multiple concurrent jobs at the same campus it would be appropriate for the number of job stacks to correspond with the number of active concurrent jobs.
• Job stacking to track department entitlements for Service Salary Based increase eligibility pursuant to Article 12 of the Faculty MOU will be accommodated in CHRS.
• Reporting of hours worked by 10/12 or 11/12 employees during their month(s) off with pay can be placed on a separate ERN as a concurrent position, since they are still active positions.

Job Stacking Student Worker Records

• Student ERNs are structured the same as a traditional employee records in PeopleSoft. Student Job code ERNs should be separate ERNs according to the following Job Code stacks:
  • 1868 (PIMS “rostered”)
  • 1870 (PIMS “non rostered”)
  • 1871 and 1872 (PIMS “non rostered”)
  • 1874, 1875, 1876 (PIMS “rostered”)

• Student worker employment activity should be tracked as a separate ERN. Staff, Faculty, and Immediate Pay should never be stacked on a Student ERN. It is appropriate to distinguish student worker employment relationships from traditional “employee” relationships because of the differences in benefits, retirement, taxability, leave accruals and other criteria. If the student is appointed into a regular CSU position, a new ERN must be established. Student worker records and job stacking should be kept separate from staff/MPP due to the customized original hire date process for 9.2 (CHRS).

Job Stacking for Immediate/Special Pay

• Immediate/Special Pay transactions can be stacked on top of other Immediate/Special Pay transactions and can be used if the Job Record is in inactive status.
• Staff, Faculty, and Students should never be stacked on an Immediate/Special Pay ERN. It is appropriate to distinguish Immediate/Special Pay worker employment relationships from traditional “employee” relationships because of the differences in benefits, retirement, leave accruals and other criteria. Immediate/Special Pay worker records and job stacking should be kept separate from staff/MPP due to the customized original hire date process for 9.2 (CHRS).

Job Stacking for Tenure Track Faculty

For tenure track, the first row should always be a ‘HIR’ row and should always be a new ERN to accommodate the CSU Hire Date process for 9.2 (CHRS).

Job Stacking for Temporary Academic Employees

The requirements below determine whether a Temporary Academic job can be stacked or not (new ERN):

• Entitlement
• Range Elevation Eligibility
• Capturing the employees when departments consolidate
• Stacking rules apply because entitlement counts continue
• Separate ERNs are needed to keep visibility by Department for security reasons

Considerations

General Information

• Standardization requirements will be implemented on a prospective basis. Historical data will be maintained status quo.
• Campuses should accept system defaults versus overriding the system

Cross-Functional Impacts (Positive / Negative)

• Benefits Administration: After discussion with Benefits teams and campus users it was determined there will some implications for Benefits, which may be addressed using a standardized business process for the hire. This would be the same standardized business process that would be used any time a hire is created using a new employment instance. Note: campus users have been using this approach for a long time in PS 9.0, with no negative implications/issues caused for Benefits.
• Labor Cost Distribution: N/A
• Workforce Administration: N/A 
• Time & Labor: N/A
• Absence Management: N/A
• Temp Faculty: N/A
• Recruiting (PageUp): N/A

CHANGE IMPACT

To be filled out by BSA (from Change Impact Tracking log):

The following items will be answered / addressed by Change Management:

1. Areas of potential change resistance to proposed HR process / policy changes?

   If campuses are doing it different then described in this paper, there may be concerns.

2. Potential resource needs in order to plan, engage, prepare, and/or deploy the change?

   If this is a process change, existing staff may need to be trained.

3. Associated costs relative to the scope of the change to requirements requested?

   None.

4. Training needs or if a straightforward change?

   This is a straightforward change with no training requirement.

5. Implication on any other related process / functions?

   This will work with all CSU custom processes including Student Hire, TFE, PageUp, etc.

6. Union impact?

   No reasonably foreseeable impacts within the scope of bargaining identified at the time of review.

REVISION CONTROL

Revision History

Review/Approval History

End of Article