The purpose of this document is to provide campuses with guidance on Person and User ID Delete in CHRS. As the process in CHRS is different. In HR 9.0, campuses had full control over deleting the Persons and User IDs from the system. Often those that were deleted were due to data entry errors, duplicates, a person declining an offer, etc. In CHRS, campuses do not have the ability to delete a Person or User ID and must submit a ServiceNow ticket requesting for the delete. Often those deletes are related to a duplicate. A duplicate can be created in CHRS and Campus Solution (CS) as an Empl ID or User Profile. Duplicates can be created manually or by using CHRS Recruiting (PageUp) Staging Table in CHRS. Duplicates are primarily created because the Social Security Number (SSN) was entered incorrectly.
It is the campus’s responsibility to review CHRS (i.e. CSU ID Search) prior to creating a new POI or Employee. It is also recommended that campuses review CS (i.e. CSU ID Search) to see if the person exists and has an SSN prior to creating a new POI or Employee in CHRS. Depending on where and how the duplicate is created, certain resolution steps must be taken.
Job Aids Pending
When a duplicate is created there are specific steps a campus should take to resolve that duplicate. The only time a campus should rename a duplicate to “Duplicate” is if the duplicate cannot be deleted from the system. The only time a campus should change the SSN to a fake set of numbers is if the duplicate cannot be deleted from the system. The more duplicates a campus has in CS the higher probability of incorrect matching to occur within CS and PDM. The same can be said about CHRS. The more duplicates in CHRS, the higher probability of incorrect matching occurring.
It is not a requirement for campuses to delete duplicates from Campus Solutions: it is highly recommended. Regardless of the steps a campus takes on a duplicate in CS, there is not a sufficient way for a campus to ensure that data for a duplicate does not connect with a person incorrectly.
Currently ALL campuses are under Integration Model 1. Although there are minor differences between how bio/demo flows between CS and HR 9.0 campuses in relationship to CS and CHRS campuses, ALL Campus Solution bio/demo data feeds to PDM. PDM is a master depository of all bio/demo data for all 23 CSU Campuses, with an extensive search match capability. Keeping this in mind, it is important when handling duplicates created in Campus Solutions and/or CHRS as duplicates cannot be deleted from PDM.
Under Integration Model 1, campuses are unable to see how duplicates impact the search match functionality in PDM. When Integration Model 2 is implemented for all CHRS campuses, the impact will be seen in the campus’ CS environments.
For example, in CS, if the campus was to only change the duplicate’s name to “duplicate”, there is still the potential for PDM to match. By only changing the name of the duplicate to Duplicate, the incorrect SSN remains in your CS environment. If a campus was to create a person in CHRS with the same SSN as the duplicate in your CS environment, PDM would send the information to both campuses CS environments. In CS, if a campus was to change the duplicate’s name to duplicate and update the SSN to be the same number (i.e.: 444-44-4444) or a random set of numbers, there is still the potential for PDM to match. A campus could create a person in CHRS with the SSN that has the same numbers or set of numbers that the duplicate in your CS environment, which will cause PDM to match and update both campuses CS environments.
It is the campus’s responsibility to monitor their CS environment for duplicates. The recommended SQL has been created for campuses to lavage for monitoring duplicates. This SQL is looking for individuals that have matching First Name, Last Name, and Date of Birth. This SQL will produce possible duplicates, but campuses will need to research the results to confirm if a true duplicate has been identified.
SELECT first_name_srch, last_name_srch,A.BIRTHDATE, Count(*)
FROM PS_PERSON A, PS_NAMES B
where A.EMPLID = B.EMPLID
AND NAME_TYPE = 'PRI'
AND B.EFFDT =
(SELECT MAX(B_ED.EFFDT) FROM PS_NAMES B_ED
WHERE B.EMPLID = B_ED.EMPLID
AND B.NAME_TYPE = B_ED.NAME_TYPE
AND B_ED.EFFDT <= SYSDATE)
group by first_name_srch,last_name_srch,A.BIRTHDATE having count(*) > 1 order by 2,1,3;
SQL
DELETE FROM PS_CSU_CHRS_XREF; INSERT INTO PS_CSU_CHRS_XREF(CSU_CHRS_ID, CSU_CS_ID) SELECT CSU_CHRS_ID, CSU_CS_ID FROM PS_CSU_EMPL_MAP_VW@CSU_CS_HR_LINK A, PS_INSTALLATION B WHERE B. COMPANY = 'XX' AND A.BUSINESS_UNIT = 'XXCMP'; COMMIT;
Example:
DELETE FROM PS_CSU_CHRS_XREF; INSERT INTO PS_CSU_CHRS_XREF(CSU_CHRS_ID, CSU_CS_ID) SELECT CSU_CHRS_ID, CSU_CS_ID FROM PS_CSU_EMPL_MAP_VW@CSU_CS_HR_LINK A, PS_INSTALLATION B WHERE B. COMPANY = 'FUL' AND A.BUSINESS_UNIT = 'FLCMP'; COMMIT;
When a ServiceNow ticket is required, the CHRS Incident Ticket Template should be used. When completing the template the following should be entered:
Subcategory: Integration
Short Description:
- Delete User Profile (Put Number)
- Delete User Profile (Put Number) and Person (Put Number)
Environment:
- Indicated if this is HCHRPRD (CHRS Production) or a different environment
Employee Name/ Campus (OPRID) ID that generated the issue:
- Indicate who created the duplicate
- Indicate who the duplicate is
Approximates Time/Date of issue:
- When was the duplicate created
Issue Description:
- Include if the duplicate is in CHRS Only, CS Only, or CHRS and CS
- Include details of the bad ID and good ID
Detailed Steps for CMS to replicate issue (navigation, input of values, search criteria, etc.):
- Since the ticket is being submitted to delete a duplicate. Just put “this is a request to delete a duplicate”.
Non-Duplicate
There are times when a person is created in CHRS and CS, and they are not a duplicate. The person could have been created from CHRS, as a student applicant, or as a simple POI. Due to unforeseen circumstances the person created decides to decline a Job Offer, withdraw their student application, or for other reasons no longer required in the system. Prior to CHRS, campuses could delete the Person/User ID from their CS and HR 9.0 environments in attempt to maintain a clean environment. Although there are no outrageous consequences for campuses that do this, when it comes to CHRS, this is not the recommended approach. SWHR recommends that all non-duplicates remain in both CHRS and CS regardless of why the person will no longer have an association with the campus.
Examples:
- Pancake has no association with any campus and is hired through CHRS Recruiting for Stanislaus. Stanislaus uses the CHRS Recruiting Staging Table to create Pancake as a Future Hire POI. Pancake receives CHRS ID 100044444 and CS Empl ID 005555555. However, 4 days before Pancake is set to begin, Stanislaus learns that Pancake is now declining the offer.
- Pancake has no association with any campus and is hired by Stanislaus. Stanislaus decides to manually create Pancake as a Future Hire POI. Pancake receives CHRS ID 100044444 and CS Empl ID 005555555. However, 4 days before Pancake is set to begin, Stanislaus learns that Pancake is now declining the offer.
Steps to Response:
- In CHRS
- Change the persons POI Status from Active to Inactive. To do this, go into correction mode on the Maintain POI page, update the Planned Exit Date to the current date, and then press “Save”.
Examples:
- Pancake has no association with any campus and is hired through CHRS Recruiting for Maritime. Maritime uses the CHRS Recruiting Staging Table to put Pancake directly in Job Data. Pancake receives CHRS ID 100044444 and CS Empl ID 005555555. However, 4 days before Pancake is set to begin, Maritime learns that Pancake is now declining the offer.
- Pancake has no association with any campus and is hired by Maritime. Maritime manually creates Pancake in Job Data rather than creating a Future Hire POI. Pancake receives CHRS ID 100044444 and CS Empl ID 005555555. However, 4 days before Pancake is set to begin, Maritime learns that Pancake is now declining the offer.
Steps to Response:
- In CHRS:
- In Job Data, add TER/ERR row with the same effective date as the hire row. In the PPT comments make a note regarding why the recording is getting the TER/ERR action/reason. (example: Declined offer after being created)
Duplicate in CS Side ONLY
Creating duplicates in CS is likely if preventative measures are not used prior to creating a new person in CHRS. Duplicates created on the CS side are primarily due to inaccurate data entry (i.e. SSN, DOB, etc.),not deleting previously created duplicates timely, or the person on the CS side does not have an SSN or has an ITIN at time of creation.
Examples:
- Waffle Cone preexisted in CS with CS Empl ID 885555555. In CS, Waffle has no SSN, a DOB of 1/1/1991, and the cell number 258/664-6525. Waffle is being hired and completes the Base Data Form in CHRS Recuriting (PageUp) and puts the SSN ending in 1988, DOB 1/1/1991, and cell 258/664-6525. When Waffle was created via the CHRS Recruiting Staging table, the CHRS ID 100044444 was created in CHRS, and a duplicate CS Empl ID 887777777 was also created causing the User Profile in CHRS to have the wrong Campus ID number.
- Waffle Cone preexisted in CS with CS Empl ID 885555555. In CS, Waffle has no SSN, a DOB of 1/1/1991, a postal code of 95337, and cell 258/664-6525. Waffle is manually entered in CHRS with the SSN ending in 1988, DOB 1/1/1991, and address with postal code 95337, and cell 258/664-6525. This creates the CHRS ID 100044444, and a duplicate CS Empl ID 887777777 is also created causing the User Profile in CHRS to have the wrong Campus ID number.
Steps to Resolve:
- Pre-Work:
- Identify the correct CS Empl ID and SSN that should be in both CHRS and CS.
- In ServiceNow:
- Submit a ServiceNow ticket requesting to DELETE the User Profile in CHRS that has the incorrect CS Empl ID.
- Wait, for confirmation that User Profile has been deleted in CHRS.
- In CHRS:
- Receive confirmation and manually recreate user profile in CHRS using the correct CS Empl ID with campus number prefix (e.g., 07003085411)
- In CS:
- Delete duplicate
- Navigation: Menu > Set Up SACR > System Administration > Database Processing
- At this point, if the SSN did not exist or is not correct, update the CS Empl ID in Add/Update Person with the SSN
- Run SQL to update Crosswalk Table in CS
- Delete duplicate
- In CHRS:
- Update a detail in Modify a Person by changing the cell phone number to 222-222-2222. (Do not forget to copy the original cell phone number to put back.
- At this point, if the SSN was entered incorrectly, it should also be updated in Modify a Person.
- In CS:
- Confirm correct Empl ID mapping on the Crosswalk Table in CS
- Navigation: Menu > CSU SA Baseline > CSU Campus Community > CHRS Cross Reference
- Confirm correct Empl ID mapping on the Crosswalk Table in CS
- In CHRS:
- Under Modify a Person return the cell phone number to what it was originally.
Examples:
- Waffle Cone preexisted in CS with SSN ending is 9999, CS Empl ID 885555555, and does not exist in CHRS. Waffle is being hired and completes the Base Data Form in CHRS Recuriting (PageUp) and puts the SSN ending in 1991. When Waffle was created via the CHRS Recruiting Staging table, the CHRS ID 100044444 was created in CHRS and a duplicate CS Empl ID 887777777 was also created causing the User Profile in CHRS to have the wrong Campus ID number.
- Waffle Cone preexisted in CS with SSN ending is 9999, CS Empl ID 885555555, and does not exist in CHRS. When Waffle was created in CHRS the SSN was entered manually ending in 9991. In CHRS ID 100044444 was created in CHRS and a duplicate CS Empl ID 887777777 was also created causing the User Profile in CHRS to have the wrong Campus ID number.
Steps to Resolve:
- Pre-Work:
- Identify the correct CS Empl ID and SSN that should be in both CHRS and CS.
- In ServiceNow:
- Submit a ServiceNow ticket requesting to DELETE the User Profile in CHRS that has the incorrect CS Empl ID.
- Wait, for confirmation that User Profile has been deleted in CHRS.
- In CHRS:
- Receive confirmation and manually recreate user profile in CHRS using the correct CS Empl ID with campus number prefix (e.g., 07003085411)
- In CS:
- Delete duplicate
- Navigation: Menu > Set Up SACR > System Administration > Database Processing
- At this point, if the SSN did not exist or is not correct, update the CS Empl ID in Add/Update Person with the SSN
- Run SQL to update Crosswalk Table in CS
- Delete duplicate
- In CHRS:
- Update a detail in Modify a Person by changing the cell phone number to 222-222-2222. (Do not forget to copy the original cell phone number to put back.
- At this point, if the SSN was entered incorrectly, it should also be updated in Modify a Person.
- In CS:
- Confirm correct Empl ID mapping on the Crosswalk Table in CS
- Navigation: Menu > CSU SA Baseline > CSU Campus Community > CHRS Cross Reference
- Confirm correct Empl ID mapping on the Crosswalk Table in CS
- In CHRS:
- Under Modify a Person return the cell phone number to what it was originally.
Duplicate in CHRS ONLY
In CHRS creating a duplicate is highly unlikely but possible. For a user to create a duplicate person, they must have entered the social security number incorrectly or did not leave the Modify a Person page when the “Carry ID” option appeared.
Unlike HR 9.0, CHRS has an extensive validation process that occurs prior to deleting a person. CHRS does not have the capability to delete someone from Job Data due to PS_PAYROLL_DATA table. The PS_PAYROLL_DATA table is populated anytime someone is added in Job Data and signifies to the system that the person should be paid.
Examples:
- Waffle Cone preexisted in CS and CHRS, with SSN ending is 9999. Waffle has CS Empl ID 885555555, and CHRS ID 100044444. Waffle is being hired and completes the Base Data Form in CHRS Recuriting (PageUp) and puts the SSN ending as 9991. When Waffle was created via the CHRS Recruiting Staging table, the CHRS Empl ID 100033333 was created when the record was loaded as a POI. A duplicate is also created in CS with the CS Empl ID 887777777 created.
- Waffle Cone preexisted in CS and CHRS with SSN ending is 9999. Waffle has CS Empl ID 885555555, and CHRS ID 100044444. Maritime forgets to check CSU ID Search to see if Waffle already exists in CHRS and begins creating Waffle manually. While creating Waffle in CHRS and puts the SSN ending as 9991, when the “Carry ID” option appeared because of the duplicate data, instead of leaving the page completely, the person continued entry and created a POI. A duplicate is created in CHRS with CHRS Empl ID 100033333, and CS with the CS Empl ID 887777777.\
Steps to Resolve:
- Pre-Work:
- Identify the correct CHRS Empl ID and CS Empl ID
- In CHRS
- Under Modify a Person updated the Person Name to "DO NOT USE" for the duplicate.
- Create a POI record associated with your campus using the correct CHRS Empl ID.
- Confirm a User Profile is created in CHRS attached to the correct CS Empl ID.
- In ServiceNow:
- Submit a ServiceNow ticket requesting to DELETE the User Profile and Person in CHRS for the duplicate.
- Wait, for confirmation that User Profile and Person has been deleted in CHRS.
- In CS:
- Delete duplicate in CS
- Navigation: Menu > Set Up SACR > System Administration > Database Processing
- Run SQL to update Crosswalk Table in CS
- Confirm correct mapping on the Crosswalk Table in CS
- Navigation: Menu > CSU SA Baseline > CSU Campus Community > CHRS Cross Reference
- Delete duplicate in CS
Examples:
- Waffle Cone preexisted in CS with SSN ending is 9999 and had CS Empl ID 885555555. Waffle also preexists in CHRS with SSN ending 9999 and CHRS Empl ID 100044444. Stanislaus forgets to check CSU ID Search to see if Waffle already exists in CHRS and begins creating Waffle manually. While creating Waffle in CHRS, with all details being the same, when the “Carry ID” option appeared because of the duplicate data, instead of leaving the page completely, the person continued entry and created a Job Record with the new CHRS Empl ID 100033333. Waffle now has two CHRS Empl ID and two CS Empl ID.
- Waffle Cone preexisted in CS with SSN ending is 9999 and had CS Empl ID 885555555. Waffle also preexists in CHRS with SSN ending 9999 and CHRS Empl ID 100044444. Waffle completes the Base Data Form in CHRS Recuriting (PageUp) and puts the SSN ending as 9991. When Waffle was created via the CHRS Recruiting Staging table, the CHRS Empl ID 100033333 was created when the record was loaded into Job Data. Waffle now has two CHRS Empl ID and two CS Empl ID.
Steps to Resolve:
- Pre-Work:
- Identify the correct CHRS Empl ID and CS Empl ID
- In CHRS:
- Under Modify a Person updated the Duplicate Person Name to "DO NOT USE" for the duplicate.
- In User Profile update the description to "DO NOT USE" for the duplicate.
- In Job Data, add TER/ERR row with the same effective date as the hire row and effective sequence 1 for the duplicate.
- Create a Job Record associated with your campus using the correct CHRS Empl ID associated with the employee. In the PPT comments make a note that duplicate CHRS empl ID that was created. (example: Duplicate CHRS ID 100033333)
- In ServiceNow:
- Submit a ServiceNow ticket requesting to Lock the User Profile in CHRS for the duplicate.
Duplicate in CHRS and CS
Creating a duplicate in both CHRS and CS is highly unlikely but possible. Duplicates are primarily created in both CHRS and CS due to the Social Security Number being entered incorrectly for a person who already exists in both environments. Having a duplicate created in both CHRS and CS adds an additional complexity in the resolution.
Examples:
- Waffle Cone preexisted in CS and CHRS, with SSN ending is 9999. Waffle has CS Empl ID 885555555, and CHRS ID 100044444. Waffle is being hired and completes the Base Data Form in CHRS Recuriting (PageUp) and puts the SSN ending as 9991. When Waffle was created via the CHRS Recruiting Staging table, the CHRS Empl ID 100033333 was created when the record was loaded as a POI. A duplicate is also created in CS with the CS Empl ID 887777777 created.
- Waffle Cone preexisted in CS and CHRS with SSN ending is 9999. Waffle has CS Empl ID 885555555, and CHRS ID 100044444. Maritime forgets to check CSU ID Search to see if Waffle already exists in CHRS and begins creating Waffle manually. While creating Waffle in CHRS and puts the SSN ending as 9991, when the “Carry ID” option appeared because of the duplicate data, instead of leaving the page completely, the person continued entry and created a POI. A duplicate is created in CHRS with CHRS Empl ID 100033333, and CS with the CS Empl ID 887777777.
Steps to Resolve:
- Pre-Work:
- Identify the correct CHRS Empl ID and CS Empl ID
- In CHRS
- Under Modify a Person updated the Person Name to "DO NOT USE" for the duplicate.
- Create a POI record associated with your campus using the correct CHRS Empl ID.
- Confirm a User Profile is created in CHRS attached to the correct CS Empl ID.
- In ServiceNow:
- Submit a ServiceNow ticket requesting to DELETE the User Profile and Person in CHRS for the duplicate.
- Wait, for confirmation that User Profile and Person has been deleted in CHRS.
- In CS:
- Delete duplicate in CS
- Navigation: Menu > Set Up SACR > System Administration > Database Processing
- Run SQL to update Crosswalk Table in CS
- Confirm correct mapping on the Crosswalk Table in CS
- Navigation: Menu > CSU SA Baseline > CSU Campus Community > CHRS Cross Reference
- Delete duplicate in CS
Examples:
- Waffle Cone preexisted in CS with SSN ending is 9999 and had CS Empl ID 885555555. Waffle also preexists in CHRS with SSN ending 9999 and CHRS Empl ID 100044444. Stanislaus forgets to check CSU ID Search to see if Waffle already exists in CHRS and begins creating Waffle manually. While creating Waffle in CHRS, with all details being the same, when the “Carry ID” option appeared because of the duplicate data, instead of leaving the page completely, the person continued entry and created a Job Record with the new CHRS Empl ID 100033333. Waffle now has two CHRS Empl ID and two CS Empl ID.
- Waffle Cone preexisted in CS with SSN ending is 9999 and had CS Empl ID 885555555. Waffle also preexists in CHRS with SSN ending 9999 and CHRS Empl ID 100044444. Waffle completes the Base Data Form in CHRS Recuriting (PageUp) and puts the SSN ending as 9991. When Waffle was created via the CHRS Recruiting Staging table, the CHRS Empl ID 100033333 was created when the record was loaded into Job Data. Waffle now has two CHRS Empl ID and two CS Empl ID.
Steps to Resolve:
- Pre-Work:
- Identify the correct CHRS Empl ID and CS Empl ID
- In CHRS:
- Under Modify a Person updated the Duplicate Person Name to "DO NOT USE" for the duplicate.
- In User Profile update the description to "DO NOT USE" for the duplicate.
- In Job Data, add TER/ERR row with the same effective date as the hire row and effective sequence 1 for the duplicate.
- Create a Job Record associated with your campus using the correct CHRS Empl ID associated with the employee. In the PPT comments make a note that duplicate CHRS empl ID that was created. (example: Duplicate CHRS ID 100033333)
- In ServiceNow:
- Submit a ServiceNow ticket requesting to Lock the User Profile in CHRS for the duplicate.
End of Article
0 Comments
Add your comment