Versions Compared

Old Version 1

changes.mady.by.user Julio Polo

Saved on

compared with

New Version Current

changes.mady.by.user Julio Polo

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

If you use HR-specific data elements such as EAC (employing agency code), employee record number, employee home record designation, job code/grade or functional code, you will need to modify your application during the weekend of October by February 23, 20202021.  The PeopleSoft HR system will be upgraded to version 9.2, and the following data will change:

  • Employee Record Number
    • Where it appears:
    • If you stored the value of employeeRecord 1 in your application data, you should change it from 1 to 0 during the weekend of October right before February 23, 20202021.
      • Why? Our current data feed from PeopleSoft translates employee record number 0 to be employee record number 1, and that's how we present it in UHIMS Events and LDAP.  There was never the possibility of an actual employee record number 1 in PeopleSoft, but that will no longer be true after this upgrade.
    • If you used the employee record number solely for the purpose of figuring out the employee's home record (it used to be that the lowest number would always be the home record), you should instead use the employee home record indicator (see below).
  • Employee Home Record
    • Where it appears:
      • UHIMS Events, appears as isHomeRecord field in affiliation and scoped home org messages
      • CAS/LDAP, the uhScopedHomeOrg attribute whose value begins with dataOrigin=hris is the employee home record.  All HR fields that appear here correspond to the home record.
    • There are no changes to the isHomeRecord data element itself. We are only highlighting it here, in case you were reading employeeRecord values only to figure out the home record.  You should always use isHomeRecord, not employeeRecord numbers for this purpose.
  • EAC (Employing Agency Code)
    • Where it appears:
    • If your application uses the EAC, you need to figure out how it needs to be modified to handle a complete overhaul of EAC values:.
      • The EAC will change in length from 8 to 11 characters.
      • Most of the existing EACs will be converted by adding a leading zero as follows:
        • 22 50 31 00 → 22 050 031 000
      • There will be some new EAC values altogether, i.e. not the result of converting from an existing EAC as done above.
    • If you use the EAC indirectly via UH Groupings, we will make the change to your grouping definitions.
    • If you use the EAC by talking directly to Grouper (e.g. via API), you should change to the new EAC values after the upgrade.
    • Time permitting, we may support backward compatibility by linking old and new EACs in the UH Group Store
    • Note: PeopleSoft stores the EAC without the leading 22.  You will see the EAC in PeopleSoft as 3 separate codes for division, branch and section.  Each code is 3-digits long.
  • Job Code and Grade
    • Where it appears:
    • The grade will no longer be appended to the jobCode. It will appear as a separate data element.
    • The job code and grade values will change for a lot of people with the upgrade.  Here are some examples that were provided early in the project (so they may have changed since then):
      • APT -  existing PS 9.1 functional codes become the job code
      • Faculty - a more cohesive job code (i.e. C2C09 becomes C2)
      • Executive/Managerial - majority remains the same and some updates with simplification
      • Graduate Assistants - GA09/GA11 becomes GA
      • Lecturers - new ones only LA, LB, LC
      • Civil Service - remain as is
  • Functional Code
    • Where it appears:
    • The functionalCode is gone after the upgrade.  Please check with your HR/PeopleSoft contact if you need to address this.
  • Employee Type Code
    • Where it appears:
    • Your application should account for a new value of P (person of interest) that can now appear in employeeTypeCode.
      • This only applies to employee type code. There is no corresponding person-of-interest role. The role value for these individuals will likely be "staff.nonCompensated" or "other"should be one of the usual role values.
    • What we know thus far about the person of interest (POI) category:
      • These are not employees, and they are not compensated. For example, non-employee PI's that need to approve workflow processes in PeopleSoft.
      • Current employees with the non-compensated job code are also considered POIs, but they are already accounted for under the non-compensated staff category.
  • Campus Key
    • Where it appears:
    • The campus key used to be derived from the EAC but it will use something called ESTABID under PeopleSoft 9.2.  This might change the campus key value for a few employees.
  • New data elements
    • The following new fields that will appear in UHIMS Events affiliation messages and inside the uhScopedHomeOrg CAS/LDAP attribute:
      • grade
      • jobFunction
      • departmentID

...