implementing hr analytics - peoplesoft adaptors

Implementing HR Analytics using PeopleSoft Adaptors

Oracle Corporation | 1

Implementing HR

Analytics using

PeopleSoft Adaptors

- A technical documentation of various aspects of the product as applies to

Oracle Business Intelligence Applications – HR PeopleSoft Adaptors



1. ORACLE BI APPLICATIONS PEOPLESOFT ADAPTOR (7.9.6 +) ....................................... 4

2. GENERAL BACKGROUND OF PEOPLESOFT ADAPTORS .................................................... 4

3. KEY ETL PROCESSES AND INCREMENTAL REFRESH STRATEGIES ............................... 5

3.1. Persistent Staging Tables ...................................................................................................................... 5

3.2. Incremental refresh of DW based on Event Queues .............................................................................. 6

3.2.1. An incremental refresh use case ..................................................................................... 6

3.2.2. A worked out example of Event Queue table ................................................................. 7

4. GENERAL IMPLEMENTATION CONSIDERATIONS ............................................................... 8

5. IMPACT OF INCORRECT CONFIGURATIONS OF DOMAIN VALUES ................................ 9

6. DETAILED UNDERSTANDING OF THE KEY HR ETL PROCESSES .................................. 11

6.1. Core Workforce Fact Process .............................................................................................................. 11

6.1.1. ETL Flow ........................................................................................................................ 11

6.1.2. Terminology .................................................................................................................. 12

6.1.3. Key Steps and Table Descriptions ................................................................................. 12

6.1.4. Key Setup/Configuration Steps ..................................................................................... 16

6.1.5. Customizing the Workforce Fact ................................................................................... 18

6.1.6. W_PSFT_WEVT_JOB_PS ................................................................................................ 19

6.1.7. W_PSFT_WEVT_IASG_PS .............................................................................................. 20

6.1.8. W_PSFT_WEVT_PERF_PS .............................................................................................. 21

6.1.9. W_PSFT_WEVT_AGE_PS ............................................................................................... 22

6.1.10. W_PSFT_POSN_WRKR_PS ............................................................................................ 23

6.1.11. W_PSFT_POSN_HLDR_PS .............................................................................................. 24

6.1.12. W_PSFT_SUPV_WRKR_PS ............................................................................................. 25

6.1.13. W_PSFT_SUPV_STATUS_PS .......................................................................................... 26

6.1.14. W_PSFT_WEVT_ASG_EQ_TMP ..................................................................................... 27

6.1.15. W_WRKFC_EVT_FS ....................................................................................................... 28

6.1.16. Workforce Base Fact (W_WRKFC_EVT_F) ..................................................................... 29

6.1.17. Workforce Age Fact (W_WRKFC_EVT_AGE_F) ............................................................. 30

6.1.18. Workforce Period of Work Fact (W_WRKFC_EVT_POW_F) ......................................... 31

6.1.19. Workforce Merge Fact (W_WRKFC_EVT_MERGE_F) .................................................... 32

6.1.20. Workforce Month Snapshot Fact (W_WRKFC_EVT_MONTH_F) .................................. 33

6.1.21. Workforce Aggregate Fact (W_WRKFC_BAL_A) ........................................................... 34

6.1.22. Workforce Aggregate Event Fact (W_WRKFC_EVT_A) ................................................. 36

6.1.23. Handling Deletes ........................................................................................................... 39

6.1.24. Propagating to derived facts ......................................................................................... 39

6.1.25. Date-tracked Deletes .................................................................................................... 40

6.1.26. Purges ............................................................................................................................ 40



6.1.27. Primary Extract .............................................................................................................. 40

6.1.28. Identify Delete............................................................................................................... 41

6.1.29. Soft Delete .................................................................................................................... 41

6.1.30. Date-Tracked Deletes - Worked Example ..................................................................... 42

6.2. Recruitment Fact Process .................................................................................................................... 43

6.2.1. ETL Flow ........................................................................................................................ 43



6.2.4. W_JOB_RQSTN_EVENT_FS ........................................................................................... 45

6.2.5. W_PSFT_APPL_EVENT_F_TMP ..................................................................................... 46

6.2.6. W_APPL_EVENT_FS ....................................................................................................... 47

6.2.7. Job Req. & Applicant Event Facts (W_JOB_RQSTN_EVENT_F & W_APPL_EVENT_F) ... 48

6.2.8. Job Requisition Accumulated Snapshot Fact (W_JOB_RQSTN_ACC_SNP_F) ............... 50

6.2.9. Applicant Accumulated Snapshot Fact (W_APPL_ACC_SNP_F) .................................... 51

6.2.10. Recruitment Pipeline Event Fact (W_RCRTMNT_EVENT_F) ......................................... 51

6.2.11. Recruitment Job Requisition Aggregate Fact (W_RCRTMNT_RQSTN_A) ..................... 54

6.2.12. Recruitment Applicant Aggregate Fact (W_RCRTMNT_APPL_A) ................................. 56

6.2.13. Recruitment Hire Aggregate Fact (W_RCRTMNT_HIRE_A) ........................................... 57

6.3. Absence Fact Process .......................................................................................................................... 59

6.3.1. ETL Flow ........................................................................................................................ 59



6.3.4. W_ABSENCE_TYPE_RSN_DS ......................................................................................... 60

6.3.5. W_ABSENCE_EVENT_TMP ............................................................................................ 61

6.3.6. W_ABSENCE_EVENT_DS ............................................................................................... 62

6.3.7. Absence Event Fact (W_ABSENCE_EVENT_F) ............................................................... 62

6.4. Learning Fact Process .......................................................................................................................... 65

6.4.1. ETL Flow ........................................................................................................................ 65



6.4.4. W_LM_ENROLLMENT_ACC_SNP_FS ............................................................................. 66

6.4.5. Learning Enrollment Acc. Snapshot Fact (W_LM_ENROLLMENT_ACC_SNP_F) ........... 67

6.4.6. Learning Enrollment Event Fact (W_LM_ENROLLMENT_EVENT_F) ............................. 69

6.5. Payroll Fact Process ............................................................................................................................ 70

6.5.1. ETL Flow ........................................................................................................................ 70

6.5.1. W_PSFT_PAYROLL_F_TMP ............................................................................................ 72

6.5.2. W_PSFT_PAYROLL_F_DIM_TMP ................................................................................... 73

6.5.3. W_PAYROLL_FS ............................................................................................................. 74

6.5.4. Payroll Fact (W_PAYROLL_F) ......................................................................................... 75

6.5.5. Payroll Aggregate Fact (W_PAYROLL_A) ....................................................................... 76

7. KNOWN ISSUES AND PATCHES ............................................................................................... 77



1. Oracle BI Applications PeopleSoft Adaptor (7.9.6 +)

The purpose of this document is to provide enough information one might need while attempting an

implementation of HR Analytics using the Oracle BI Applications PeopleSoft Adaptors.

Apart from understanding the ‘entry points’ that are required to implement HR Analytics, it also

helps to know the process details of some ‘key’ components of HR Analytics. A few of these key facts

and dimensions are also discussed and an overview of their process/usages is provided towards the

end.

This document is intended for Oracle BI Applications Releases 7.9.6, 7.9.6.1, 7.9.6.2 as well as

7.9.6.3. For upcoming releases, this document will be updated in due course of time.

2. General Background of PeopleSoft Adaptors

Oracle BI Applications’ Data Warehouse consists of a huge set of facts, dimensions and aggregate

tables. The portion of the ETL that loads to these ‘end’ tables are typically Source Independent

(loaded using the Informatica folder SILOS). These ETL maps start from a staging table and load data

incrementally into the corresponding end table. Aggregates are created upstream, and have no

relation to which source system the data came from. The ETL portion, Source Dependent Extract,

that extracts into these staging tables (also called Stage Tables) are the ones that go against a given

source system, like EBS or PSFT and so on. For Universal, they go against a similarly structured CSV

file. Take any Adaptor – the stage tables are exactly the same structurally. The grain expectation is

also exactly the same for all adaptors.

Oracle BI Applications provide packaged ETL mappings against various source OLTP systems and

Oracle PeopleSoft is one of them. PeopleSoft Adaptors for Oracle BI Applications provide packaged

maps supporting various business areas such as Human Resources, Supply Chain & Procurements,

Order Management, Financials and Service. Depending on the Oracle BI Application product

releases, a variety of PeopleSoft versions are also supported, including 8.9, 9.0 and 9.1.



3. Key ETL processes and Incremental Refresh Strategies

The Oracle BI Applications PeopleSoft Adaptor comes with pre-packaged ETL maps that are designed

to carry out incremental refreshes of your data warehouse. The in-built extraction logic not only

supports how to figure out the ‘changes’ but also supports refreshing of your data warehouse in

case there has been a correction done to your OLTP system. This is quite common in HRMS systems.

There are two points to talk about in this matter:

3.1. Persistent Staging Tables

Persisted Staging (PS) tables are similar to the Operational Data Store (ODS) concept. Usually the PS

tables reflect the structure of a transaction table plus calculations/lookups. The PS layer has been

brought into the ETL for a couple of different reasons. The main purpose is to filter out incremental

changes that do not affect the data warehouse:

If capturing changes using LASTUPDDTTM then updates to columns not used by the

warehouse would trigger unnecessary updates. Also a date-tracked update causes two

records to be changed – one new record to be inserted (the change we are interested in)

and the old record is end-dated (not a change that affects any warehouse data)

Some OLTP tables do not have any last update timestamp, so comparing the full extract with

the PS layer allows only the true incremental changes to be processed downstream.

Another purpose of the PS layer is to do some calculations (setting indicators, domain lookups). By

doing this processing at the first opportunity it can be reused by other processes. This improves

consistency and efficiency.

Persistent Staging tables are not truncated throughout the life of the data warehouse (hence the

term “persistent”). There is a specific style of modelling PS tables. Here are a few key column

natures that might be worth to mention:

Change indicators - Whether the assignment record has a different organization, job, grade etc.

compared with the previous record. This is very common in PeopleSoft to have more than one

change pushed into a single ASSIGNMENTS record, whereas theoretically, several changes were

actually done to it. For example, Job Change, Grade change, Department Change – all three of these

can happen at the same time and PeopleSoft might only give you “one” new record reflecting all the

changes in one shot. However, these are different equally important events for our data warehouse.

To make our downstream processes simpler, we add these indicator columns, and later filter by

indicator values (0 or 1) to get our required events. Obviously, populating these indicator columns

efficiently is a non-trivial task, but the good thing is that it all comes pre-packaged for you.

Entry dates - the date of last change for organization, job, grade etc.



3.2. Incremental refresh of DW based on Event Queues

Event Queue tables help manage the incremental refresh of a history table (e.g. fact or type 2

dimension). The EQ table columns are usually the natural key plus the earliest date of change. During

incremental load it is possible for one (back-dated) change to impact many different records.

For example, the workforce fact tracks assignment changes, appraisals, salary etc. If an appraisal

rating was provided late, then the correct performance rating would need to be updated on any

assignment changes or salary changes since the appraisal. To simplify the cost of determining the

impact of changes, event queue tables only store for each assignment the date of the earliest

change. Then everything from that point on is reprocessed.

In “normal” loads only a small percentage of all assignments should change, and most changes

would be current. So the event queue tables should usually be small. The only exception is for the

monthly snapshot fact where if the load moves into a new month then a new snapshot has to be

created for all active (not terminated) assignments.

3.2.1. An incremental refresh use case

Like we mentioned earlier, this refresh strategy is useful where one update transaction on the

source can have a much bigger impact on the warehouse. In HCM, the main fact (workforce) is a

combination of mini facts from various places (assignment, appraisals, salary, budget values, length

of service, supervisor). It is more about status (balance) than tracking single events. To illustrate the

impact, suppose we have:

The fact will look something like this:

Assignment Date From Date To Event Grade Grade Change Salary Performance

1 1 Jan 31 Jan Hire A N 50 GOOD

1 1 Feb 28 Feb Appraisal A N 50 BAD

1 1 Mar 31 Mar Review B Y 60 BAD

1 1 Apr 30 Apr Appraisal B N 60 UGLY

1 1 May 31 May Review B N 70 UGLY

1 1 Jun 30 Jun Assignment B N 70 UGLY

1 1 Jul 31 Jul Appraisal B N 70 GOOD

1 1 Aug 31 Aug Review B N 80 GOOD

1 1 Sep End Assignment B N 80 GOOD

Assignment

A Grade B B B

Salary

Performance

$50k $60k $70k $80k

GOOD BAD UGLY GOOD



If we correct the second assignment record so that the grade change is deferred (A, B, B, B A, A,

B, B) then we will need to correct the records as highlighted below.

Assignment Date From Date To Event Grade Grade Change Salary Performance

1 1 Jan 31 Jan Hire A N 50 GOOD

1 1 Feb 28 Feb Appraisal A N 50 BAD

1 1 Mar 31 Mar Review A N 60 BAD

1 1 Apr 30 Apr Appraisal A N 60 UGLY

1 1 May 31 May Review A N 70 UGLY

1 1 Jun 30 Jun Assignment B Y 70 UGLY

1 1 Jul 31 Jul Appraisal B N 70 GOOD

1 1 Aug 31 Aug Review B N 80 GOOD

1 1 Sep End Assignment B N 80 GOOD

Therefore a single correction on the transaction system can result in many records requiring

correction on the warehouse. Because of the complexity of working out exactly what is impacted, a

simple and efficient refresh strategy is to capture the earliest refresh date per person/assignment

