University of California, Berkeley

HCM: Identifying HR Data to be used in Analyses

HR data analysis is distinguished from simple reporting of the contents of the HCM database in that analysis seeks to glean patterns and meaning from the raw information stored in the HR data repository. For example, a list of all the job rows that were coded as a "promotion" during a certain time period for a campus department would be a simple report of the contents of the database, and might be useful to a manager auditing personnel activity in the department. An assessment of those job rows that counted how many promotions occurred in the department during the specified time period -- ignoring any rows that were inserted to correct data-entry errors -- would constitute HR analysis.)

Some types of Employment Records in HCM do not represent "real" jobs that an analyst of Human Resources data would wish to include in analytical data sets. These job rows are necessary for several reasons:

  • To pass to Berkeley's PPS (Payroll/Personnel System) information it needs in order to pay employees properly;
  • To pass to Budget Office systems data on positions/chartstrings for which funds are and are to remain budgeted, but in which the employee who fills the position is not working or is not being paid for some period of time;
  • To record a temporary academic appointment, such as a Summer Research position, for a faculty member whose principal appointment remains the "position of record" for most HR analytical purposes even during the period of the temporary appointment.

In order to provide meaningful data sets for Human Resources analyses, an analyst must therefore be able to distinguish between several categories of jobs. The JOB_ROW_CATEGORY field in HR-BAIRS -- Job Category on the HCM Job Data : Job Information page -- differentiates data in HCM that is of interest to analysts of HR data from rows that are, in most cases, not of interest.

Job Row Categories

The categories of Job Rows defined for this purpose are detailed below:

  • PRINCIPAL JOB ROW (P): The principal or sole Job Row for any given position; these are the job rows that are "meaningful" for purposes of (most) Human Resources analysis.
  • BUDGETARY-HOLD JOB ROW (B): Job rows that exist solely to identify payroll funding that is to be preserved for budgetary purposes. This generally occurs when the employee who normally works in a job -- or is paid from the budgeted chartstring(s) normally associated with that job -- and will presumably return to the job or budgeted funding is:
    • working in another position instead of the job in question; or,
    • paid for 100% of work in the same position from chartstring(s) other than the budgeted one(s); or, · on (full) leave from the job in question.
  • SECONDARY JOB ROW (S): Job rows that exist to denote "temporary" or "extra" pay associated with a concurrent Principal Job row:
    • for staff, to satisfy PPS requirements necessary to pay component(s) of compensation for a Principal Job described by another, concurrently-effective row of data; or,
    • for academics, to record temporary jobs (such as summer research or teaching work) which may have a different job code and/or Dept_ID from the employee's (permanent) Principal Job, but are tied to the Principal Job's compensation rate.

  • CONVERSION JOB ROW (C): Job rows converted from PPS on 7/1/2002 which have no JOB_EARNS_DIST child rows (and thus cannot be programmatically calculated from the rules described below). These are considered to be exceptional cases, though there are a significant number of such rows in the HCM database.

In most analyses, Principal job rows alone are the rows of interest. For some HR analyses, Principal and Budgetary-Hold rows may be included. Secondary rows are generally not germane to HR analyses, because they exist only as "extensions" of information recorded in a concurrent Principal or Budgetary-Hold row.

Conversion rows are exceptional because there is no reliable, programmatic method for categorizing them; and because they record personnel activity that occurred prior to the time the PeopleSoft HCM system was put into service. For both these reasons, inclusion of Conversion rows in HCM analyses generally leads to inaccuracies.

Job rows are assigned to exactly one of the categories described above by applying the following rules, sequentially:

  1. A Job row whose PERSON.PER_STATUS = "N" (Non-Employee) is always a Principal Job row
  2. Employee records (PERSON.PER_STATUS = "E") are categorized as follows (see exceptional cases in #3, below)
    • A Job row is a Principal Job row if its distribution child-rows include at least one whose JOB_EARNS_DIST.ERNCD values:
      • denotes Regular Pay: REC, REG, REN, RG1, SLN, SLR, TAP
      • denotes By-Agreement compensation: BYA, BYN
      • denotes a Post-Doctoral Fellowship: FEL, FEN, FER
      • denotes Summer Session pay: SSR, SUM
      • denotes University Extension instructor pay: UNX
      • denotes a Without Salary appointment: WOS
      • denotes Military Leave special pay: MIL
      • denotes Sick-Leave/Worker's Comp compensation: ESL, SWC, SWP
    • A Job row is a Budgetary-Hold Job row if its distribution child-rows all have JOB_EARNS_DIST.ERNCD values of PRT and/or NPY
    • A Job row that is neither a Principal Job or a Budgetary-Hold Job row per the rules given above is a Secondary Job row
       
  3. Cases that are exceptions to the rules above include Terminated job rows, which have no distributions; and rows converted from PPS on 07/01/2002, when HCM went into production.
    • Terminated Job Rows: if a job row carries the Action_Cd value "TER", it is terminated, and will not have any JOB_EARNS_DIST child-rows.
      • For such rows, the category will match the category of the row that precedes the Terminated row (prior effective-dated row with same EMPL_RCD_NO value).
      • If a job-row that precedes a TER job row is corrected (and its category re-calculated), the value of the subsequent TER row will be recalculated also (as described in the preceding bullet-point).
    • Converted Job Rows: Job rows converted when HCM went into production (effective date <= 7/1/2002) which have zero JOB_EARNS_DIST child-rows are considered to be in an exception category: "Conversion" (code: "C")

The JOB_ROW_CATEGORY field in HCM was populated per the above rules for extant HCM data on April 1, 2003. Subsequently, a job row's category is determined in HCM when the row is saved (whether the row has just been created, or has just been edited/corrected). This determination is recorded as a code in the HCM database, and is used to populate the appropriate HR-BAIRS table during the nightly load of HR-BAIRS data.