This view contains all of the basic core employee information. Start here and then branch out if you are not finding the data you need.
EAH-Workforce-View includes data on employee job,position,salary information, and benefits eligibility for all employee types.
Granularity:
One row per employee, per employee record, per job action effective date, per job effective sequence numbers.
Level | Key (uniqueness / group by) | Measures | |
---|---|---|---|
1 | Employee | Employee ID | |
2 | Employee Record | Employee ID + Employee Record | |
3 | Job Action Effective Date | Employee ID + Employee Record + Job Action Effective Date | |
4 | Lowest | Employee ID + Employee Record + Job Action Effective Date + Job Effective Sequence Number |
Key Fields: *Make Up the Primary Key
- Employee ID*
- Employee Record*
- Job Action Effective Date (use in combination w/above depending on current or as of date requirements of your report)
- Job Effective Sequence Number (use in combination w/above depending on current or date requirements of your report)
Key Fields to use as filters:
- Job AsOf Indicator *= Values of Current, History, and Future in cases where there are Future positions or jobs in UCPath.
- Job Effective Sequence Indicator *= Maximum is the current record for 1 row per empid and record number, Prior is previous record
- Job Indicator *= Primary returns only the primary job when employee has concurrent jobs
- Organizational Relationship - values EMP for Employees and CWR for Contingent Workers
- HR Status - Values of Active and Inactive
- Employee Status - 6 Values of Active Paid Leave of Absence, Retired, etc.
- Job Code = CONV are converted records that can be filtered out if not needed
- Employee Class - Values of Academic, Staff, Student etc.
- Position Pool - Values of WS-Federal, WS-Math/Reading Tutors
- Job Action has values - Termination, Hire, Rehire etc.
- Job Action Reason has values - Rehire, Academic Concurrent Hire etc.
- Union Code has values - Service, Technical, Academic Researchers etc.
- Employee Type has values - Salaried, hourly etc.
- Salary Plan has values - RX Salary Plan, Career Tracks etc.
- FLSA Status has values - Exempt, Nonexempt
- Occupation Sub Group has values - Managers, Facilities, Contingent Workers etc.
- Eligibility Configuration codes
- Class Indicator has 5 values of Academic, Senior Management Group etc.
- Full/Part Time Indicator has values - Variable, Fixed etc.
- Probation Status has values - Within Probation, probation Completed etc.
- Salary Grade has values - Professor, Assistant Professor, Technical Assistant etc.
- Location Use Type
"*" These 3 field filters would return 1 row per person with the indicated filter values.
Ui expand | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
Appointment fields do not exist in PPS. There is not a 1 to 1 correlation of Appointment from PPS to UC Path. Appointments that were created for a stipend no longer exist, they are now just part of an employee's additional pay for an existing job. Please note, as we all adapt to the new processes with UC Path, our reports will also need to adapt. That may mean removing fields that are no longer being used and adding new UC Path fields.
|
Ui expand | ||
---|---|---|
| ||
Identity data is loaded into EAH on a nightly basis and comes from a combination of:
|
Ui expand | ||
---|---|---|
| ||
For Job Code Description, Position and Job Org Business Title: All three are managed within UCPath. Job Code Description is the origin. Position inherits the Job Code description upon position creation. Job Org Business Title inherits from position description when a Job record is created. It is a business decision to override the Position or Job Org Business Title with a more descriptive value. When the business overrides the position description, it flows through to the Job Org Business title. While UCSD HR does not train or tell departments to override the Job Org Business title, they can absolutely do so and HR has no control to stop them. |
Ui expand | ||
---|---|---|
| ||
Identity data is loaded into EAH on a nightly basis and comes from a combination of: UCPath delivers the field 'Job Indicator' to attribute an employee's workforce record as 'Primary' or 'Secondary'. |
Ui expand | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||
There are three CCOA codes in the Workforce View: "Position Funding Default CCOA", "Position Funding Default CCOA FinU Code", "Position Funding Default CCOA FinU", The view has logic to return exactly one position funding source in the event the employee’s position might be split-funded. If your requirements state that the Accruals must be split according to actual staged position funding, this solution is not going to work. In a split-funded scenario the view returns the single greatest percentage. If there are multiples with the greatest percentage (50/50, 40/40/20, etc), the choice of funding source from the greatest percentages is arbitrary. The view also looks at department-level default funding if the position funding is missing entirely. So you may also think of this field representing the ‘Primary’ funding source as much as a ‘Default’ funding source. Furthermore, within the ‘stack’ of position funding data layers, the following row selection logic is always used within the view:
The "Position Funding Default CCOA" field is a data pattern representing a sequence of chartfields. Therefore, you can find a specific chartfield value based on the location of the data within the string as shown by this table:
Also be advised the chartfield values represented in the string may be changed by downstream GL processing. The CCOA value selected by the view represents the actual value staged during position funding. In response to your concerns over the use of ‘default’ chartfield values, I would advise the business to review the values returned by the query for use of any obvious defaults. They requested the fields, they know their data. |
Ui expand | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
Due to Tableau architecture limitations the pre-built filters filter sets in Cognos can not be pre-built in Tableau. However developers can create the filters ad hoc as follows:
|