and do a refresh of that portion of the target.

Usually the event queue table will contain:

Primary Key Columns (e.g. Assignment)

Other Key Columns (e.g. Data Source)

Earliest Change / Refresh From Date (date of earliest change e.g. 1 Mar from example

above)

Previous End Date (always equal to Earliest Change Date – 1 this makes the implementation

more portable)

3.2.2. A worked out example of Event Queue table

The source table is loaded with the initial load.

Assignment Event Date Event Grade Salary LOAD_ID

1 1 Jan 2000 Hire A 50 1

1 1 Jan 2003 Review B 60 1

The target table gets the same data and calculates the effective end date:

Assignment Date From Date To Event Grade Salary LOAD_ID

1 1 Jan 2000 31 Dec 2002 Hire A 50 1

1 1 Jan 2003 End Review B 60 1

The subsequent incremental load (ID=2) changed the source table as follows:

Assignment Date From Date To Event Grade Salary LOAD_ID Comment

1 1 Jan 2000 31 Dec 2000 Hire A 50 1

1 1 Jan 2001 31 Dec 2002 Promotion B 50 2 New Record

1 1 Jan 2003 End Review B 60 1



The Event Queue Table would hold:

Assignment Earliest Change Date Previous End Date

1 1 Jan 2001 31 Dec 2000

4. General Implementation Considerations

Oracle BI Applications PeopleSoft Adaptor being a ‘packaged’ ETL application, it assumes

correctness of source OLTP data. If your source data isn’t clean enough, you are bound to encounter

problems down the line. We strongly recommend that you carry out a good health-check of your

source data (by writing custom SQL’s etc) and detect issues upfront and have them fixed, prior to

running your ETL. Areas of consideration include, but not limited to, are:

The total number of Worker and Non Worker assignments as of "End Date".

Periods during which Workers and Non Workers have assignment budget values totaling

more than one. This check requires the initial load request set to have been run.

Periods during which worker assignments do not have a supervisor.

Periods during which worker and non-worker assignments have a supervisor who has been

terminated.

Periods during which worker assignments do not have a salary.

Workers and non-workers who were terminated without providing a leaving reason.

Workers who have never had a performance review or an appraisal rating.

Assignment Budget Value Total by Supervisor

Total salaries for the supervisor's subordinates as of “End Date”.

Details of Non workers without a projected end date.

Number of users who have the ability to access Oracle Business Intelligence Applications

dashboards

Details of current users who can access Oracle Business Intelligence Applications

dashboards, but cannot view data due to security restrictions. This check requires the initial

load request set to have been run.

Supervisor Loops present in the system.

A few of these are checks for you to compare later against the warehouse. Others are examples of

possible bad data. The key is to get these results handy and on a case by case basis, have the OLTP

data corrected. For example, having a loop in the reporting relationships can make the ETL behavior

unpredictable or wrong.



5. Impact of incorrect configurations of domain values

Domain values constitute a very important foundation for Oracle Business Intelligence Applications.

We use this concept heavily all across the board to ‘equalize’ similar aspects from a variety of source

systems. The Oracle Business Intelligence Applications provide packaged data warehouse solutions

for various source systems such as E-Business Suite, PeopleSoft, Siebel, JD Edwards and so on. We

attempt to provide a “source dependent extract” type of a mapping that leads to a “source

independent load” type of a mapping, followed by a “post load” (also source independent) type of

mapping. With data possibly coming in from a variety of source systems, this equalization is

necessary. Moreover, the reporting metadata (OBIEE RPD) is also source independent. The metric

calculations are obviously source independent.

The following diagram shows how a worker status code/value is mapped onto a warehouse domain

to conform to a single target set of values. The domain is then re-used by any measures that are

based on worker status.

Domain values help us to equalize similar aspects or attributes as they come from different source

systems. We use these values in our ETL logic, sometimes even as hard-coded filters. We use these

values in defining our reporting layer metrics. And hence, not configuring, incorrectly configuring, or

changing the values of these domain value columns from what we expect, will lead to unpredictable

results. You may have a single source system to implement, but still you have to go through all the

steps and configure the domain values based on your source data. Unfortunately, this is small price

you pay for going the “buy” approach VS the traditional “build” approach for your data warehouse.

OLTP 2

Data Warehouse

OLTP 1

A

I

Active

Inactive

2

3

Suspended

Terminated

1 Active

A

I

Active

Inactive

2

3

Suspended

Terminated

1 Active

ACTIVE

INACTIVE

INACTIVE

INACTIVE

ACTIVE

Source Domain

“Active”

Measures



One of the very frequently asked question is “what is the difference between domain value

code/name pairs VS the regular code/name pairs that are stored in W_CODE_D”.

If you look at the structure of W_CODE_D table, it appears to be also capable of standardizing

code/name pairs to something common. This is correct. However, we wanted to give an extensive

freedom to users to be able to do that standardization (not necessarily equalization) of their

code/names and possibly use that for cleansing as well. For example, if the source supplied

code/name are possibly CA/CALIF or CA/California, you can choose the W_CODE_D approach (using

Master Code and Master Map tables – see configuration guide for details) to standardize on

CA/CALIFORNIA.

Now, to explain the difference of domain value code/name pairs Vs the regular code/name pairs, it

is enough if you understand the significance of the domain value concept. To keep it simple,

wherever we (Oracle Business Intelligence Applications) felt that we should equalize two similar

topics that give us analytic values, metric calculation possibilities etc, we have “promoted” a regular

code/name pair to a domain value code/name pair.

If we have a requirement to provide a metric called “Male Headcount”, we can’t do that accurately

unless we know which of the headcount is “Male” and which is “Female”. This metric therefore has

easy calculation logic: Sum of headcount where sex = Male. Since PeopleSoft can call it “M” and EBS

can have “male”, we decided to call it a domain value code/name pair, W_SEX_MF_CODE (available

in the employee dimension table). Needless to say, if you didn’t configure your domain value for this

column accurately, you won’t get this metric right.



6. Detailed understanding of the key HR ETL Processes

6.1. Core Workforce Fact Process

6.1.1. ETL Flow

JobW_ PSFT_ WEVT_JOB_PS

W_ PSFT_ WEVT_JOB_TMP

International AssignW_ PSFT_ WEVT_ IASG_PS

AppraisalW_ PSFT_ WEVT_ PERF_PS

W_ PSFT_ WEVT_ PERF_TMP

AgeW_ PSFT_ WEVT_AGE_PS

Supervisor StatusW_ PSFT_ SUPV_ STATUS_PS

Workforce Fact StagingW_ WRKFC_EVT_FS

Job International International Appraisal Supervisor Status

Events Asg Start Events Asg End Events Events Change Events

For each change type all the PS tables are joined together to produce event records

with all information correct as of the event

Workforce FactW_ WRKFC_EVT_F

Age Band DimensionW_AGE_ BAND_D

Period of Work Band Dimension

W_PRD_OF_ WRK _BAND_D

Workforce Age FactW_ WRKFC_EVT_AGE_F

Workforce Service FactW_ WRKFC_EVT_POW_F

Workforce Merge FactW_ WRKFC_EVT_ MERGE_F

Month DimensionW_ MONTH_D

Workforce Month Snapshot FactW_ WRKFC_EVT_ MONTH_F

Workforce Fact StagingW_ WRKFC_EVT_FS

Workforce Balance Aggregate

W_WRKFC_BAL_A

Workforce Event Aggregate

W_WRKFC_EVT_A

Dimension Aggregate

W_EMPLOYMENT_STAT_CA

T_D

Dimension Aggregate

W_WRKFC_EVENT_GROUP_D



6.1.2. Terminology

“Assignment” is used to refer to an instance of a person in a job. In PeopleSoft systems this

is represented in PS_JOB by a distinct combination of EMPLID and EMPL_RCD.

6.1.3. Key Steps and Table Descriptions

Initial Extract

Tables used for initial source extraction.

Table Primary Sources Grain Description

W_PSFT_WEVT_JOB_PS PS_JOB As primary source Job records on or after

initial extract date

W_PSFT_WEVT_IASG_PS PS_ASSIGNMENT

PS_ASGN_HOME_HOST

One row per international

assignment

References home and

host records for

workers on

international

assignment

W_PSFT_WEVT_PERF_PS PS_EP_APPR One row per assignment per FTE

change

Appraisal ratings

normalized (converted

to a %) and stored

against each

assignment

W_PSFT_WEVT_AGE_PS PS_PERSON As primary source Stores dates of birth for

incremental change

detection

W_PSFT_POSN_WRKR_PS W_PSFT_WEVT_JOB_PS One row per assignment per

change in supervisor/positions

Records supervisor

changes and

position/reports to

position changes if

position management is

used

W_PSFT_POSN_HLDR_PS* W_PSFT_POSN_WRKR_PS One row per position per

change in worker holding that

position

Tracks the worker

holding a given position

over time. If more than

one worker is in the

same position only one

is selected.

W_PSFT_SUPV_WRKR_PS W_PSFT_POSN_WRKR_PS

W_PSFT_POSN_HLDR_PS

One row per assignment per

change in supervisor

Translates reports to

position to a supervisor

by looking up the

worker in the position

at the time



W_PSFT_SUPV_STATUS_PS W_PSFT_SUPV_WRKR_PS One row per person per change

in supervisor status

At any given time a

person is a supervisor if

an active assignment

exists that reports to

them (via supervisor or

position)

W_WRKFC_EVT_FS W_PSFT_WEVT_JOB_PS

W_PSFT_WEVT_IASG_PS

W_PSFT_WEVT_PERF_PS


workforce event

Records workforce

events for assignments

Including appraisals and

international

assignment start/end

W_WRKFC_EVT_F W_WRKFC_EVT_F One row per assignment per

workforce event

Records workforce


from hire/start through

to termination/end.

Includes appraisals,

salary reviews and

general changes.

W_WRKFC_EVT_AGE_F W_AGE_BAND_D

W_WRKFC_EVT_F

One row per assignment per age

band change

Records age band

change events for each

assignment

W_WRKFC_EVT_POW_F W_PRD_OF_WRK_BAND_D

W_WRKFC_EVT_F


service band change

Records service band

change events for each

assignment

W_WRKFC_EVT_MERGE_F W_WRKFC_EVT_F

W_WRKFC_EVT_AGE_F

W_WRKFC_EVT_POW_F


workforce or band change event

Merges band change

events with workforce


W_WRKFC_EVT_MONTH_F W_WRKFC_EVT_MERGE_F

W_MONTH_D


change event or snapshot

month

Adds in monthly

snapshot records along

with the workforce and

band change events.

W_EMPLOYMENT_STAT_CAT

_D

W_EMPLOYMENT_D One row per Employment Status

and category.

This table is an

aggregated dimension

table on the distinct

Employment Status and

Category available in

W_EMPLOYMENT_D

table.

W_WRKFC_EVENT_TYPE_D W_WRKFC_EVENT_TYPE_DS The grain of this table is at a

single Workforce Event Type

level.

This dimension table

stores information about

a workforce event, such

as the action, whether

the organization or job



has changed, whether it

is a promotion or a

transfer, and so on. This

table is designed to be a

Type-1 dimension.

W_WRKFC_EVENT_GROUP_

D

W_WRKFC_EVENT_TYPE_D One row per Event group and

Event Sub group

This table is an

aggregate dimension

based on the Event

Group and Event Sub

Group in the

W_WRKFC_EVENT_TYPE

_D dimension table.

W_WRKFC_BAL_A W_EMPLOYMENT_STAT_CA

T_D

W_WRKFC_EVT_MONTH_F

One row per employment

status/category and snapshot

month

This is a Balance

Aggregate table based

on the Snapshot Fact

table

W_WRKFC_EVT_MONTH

_F.

W_WRKFC_EVT_A W_EMPLOYMENT_STAT_CA

T_D

W_WRKFC_EVENT_GROUP_

D

W_WRKFC_EVT_MERGE_F

One row per workforce event

group/event sub group and

employment status/category

This is an Events

Aggregate table based

on the Base Event Fact

table

W_WRKFC_EVT_MERGE

_F.

* see configuration section – these tables are used only if full or partial position management is

implemented.



Incremental Extract

Additional tables used for incremental source extraction only. Grain is for new/updated records only.

Table Primary Sources Grain

(changes)

Description

W_PSFT_WEVT_JOB_TMP PS_JOB As primary

source

Job records on or after

initial extract date

W_PSFT_WEVT_PERF_TMP PS_EP_APPR One row per

assignment

per

appraisal

Appraisal ratings

normalized (converted to a

%) and stored against each

assignment

W_PSFT_WEVT_ASG_EQ_TMP All W_PSFT_*_PS One row per

assignment

Assignments and their

earliest date of any change

W_PSFT_SUPV_OLD_TMP W_PSFT_WEVT_JOB_PS One row per

assignment

per

supervisor

change

Keeps track of prior

supervisors (before

assignments are updated)

as these may have a change

in supervisor status

W_PSFT_SUPV_EQ_TMP W_PSFT_WEVT_JOB_PS One row per

assignment

Assignments and their

earliest date of supervisor

change

W_PSFT_POSN_HLDR_EQ_TMP* W_PSFT_SUPV_EQ_TMP

W_PSFT_SUPV_OLD_TMP

W_PSFT_POSN_WRKR_PS

W_PSFT_POSN_HLDR_PS

One row per

position

Positions and the earliest

date of change of worker in

the position

W_PSFT_SUPSTAT_EQ_TMP W_PSFT_SUPV_WRKR_PS

