There are no error reports available for this in CHRS.  It is recommended that  campus get this information from the CHRS Reporting tool, QuickSight.

Planned exit dates for Emeritus are campus-specific.  When discussed by the Standardization Team in 2020, many campuses replied they use a date far in the future such as ''12/31/2099', and review annually if update is needed.

Employee Homepage personalization will not be allowed in CHRS. 

Since no personalization will be allowed,  campuses will not be allowed to campus specific work centers

​Retroactive/future changes in job will not be an issue in CHRS. You will be able to make retroactive pay changes and/or position changes in Job. New job records can be inserted between existing job rows without issues. Note that CHRS does use PeopleSoft delivered functionality throughout Workforce Administration, which does validations on all job data entries.​

The most recently acquired degree will populate on the PPT. This is based on the date acquired field (there’s no effective date field in the 9.2 environment). In the event that the date acquired is the same for both Master’s degrees, it will populate the most recently entered row.

There is a last update field that can be queried but there will not be a history log delivered with CHRS

The answer is no.  The Position Pool ID is used in the Dept Budget Tables to setup funding for LCD.

There is currently no approval workflow for the Student Mod.

Student Module does have row level security.

​The transaction will use the current date if you do not enter a new Effective Date in the Mass Changes side of the page.  The values entered there get copied down to the selected employees and the effective date in the individual employee row defaults to system date when one is not entered on the Mass Change page.

The student termination process is optional.  It was designed to auto terminate employees who have not been paid for a specific number of days since hire or employees who have not entered time for a specific number of days. 

The peoplecode reads a table in the Campus Solutions database called STND_CAR_TERM.  It reads two fields – ELIGI_TO_ENROLL and UNT_TAKEN_PRRSS.  For the current term, the student must have a row in this table.  The settings in those two fields are pulled into CHRS.  It does not determine if they are on Academic Probation or Disqualified unless you can tell that from these two fields.

The only parameter is if the student has a row in the STND_CAR_TERM for the current term.  We read two fields – ELIGI_TO_ENROLL and UNT_TAKEN_PRRSS.

​The approver can deny the transaction which goes back to the requester.  The requester can make the changes to the denied transaction and resubmit for approval.  It will go back through the entire workflow approval.  It is not necessary to create a new transaction.  Additionally, employees with the final approver role have the ability to make changes to the transaction themselves for all fields with the exception of Business Unit and Action.

​Campuses can do multiple positions at one time for Reports to and Time Based changes.

On initial entry of transaction, there is one comment box that is for the Requester to add whatever comments they want the Approvers to see. Once the workflow starts, the Requester comment box is still there with the requester comments and a new comment box that is for Approvers comments is created. Both comment boxes are available to both approvers and requesters. As the transaction moves through the approval workflow the process keeps up with each Approvers Comments. The current approver has an open comment box and there will also be a box with a user id and comments from a previous approver