The purpose of this document is to provide users with responses to frequently asked questions about different aspects of the Consolidation and Upgrade of Human Resources (CHRS) 9.2, application integration, impacts to integrating with Campus Solutions (CS) 9.2 and Common Finance System (CFS) 9.2.
Database Maintenance
When CHRS database is down for upgrade, maintenance, application of MPs, Wave implementation (several days) or some other reason, specific steps are taken to ensure minimum impact to the CS and CFS environments.
- CMS in CHRS will review both Synchronous and Asynchronous Messages to confirm NO errors
- CMS will work directly with CO Tech Services for CHRS to have
- All job processes PAUSED for ALL Campuses
- The campus’s production CS environments temporarily connected to a false CHRS production environment through a DB link. (Note: The CFS environment will remain unconnected)
- To use “lock and unlock” scripts to prevent all employees/POIs from accessing CHRS during the maintenance.
- Campuses will need to communicate to campus employees/POIs about the upcoming maintenance for CHRS and encourage all employees/POIS to make any personal data updates in CHRS prior to the maintenance.
- In CS, campuses will need to:
- Pause Automated Processes (BUSN Email Previsioning, Schedule Jobs, etc.)
- Review both Synchronous and Asynchronous Messages to confirm NO errors
- In CFS, campuses will need to:
- Review Asynchronous Messages to confirm NO errors
To ensure that the campus’s production CS environment is not impacted by the CHRS maintenance. Without the connection the campus’s production CS environment would have functionality that would fail and impact the student population.
Yes, the CHRS Non-PRD Clone Schedule is located here.
The following would be impacted:
- Assigning instructors to classes
- Work study processing.
- Personal Data cannot be saved in CS-Admissions will not function.
- Student Center (baseline may need a modification to address this).
The following would be impacted:
- Adding / updating ChartFields: Fund, Account, Program, Project, or Class
- Journal generation of HR data from the HR_ACCTG_LINE table which published the journal ID back to CHRS
- Messages will error out and Campus IB Administrators will need to resubmit the messages when HCHRPRD IB is back up
If the CHRS database is down, then a notification will be sent to the campuses and no Asynchronous or Synchronous messages will go in or out of CHRS.
Yes
When a CS campus is down for upgrade, maintenance, application of MPs or some other reason, specific steps are taken to ensure that only the campus going through the maintenance is impacted.
- Campus will need to provide “lock and unlock” scripts for both employees and POIs. The “lock and unlock” scripts will need to be for both CHRS and CS environments. The “lock and unlock” scripts will need to be provided to the Upgrade Team.
- Campus will be responsible for communicating to their employees/POIs and shared employees/POIs about the upgrade.
- Inform active shared employees or shared POIs with a connection and/or relationship to other CHRS campuses
- CMS will work directly with CO Tech Services for CHRS to have an update made to the “URL Maintenance Page” for the campus going through the CS upgrade to prevent the campus employee/POI and shared employee/POI from making personal transactions updates during the downtime.
- CMS will work directly with CO Tech Services for CHRS to the following three job processes during CS Solutions PeopleTools Upgrade window will be PAUSED for ALL Campuses
- CSU Employee Refresh
- CSU POI Status Update
- CSU Workstudy Data Refresh
A variety of locations through CS will fail without the DB link from CS. For example
- Add/Update Person
If the CS database is down, then no Asynchronous or Synchronous messages will go in or out of CS.
When a CFS is down for upgrade, maintenance, application of MPs or some other reason, all CHRS DB Links will fail and all Ayshcrnonous messages will go into a queued state until they can be resubmitted.
The CHRS App Dev team will be responsible for resubmitting all Ayshcrnonous messages in CHRS when able.
All CHRS DB Links will fail and all Ayshcrnonous messages will go into a queued state until they can be resubmitted. The CHRS App Dev team will be responsible for resubmitting all Ayshcrnonous messages in CHRS when able.
Database Clones
Yes, CHRS will have daily clones of production, Sunday through Thursday. Campuses can learn more about the clones by visiting the CHRS Non-Production page.
CMS will connect the Sunday CHRS Production Support databases (H*CHRSPA/H*CHRPSB) to an internal CS database only. All other CHRS production support databases will not be connected to a Campus CS database unless a ServiceNow ticket is submitted by the campus.
Follow the steps noted in the Requesting CHRS environment to connect to CS environment Job Aid.
Yes! CHRS production support database will never be connected to a Campus CS database unless a ServiceNow ticket is submitted.
Yes
No
Submit a ServiceNow ticket.
Integration Functionality
Integration is a one directional sync between CHRS and CS. This means that Bio/Demo will go from CHRS to CS, but not from CS to CHRS. The only data that CS will send to CHRS is the Campus Empl ID and BUSN email.
- Understand that integration is a one directional sync between CHRS and CS. This means that Bio/Demo will go from CHRS to CS, but not from CS to CHRS. The only data that CS will send to CHRS is the Campus Empl ID and BUSN email.
- Keep in mind that CHRS has established standardized values that must be present in CS, and it is your campus's responsibility to ensure they are added.
Review all areas where values are used and determine retrofits. This would include provisioning tools, Search/Match (gender, birthdate) and other third parties that utilize unsynced bio/demo data for faculty/staff. Ensure all CHRS bio/demo types listed above exist on field or translate tables in CS and are active.
- Name Type
- Name Suffix
- Name Prefix
- AddressType
- Phone Type
- Email Type
- POI Type
It is the campus’s responsibility and should be done before their Pass A.
All CHRS standardized configured types will be synced to CS (i.e. Name, Address, SSN, Phone, Date of Birth, POI Type, etc.)
The only data that CS will send to CHRS is the Campus Empl ID and BUSN email.
- Gender
- Emergency Contacts
- Date of death
- Marital status
- Military status
- Disability
- Disability accommodation
- Ethnicity/Diversity
- Citizenship
- Passport
- Visa/permits
- ITIN
Yes.
The CHRS Library has a full list of the standardized values. However, for ease of access, we have included the values below that are finalized as of 11/5/2021.
- BUSN
- CELL
- FAX
- HOME
- OTR
- PGR1
- BUS2
- TDD
- HOME
- OTHR
- HOME
- OFFC
- PRF
- PRI
- PharmD
- Esq
- MD
- PhD
- I
- II
- III
- IV
- V
- CPA
- DC
- DDS
- DMD
- DVM
- EdD
- JD
- Jr
- OD
- OMD
- PE
- RN
- TTEE
- Sr
- VI
- VII
- VIII
- ADM
- CADT
- CAPT
- COL
- CMDT
- CDR
- Dr
- Fr
- Jdg
- LT
- LCDR
- MAJ
- Miss
- Mr
- Mrs
- Ms
- PRES
- RABI
- REV
- Sr
The ONLY data that CS will send to CHRS is the Campus Empl ID and BUSN email.
CHRS is the system of record for preferred name for faculty, staff, and student workers. Preferred name updates will sync from CHRS to CS. No updates from CS will go to CHRS.
Student workers who update their preferred name in Campus Solutions will not update CHRS. Student workers will need to update their preferred name in CHRS also.
The employee must be active for the information to feed from CHRS to CS. If the employee is active at multiple campuses and their personal data is updated for one of the values that integrates from CHRS to CS, then it will update all CS environments the employee is actively associated with and not just the primary campus.
- Baseline delivered integration broker messages between CS (updated via Add/Update a Person) and CHRS will update this value on the PSOPRDFN table but does not update the CHRS Email bio/demo value. Updating Business Email on CHRS via Self Service or Bio/Demo is disabled.
- Business Email (BUSN email type only) will be sent from CS to CHRS over to the PSOPRDFN table as the EMAILID.
In PSOPRDEFN table located in the User Profile.
For provisioning, campuses should review usage of Business Email. Integration from CS to CHRS for the Business Email will only work if the Business Email in CS is updated on the “Add/Update a Person” component and not the Electronic Addresses component.
In CHRS, the PSOPRDEFN table houses the BUS email type for individual campus User IDs. This value is populated by Campus Solutions campus provisioning when the BUSN email type from PS_EMAIL_ADDRESSES is populated (or when manually updated on Campus Solutions’ Add/Update a Person)
No, Business Email Addressed cannot be created/updated in Modify Person.
The following CS tables should the following value:
| Campus Solution (CS) Table Name | Business Email Value |
| PS_EMAIL_ADDRESSES | BUSN |
| PSUSEREMAIL | BUS |
No, the Business email address does not go from CHRS to CS, it only goes from CS to CHRS.
| Scenario: | CS Tables Update | CHRS Tables Updated | |
| 1 | CS Business Email Address Inserted/Updated in Bio-Demo | PS_EMAIL_ADDRESSES (BUSN) and PSUSEREMAIL (BUS) | PSOPRDEFN and PSUSEREMAIL (BUS) |
| 2 | CS Email address Updated in PSOPRDEFN | PSOPRDEFN and PS_EMAIL_ADDRESES (OTH) | N/A |
| 3 | CHRS Email Address Updated in PSOPRDEFN | N/A | PSOPRDEFN and PSUSEREMAIL (BUS) |
For the Business email address, only the Add/Update a Person page in CS will update the PSOPRDEFN in CHRS.
| CS Page Name | Navigation | Updates PSOPRDEFN in CHRS |
| Add/Update a Person | Menu > Campus Community > Personal Information > Add/Update a Person | Yes |
| Electronic Addresses | Menu > Campus Community > Personal Information > Biographical > Addresses/Phones > Electronic Addresses | No |
The code is in CSU_CHRS_INTEGRATION.Provisioning.ProvisionIntegrationOneID to send an updated Business email in CS to CHRS
Yes, all faculty/staff/POIs created in CHRS will exist in Campus Solutions/
There is no different functionality between creating and entering someone new directly in Job Data verses creating someone new and giving them a POI. Both scenarios only send the BIO/Demo details to CS, and it is up to the campus to determine they need additional information through a DB link for a provisioning process (i.e., a User Profile in CS, a BUSN email, a specific report, etc.).
Yes, when a CHRS employee and/or POI is created on the CS side, another student POI Type of 0009 “CS Person” will be auto created during the creation of the CS EMPLID.
Yes, however the POI Type is only visible in CS under the CSU ID Search page.
Yes, the POI Type and description should match exactly.
The user will appear on the CS side with a “Future Hire” POI Type and not the POI Type they were created with in CHRS. A User Profile will NOT get created in CHRS side.
The key is that the POI Type must at least exist on the CS side for the integration to be successful. If an inactive POI Type is used in CHRS, the integration process will still be successful, and a User Profile will be created in CHRS.
The CHRS Library has a full list of POI Type and how they will convert under the CHRS Data Dictionary Section.
No, if a faculty/staff/POI is created in CHRS for one campus, then only that campus CS environment will receive the created faculty/staff/POI.
Nothing will happen. The new campus will have a User Profile created in CHRS, and both CS environments will be updated with the Bio Demo changes.
If an employee and/or POI exists at multiple campuses and a change is made to their BIO Demo, then certain campus CS environments are updated. Use the chart below to see the different scenarios.
| Campus 1 | Campus 2 | CS Environment Updates |
| Active POI Only | No Association | Campus 1 |
| No Association | Active POI Only | Campus 2 |
| Active Job Record | No Association | Campus 1 |
| No Association | Active Job Record | Campus 2 |
| Active Job Record | Active POI Only | Campus 1 and Campus 2 |
| Active Job Record | Active Job Record | Campus 1 and Campus 2 |
| Active POI Only | Active POI Only | Campus 1 and Campus 2 |
| Active Job Record | Inactive POI Only | Campus 1 |
| Inactive Job Record | Active POI Only | Campus 2 |
| Active POI Only | Inactive POI Only | Campus 1 |
| Inactive Job Record | Active Job Record | Campus 2 |
An Unknown POI Type is created when the process of creating the user as a POI or in Job Data was not fully completed. This can occur through CHRS Recruiting or by manual entry. For example, a user entering a new employee manually on the Add a Person page presses save and exits the page before completing the Organizational Relationship section.
Once an Unknown POI Type is created, the IB process will fail, and a User Profile will not to be created on the CHRS side. To resolve this, the campus will have to either create the user directly in Job Data or add another POI Type to the user. Once that is done, the IB process will be successful and a User Profile on the CHRS side for the User Profile to be created. There are some cases where the campuses will not be able to resolve the Unknown POI and will need to open a ServiceNow ticket.
A POI can be backdated if the required date is the same as the Effective Date of the Name and does not have associations with other campuses. However, the integration will send the bio/demo details to CS will the current effective date.
No. POIs who exist in multiple campuses cannot be backdated when POIs are created in the CHRS database. They will be locked by SETID and will be synched with the campus to which it has been assigned – by the SETID / Department. Each campus will see their own POIs assigned by campus departments.
No, CS will always have a current effective date regardless of what has been entered in CHRS.
No. The CHRS System does not allow for future dated entry.
The User Profile Role will no longer be synchronized between CHRS and CS. When a person is created in CHRS, their User Profile will not be automatically created in CS.
Roles assigned in User Profiles will not sync between CHRS and Campus Solutions. Campuses that rely on roles syncing will need to review impacts/alternatives to business processes.
The persons will have one ID in CHRS and different IDs in CS environments. In CHRS, the CS ID is found on the User Profile Page with a prefix of the campus code found on COSAR Table 01. Persons existing in multiple CS campuses will have multiple User Profiles in CHRS.
During the implementation conversion everyone receives a User Profile, except for those that are deceased. After conversion everyone receives a User Profile, if one needs to be deleted then a ServiceNow ticket is required.
Yes.
In CHRS, when an employee is created, a CHRS ID is generated, and sends the information to Campus Solutions, where a Campus Solution ID is generated. The generated Campus Solutions ID is then, sent from CS to CHRS with the CS ID prepended with the two digit campus code which is stored in PSOPRDEFN in CHRS as the OPRID.
In CHRS, once a User Profile is created through integration, it cannot be recreated. This means, that a User Profile must remain connected to the employee even if they are no longer connected to that campus. If the User Profile is deleted, it would have to be manually recreated.
The only time a User Profile can be deleted, is if it is related to a duplicate.
No! A User Profile is NOT automatically created in Campus Solutions. If campuses want an employee/POI to have a User Profile in CS they either need to manually create or have a process established that creates user profiles in CS.
ID Search
- In CHRS, the CSU ID Search will only display CHRS Empl ID.
- In Campus Solutions, the CSU ID Search will only display CS Empl ID.
- CS Navigation: CSU SA Baseline > CSU Campus Community > CSU ID Search
Yes, it is CSU_CHRS_XREF.
Yes, the CHRS Cross Reference Table can be located using the following navigation:
CSU SA Baseline > CSU Campus Community > CSU Cross Reference to search a person online in CS
Campuses will have to rely on the CHRS Cross Reference Table on their CS side.
Yes, but they should not the CHRS OPRID is <campus code> + CS ID
Integration Messages
Yes
| MSGNAME | APMSGVER | RECNAME | CHRS > CFS | CFS > CHRS |
|---|---|---|---|---|
| CHRS_ACCOUNT_CHARTFIELD_SYNC | VERSION_1 | GL_ACCOUNT_TBL | X | |
| CHRS_BUS_UNIT_GL_SYNC | VERSION_1 | BUS_UNIT_TBL_GL | X | |
| CHRS_CLASS_CF_SYNC | VERSION_1 | CLASS_CF_TBL | X | |
| CHRS_DETAIL_CALENDAR_SYNC | VERSION_1 | CAL_DEFN_TBL | X | |
| CHRS_DETAIL_CALENDAR_SYNC | VERSION_1 | CAL_DETP_TBL | X | |
| CHRS_FUND_CF_SYNC | VERSION_1 | FUND_TBL | X | |
| CHRS_JOURNAL_GEN_APPL_ID_SYNC | VERSION_1 | JRNLGEN_APPL_ID | X | |
| CHRS_LABOR_COST_DISTRIBUTION | VERSION_1 | CSU_LABOR_DIST | X | |
| CHRS_LEDGER_DEFN_SYNC | VERSION_1 | LED_DEFN_TBL | X | |
| CHRS_PAYROLL_ACCTG_TRANSACTION | VERSION_1 | CHRS_ACCTG_LINE | X | X |
| CHRS_PROGRAM_CF_SYNC | VERSION_1 | PROGRAM_TBL | X | |
| CHRS_PROJECT_SYNC | VERSION_1 | PROJECT | X | |
| CSU_PROVISION_INT | V1 | PSOPRDEFN |
CSU Exporting Accounting Lines
- HR_ACCTG_LINE-JOURNAL_LINE
- HR_ACCTG_LINE-JOURNAL_DATE
- HR_ACCTG_LINE-JOURNAL_ID
- HR_ACCTG_LINE-ACCOUNTING_PERIOD
- HR_ACCTG_LINE-FISCAL_YEAR
No. The messages that go between CHRS and CS will be primarily synchronous.
CS will only send CSU_PROVISION_INT (BUSN email) and CSU_SEC_USERID (CS Empl ID), which will include the ID for the User Profile and Business email.
| MSGNAME | APMSGVER | RECNAME | CHRS > CS | CS > CHRS |
|---|---|---|---|---|
| CSU_CHRS_CS_INTEGRATION | v1 | ADDRESSES | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | EMAIL_ADDRESSES | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | NAMES | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERSON | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERSONAL_PHONE | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERS_DATA_EFFDT | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERS_NID | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PER_POI_TYPE | X | |
| CSU_SEC_USERID | v1 | CSU_SEC_CHRS | X | |
| CSU_PROVISION_INT | V1 | PSOPRDEFN | X |
Security
No, Campuses will need to develop their own role or add the CSU_CHRS_XREF page to an existing role.
Users will need a total of 2 roles:
- CMS_PT_CSUCSHR
- CMS_PT_ENABLE_CI
Campus DO NOT have a role in CHRS to view Asynchronous and Synchronous messages. Due to the Level 1 data imbedded in the Asynchronous and Synchronous messages in CHRS, only those in CMS will have access.
The roles are delivered in CS008 and can be granted to a campus once CS008 is applied to the campuses CS production during the CHRS MTP.
Campus are always welcome to submit Change Controls. However, due to the Level 1 data imbedded in the Asynchronous and Synchronous messages in CHRS, a Change Control will not be approved.
Retrofits and Modifications
The CS Baseline Work Study modification utilizes CSU_PIP_HISTORY to determine how Much money students have available for financial aid disbursement. The CHRS table JOB will be converted as of November 1, 2019. Currently, at least 10 campuses use this modification.
In CHRS, this table will contain converted data as of July 1, 2019.
In CHRS, faculty/staff that had more than one job in multiple campuses also would have duplicate EMPL_RCDs when consolidated into one database. Therefore, all EMPL_RCDs in this situation have been renumbered during conversion only. New data added into CHRS will not be maintained through this table.
- CSU_JOBEMPL_MAP (mapping/crosswalk table in CHRS)
- EMPLID (CHRS EMPLID)
- EMPL_RCD (CHRS EMPL_RCD)
- EMPLID_OLD (Campus EMPLID)
- EMPL_RCD_PREV (Campus EMPL_RCD)
- COMPANY (Campus/Company)
APDB and Workstudy both use EMPL_RCD. At the time of conversion to CHRS, a script will be run in the corresponding CS campus to update three tables to match the EMPL_RCD from the CHRS crosswalk table.
- CLASS_INSTR
- INSTR_TERM_DTL
- STDNT_WS_AWARD
Campuses should review all areas where EMPL_RCD is used and determine retrofits. The three tables above are not inclusive of CS Tables that contain EMPL_RCD, only ones that are used in baseline. Most of the other tables are related to payroll, which is not used at the CSU.
In CHRS, 7 campuses (CI, EB, FRE, LA, LB and SF + CO) had their Company changed (CIS, EBY, FRE, LAS, SFO, CHO). Many went from a 2 digit codes to a 3 digit code.
For CS, baseline has developed views that utilize the COMPANY conversion. Campuses should review all areas where COMPANY used and determine retrofits.
CSU_PAY_CHCK_VW has been created to blank out the SSN field, making it so that the SSN is no longer available on this record (view). Campuses will need to review all areas where PAY_CHECK is used and determine retrofits. As CS will link to the new view and only have access to that view through DB links.
In CS, PeopleSoft Campus Community ID Delete (HR_PER502) process uses the PAY_CHECK record.
- Academic Advising - CAAR Advising Report
- Financial Aid - Work Study
- CSU ID Search
- Campus Community – ALMA (Library modification)
- Systemwide Reporting – APDB
Campus needs to heavily test:
- CS Campus Customizations
- CS Third Parties
- Provisioning
YES, campuses should review ALL CS Custom modifications and gather a list of all tables used. Then campuses should review whether the table is “owned” by HR. If not already on the DB Link list of tables:
- If another table needs to be used that is in the DB link view then notify your CHRS Implementation Manager why a table is needed in CS
- Note: Use this SQL as a guide to determine the application owner of the table:
- Find all tables and views with an Owner ID of HR
- Note that this only works for Peoplesoft-delivered objects
- CSU objects do not have consistent owner IDs
SELECT *
FROM PSRECDEFN A
WHERE A.OBJECTOWNERID LIKE 'H%' -- Owner is HR
AND A. RECTYPE IN ('0', '1') -- Tables and views
ORDER BY RECNAME.
- Does the modification create a new person?
- If yes, then add the person with minimal data, using the custom Component interface CSU_SR_CREATE_BIO_DEMO.
- Whether this is a new person or an existing one, update that person's data using a different CI, HCR_PERSONAL_DATA_SRV.
- Example code can be found in:
- App Engine CSU_CM_POST, Section BIO-APP, Step01, which calls app package CSU_SR_COMMON_PKG, which invokes the CIs.
No
Data will not be synchronized without a CI or API
Refer to a sample component interface in the Application Engine program below:
- CSU_ESP_PST
- Section POST
- Step01 (PeopleCode)
Campuses will need to retrofit their customizations which update personal data by adding a synchronization step OR by performing the update in both CS and CHRS applications. The synchronization step is done via component interface or API. All baseline delivered modifications have already been updated. Some examples of campus customizations are:
- Updating preferred name
- Synchronizing home address for reporting
- Auto-creating POIs in HR
- Updating Business Phone
- AAWS Web Services
- Duplicate ID Deletion
- Email address update
- Load Runner to update addresses
There is a variety of tables/views that are available through DB Links between CS/CHRS and CHRS/CFS. The full list can be found in the DB Link Details located in the CHRS Knowledgebase.
Queries
- Ensure queries are written with the “3-letter Campus Code_2-letter Module Code_Name with_between words”. Business Unit must be part of the criteria in queries. For more information refer to CHRS Query Policy Guide located in the CHRS Library.
- Campuses should retrofit any query that still utilizes SJT tables, which have not been a part of CS since the HR/CS split.
The following SQL identifies custom queries created in your system from the PSQRYDEFN PeopleTools table. It includes the query type (and the operator ID who owns the query if it is private).
select
QRYNAME as "Query Name",
DESCR as "Query Description",
CREATEOPRID as "Created By",
CREATEDTTM as "Created On",
LASTUPDDTTM as "Last Updated On",
LASTUPDOPRID as "Last Updated By", case when OPRID != ' ' then 'Private - ' || OPRID else 'Public' end as "Query Type",
VERSION as "Revisions",
QRYAPPROVED as "Query Approved?",
APPROVEOPRID as "Approved By",
APPROVEDTTM as "Approved On"
from PSQRYDEFN
where LASTUPDOPRID != 'PPLSOFT'
order by QRYNAME;
To change a private query to a public query, the campus must submit a ServiceNow ticket. So to answer the question above should simply be submit a change control and attach their private query for CMS to use as a basis
No.
The campus can either recreate the public query as a campus private query or submit a Change Control requesting a modification.
Campuses can either submit a Change Control requesting the query be created by CMS in CHRS as public or submit a Change Control to have it created in CHRS Reporting (Quicksight).
End of Article
0 Comments
Add your comment