W_PSFT_WEVT_JOB_PS

W_PSFT_POSN_WRKR_PS

W_PSFT_POSN_HLDR_PS*

One row per

person

Lists people with potential

changes in supervisor status

W_WRKFC_EVT_EQ_TMP W_WRKFC_EVT_FS One row per

changed

assignment

Reference table for which

assignments have changed

and the earliest change

dates

W_WRKFC_EVT_MONTH_EQ_TMP W_WRKFC_EVT_EQ_TMP

W_WRKFC_EVT_F

W_MONTH_D

One row per

changed

assignment

Expands

W_WRKFC_EVT_EQ_TMP to

include assignments

needing new snapshots

W_WRKFC_BAL_A_EQ_TMP W_WRKFC_EVT_MONTH_EQ_TMP

W_WRKFC_EVT_MONTH_F

W_EMPLOYMENT_STAT_CAT_D

One row per

changed

employment

status/categ


employment

status/category have

changed and the snapshot



ory and

snapshot

month

month

W_WRKFC_EVT_A_EQ_TMP W_WRKFC_EVT_EQ_TMP

W_WRKFC_EVT_MERGE_F


W_WRKFC_EVENT_GROUP_D

One row per

changed

event

group/sub

group and

employment

status/categ

ory


event group/sub groups

have changed and changed

employment

status/category.

* see configuration section – these tables are used only if full or partial position management is

implemented.

6.1.4. Key Setup/Configuration Steps

The following table documents the minimum setup required for the target snapshot fact to be

loaded successfully. For other functionality to work it is necessary to perform other setup as

documented by the installation guide below. If this is not done it may be necessary to re-run initial

load after completing the additional setup.

Type Name Description

DAC System Parameter INITIAL_EXTRACT_DATE Earliest date to extract data across all facts

HR_WRKFC_EXTRACT_DATE Earliest date to extract data from HR Facts

HR_WRKFC_ADJ_SERVICE_DATE Whether or not to count length of work from the

service date override

HR_WRKFC_SNAPSHOT _DT Earliest date to generate snapshots for HR

Workforce.

This should be set to the 1st

of a month.

HR_WRKFC_SNAPSHOT _TO_WID Current date in WID form – should not be changed

Domains Age Band Age bands need to be defined in a continuous set

of ranges

Period of Work Bands Period of work bands need to be defined in a

continuous set of ranges

Configuration Tag PeopleSoft - Populate Full/Partial

Position Management

Whether or not to load PS tables supporting

position management

Notes



1) Workforce extract date should be the earliest date from which HR data is required for

reporting (including all HR facts e.g. Absences, Payroll, Recruitment). This can be later than

initial extract date if other non-HR content loads need an earlier initial extract date.

2) Snapshots should be generated for recent years only in order to improve ETL performance

and reduce the size of the snapshot fact.



6.1.5. Customizing the Workforce Fact

Adding new attributes/measures

Modifying the existing mappings for the above tables is possible but there are many places where

code has to be changed in order to fully integrate with the existing operation.

The recommended way of extending the workforce fact is:

Add new tables to hold the additional content

For modifications to existing columns/content change the SA mapplet only

(mplt_SA_PSFT_WorkforceEventFact) and add lookup(s) to the new table(s) and modify the

output columns

For new columns, rather than change all seven mappings that load the fact staging table

(SDE_PSFT_WorkforceEventFact_*) it would be simpler to define a single post-load update

mapping that runs afterwards. This can be ordered later in the existing DAC task group

(TASK_GROUP_EXTRACT_WorkforceEventFact).

For new events – add a new mapping to load the new events and include it in the existing

DAC task group (TASK_GROUP_EXTRACT_WorkforceEventFact).

Integrating with incremental refresh

If there are changes to the extended content that require a refresh of the data for a particular

assignment (or set of assignments) then the following steps should be followed to ensure the system

remains consistent:

Modify the mapping SDE_PSFT_WorkforceEventQueue_Asg to include the assignments

requiring a refresh. Adding another UNION to pick up assignments and earliest changes from

the extended content should suffice.

Do not refresh any more data than is absolutely necessary. For example, pushing all

assignments into the event queue “to be sure of detecting all the changes” is a bad idea – it

will effectively do a very slow initial load.

If new events are added via a new mapping then this should have an incremental override to

only process assignments and dates as per the event queue (W_PSFT_WEVT_ASG_EQ_TMP).



6.1.6. W_PSFT_WEVT_JOB_PS

The job persisted staging table mirrors the job transaction table (PS_JOB) for records on or after the

initial extract date.

W_PSFT_WEVT_JOB_PS

PS_JOB

PS_PER_ORG_INST

PS_PER_ORG_ASGN

Effective end dates added

Previous FKs and change indicators added

Max sequence indicator added

Last event date calculated

Normal working hours standardized

Events mapped to conformed events

W_PSFT_WEVT_JOB_TMP

IncrementalInitial

Changes

Initial Load Sessions

SDE_PSFT_PersistedStage_WorkforceEvent_Job_Full (loads new records)

Incremental Load Sessions

SDE_PSFT_PersistedStage_WorkforceEvent_Job_Incr (stages all records in the _TMP table)

SDE_PSFT_PersistedStage_WorkforceEvent_SupOld (keeps a record of old supervisors (or

reports to positions) – where the supervisor is changed, as the old supervisor needs to be

checked for status)

SDE_PSFT_PersistedStage_WorkforceEvent_Job_Mntn (compares _TMP and _PS tables to

detect differences, and pushes the changes into the _PS table)

By default all job records are extracted during incremental load and a full comparison is done to

determine what has changed. This enables deletes to be detected. However this strategy causes

poor performance the following changes can be made to reduce the data traffic and keep the same

functionality:

1. Add a filter to the incremental extract to only process changed records

ps_job.lastupddttm >= $$LAST_EXTRACT_DATE

2. Add a delete trigger to PS_JOB to update the last update timestamp of the job record

immediately prior to the deleted record (for the same assignment). This will ensure the

delete is detected during the _Mntn mapping.



6.1.7. W_PSFT_WEVT_IASG_PS

The international assignment persistent staging table stores details of workers going on international

assignment. It tracks the period of the international assignment, and the home and host assignment.

W_PSFT_WEVT_IASG_PS

PS_ASSIGNMENT

PS_PER_ORG_ASGN

PS_ASGN_HOME_HOST

Filters out duplicate or overlapping

international assignments

W_PSFT_WEVT_IASG_TMP

IncrementalInitial

Changes


SDE_PSFT_PersistedStage_WorkforceEvent_IntlAssg_Full (loads new records)


SDE_PSFT_PersistedStage_WorkforceEvent_IntlAssg_Incr (loads changed records in the

_TMP table)

SDE_PSFT_PersistedStage_WorkforceEvent_IntlAssg_Mntn (compares _TMP and _PS tables

to detect differences, and pushes the changes into the _PS table)

There are no data change timestamp columns on the source tables, so incremental load refreshes

the international assignments ending on or after the last load date. This behaviour can be modified

by changing the incremental session source extract.



6.1.8. W_PSFT_WEVT_PERF_PS

The performance persisted staging table stores selected appraisals and ratings only. The appraisal

types to include are passed in as a parameter to the task in DAC.

W_PSFT_WEVT_PERF_PS

PS_EP_APPR

PS_REVW_RATING_TBL

Add effective dates for review ratings

Normalize ratings (converts to

percentage) for performance bands

W_PSFT_WEVT_PERF_TMP

IncrementalInitial

Changes


SDE_PSFT_PersistedStage_WorkforceEvent_Performance_Full (loads new records)


SDE_PSFT_PersistedStage_WorkforceEvent_Performance_Incr (loads changed records in the

_TMP table)

SDE_PSFT_PersistedStage_WorkforceEvent_Performance_Mntn (compares _TMP and _PS

tables to detect differences, and pushes the changes into the _PS table)

There are no data change timestamp columns on the source tables, so incremental load only

refreshes the appraisals completed within the last year. This behaviour can be modified by changing

the incremental session source extract.



6.1.9. W_PSFT_WEVT_AGE_PS

The age persisted staging table stores dates of birth for workers.

W_PSFT_WEVT_AGE_PS

PS_PERSON

Detect changes to date of birth

Sessions

SDE_PSFT_PersistedStage_WorkforceEvent_Age (loads all records)

There is a data change date column which is set whenever a person’s date of birth is changed. This is

picked up by the incremental load event queue and all records for that person are refreshed in the

fact.



6.1.10. W_PSFT_POSN_WRKR_PS

The worker position persistent staging table stores assignments and their supervisor. If position

management is used then position and reports to position are included. It tracks changes to these

attributes plus assignment start / end events all of which potentially affect the supervisor hierarchy.

W_PSFT_WEVT_JOB_PS

W_PSFT_POSN_WRKR_PSSupervisor / Position / Reports To

changes only

Adds effective dates

Filters to one change per day (if

applicable)W_PSFT_SUPV_EQ_TMP

Incremental

Only


SDE_PSFT_PersistedStage_WorkforceEvent_WorkerPosition_Full (loads new records)


SDE_PSFT_WorkforceEventQueue_Sup (loads assignments in W_PSFT_WEVT_JOB_PS that

have had a change that potentially impacts the supervisor hierarchy)

SDE_PSFT_PersistedStage_WorkforceEvent_WorkerPosition_Incr (loads changed records in

the _PS table)

SDE_PSFT_PersistedStage_WorkforceEvent_WorkerPosition_Mntn (deletes any obsolete

records in the _PS table, and maintains the effective start/end dates)



6.1.11. W_PSFT_POSN_HLDR_PS

The position holder persisted staging table stores the single worker in a given position over time. If

more than one worker has the same position one is selected arbitrarily. This table is only needed if

position management is used, so the tasks that load it can optionally be disabled – see the

configuration section above.

W_PSFT_POSN_WRKR_PS

W_PSFT_POSN_HLDR_PS


For each position, stores the worker in

that position at each point in time

If more than one worker is in the same

position, one is selected arbitrarily

W_PSFT_POSN_HLDR_EQ_TMPIncremental

Only


SDE_PSFT_PersistedStage_WorkforceEvent_PositionHolder_Full (loads new records in the

_PS table)


SDE_PSFT_WorkforceEventQueue_Pos (Identifies position changes – new positions /

assignments starting / ending / changing position)

SDE_PSFT_PersistedStage_WorkforceEvent_PositionHolder_Incr (loads changed records in

the _PS table)

