This document is to provide campus users with a list of questions regarding Time and Labor (TL).
Configuration:
Implementing campuses have an array of tasks to complete. Campuses should refer to the TL Setup Checklist for Implementing Campuses for details.
The TL auto-enrollment process is configurable by campuses and should be reviewed by the campus. Starter queries and enrollment configurations have been provided by CMS, but they can be edited or inactivated as part of campus configuration.
The CO delivers baseline templates in CHRS, but campuses have the ability to create their own templates, as needed.
The only employees that require a work schedule are those enrolled in absence management or using Time & Labor rules which refer to the assigned work schedule (e.g. auto-assignment of ADO).
Yes. Campuses can build and maintain their own TL Rule Programs.
The fields in this region are used to specify the information displayed alongside the employee's name and job title on the Time and Labor Self Service pages.
Currently, in CHRS, the Auto Enrollment process can only assign one value to Taskgroup or Task Profile fields, per workgroup. For campuses that require different values, per workgroup, the following process is recommended.
Implementing campuses must complete this process each time they wish to enable the functionality, as SQL scripts are not applied automatically.
- Campus develops the SQL needed to populate the Taskgroup and/or Task Profile fields.
- Campus submits a ServiceNow ticket to requesting update for Pass. The following fields must be completed:
- Type: Request
- Severity: Campus-Specific
- Category: CMS-CHRS
- Subcategory: Time & Labor
- Assignment Group: CMS-CHRS
-
Short Description:
- Indicate your campus needs to have an update for the Taskgroup or Task Profile Fields that needs to be applied during a Pass (Example: FUL-Taskgroup Update- Wave 1- Pass B)
-
Issue Description:
- Specify the desired Pass with justification.
- Indicate the pass testing should occur.
- Indicate who will be completing the validation.
-
Attachment:
- SQL to be used for updating the Taskgroup and/or Task Profile fields.
- CMS will coordinate internally to have the update applied to HACHRSIT and notify campus through ServiceNow ticket when done.
- The campus completes validation.
- Campus develops the SQL needed to populate the Taskgroup and/or Task Profile fields and tests during a pass.
- Campus submits a ServiceNow ticket to requesting update to occur after MTP. The following fields must be completed:
- Type: Request
- Severity: Campus-Specific
- Category: CMS-CHRS
- Subcategory: Time & Labor
- Assignment Group: CMS-CHRS
-
Short Description:
- Indicate your campus needs to have an update for the Taskgroup or Task Profile Fields that needs to be applied after MTP (Example: CHI-Taskgroup Update- Wave 3- MTP)
-
Issue Description:
- Specify the desired monthly release date, which should align with the second Wednesday following the month of MTP. If a different date is needed, provide a justification.
- Indicate the pass the testing occurred in and who completed the validation.
-
Attachment:
- SQL to be used for updating the Taskgroup and/or Task Profile fields.
- CMS will coordinate internally to have the update applied to production via the CHRS COMR process, which takes place on the second Wednesday of each month, and resolves the ServiceNow ticket.
- Campus submits a ServiceNow ticket to requesting update to occur after MTP. The following fields must be completed:
- Type: Request
- Severity: Campus-Specific
- Category: CMS-CHRS
- Subcategory: Time & Labor
- Assignment Group: CMS-CHRS
-
Short Description:
- Indicate your campus needs to have an update for the Taskgroup or Task Profile Fields that needs to be applied after MTP (Example: CHI-Taskgroup Update- Wave 3- MTP)
-
Issue Description:
- Specify the desired monthly release date, which should align with the second Wednesday of the following month of MTP. If a different date is needed, provide a justification.
- Indicate the pass the testing occurred in and who completed the validation.
-
Attachment:
- SQL to be used for updating the Taskgroup and/or Task Profile fields.
- CMS will coordinate internally to have the update applied to production via the CHRS COMR process, which takes place on the second Wednesday of each month, and resolves the ServiceNow ticket.
- Campus develops the SQL needed to populate the Taskgroup and/or Task Profile fields.
- Campus submits a ServiceNow ticket to request production updates. The following fields must be completed:
- Type: Request
- Severity: Campus-Specific
- Category: CMS-CHRS
- Subcategory: Time & Labor
- Assignment Group: CMS-CHRS
-
Short Description:
- Indicate your campus needs to have an update for the Taskgroup or Task Profile Fields.
-
Issue Description:
- Specify the desired monthly release date, which should align with the second Wednesday of the following month. If a different date is needed, provide a justification.
- Indicate desired production support database to test the SQL update.
- Indicate who will be completing the validation.
-
Attachment:
- SQL to be used for updating the Taskgroup and/or Task Profile fields.
- CMS and the campus work together to identify the appropriate production support database and establish the campus validation timeline.
- The campus completes validation and provides signoff.
- CMS will coordinate internally to have the update applied to production via the CHRS COMR process, which takes place on the second Wednesday of each month, and resolves the ServiceNow ticket.
Campuses should submit the ticket at least 3 weeks prior to the targeted release date. The earlier the submission, the more time there will be for proper testing and validation.
General:
- CHRS is the system of record, it is important that all time entries (including late time) are recorded in PeopleSoft before submitting time for payment in PIMS. Time reported on the timesheet must match the time reported to the SCO.
- Report time worked on timesheets, including late time entries.
- Payable time values are generated according to the CSUC111 rule which rounds payable time as per SCO guidelines. The rounding occurs for each individual date, not the sum of hours worked in the period.
- For AM-eligible hourly employees, follow the late time entry business process to activate a retro trigger for absence management to accumulate the late transaction.
- The Adjust Paid Time process should be used if there is a change in pay that cannot be reflected by correcting the timesheet, otherwise, enter corrections via the timesheet.
Navigation: Manager Self Service > Time Management > Report Time > Timesheet
Employees and timekeepers will report time using delivered timesheet.
- Report time worked on a daily basis for the current pay cycle on the timesheet.
- Types of time to be reported on the timesheet include: Regular, Overtime, Shift, Compensatory Time, ADO, Holiday CTO, Holiday Credit, and HG5/HG6.
Navigation: Manager Self Service > Time Mgmt > Report Time > Timesheet
- All timesheet transactions must be reviewed and approved to ensure accurate payment and balances.
- For managers, the approval tile displays a count of approvals pending action.
Navigation: Manager Self Service > Time Mgmt > Approve Time & Exceptions > Payable Time
Time Admin is automatically triggered to run as time entries are submitted on the timesheet and the time is available for approval immediately afterwards. Time Admin will not be scheduled to run via batch. Campuses can run Time Admin, as needed.
Navigation: Menu > Time and Labor > Process Time > Request Time Admin
- All compensatory time are maintained in Time & Labor and not Absence Management in CHRS. This includes all compensatory time: CTO, ADO, Holiday CTO, Holiday Credit, and HG5/HG6.
- Employees must be enrolled in comp time plan(s).
- Navigation: Menu > Time & Labor > Enroll Time Reporters > Comp Plan Enrollment
- Report all compensatory time adjustments using the timesheet.
- ADO is automatically generated by the system based on employees’ work schedule. ADO is maintain by days, not by hours.
Campus users are to use the Exceptions page to review and resolve exceptions.
Navigation: Manager Self Service > Time Mgmt > Approve Time & Exceptions > Exceptions
All absence eligible employees – those enrolled in absence management in Job Data – or those enrolled in a Time & Labor ADO plan must be assigned to a work schedule. All schedule assignments must align with the employees’ FTE (e.g. a part-time .50 FTE employee must be assigned to a corresponding .50 FTE schedule.) Any employees who are not explicitly assigned a schedule will default to the Standard M-F 40 Hours schedule.
Navigation: Menu > Time and Labor > Enroll Time Reporters > Assign Work Schedule
The TL auto enrollment process is used to automatically set up and update Time Reporter Data for employees. Campuses are responsible for their own setup. Review the starter queries and enrollment configurations delivered by CMS and update, if necessary, to meet campus specific needs.
Navigation: Menu > Time & Labor > Enroll Time Reporters > Process Auto Enrollments
Once the employee submits the time a timeadmin process for that employee is automatically run and Payable time is created. Goes to the designated approver (based on the approval options) for approval.
Hourly employees, including student workers, should enter their hours daily.
The Rule CSUT008 will be delivered in baseline and will automatically set blank TRC rows as "REG".
The hours will not count towards accruals.
Yes, enter on the timesheet. If a correction to accruals is required, perform the late time entry business process to set a retro trigger.
No, the adjust paid time process is only needed if payable time needs to be adjusted. Make changes to the timesheet directly.
Anything entered on the timesheet will require approval as per the campus-defined approval process. ADO created via rules will not require approval.
CTO Time is approved in the Approvals tile. If the time is not showing up in the tile, review the Workgroup as it could be misconfigured before opening a ServiceNow ticket.
They are done directly on the timesheet using the appropriate adjustment TRC.
Job Aids:
The timesheet should be used to correct all prior period entries. The hours worked on the timesheet should reflect the hours reported to the SCO. The adjust paid time process should only be used if there is a change in the pay that cannot be reflected by correcting the timesheet.
Time & Labor entries come in via the TL_PAYABLE_TIME record. The campus then has to run the CSU TL Earnings Distribution process (CSUTL09A.SQR) for that data to get populated into the CSU_TL_ERN_DIST record. From there, Pay Check Create program (CSULCD20.SQR) picks up the Combo Code from the CSU_TL_ERN_DIST record. For Additional Pay, that gets entered on the Additional Pay page into the ADDL_PAY_DATA record, which should also get picked up in the Pay Check Create program (CSULCD20.SQR).
Transactions are routed to the employee’s reports-to position. This routing logic does not account for leave status or other employment statuses. To avoid approval interruptions, it is recommended to proactively set up delegation before any planned leave.
However, for Time and Labor (TL) approvals, the recommended setup is to use Dynamic Groups instead of the reports-to hierarchy.
No, the "Save for Later" functionality is not enabled on Timesheets.
Campus controls the security on what they can see and what they can not see. Row level security for the user is tied to the T&L access tied using a dynamic group that campuses maintain.
Notifications:
No, the manager will not receive an email when time is entered on the timesheet.
No, the manager will not receive an email when time is entered on the timesheet.
No.
The manager will see a number on the approvals tile indicating the number of pending approvals.
No, the employee will not see any notifications on their fluid tiles.
Earliest Change Date (ECD)
The Earliest Change Date identifies the earliest date in an employee’s reported time that still requires recalculation. PeopleSoft uses ECD to avoid reprocessing the employee’s entire time history; only time from the ECD forward is recalculated during Time Administration.
ECD is established when the employee is enrolled as a time reporter. If the employee is not enrolled in Time & Labor, there is no ECD.
The system sets ECD to the earliest relevant date that Time Admin may need to evaluate, typically tied to:
- Time Reporter Data effective date
- Job Data effective date that impacts time reporting
- Hire date
- Rehire date
- Transfer date into T&L eligible position.
- Example #1: An employee hired on 2/2/26 and enrolled in Time & Labor with an effective date of 2/2/26. The ECD will be initially set to 2/2/26.
- Example #2: An employee hired on 2/2/15, was terminated on 3/1/2019. The first row in Time & Labor will have an active effective date of 2/2/15 and inactive effective date of 3/1/2019. The ECD was initially set to 2/2/15. As they reported time and were processed by Time Admin, the ECD was eventually updated to 3/1/19. After being rehired on 2/2/26 and reenrolled in Time & Labor with an active effective date of 2/2/26, the ECD will be updated to 2/2/26.
The auto-enrollment process picks up job data information and creates time reporter data. The creation of the time reporter data triggers the initial ECD.
For implementing campuses, the ECD for converted employees is initially set to the conversion snapshot date of the environment.
PeopleSoft automatically updates ECD when changes occur that could affect previously processed time.
System triggers that update ECD include:
- Reported Time changes
- Adding, deleting, or modifying reported time
- Entering or adjusting punches
- Retro Job Data Changes causing auto-enrollment changes
- Retro Time Reporter Data Changes
- Workgroup gets updated at the employee level
- Retro Workgroup Update at the configuration level
- Ex. Default schedule, Rule program, TRC program
- Retro Schedule assignment changes at the employee level
- Retro Payable Time changes
- Manual adjustments via Adjust Paid Time
The ECD is updated to the earliest date impacted by the change for example:
- Effective date of retro workgroup configuration change
- Earliest date of reported time changes
- Effective date of time reporter data change
Example
On 2/12/26, a student employee’s ECD is 3/1/26. Some time is submitted retroactively for 1/20/26. The ECD will be pushed back to 1/1/26 (the beginning of the January pay period). When Time Admin runs, it will update the ECD forward to 3/1/26 (the beginning of the next period). Time Admin then reprocesses time starting from that ECD forward.
The ECD should not normally need to be manually updated. If a retroactive change occurs that updates the ECD in a way that causes Time Admin to run to no success, the ECD can be manually updated to the earliest date on which new or changed information affects already-processed time.
Common examples of correct ECD dates:
- Effective date of a reported time correction
- Effective date of a schedule change
- Date a Time Admin rule or TRC change took effect
- Date payable time was manually adjusted
Note: Using today’s date may skip required recalculation and lead to inaccurate payable time.
- Earliest Change Date
- Time Administration Status (TA Status)
TA Status Values
Up for Processing
- Employee will be picked up by Time Admin
- This is the appropriate status after manual ECD correction
In Process
- System-controlled status
- Used when Time Admin is actively processing
- Should not be manually selected
- If stuck, the Time Admin process may need to be cleared/deleted
Not Up for Processing
- System-controlled status
- Indicates processing completed
- Should not be manually selected
Correct TA Status is essential because Time Admin will not evaluate time at all if the status is incorrect, regardless of ECD.
Update TA Status and ECD page navigation: Time and Labor > Process Time > Update TA Status and ECD
Most campuses address ECD reactively, when Time Admin errors occur. Avoid making retroactive changes to workgroup configurations, schedule assignments, job data, etc. if you don’t intend to reprocess time. These changes should generally be future dated.
Proactive practices:
- Run queries to identify:
- Active employees with ECDs far in the past
- Misalignment between ECD and Job/Time Reporter effective dates
- Review ECD after:
- Mass schedule updates
- Rule or configuration changes impacting payable time calculation.
- Large retroactive corrections
The TL_TR_STATUS record in Query Manager contains the ECD and TA Status information for employees.
PIP:
All time entries and approvals for the cycle must be complete before the 5th business day. Central CHRS will close the cycle for all campuses on the 5th day each month. New to CHRS, the PIP interface process includes the ability to exclude specific employees from the PIP file.
Navigation: Menu > Time & Labor > CSU Time & Labor > CSU PIP
Yes.
In CHRS, campuses will have the ability to remove rows from the PIP file through the front end. If an update to the PIP file is required, then the best practice is to do it through the front end, rather than modifying the file itself.
Yes, each PIP Process creates a PDF, a CSV and a text file.
When payable time values are generated from reported time values, a rule is run (CSUC111) which rounds the payable time as per SCO rules. The rounding occurs for each individual date (DUR - Date Under Report), and not a sum of hours worked in the period.
Rounding will not occur on reported time (either elapsed or punch), but will round on payable time. The rounding will occur for each payable time entry; on a daily basis, not on a sum of hours.
PIP is the process used to generate the file, but the campus still transfers it to the SCO since the SCO's role remains unchanged.
Reports:
No, the data is displayed on a separate page in CHRS.
Navigation: Menu > Time and Labor > CSU Time & Labor > CSU Run MPC Process
Review the Run Master Payroll Certification (MPC) Reports Job Aid for more information.
The main difference between the two is freshness of data. CHRS Reporting QuickSight will be a day old, while the multi-report will be live. From a CMS perspective, it is preferred that campuses use CHRS Reporting QuickSight as it is optimized for reporting purposes. That said, the campus should use the tool which matches their business process.
The table you will need is CSU_WS_BAL_VW.
TL_COMPLEAV_TBL and TL_COMP_DAY_BAL.
The Comp Time TRCs have been incorporated in to the Absence MultiReports (GRP 186)
No audits will be provided as the "Save for Later" functionality is not enabled on Timesheets.
Yes.
Yes, the list of delivered queries is available in the CHRS Knowledgebase, in a document titled TL CHRS Delivered Queries.
End of Article