SDE_PSFT_PersistedStage_WorkforceEvent_PositionHolder_Mntn (deletes any obsolete




6.1.12. W_PSFT_SUPV_WRKR_PS

The worker position persistent staging table stores assignments and their supervisor changes over

time. If position management is used then the supervisor is derived via the position holder table

(looking up the worker who is in the reports to position at the given time).

W_PSFT_POSN_WRKR_PS

W_PSFT_SUPV_WRKR_PS


Tracks the manager for each worker

over time

Manager is derived via supervisor or via

reports to position (using position holder

table to find the person in that position at

the time)

W_PSFT_POSN_HLDR_PS

W_PSFT_SUPV_EQ_TMPIncremental

Only


SDE_PSFT_PersistedStage_WorkforceEvent_WorkerSupervisor_Full (loads new records)


SDE_PSFT_WorkforceEventQueue_SupPosChanges (adds in assignments needing refresh

due to a change in position holder table)

SDE_PSFT_PersistedStage_WorkforceEvent_WorkerSupervisor_Incr (loads changed records

in the _PS table)

SDE_PSFT_PersistedStage_WorkforceEvent_WorkerSupervisor_Mntn (deletes any obsolete




6.1.13. W_PSFT_SUPV_STATUS_PS

The supervisor status persistent staging table stores for each person whether or not they are a

supervisor at any point in time. A person is a supervisor at a given point in time if they supervise one

or more assignments that are active at that time (or, if position management is used, then a person

is a supervisor if there is a worker reporting to the position held by the person).

W_PSFT_WEVT_JOB_PS

W_PSFT_SUPV_OLD_TMPPre-refresh supervisor (or position)

pending changes

W_PSFT_SUPV_STATUS_PSStatus changes only

W_PSFT_SUPSTAT_EQ_TMPPeople potentially changing status

Pre-refresh

Incremental

W_PSFT_SUPV_WRKR_PS

Supervisor changes over time

W_PSFT_POSN_WRKR_PSSupervisor / Position / Reports To

changes over time

W_PSFT_POSN_HLDR_PSTracks holding worker in a position

over time


SDE_PSFT_PersistedStage_WorkforceEvent_SupervisorStatus_Full (loads new records)


SDE_PSFT_WorkforceEventQueue_SupStatus (separate task to load people whose

supervisor status changed into an event queue)

SDE_PSFT_WorkforceEventQueue_AsgUpdate (pushes assignments whose owners

supervisor status has changed into the main assignment change queue to force the fact

refresh to pick up the change in status)

SDE_PSFT_PersistedStage_WorkforceEvent_SupervisorStatus_Incr (loads changed records)

SDE_PSFT_PersistedStage_WorkforceEvent_SupervisorStatus_Mntn (deletes records to be

re-inserted, maintains date-track)



6.1.14. W_PSFT_WEVT_ASG_EQ_TMP

Stores a list of assignments that have had a change in any one of the PS tables. Any change may

impact several records – so the fact is refreshed based on the earliest change, and all subsequent

events are re-loaded.

JobW_PSFT_WEVT_JOB_PS

International AssignW_PSFT_WEVT_IASG_PS

AppraisalW_PSFT_WEVT_PERF_PS

AgeW_PSFT_WEVT_AGE_PS

Supervisor StatusW_PSFT_SUPV_STATUS_PS

Workforce Event QueueW_PSFT_WEVT_ASG_EQ_TMP


None


SDE_PSFT_WorkforceEventQueue_Asg (Changes from any source PS table)

SDE_PSFT_WorkforceEventQueue_AsgUpdate (Merges in supervisor status changes)



6.1.15. W_WRKFC_EVT_FS

The fact staging table is loaded from the PS tables. Workforce events may derive from any of these

sources, and each source gives a workforce event with a different change type to help track the

source of the event.

For each change type there is one mapping that loads events into staging (sourced primarily from

the one PS table corresponding to the change type). However to ensure every measure/attribute is

available for each event record, all the rows are joined together for each mapping.

In incremental load each mapping additionally joins to the event queue table to restrict the

processing to only new/changed records – plus all subsequent events to ensure consistency.

JobW_PSFT_WEVT_JOB_PS

International AssignW_PSFT_WEVT_IASG_PS

AppraisalW_PSFT_WEVT_PERF_PS

Supervisor StatusW_PSFT_SUPV_STATUS_PS

Event QueueW_PSFT_ASG_EQ_TMP

Workforce Fact StagingW_WRKFC_EVT_FS

Job International International Appraisal Supervisor Status

Events Asg Start Events Asg End Events Events Change Events

For each change type all the PS tables are joined together to produce event records

with all information correct as of the event


SDE_PSFT_PersistedStage_WorkforceEventFact_*_Full (loads all records)


SDE_PSFT_PersistedStage_WorkforceEventFact_* (loads new/changed records as per event

queue)



6.1.16. Workforce Base Fact (W_WRKFC_EVT_F)

Calculates EFFECTIVE_END_DATE based

on next event date

W_WRKFC_EVT_F

W_WRKFC_EVT_FS

W_WRKFC_EVT_EQ_TMP

Incremental

only

Deletes any obsolete fact records

Maintains effective start/end dates

Incremental

only

The workforce base fact is refreshed from the workforce fact staging table.

Effective end date is calculated based on the next event date

Deleted events are removed (subsequent events previously loaded but no longer staged –

see Incremental Load section on backdated changes)


SIL_WorkforceEventFact (loads new/updated records)


SIL_WorkforceEventFact (loads new/updated records)

PLP_WorkforceEventQueue_Asg (loads change queue table with changed (staged)

assignments and their earliest change (staged event) date)

PLP_WorkforceEventFact_Mntn (deletes obsolete events – see note above)

The date-track (having a continuous non-overlapping set of effective start/end dates per

assignment) is critical to downstream facts and the correct operation of the reports.

Deletes can also be handled separately (see deletes section below) but care needs to be taken to

ensure the date-track is correctly maintained if deleting individual records.



6.1.17. Workforce Age Fact (W_WRKFC_EVT_AGE_F)

W_WRKFC_EVT_AGE_F

W_WRKFC_EVT_FW_AGE_BAND_D

The age fact contains one starting row plus one row each time an assignment moves from one age

band to the next. For example, if the last age band is 55+ years then there will be an event generated

for each assignment on the 55th birthday of the worker (BIRTH_DT + 55 years). Any worker hired

beyond the age of 55 will have no additional band change events, just the starting row.

Note the age bands are completely configurable, but because of the dependencies between the age

bands and the facts any changes to the configuration will require a reload (initial load).

This fact is refreshed for an assignment whenever there is a change to the worker’s date of birth on

the hire record (or the first record if the hire occurred before the fact initial extract date).


PLP_WorkforceEventFact_Age_Full (loads new records)


PLP_WorkforceEventFact_Age_Mntn (deletes records to be refreshed or obsolete)

PLP_WorkforceEventFact_Age (loads changed records)



6.1.18. Workforce Period of Work Fact (W_WRKFC_EVT_POW_F)

W_WRKFC_EVT_POW_F

W_WRKFC_EVT_FW_PRD_OF_WRK_BAND_D

The period of work fact contains one starting row plus one row each time an assignment moves from

one service band to the next. For example, if the first service band is 0-1 years then there will be an

event generated for each assignment exactly one year after hire (POW_START_DT).

Note the period of work bands are completely configurable, but because of the dependencies

between the service bands and the facts any changes to the configuration will require a reload

(initial load).

This fact is refreshed whenever there is a change to the hire record (or first record if the hire was

before the fact initial extract date).


PLP_WorkforceEventFact_Pow_Full (loads new records)


PLP_WorkforceEventFact_Pow_Mntn (deletes records to be refreshed)

PLP_WorkforceEventFact_Pow (loads changed records)



6.1.19. Workforce Merge Fact (W_WRKFC_EVT_MERGE_F)

W_WRKFC_EVT_MERGE_F

W_WRKFC_EVT_AGE_FW_WRKFC_EVT_F W_WRKFC_EVT_POW_F

This fact contains the change events from the base, age and service facts. It is refreshed based on

the combination of assignments and (earliest) event dates in the fact staging table.


PLP_WorkforceEventFact_Merge_Full (loads new records)


PLP_WorkforceEventFact_Merge_Mntn (deletes records to be refreshed)

PLP_WorkforceEventFact_Merge (loads changed records)



6.1.20. Workforce Month Snapshot Fact (W_WRKFC_EVT_MONTH_F)

W_WRKFC_EVT_MONTH_F

W_WRKFC_EVT_MERGE_FW_MONTH_D

Workforce

EventsMonthly

Snapshots

This fact contains the merged change events plus a generated snapshot record on the first of every

month on or after the HR_WRKFC_SNAPSHOT_DT parameter. To allow future-dated reporting

snapshots are created up to 6 months in advance.

This fact is refreshed based on:

Combination of assignments and (earliest) event dates in the fact staging table

Any snapshots required for active assignments since the last load (e.g. if the incremental

load is not run for a while, or the system date moves into a new month since the last load)


PLP_WorkforceEventFact_Month_Full (loads new records)


PLP_WorkforceEventQueue_AsgMonth (adds to the change queue table any assignments

needing new snapshots since the last load)

PLP_WorkforceEventFact_Month_Mntn (deletes records to be refreshed)

PLP_WorkforceEventFact_Month (loads changed records)



6.1.21. Workforce Aggregate Fact (W_WRKFC_BAL_A)

Dimension

W_EMPLOYMENT_D

Workforce Dimension Aggregate


Workforce Month Snapshot Fact

W_WRKFC_EVT_MONTH_F

Workforce Aggregate Fact

W_WRKFC_BAL_A

PLP

Dimension

Aggregate Load

FULL and INCR

PLP Load Process

FULL

Change Queue table

W_WRKFC_BAL_A_EQ_TMP

PLP

Parent level

Update

FULL and

INCR

Aggregate Fact is loaded

directly by Employment

Dimension but it still remains

at the grain of

the Employment Stat Cat

Aggregate Dimension

PLP Load process

INCR only

Workforce Month Fact

W_WRKFC_EVT_MONTH_F

Change queue tableW_WRKFC_EVT_MONTH_EQ_TM

P

PLP

INCR only

Aggregate dimension W_EMPLOYMENT_STAT_CAT_D is based on the distinct Employment Status

and Category available in W_EMPLOYMENT_D table.

Aggregate Fact table (W_WRKFC_BAL_A) is based on the Snapshot Fact table

W_WRKFC_EVT_MONTH_F and Aggregate dimension W_EMPLOYMENT_STAT_CAT_D so as to

improve performance of Fact table W_WRKFC_EVT_MONTH_F.

Aggregate Fact W_WRKFC_BAL_A is loaded directly by Dimension W_EMPLOYMENT_ D (essentially

remains at the grain of Dimension Aggregate W_EMPLOYMENT_ STAT_CAT_D) and Workforce

Month Snapshot Fact W_WRKFC_EVT_MONTH_F.




PLP_EmploymentDimensionAggregate_Load_Full (Loads Aggregate dimension

W_EMPLOYMENT_STAT_CAT_D based on the distinct Employment Status and Category

available in W_EMPLOYMENT_D table.

PLP_EmploymentDimension_ParentLevelUpdate_Full(Aggregate dimension

W_EMPLOYMENT_STAT_CAT_D updates parent dimension W_EMPLOYMENT_D table

PLP_WorkforceBalanceAggregateFact_Load _Full (loads new records into the Balance

Aggregate Fact table based on W_WRKFC_EVT_MONTH_F and the Aggregate Dimension

(W_EMPLOYMENT_STAT_CAT_D).Although it gets directly loaded from

W_EMPLOYMENT_D, the Balance Aggregate Fact remains at the grain of the Aggregate

Dimension (W_EMPLOYMENT_STAT_CAT_D))


PLP_EmploymentDimensionAggregate_Load (Loads new rows into Aggregate dimension

W_EMPLOYMENT_STAT_CAT_D from current ETL run, based on the distinct Employment

Status and Category available in W_EMPLOYMENT_D table.)

PLP_EmploymentDimension_ParentLevelUpdate(Aggregate dimension

W_EMPLOYMENT_STAT_CAT_D updates parent dimension W_EMPLOYMENT_D table)

PLP_WorkforceBalanceAggregateFact_Load (deletes records that came in the event queue

table (W_WRKFC_BAL_A_EQ_TMP)and loads new records into the Balance Aggregate Fact

table)

PLP_WorkforceBalanceQueueAggregate_PostLoad (Loads Event Queue table

W_WRKFC_BAL_A_EQ_TMP with records based on W_WRKFC_EVT_MONTH_EQ_TMP and

W_WRKFC_EVT_MONTH_F)



6.1.22. Workforce Aggregate Event Fact (W_WRKFC_EVT_A)

Dimension

W_EMPLOYMENT_D

Workforce Dimension

Aggregate

W_EMPLOYMENT_STAT_

CAT_D

Workforce Event Merge Fact

W_WRKFC_EVT_MERGE

_F

Workforce Aggregate Fact

W_WRKFC_EVT_A

PLP

Dimension

Aggregate Load

FULL and INCR

PLP Load Process

FULL

Change Queue table

W_WRKFC_EVT_A_EQ_T

MP

PLP

Parent level

Update

FULL and

INCR


directly by Employment

Dimension but it is at the

grain of

the Employment Stat Cat

Aggregate Dimension

Workforce Dimension

Aggregate

W_WRKFC_EVENT_GRO

UP_D

Dimension

W_WRKFC_EVENT_TYPE_D

PLP

Dimension

Aggregate Load

FULL and INCR

PLP

Parent level

Update

FULL and

INCR


directly by Workforce Event

Type Dimension but it is at

the grain of

the Workforce Event Group

Aggregate Dimension

W_WRKFC_EVT_MERGE_F W_WRKFC_EVT_EQ_TMP

PLP

INCR only

PLP Load process

INCR only

Aggregate dimension (W_EMPLOYMENT_STAT_CAT_D) is based on the distinct Employment

Status and Category available in W_EMPLOYMENT_D table.

Aggregate dimension (W_WRKFC_EVENT_GROUP_D) is based on the Event Group and Event Sub

Group in the W_WRKFC_EVENT_TYPE_D dimension table.

W_WRKFC_EVT_A is an Aggregate Fact table based on the Merged Event Fact table,

W_WRKFC_EVT_MERGE_F, Aggregate dimension W_WRKFC_EVENT_GROUP_D and Aggregate

dimension W_EMPLOYMENT_STAT_CAT_D, to improve performance of W_WRKFC_EVT_MERGE_F.

Aggregate Fact W_WRKFC_EVT_A is loaded directly by Dimension W_EMPLOYMENT_ D (essentially

remains at the grain of Dimension Aggregate W_EMPLOYMENT_STAT_CAT_D), Dimension

W_WRKFC_EVENT_TYPE_D (essentially remains at the grain of Dimension Aggregate

W_WRKFC_EVENT_GROUP_D) and Workforce Fact W_WRKFC_EVT_MERGE_F.




PLP_EmploymentDimensionAggregate_Load_Full (Loads Aggregate dimension

W_EMPLOYMENT_STAT_CAT_D based on the distinct Employment Status and Category

available in W_EMPLOYMENT_D table.)

PLP_EmploymentDimension_ParentLevelUpdate_Full(Aggregate dimension


PLP_WorkforceEventGroupDimensionAggregate_Load_Full (Loads Aggregate dimension

(W_WRKFC_EVENT_GROUP_D) based on the Event Group and Event Sub Group in the

W_WRKFC_EVENT_TYPE_D dimension table.)

PLP_WorkforceEventGroupDimension_ParentLevelUpdate (Aggregate dimension

(W_WRKFC_EVENT_GROUP_D) updates EVENT_GROUP_WID of parent level dimension

(W_WRKFC_EVENT_TYPE_D))

PLP_WorkforceEventAggregateFact_ Full (loads new records into the Event Aggregate Fact

table (W_WRKFC_EVT_A) based on Workforce Fact table (W_WRKFC_EVT_MERGE_ F),

Aggregate Dimension (W_EMPLOYMENT_STAT_CAT_D) and Aggregate Dimension

(W_WRKFC_EVENT_GROUP_D).

Although it gets directly loaded from W_EMPLOYMENT_D and W_WRKFC_EVENT_TYPE_D,

the Balance Aggregate Fact remains at the grain of the Aggregate Dimensions

(W_EMPLOYMENT_STAT_CAT_D and W_WRKFC_EVENT_GROUP_D))


PLP_EmploymentDimensionAggregate_Load (Loads new rows into Aggregate dimension

W_EMPLOYMENT_STAT_CAT_D from current ETL run, based on the distinct Employment

Status and Category available in W_EMPLOYMENT_D table.)

PLP_EmploymentDimension_ParentLevelUpdate(Aggregate dimension


PLP_WorkforceEventGroupDimensionAggregate_Load (Loads new rows into Aggregate

dimension (W_WRKFC_EVENT_GROUP_D) from current ETL run, based on the Event Group

and Event Sub Group in the W_WRKFC_EVENT_TYPE_D dimension table.)

PLP_WorkforceEventGroupDimension_ParentLevelUpdate(Aggregate dimension

(W_WRKFC_EVENT_GROUP_D) updates parent level dimension

(W_WRKFC_EVENT_TYPE_D) )



PLP_WorkforceEventAggregateFact (deletes records that came in the event queue table

(W_WRKFC_EVT_A_EQ_TMP)and loads new records into the Workforce Event Aggregate

Fact table)

PLP_WorkforceEventQueueAggregate_PostLoad (Loads Event Queue table

W_WRKFC_EVT_A_EQ_TMP with records based on W_WRKFC_EVT_EQ_TMP and

W_WRKFC_EVT_F)



6.1.23. Handling Deletes

W_WRKFC_EVT_F

W_WRKFC_EVT_F_PE

W_WRKFC_EVT_DEL_F

Source OLTP

Any fact record where:

Fact integration key is not in the

primary extract table, or

Fact assignment key is not in the

primary extract table

Integration keys

or assignments

Set delete

flag

Records to

be deleted

All the standard OBIA mappings are provided for processing deletes (Primary Extract, Identify

Deletes, and Soft Delete). However because of the added complexity of maintaining the date-track

(continuous set of effective start/end dates per assignment) the functionality differs slightly.

There are two types of delete to make a distinction between:

Date-tracked delete – a single record is deleted for an assignment, but others remain

Purge – all records for an assignment are deleted, the assignment no longer exists on the

source transaction system

These are discussed in more detail below.

6.1.24. Propagating to derived facts

The incremental load for derived facts will automatically detect any records deleted via the delete

process (W_WRKFC_EVT_F_DEL). Deleted records will be physically removed from the derived fact

tables as part of the incremental refresh.



6.1.25. Date-tracked Deletes

To delete individual records using the standard delete mappings the primary keys of the fact should

be extracted into the primary extract table. Then the identify delete mapping will compare the

primary extract table with the fact table and the soft delete mapping will flag as deleted any record

in the fact which is not in the primary extract table.

6.1.26. Purges

To purge all records for an assignment using the standard delete mappings the distinct assignment

ids should be extracted into the primary extract table. Then the identify delete mapping will

compare the primary extract table with the fact table and the soft delete mapping will flag as

deleted all records for assignments in the fact which are not in the primary extract table.

6.1.27. Primary Extract

W_WRKFC_EVT_F_PEDATASOURCE_NUM_ID

INTEGRATION_ID (ASSIGNMENT_ID)

Source OLTP

W_WRKFC_EVT_F_PEDATASOURCE_NUM_ID

INTEGRATION_IDEither / Or

Extract from the source OLTP either the valid assignments or valid integration keys for the fact. The

delete process will delete fact records with no valid assignment (purge) and no valid integration key

(individual record delete). This step can be skipped if there is an alternative method (e.g. source

trigger) of detecting the purges or deletes and pushing the fact keys to delete directly to the

W_WRKFC_EVT_F_DEL table.

The recommendation is to use the purge – only extract the distinct valid assignment ids. If the other

option is used then care should be taken to leave the fact consistent. See the worked example

below.



6.1.28. Identify Delete

W_WRKFC_EVT_FW_WRKFC_EVT_F_PE

W_WRKFC_EVT_DEL_F

Any fact record where:

Fact integration key is not in the

primary extract table, or

Fact assignment key is not in the

primary extract table

Records to

be deleted

Compares the primary extract table with the fact table to detect purges or deletes. The primary keys

of fact records to be deleted are inserted into the delete table.

This step can be skipped if there is an alternative method (e.g. source trigger) of detecting the

purges or deletes and pushing the fact keys to delete directly to the W_WRKFC_EVT_F_DEL table.

Incremental Sessions:

SIL_WorkforceEventFact_IdentifyDelete

6.1.29. Soft Delete

W_WRKFC_EVT_F

W_WRKFC_EVT_DEL_F

Set delete

flag

This updates the delete flag to “Y” (Yes) for fact records in the delete table.

Incremental Sessions:

SIL_WorkforceEventFact_SoftDelete



6.1.30. Date-Tracked Deletes - Worked Example

The recommended way of handling date-tracked deletes in the workforce fact is to always stage

changed records (in the case of a delete – the previous record) and allow the fact incremental load

mappings handle the changes. The following example shows what can happen if the fact is not

maintained correctly when deleting records.

W_WRKFC_EVT_F

Suppose after initial load the following data was loaded in the fact table for assignment 1:

Assignment Start Date End Date Change Type Organization Salary

1 01-Jan-2000 31-Dec-2000 HIRE A 5000

1 01-Jan-2001 31-Dec-2001 REVIEW A 6000

1 01-Jan-2002 31-Dec-2002 TRANSFER B 6000

1 01-Jan-2003 01-Jan-3714 REVIEW B 7000

Now suppose the transfer record was deleted on the source transaction system. If this was handled

by the primary extract – identify delete – soft delete mappings then there would be the following

records left in the fact table (delete flag = ‘N’):

Assignment Start Date End Date Change Type Organization Salary

1 01-Jan-2000 31-Dec-2000 HIRE A 5000

1 01-Jan-2001 31-Dec-2001 REVIEW A 6000

1 01-Jan-2003 01-Jan-3714 REVIEW B 7000

This is wrong on two counts:

1. The date-track is not continuous, so downstream ETL may fail or lose data. Also reports in

Answers may not return data for the gaps in the date-track.

2. The data is not consistent – since the transfer has been deleted the REVIEW on 01-Jan-2003

should not still be showing organization B.

The first issue would be reasonably simple to fix with an update (either pushing the updated record

into the fact staging table, or if directly updating the fact it would be necessary to track the event

(effective start) date of the updated row in W_WRKFC_EVT_EQ_TMP).

However the second issue is more complex. By allowing the fact incremental load to take care of the

deletes these issues are avoided.



6.2. Recruitment Fact Process

6.2.1. ETL Flow

Job Requisition Event Fact

W_JOB_RQSTN_EVENT_F

Job Requisition Accumulated Snpsht Fact

W_JOB_RQSTN_ACC_SNP_F

Recruitment Pipeline Fact

W_RCRTMNT_EVENT_F

Recruitment Job Req Aggregate

W_RCRTMNT_RQSTN_A

Job Requisition Event Fact Staging

W_JOB_RQSTN_EVENT_FS

Applicant Event Fact Staging

W_APPL_EVENT_FS

Applicant Event Fact

W_APPL_EVENT_F

Applicant Accumulated Snapshot Fact

W_APPL_ACC_SNP_F

Recruitment Applicant Aggregate

W_RCRTMNT_APPL_A

Recruitment Hire Aggregate

W_RCRTMNT_HIRE_A

PS

FT

Syste

m

PS

FT

Syste

m

HRS_JOB_OPENING,

HRS_JO_STS,

JOBCODE_TBL

HRS_APPLICANT,

HRS_RCMNT_STS,

HRS_RCMNT,

HRS_JOB_OPENING,

HRS_INT_EVAL,

HRS_INT_RTG_TBL,

HRS_SCR_RSLT,

HRS_EE_REFERRAL

Appraisal

W_PSFT_WEVT_PERF_PS

Applicant Employee Map

W_PSFT_APPL_EVENT_F_TMP

Job

W_PSFT_WEVT_JOB_PS



W_JOB_RQSTN_EVENT_FS HRS_JOB_OPENING

HRS_JO_STS

JOBCODE_TBL

One row per job

requisition per job

requisition event per

event date

Records job requisition

events for all job

requisitions from open

through to close/fulfilment.

W_APPL_EVENT_FS HRS_APPLICANT

HRS_EE_REFERRAL

HRS_RCMNT

HRS_RCMNT_STS

HRS_JOB_OPENING

HRS_INT_EVAL

HRS_SCR_RSLT

HRS_INT_RTG_TBL

W_PSFT_WEVT_PERF_PS

W_PSFT_WEVT_JOB_PS


One row per application

per job requisition event

per event date and

sequence

Records application events

for all applications from

applying, screening,

selection though offer

extension, hire or

termination of the

application.



W_JOB_RQSTN_EVENT_F W_JOB_RQSTN_EVENT_FS One row per job

requisition per job

requisition event per

event date


events for all job

requisitions from open

through to close/fulfilment.

W_JOB_RQSTN_ACC_SNP_F W_JOB_RQSTN_EVENT_F One row per job

requisition


related event dates, de-

normalized.

W_APPL_EVENT_F W_APPL_EVENT_FS One row per application

per job requisition event

per event date and

sequence

Records application events

for all applications from

applying, screening,

selection though offer

extension, hire or

termination of the

application.

W_APPL_ACC_SNP_F W_APPL_EVENT_F One row per application Records application related

event dates, de-normalized.

W_RCRTMNT_EVENT_F W_JOB_RQSTN_F

W_APPL_EVENT_F


W_APPL_ACC_SNP_F

One row per recruitment

event type per event date

and sequence

Merges the job requisition

events and application

events along with de-

normalized event dates.

Also known as the

Recruitment Pipeline fact.

W_RCRTMNT_RQSTN_A W_RCRTMNT_EVENT_F

W_MONTH_D

One row per job

requisition per

recruitment event month

Aggregates the job

requisition related metrics

at a monthly grain.

W_RCRTMNT_APPL_A W_RCRTMNT_EVENT_F

W_MONTH_D

One row per applicant’s

demographics per

recruitment event month

Aggregates the applicant

related metrics at a

monthly grain.

W_RCRTMNT_HIRE_A W_RCRTMNT_EVENT_F

W_MONTH_D

One row per hired

applicant’s demographics

per recruitment event

month

Aggregates the applicant

related metrics with a focus

on hired applicants only at a

monthly grain.


All the set up and configuration steps that are required for core Workforce also applies for

Recruitment (see the same section for Workforce). For PeopleSoft adaptors, there are no more extra

configuration steps required as long as the domain values are configured accurately.



6.2.4. W_JOB_RQSTN_EVENT_FS

Staging area table used to store Job Requisition related information from PeopleSoft.

Records job requisition events for all job requisitions from open through to close/fulfilment.


HRS_JOB_OPENING

HRS_JO_STS

JOBCODE_TBL

FULL

And

INCR


SDE_PSFT_JobRequisitionEventFact_Full (Loads all records into Job requisition Fact staging

table with details of the Job Requisition such as Status, Recruiter and Manager information)


SDE_PSFT_JobRequisitionEventFact (Loads all records into Job requisition Fact staging table

with details of the Job Requisition such as Status, Recruiter and Manager information after

the last extract date after the last extract date)



6.2.5. W_PSFT_APPL_EVENT_F_TMP

Temporary table, that records application events for all applications from applying, screening,

selection though offer extension, hire or termination of the application.


HRS_APPLICANT HRS_EE_REFERRAL

HRS_HIRE HRS_RCMNT HRS_STS_TBL

FULL

&

INCR


SDE_PSFT_ApplicantEvent_EmpAppl_Full ( Loads all records from HRS* tables into

temporary table W_PSFT_APPL_EVENT_TMP)


SDE_PSFT_ApplicantEvent_EmpAppl ( Loads records from HRS* into temporary table

W_PSFT_APPL_EVENT_TMP after the last extract date)



6.2.6. W_APPL_EVENT_FS

Staging table that records application events for all applications from applying, screening, selection

though offer extension, hire or termination of the application.

Applicant Event Fact Staging

W_ APPL_ EVENT_FS

Appraisal

W_ PSFT_ WEVT_ PERF_PS

Applicant Employee Map

W_ PSFT_ APPL_ EVENT_F_TMP

Job

W_ PSFT_ WEVT_JOB_PS

FULL

&

INCR

FULL

& INCR

FULL

&INCR

PS

FT

Syste

m

HRS_ APPLICANT,

HRS_ RCMNT_STS,

HRS_ RCMNT,

HRS_JOB_ OPENING,

HRS_INT_ EVAL,

HRS_INT_RTG_TBL,

HRS_SCR_ RSLT,

HRS_EE_ REFERRAL


SDE_PSFT_ApplicantEventFact_Full (Loads all Applicant records into staging table

W_APPL_EVENT_FS from PeopleSoft Source tables with details such as Applicant Id, Referrer

Id, Scores and so on)

SDE_PSFT_ApplicantEvent_EmployeeEvent (Updates applicant records in table

W_APPL_EVENT_FS with Employee details from temporary table

W_PSFT_APPL_EVENT_F_TMP and Workforce job persisted stage table

W_PSFT_WEVT_JOB_PS. W_PSFT_APPL_EVENT_F_TMP table acts as a bridge between

Applicant and Employee to get Employee related details of an applicant)

SDE_PSFT_ApplicantEvent_PerformanceReviews (Updates records in table

W_APPL_EVENT_FS with Performance details such as review rating and performance rating

if available from tables W_PSFT_WEVT_JOB_PS and W_PSFT_WEVT_PERF_PS.

W_PSFT_APPL_EVENT_F_TMP table is used in the process that acts as a bridge between

Applicant and Employee to get Employee related details of an applicant)


SDE_PSFT_ApplicantEventFact (Loads all Applicant records into staging table

W_APPL_EVENT_FS from PeopleSoft Source tables with details such as Applicant Id, Referrer

Id, Scores and so on after last extract date)



SDE_PSFT_ApplicantEvent_EmployeeEvent (Updates applicant records in table

W_APPL_EVENT_FS with Employee details from temporary table

W_PSFT_APPL_EVENT_F_TMP and Workforce job persisted stage table

W_PSFT_WEVT_JOB_PS. W_PSFT_APPL_EVENT_F_TMP table acts as a bridge between

Applicant and Employee to get Employee related details of an applicant. The PS tables are

used in a way that only changed/new records are processed)

SDE_PSFT_ApplicantEvent_PerformanceReviews (Updates records in table

W_APPL_EVENT_FS with Performance details such as review rating and performance rating

if available from tables W_PSFT_WEVT_JOB_PS and W_PSFT_WEVT_PERF_PS.

W_PSFT_APPL_EVENT_F_TMP table is used in the process that acts as a bridge between

Applicant and Employee to get Employee related details of an applicant. The PS tables are

used in a way that only changed/new records are processed)

6.2.7. Job Req. & Applicant Event Facts (W_JOB_RQSTN_EVENT_F &

W_APPL_EVENT_F)

These two tables are loaded via the corresponding staging tables (W_JOB_RQSTN_EVENT_FS and

W_APPL_EVENT_FS).


W_JOB_RQSTN_EVENT_F

Job Requisition Accumulated

Snapshot Fact



W_APPL_EVENT_F

Applicant Accumulated Snapshot

Fact

W_APPL_ACC_SNP_F

FULL load

process (Job

Req.)

FULL load

process

(Applicant)

Job Req. Age

Band Events

(FULL)

Applicant

Generated

Events (FULL)


Stage


Applicant Event Fact Stage

W_APPL_EVENT_FS




W_JOB_RQSTN_EVENT_F


Snapshot Fact



W_APPL_EVENT_F


Fact

W_APPL_ACC_SNP_F

INCR load

process (Job

Req.)

INCR load

process

(Applicant)

Job Req. Age

Band Events

(INCR)

Applicant

Generated

Events (INCR)


Stage


Applicant Event Fact Stage

W_APPL_EVENT_FS

Applicant POW

Events (INCR)


SIL_JobRequisitionEventFact_Full (loads new records)

SIL_ApplicantEventFact_Full (loads new records)

PLP_JobRequisition_AgeBandEvents_Full (deletes and creates requisition age band change

event records for those job requisitions that are supposed to enter a new requisition age

band based on their current age since opening, and applies this new event to the job

requisition accumulated snapshot fact)

PLP_ApplicantEventFact_GeneratedEvents_Full (deletes and generates pseudo applicant

events that were not supplied by source system, but necessary for the complete analysis of

the recruitment pipeline process)


SIL_JobRequisitionEventFact (updates changed records and loads new records)

PLP_JobRequisition_AgeBandEvents (deletes and creates requisition age band change

event records for those job requisitions that are supposed to enter a new requisition age

band based on their current age since opening and applies this new event to the job

requisition accumulated snapshot fact)

SIL_ApplicantEventFact (updates changed records and loads new records)

PLP_ApplicantEventFact_GeneratedEvents_Full(deletes and generates pseudo applicant

events that were not supplied by source system, but necessary for the complete analysis of

the recruitment pipeline process)

PLP_ApplicantEventFact_PeriodOfWorkEvents (generates pseudo period-work-work-band-

crossing events in case a hired applicant crosses his/her first period of work band; this is



something that the source does not give and we do it for all applicants assuming all of them

will be hired and stay for the first period-of-work-band timeframe)

6.2.8. Job Requisition Accumulated Snapshot Fact (W_JOB_RQSTN_ACC_SNP_F)

This table stores the de-normalized dates against various job requisition events from the Job

Requisition Events base fact table. After the pseudo Age Band Change events are populated in the

base Job Requisition fact table, those dates are also reflected in the Accumulated snapshot fact

table. Any changes to the Hiring Manager Position Hierarchy are also updated in this accumulated

snapshot fact. Note that the updates because of hierarchy changes do not apply during full ETL run.


W_JOB_RQSTN_EVENT_F


Snapshot Fact


Position Hierarchy Post Change Temporary

W_POSITION_DH_POST_CHG_TMP

Job Req. Age

Band Events

(FULL & INCR)

Position Hierarchy Update Process

(INCR ONLY)

Job Req. Load

(FULL & INCR)

Age Band Dimension

W_AGE_BAND_D

Position Hierarchy Pre Change Temporary

W_POSITION_DH_PRE_CHG_TMP


PLP_JobRequisition_AccumulatedSnapshot_Full (loads new records)

PLP_JobRequisition_AgeBandEvents_Full (after the age-band-change events are recorded

in the base Job Requisition fact table, this mapping updates the related date column in the

accumulated snapshot fact table)


PLP_JobRequisition_AccumulatedSnapshot (updates changed records and loads new

records)

PLP_JobRequisition_AgeBandEvents(after the age-band-change events are recorded in the

base Job Requisition fact table, this mapping updates the related date column in the

accumulated snapshot fact table)



PLP_JobRequisition_AccumulatedSnapshot_PositionHierarchy_Update (changes in the Hiring Manager Position Hierarchy due to regular or back dated changes are applied to the accumulated snapshot fact table)

6.2.9. Applicant Accumulated Snapshot Fact (W_APPL_ACC_SNP_F)

This table stores the de-normalized dates against various applicant events from the Applicant Events

base fact table. After the pseudo Age Band Change, Period of Work Band Change and other ‘Missing’

recruitment pipeline events are populated in the base Applicant Event fact table those dates are also

reflected in the Accumulated snapshot fact table.


W_APPL_EVENT_F


Fact

W_APPL_ACC_SNP_F

Period of

Work Band

Events

(FULL &

INCR)

Applicant

Load (FULL

& INCR)

Period of Work Band Dimension

W_PRD_OF_WRK_BAND_D


PLP_Applicant_AccumulatedSnapshot_Full (loads new records)


PLP_Applicant_AccumulatedSnapshot (updates changed records and loads new records)

6.2.10. Recruitment Pipeline Event Fact (W_RCRTMNT_EVENT_F)

This is the main Recruitment Pipeline event fact table that is used for the reporting needs, and also is

used to build aggregate tables at three different grains for reporting purposes. The main purpose of

this table is to merge both sides of the recruitment events (job requisition events as well as applicant

events) and on top of that provide some value added metrics.



At first, the image of this table is captured prior to loading any data into an “Event Queue” table, the

purpose of which is to track all changes that are about to happen in this current run. Since this ‘pre-

image’ is captured by comparing to the main pipeline fact table, this ‘pre-imaging’ process does not

apply during full ETL run. Note that this pre-imaging process occurs from both sides (job requisition

events as well as applicant events) and apart from the event queue table; these processes also

populate another temporary table (W_RCRTMNT_EVENT_F_TMP) which comes in handy during

aggregate building.

Next, the data from either side are brought into the pipeline fact. The Event queue table drives the

merge process during incremental runs to get better performance. Once the data is loaded, a “post-

image” process captures the image of the loaded pipeline fact table and writes it to the temporary

table W_RCRTMNT_EVENT_F_TMP. This becomes the driver table for the rest of three aggregate

building.


W_JOB_RQSTN_EVENT_F


Snapshot Fact



W_RCRTMNT_EVENT_F


W_APPL_EVENT_F


Fact

W_APPL_ACC_SNP_F

Full load

process

(Job Req.)

Full load

process

(Applicant)

Process flow for INITIAL Load of the Recruitment Pipeline fact




W_JOB_RQSTN_EVENT_F


Snapshot Fact



W_RCRTMNT_EVENT_F


W_APPL_EVENT_F


Fact

W_APPL_ACC_SNP_F

Recruitment Pipeline Event Queue

W_RCRTMNT_EVENT_F_EQ_TMP

Recruitment Pipeline Temporary

W_RCRTMNT_EVENT_F_TMP

Pre

Im

ag

e

Pro

ce

ss

(Jo

b R

eq

.)

Pre

Im

ag

e

Pro

ce

ss

(Ap

plic

an

t)


W_JOB_RQSTN_EVENT_F


Snapshot Fact



W_RCRTMNT_EVENT_F


W_APPL_EVENT_F


Fact

W_APPL_ACC_SNP_F

Recruitment Pipeline Event Queue

W_RCRTMNT_EVENT_F_EQ_TMP

Incremental load

process (Job Req.)

Incremental load

process (Applicant)


W_RCRTMNT_EVENT_F



Post

Image

Process



Process flow for INCREMENTAL Load of the Recruitment Pipeline fact


PLP_RecruitmentEventFact_Applicants_Full (loads new records)

PLP_RecruitmentEventFact_JobRequisitions_Full (loads new records)


PLP_RecruitmentEventFact_Applicants_PreImage (takes a pre-image of the pipeline fact

before the new applicant events are loaded; in other words, determine what is about to

change)

PLP_RecruitmentEventFact_JobRequisitions_PreImage (takes a pre-image of the pipeline

fact before the job requisition events are loaded; in other words, determine what is about

to change)

PLP_RecruitmentEventFact_Applicants (deletes old records that came in the event queue

and re-processes and re-inserts them; new records are inserted)

PLP_RecruitmentEventFact_JobRequisitions (deletes old records that came in the event

queue and re-processes and re-inserts them; new records are inserted)

PLP_RecruitmentEventFact_PostImage (takes a post-image of the pipeline fact after all the

changes are done to it)

6.2.11. Recruitment Job Requisition Aggregate Fact (W_RCRTMNT_RQSTN_A)

This table stores aggregated measures applicable to Job Requisitions, at a monthly level. The load of

this table drives from the Pipeline fact the temporary table W_RCRTMNT_EVENT_F_TMP that was

populated during the process of loading the Pipeline fact.

During full load, the metrics get aggregated into a temporary table W_RCRTMNT_RQSTN_A_TMP2,

which gets subsequently updated to set the effective to date column of the end aggregate table, and

finally gets loaded to the end aggregate table.

During incremental, an additional process, driven by the pre-populated temporary table

W_RCRTMNT_EVENT_F_TMP that tracks the changes affected in the Pipeline fact in the current ETL

run, loads yet another temporary table W_RCRTMNT_RQSTN_A_TMP1. The following aggregation of

metrics to the second temporary table W_RCRTMNT_RQSTN_A_TMP2 is similar to that of the full

load, and so are the remaining processes (updating effective to dates, and loading the end aggregate

table).

The aggregate table has an EFFECTIVE_FROM_DT and EFFECTIVE_TO_DT column. In order to cater

for balance metrics (non-event ones that are non-additive), these dates help to avoid create

unnecessary monthly snapshots if nothing has changed for a Job Requisition. The effective from date

is the date of the last event happened in the month, and the effective to date is the last day of that

month minus one day.



The overall ETL process for this table is explained in the following diagrams.


W_RCRTMNT_EVENT_F

Recruitment Requisition

Aggregate

W_RCRTMNT_RQSTN_A

Derive

Process

(FULL)

Update

Process

(Common

)

Time

Dimension -

Day

W_DAY_D

Time

Dimension -

Month

W_MONTH_

D

Requisition Aggregate Temp-2

W_RCRTMNT_RQSTN_A_TMP

2

Load process

(FULL)




W_RCRTMNT_EVENT_F

Recruitment Requisition

Aggregate

W_RCRTMNT_RQSTN_A

Load process

(INCR)

Time Dimension

- Day

W_DAY_D

Time Dimension

- Month

W_MONTH_D



1



2

Derive process

(INCR)

Update

process

(COMMON)

Extract

process

(INCR)


PLP_RecruitmentRequisitionAggregate_Load_Derive_Full (loads new records into the TMP2

table)

PLP_RecruitmentRequisitionAggregate_Load_Update (updates effective to date back into

the same TMP2 table)



PLP_RecruitmentRequisitionAggregate_Load_Full (loads new records into the end

aggregate table)


PLP_RecruitmentRequisitionAggregate_Extract (extracts records into a TMP1 table based

on changes that happened in the Pipeline fact in the current ETL run)

PLP_RecruitmentRequisitionAggregate_Load_Derive (loads new and changed records into

the TMP2 table)

PLP_RecruitmentRequisitionAggregate_Load_Update (updates effective to date back into

the same TMP2 table)

PLP_RecruitmentRequisitionAggregate_Load (deletes and re-loads new and changed

records into the end aggregate table)

6.2.12. Recruitment Applicant Aggregate Fact (W_RCRTMNT_APPL_A)

This mapping aggregates the applicable recruitment pipeline metrics and groups by all the

dimensions in the Applicant Analysis Aggregate Fact table, at a monthly grain. All applicants that

pass through the Recruitment pipeline process gets in this aggregate table. During incremental load,

the process deletes the records that are about to get impacted because of changes in the Pipeline

fact table, then re-processes them.


W_RCRTMNT_EVENT_F


W_RCRTMNT_APPL_A

Time Dimension

- Day

W_DAY_D

Time Dimension

- Month

W_MONTH_D

Load process (FULL)




W_RCRTMNT_EVENT_F


W_RCRTMNT_APPL_A

Extract

Process

(INCR)

Time

Dimension -

Day

W_DAY_D

Time

Dimension -

Month

W_MONTH_

D

Applicant Aggregate Temporary

W_RCRTMNT_APPL_A_TMP

Load process (INCR)


Temporary



PLP_RecruitmentApplicantAggregate_Load_Full (loads new records)


PLP_RecruitmentApplicantAggregate_Extract (loads new and changed records into a

temporary table that got impacted in the Pipeline fact during the current ETL run)

PLP_RecruitmentApplicantAggregate_Load (deletes, re-processes and re-loads the data,

both changed and new, into the end aggregate table)

6.2.13. Recruitment Hire Aggregate Fact (W_RCRTMNT_HIRE_A)

This mapping aggregates the applicable recruitment pipeline metrics and groups by all the

dimensions in the Hire Analysis Aggregate Fact table, at a monthly grain. Only applicants that are

hired gets in this aggregate table. During incremental load, the process deletes the records that are

about to get impacted because of changes in the Pipeline fact table, then re-processes them.




W_RCRTMNT_EVENT_F


W_RCRTMNT_HIRE_A

Time Dimension

- Day

W_DAY_D

Time Dimension

- Month

W_MONTH_D

Load process (FULL)


W_RCRTMNT_EVENT_F


W_RCRTMNT_HIRE_A

Extract

Process

(INCR)

Time

Dimension -

Day

W_DAY_D

Time

Dimension -

Month

W_MONTH_D

Hire Aggregate Temporary

W_RCRTMNT_HIRE_A_TMP

Load process (INCR)


Temporary



PLP_RecruitmentHireAggregate_Load_Full (loads new records)


PLP_RecruitmentHireAggregate_Extract (loads new and changed records into a temporary

table that got impacted in the Pipeline fact during the current ETL run)

PLP_RecruitmentHireAggregate_Load (deletes, re-processes and re-loads the data, both

changed and new, into the end aggregate table)



6.3. Absence Fact Process

6.3.1. ETL Flow

Absence Event Dimension

W_ABSENCE_EVENT_D

Day Dimension

W_DAY_D

Absence Fact

W_ABSENCE_EVENT_F

Absence Event Dim Staging

W_ABSENCE_EVENT_DS

Absence Type Reason Dim Staging

W_ABSENCE_TYPE_RSN_DS

Workforce Fact

W_WRKFC_EVT_F

Absence Type Rsn Dimension

W_ABSENCE_TYPE_RSN_D

PS

FT

Syste

m

ABS_CODE_TBL,

ABS_CLASS_TBL,

ABS_TYPE_TBL

PS

FT

Syste

m ABS_HIST

Absence Event Temporary Staging

W_ABSENCE_EVENT_TMP

Job

W_PSFT_WEVT_JOB_PS



W_ABSENCE_EVENT_DS W_ABSENCE_EVENT_TMP

W_PSFT_WEVT_JOB_PS

One record per absence

occurrence for a given

employee/absentee and his/her

assignment.

Stores the Absence

Occurrences for

each Employee

(Dimension

Staging table).

W_ABSENCE_TYPE_RSN_DS ABS_CODE_TBL

ABS_CLASS_TBL

ABS_TYPE_TBL

One record per valid Absence Type

and Reason combination for one

set of records. To handle

situations where a Reason is not

available in the transaction, add

another set of records for each

valid Absence Type only (no

reasons).

Stores absence

type, reason and

category

information.

( Dimension

Staging table)

W_ABSENCE_EVENT_D W_ABSENCE_EVENT_DS


One row per Absence Occurrence

for a given employee and his/her

assignment.

Stores the Absence

Occurrences for

each Employee

W_ABSENCE_TYPE_RSN_D W_ABSENCE_TYPE_RSN_DS One record per valid Absence Type

and Reason combination for one

set of records. To handle

situations where a Reason is not

available in the transaction, add

another set of records for each

Stores Absence

type, reason and

category

information.



valid Absence Type only (no

reasons).

W_ABSENCE_EVENT_F W_ABSENCE_EVENT_D

W_DAY_D

W_WRKFC_EVT_F

One row per Absence day per

Absence Occurrence for given

employee and his/her assignment.

Stores One row per

Absence day per

Absence

Occurrence for

given employee

and his/her

assignment.


All the set up and configuration steps that are required for core Workforce also applies for Absence

(see the same section for Workforce). For PeopleSoft adaptors, there are no more extra


6.3.4. W_ABSENCE_TYPE_RSN_DS

Dimension Staging table which stores absence type, reason and category information.

Absence Type Reason Dim Staging

W_ ABSENCE_ TYPE_ RSN_DS

ABS_CODE_TBL ABS_CLASS_TBL ABS_TYPE_TBL

FULL

&

INCR


SDE_PSFT_AbsenceTypeReason (Loads all records with Absence Type, Reason and Category

information and other details such as, whether the Absence is paid or not, from ABS

PeopleSoft Tables)


SDE_PSFT_AbsenceTypeReason (Loads all records with Absence Type, Reason and Category

information and other details such as whether the Absence is paid or not, from ABS

PeopleSoft Tables after last extract date)



6.3.5. W_ABSENCE_EVENT_TMP

Absence Event Temporary StagingW_ ABSENCE_ EVENT_ TMP

FULL

&

INCR

ABS_HIST


SDE_PSFT_AbsenceEventDimension_Preload_Full (Loads all Absence records with Absence

related details such as start and end dates of Absence, resolves approval status and loads

into W_ABSENCE_EVENT_TMP table from ABS_HIST table)


SDE_PSFT_AbsenceEventDimension_Preload (Loads all Absence records with Absence

related details such as start and end dates of Absence, resolves approval status and loads

into W_ABSENCE_EVENT_TMP table from ABS_HIST table after the last extract date)



6.3.6. W_ABSENCE_EVENT_DS

Dimension staging table that stores the Absence Occurrences for each Employee.

Absence Event Dim Staging

W_ABSENCE_ EVENT_DS

Absence Event Temporary Staging

W_ABSENCE_ EVENT_ TMP

Job

W_ PSFT_ WEVT_JOB_PS

FULL

&

INCR


SDE_PSFT_AbsenceEventDimension_FinalLoad (Loads W_ABSENCE_EVENT_DS staging table

with Absence records from W_ABSENCE_EVENT_TMP and Workforce (JOB) Persisted Staging

table W_PSFT_WEVT_JOB_PS. It updates Absence Category, Type and Reason columns)


SDE_PSFT_AbsenceEventDimension_FinalLoad (Loads W_ABSENCE_EVENT_DS staging table

with Absence records from W_ABSENCE_EVENT_TMP and Workforce (JOB) Persisted Staging

table W_PSFT_WEVT_JOB_PS. It updates Absence Category, Type and Reason columns)

6.3.7. Absence Event Fact (W_ABSENCE_EVENT_F)

This table is loaded using the two dimension tables W_ABSENCE_EVENT_D and

W_ABSENCE_TYPE_RSN_D along with time dimension. The dimension tables are loaded via their

corresponding Universal Staging area tables (W_ABSENCE_EVENT_DS and

W_ABSENCE_TYPE_RSN_DS).



W_ABSENCE_EVENT_DS

W_ABSENCE_EVENT_DW_ABSENCE_TYPE_RSN_D


W_ABSENCE_EVENT_F

SIL Load

Process

FULL

SIL Load

Process

FULL

Load

Process

FULL

Position Hierarchy Post Change

Temporary

W_POSITION_DH_POST_CHG_TM

P

Position Hierarchy Update

Process

INCR

Position Hierarchy Pre Change

Temporary


W_ABSENCE_EVENT_DS

W_ABSENCE_EVENT_D

W_ABSENCE_TYPE_RSN_D

W_ABSENCE_TYPE_RSN_

DS

W_ABSENCE_EVENT_F

SIL INCR Load

Process

SIL Incr Load

Process

Load Process

INCR

W_ABSENCE_EVENT_EQ_TMP

W_WRKFC_EVT_EQ_TMP

Mntn Process

INCR

Event Queue

Process INCR




SIL_AbsenceEventDimension _Full(loads new/updated records from Absence Event Staging

Dimension and Absence Type Reason Dimension)

SIL_AbsenceTypeReasonDimension_Full (loads new/updated records from Absence Type

Reason Staging Dimension)

PLP_AbsenceEventFact_Full (loads new/updated records from Absence Event Dimension)


SIL_AbsenceEventDimension(loads new/updated records from Absence Event Staging

Dimension and Absence Type Reason Dimension)

SIL_AbsenceTypeReasonDimension (loads new/updated records from Absence Type Reason

Staging Dimension)

PLP_AbsenceEventFact (loads new/updated records from Absence Event Dimension, Day

Dimension and Workforce Fact) PLP_AbsenceEventQueue_Event (loads change queue table with changed (staged)

assignments and their earliest change (staged event) date for each Absence Event )

PLP_AbsenceEventFact_Mntn( deletes obsolete Absence records from Absence Fact based

on the change queue table (W_ABSENCE_EVENT_EQ_TMP )

PLP_AbsenceEventFact_PositionHierarchy_Update (changes in the Absent Employee’s

Position Hierarchy due to regular or back dated changes are applied to the Absence fact

table)



6.4. Learning Fact Process

6.4.1. ETL Flow

Learning Enrollment SNP Fact Staging

W_LM_ENROLLMENT_ACC_SNP_FS

Learning Enrollment Snapshot Fact

W_LM_ENROLLMENT_ACC_SNP_F

Learning Enrollment Fact

W_LM_ENROLLMENT_EVENT_F

Learning Grade Band

Dimension

W_LM_GRADE_BAND_D

FILE_LEARNING_

GRADE_BAND

File Input

FILE_ROW_GEN_

BAND

File Input

PS

FT

Syste

m

LM_ENRLMT,

LM_PERSON,

LM_PERSON_JOB,

LM_GRD_SCH_VW,

LM_JOBCODE_TBL



W_LM_ENROLLMENT_ACC_

SNP_FS

LM_ENRLMT

LM_PERSON

LM_PERSON_JOB

LM_GRD_SCH_VW

LM_JOBCODE_TBL

The grain of this table is a

single activity related to a

given course on a given

enrollment status date.

W_LM_GRADE_BAND_D Flat file Sources One row per Learning Grade

Band and one row for each

learning Score

Learning Grade Band

Dimension stores

data for

Grade/Scoring Bands

for Learning Activities


SNP_F


SNP_FS

One row per enrollment per

learner/Employee per

learning activity

For example, an employee

requests, enrolls and

completes a learning activity;

there will be one row in this

table.

Accumulated

snapshot fact table

captures each

learner's enrollment

to a learning activity.



W_LM_ENROLLMENT_EVEN

T_F


SNP_F

W_LM_GRADE_BAND_D

Its grain is Learner/Employee

+Learning Activity +Status.

For example, an employee

requests, enrolls and

completes a learning activity;

there will be 3 rows in this

table, one for each of the

statuses.

This fact table stores

the status changes

for the learning

enrollment process.


All the set up and configuration steps that are required for core Workforce also applies for Learning.

(See the same section for Workforce). For PeopleSoft adaptors, there are no more extra


6.4.4. W_LM_ENROLLMENT_ACC_SNP_FS

Accumulated snapshot fact staging table captures each learner's enrollment to a learning activity.

LM_ENRLMT LM_PERSON

LM_PERSON_JOB LM_GRD_SCH_VW LM_JOBCODE_TBL

FULL

&

INCR

W_LM_ENROLLMENT_ACC_SNP_FSFULL

&

INCR




SDE_PSFT_LearningEnrollmentFact_Full (Loads all records from the Learning source tables in PeopleSoft into table W_LM_ENROLLMENT_ACC_SNP_FS. The main source table is

LM_ENRLMT. It also joins HR tables to retrieve Employee data.)

SDE_PSFT_LearningEnrollmentFact_HRData (Updates W_LM_ENROLLMENT_ACC_SNP_FS

with HR Information such as Supervisor Id)


SDE_PSFT_LearningEnrollmentFact (Loads all records from the Learning source tables in

PeopleSoft into table W_LM_ENROLLMENT_ACC_SNP_FS after the last extract date)

SDE_PSFT_LearningEnrollmentFact_HRData (Updates W_LM_ENROLLMENT_ACC_SNP_FS

with HR Information such as Supervisor Id)

6.4.5. Learning Enrollment Acc. Snapshot Fact (W_LM_ENROLLMENT_ACC_SNP_F)

W_LM_ENROLLMENT_ ACC_SNP_F accumulated snapshot fact table captures each learner's

enrollment to a learning activity and the status changes. The grain of this table is at

Learner/Employee +Learning Activity level. For example, an employee requests, enrolls and

completes a learning activity; there will be one row in this table.




Temporary


Position Hierarchy

Update Process

INCR ONLY


Temporary

W_POSITION_DH_PRE_CHG_TMPW_LM_ENROLLMENT_ACC_SNP_FS

SIL Load Process

FULL and INCR

PLP Load Process

FULL and INCR



SIL_LearningEnrollmentFact_Full (This mapping is responsible for loading fact records for the table W_LM_ENROLLMENT_ACC_SNP_F based on the corresponding staging area table.)

PLP_LearningEnrollmentUpdate_Full (This mapping is used to update the initial waitlisted

and enrollment initiated dates in the Learning Enrollment Accumulative Snapshot Fact

table, W_LM_ENROLLMENT_ACC_SNP_F.)


SIL_LearningEnrollmentFact(This mapping takes care of inserting new records as well as

updating existing records in the target table W_LM_ENROLLMENT_ACC_SNP_F.)

PLP_Learning_Enrollment_Accumulated_Snapshot_PositionHierarchy_Update (changes in

the Employee’s Position Hierarchy due to regular or back dated changes are applied to the

Learning Snapshot Fact table)

PLP_LearningEnrollmentUpdate (This mapping is used to incrementally update the initial

waitlisted and enrollment initiated dates in the Learning Enrollment Accumulative Snapshot

Fact table, W_LM_ENROLLMENT_ACC_SNP_F.)



6.4.6. Learning Enrollment Event Fact (W_LM_ENROLLMENT_EVENT_F)

W_LM_ENROLLMENT_EVENT_F fact table stores the status changes for the learning enrollment process. Its grain is Learner/Employee - Learning Activity - Status. For example, an employee requests, enrolls and completes a learning activity; there will be 3 rows in this table, one for each of the statuses.


W_LM_ENROLLMENT_EVENT_F

PLP Load process

FULL and INCR


PLP_LearningEnrollmentEventFact_Full (This mapping is used to create the learning

enrollment event Fact, W_LM_ENROLLMENT_EVENT_F)


PLP_LearningEnrollmentEventFact (This mapping is used to insert/update rows into the

learning enrollment event Fact, W_LM_ENROLLMENT_EVENT_F)



6.5. Payroll Fact Process

6.5.1. ETL Flow

Payroll Fact Staging

W_PAYROLL_FS

Payroll Fact

W_PAYROLL_F

Payroll Aggregate Fact

W_PAYROLL_A

Employee Demographic

Aggregate Dimension

W_EMP_DEMOGRAPHICS_D

Job Category Aggregate

Dimension

W_JOB_CATEGORY_D

Pay Type Group Aggregate

Dimension

W_PAY_TYPE_GROUP_D

PS

FT

Syste

m

PAY_CHECK,

PAY_DEDUCTION,

PAY_EARNINGS,

PAY_OTH_EARNS,

PAY_TAX

PS

FT

Syste

m

JOBPayroll Fact Staging Temporary

W_PSFT_PAYROLL_F_TMP

Payroll Fact Staging Temporary

W_PSFT_PAYROLL_F_DIM_TMP

Terminology

“Pay Type” describes various types of compensations or deductions that typically come in a pay

stub. Examples include Earning, Bonus, and Taxes and so on.

“Pay Item Detail” describes whether the line item in the payroll fact is at a detail level (like 401K

deductions, Medicare deductions, Social Security Deductions, Health Insurance Deductions etc) or if

it is at a higher level of a group (like DEDUCTIONS, or EARNINGS or TAXES and so on).



Key Steps and Table Descriptions


W_PSFT_PAYROLL_F_TMP PAY_CHECK

PAY_DEDUCTION

PAY_EARNINGS

PAY_OTH_EARNS

PAY_TAX

One row per employee and

pay period per pay type.

Temporary Table.

Pay Type includes base

ones such as Earnings,

Deductions, Taxes

(State and Federal) as

well as balance ones

such as TOTAL_TAX,

TOTAL_DEDUCTIONS

etc.

W_PSFT_PAYROLL_F_DIM_

TMP

JOB One row per employee

effective date.

Temporary table.

Stores employee’s

worker dimensions

and relations that is

not available in the

payroll component.

W_PAYROLL_FS W_PSFT_PAYROLL_F_TMP

W_PSFT_PAYROLL_F_DIM_

TMP

One row per employee and

pay period per pay type.

This table stores base

and balance payroll

transactions.

W_PAYROLL_F W_PAYROLL_FS The grain of this table is

typically at an Employee -

Pay type - Pay Period Start

Date - Pay Period End Date

level. For a given employee

and pay period, each record

in this table stores the

amount associated with

that pay type (line item).

Stores the base Payroll

Transactions.

Examples of fact

information stored in

this table include Pay

Check Date, Pay Item

Amount, Currency

Codes, and Exchange

Rates and so on.

W_PAYROLL_A_TMP W_PAYROLL_F Same grain as of

W_PAYROLL_F.

This temporary table is

used to extract

incremental changes

that happened on the

base fact and used to

drive the incremental

aggregate refresh.

W_PAYROLL_A W_PAYROLL_F

W_PAYROLL_A_TMP

W_EMP_DEMOGRAPHICS_

D

W_JOB_CATEGORY_D

W_PAY_TYPE_GROUP_D

The grain of this table is at

a Monthly level (Period

Start and End Dates) out of

box (configurable though)

and to the Employee

Demographics, Job

Category, and Pay Type

Groups aggregate

dimension levels.

Stores Payroll

transactions

aggregated at a

Monthly (configurable)

level on top of the

base fact table

W_PAYROLL_F



Key Setup/Configuration Steps

All the set up and configuration steps that are required for core Workforce also applies for Payroll

(see the same section for Workforce). The time grain (OOTB Monthly) of the payroll aggregate table

can be configured to become Weekly or Quarterly or Yearly. Check the configuration steps for the

parameter $$GRAIN.

6.5.1. W_PSFT_PAYROLL_F_TMP

SDE Extract Process

FULL and INCR

Payroll Staging Temporary Table


PS

FT

Syste

m

PAY_CHECK,

PAY_DEDUCTION,

PAY_EARNINGS,

PAY_OTH_EARNS,

PAY_TAX

De

du

ctio

ns

Ea

rnin

gs

Ta

xe

s

Oth

er

Ea

rnin

gs

To

tal

SDE Extract Process

INCR ONLYP

SF

T S

yste

m

PAY_CHECK,

PAY_DEDUCTION,

PAY_EARNINGS,

PAY_OTH_EARNS,

PAY_TAX

De

du

ctio

ns (

A &

R)

Ea

rnin

gs (

A &

R)

Ta

xe

s (

A &

R)

Oth

er

Ea

rnin

gs (

A &

R)

To

tal (A

& R

)


SDE_PSFT_PayrollFact_Deductions_Full (Extracts Deduction lines – base pay type)

SDE_PSFT_PayrollFact_Earnings_Full (Extracts Earning lines – base pay type)

SDE_PSFT_PayrollFact_EarningsOther_Full (Extracts Other Earning lines – base pay type)

SDE_PSFT_PayrollFact_Taxes_Full (Extracts all Taxes lines – base pay type)

SDE_PSFT_PayrollFact_Total_Full (Extracts Balances such as TOTAL_GROSS, TOTAL_DEDUCTIONS, TOTAL_TAXES and NET_PAY – balance pay type)


SDE_PSFT_PayrollFact_Deductions (Extracts Deduction lines since last extract date)



SDE_PSFT_PayrollFact_Deductions_Adjustments_Reversals (Extracts Deduction lines for any Adjusted check or Reversed check since last extract date)

SDE_PSFT_PayrollFact_Earnings (Extracts Earning lines since last extract date)

SDE_PSFT_PayrollFact_Earnings_Adjustments_Reversals (Extracts Earning lines for any Adjusted check or Reversed check since last extract date)

SDE_PSFT_PayrollFact_EarningsOther (Extracts Other Earning lines since last extract date)

SDE_PSFT_PayrollFact_EarningsOther_Adjustments_Reversals (Extracts Other Earning lines for any Adjusted check or Reversed check since last extract date)

SDE_PSFT_PayrollFact_Taxes (Extracts all Taxes lines since last extract date)

SDE_PSFT_PayrollFact_Taxes_Adjustments_Reversals (Extracts all Taxes lines for any Adjusted check or Reversed check since last extract date)

SDE_PSFT_PayrollFact_Total (Extracts Balances such as TOTAL_GROSS, TOTAL_DEDUCTIONS, TOTAL_TAXES and NET_PAY, since last extract date)

SDE_PSFT_PayrollFact_Total_Adjustments_Reversals (Extracts Balances such as TOTAL_GROSS, TOTAL_DEDUCTIONS, TOTAL_TAXES and NET_PAY for any Adjusted check or Reversed check since last extract date)

6.5.2. W_PSFT_PAYROLL_F_DIM_TMP

SDE Extract

Process

FULL and INCR



PS

FT

Syste

m JOB

Worker

Dimensions

for

Employees


SDE_PSFT_PayrollFact_GetDimensionalities (This mapping extracts all the dimensional records for the fact stage table W_PAYROLL_FS. These Dimensional records are later resolved with the Integration Id's of the corresponding Dimensions. This needs to be done since the Payroll tables like PS_PAY_CHECK, PS_PAY_DEDUCTIONS etc do not provide the level of dimensionality we need for the payroll fact stage.)


SDE_PSFT_PayrollFact_GetDimensionalities (Same as above. No special incremental handling.)



6.5.3. W_PAYROLL_FS

SDE Extract

Process

FULL and INCR

Payroll Staging Table

W_PAYROLL_FS






SDE_PSFT_PayrollFact (This mapping merges the data from the two temporary tables W_PSFT_PAYROLL_F_TMP which actually has the core payroll transaction data, and W_PSFT_PAYROLL_F_DIM_TMP, which has the dimensionality information given an employee and a pay period, and loads the resultant information into the final staging tale W_PAYROLL_FS. The join is simply on the EMPLID+RCD combination, and also makes sure that the Pay Period Start and End dates fall appropriately within the valid effective date ranges in the *DIM_TMP table.)


SDE_PSFT_PayrollFact (Same as above. No special incremental handling. The main source table for this mapping, W_PSFT_PAYROLL_F_TMP is already incrementally loaded.)



6.5.4. Payroll Fact (W_PAYROLL_F)

W_PAYROLL_F fact table stores the base Payroll Transactions. Examples of fact information stored in

this table include Pay Check Date, Pay Item Amount, Currency Codes, and Exchange Rates and so on.

The grain of this table is typically at an Employee - Pay type - Pay Period Start Date - Pay Period End

Date level. For a given employee and pay period, each record in this table stores the amount

associated with that pay type (line item).


Temporary


Position

Hierarchy

Update Process

INCR ONLY


Temporary


Payroll Fact Stage

W_PAYROLL_FS

SIL Load

Process

FULL and INCR

Payroll Fact

W_PAYROLL_F


SIL_PayrollFact_Full (This mapping is responsible for loading fact records for the table W_PAYROLL_F based on the corresponding staging area table)


SIL_PayrollFact (This mapping is responsible for loading fact records for the table

W_PAYROLL_F based on the corresponding staging area table, since the last refresh date)

PLP_PayrollFact_PositionHierarchy_Update (changes in the Employee’s Position Hierarchy

due to regular or back dated changes are applied to the Payroll Fact table)



6.5.5. Payroll Aggregate Fact (W_PAYROLL_A)

W_PAYROLL_A aggregate fact table stores Payroll transactions aggregated at a Monthly level on top of the base fact table W_PAYROLL_F. The grain of this table is at a Monthly level (Period Start and End Dates) out of box (configurable though) and to the Employee Demographics, Job Category, and Pay Type Groups aggregate dimension levels.

PLP Process

INCR ONLY

Payroll Fact

W_PAYROLL_F

PLP Process

FULL And INCR

Payroll Aggregate Fact

W_PAYROLL_A

Employee Demographics

Aggregate Dimension

W_EMP_DEMOGRAPHI

CS_D

Job Category Aggregate

Dimension

W_JOB_CATEGORY_D

Pay Type Group

Aggregate Dimension

W_PAY_TYPE_GROUP

_D

Payroll Aggregate

Temporary

W_PAYROLL_A_TMP

PLP Process

INCR ONLY


PLP_PayrollAggregate_Load_Full (Aggregates all base Payroll transactions from

W_PAYROLL_F at the grain of the designed Aggregate dimensions like Demographics, Job

Category and Pay type Group at a monthly level)


PLP_PayrollAggregate_Extract (Loads new or changed payroll base transaction records from

W_PAYROLL_F into a temporary table W_PAYROLL_A_TMP. This mapping resolves the

aggregate dimension keys by looking up the aggregate dimensions. Also, based on the time

granularity chosen, this mapping looks up the correct time-bucket. With these two steps

done, the final Payroll Aggregate refresh becomes simpler)



PLP_PayrollAggregate_Load (Refreshes the Payroll Aggregate table W_PAYROLL_A driving

from the temporary table loaded in the prior step, W_PAYROLL_A_TMP. The incremental

refresh policy relies on the fact that for Payroll, there can practically be no updates. It could

well be an ‘adjustment run’ or a ‘reversal run’ or likewise. The ITEM_AMT value in the base

payroll transaction will also carry the appropriate ‘sign’ to indicate whether the adjustment

was a negative effect or a positive effect. Reversal run typically comes with negative value of

ITEM_AMT. With this assumption, when a repeat record (key matches) comes in, we update

the value of the ITEM_AMT simply as:

Final ITEM_AMT <aggregate> = Old ITEM_AMT <aggregate> + New ITEM_AMT <temporary>)

7. Known Issues and Patches

The following Oracle Internal document lists all the known issues of HR Analytics (all Adaptors

together) and the patches produced for them, so far, Oracle BI Applications release-wise.

Here is the link to the Patch Library.

We will make every attempt to keep this up to date.

http://files.oraclecorp.com/content/MySharedFolders/Business%20Intelligence%20Solution/Applications/Release%20Independent%20Documents/BI%20Applications%20Patch%20Library/Oracle%20BI%20Applications%20Patch%20Library.xlsx

implementing hr analytics - peoplesoft adaptors

Documents

hr analytics

key hr etl processes

key etl processes

key steps

incremental refresh

incremental refresh

key setupconfiguration

incremental refresh