Hrms for beginners

Copyright (c) 2001 - Oracle Corporation UK Limited
Oracle HRMS Technical Workshop
3-4 December 2001

Introductions
 Your Name ?
 Job & what department ?
 How long have you been here ?
 Experience of Applications ?

Assumptions...
 Familiarity with relational database concept
 Knowledge of following tools:
– SQL & SQL*Plus
– PL/SQL
– DML
– Stored Packages and Procedures
– Unix and Vi (or comparable editor)

The Agenda
 The Big picture
 Core Entities
 The Concept of
Datetrack
 Lookups
 HR Tables
 WHO and OVN
 Payroll Tables
 OTA
 Custom Library
 Data-migration
 Security
 APPL_TOP Directory

The Big Picture
Just what are we dealing with here?

The Big Picture
 Human Resources
 Payroll
 Oracle Training Administration
 Oracle Time and Labour
 Oracle Advanced Benefits
 Statutory Sick Pay

HRMS Product Codes
Application
Id
3-Character
Code
2-Character
Code
Products
Tables names
are prefixed with
the following
code.
Module and
File names
are prefixed
with the
following
code
805 BEN BE Advanced Benefits
810 OTA OT Training Administration
801 PAY PY Payroll
800 PER PE Human Resources
804 SSP SP Statutory Sick Pay
808 HXT HT Time and Labour Management
HR Human Resources & Payroll

The Big Picture
 Combined total in excess of 1000 tables
 400+ API’s
 Tens-of-thousands of code objects
 Numerous ‘buzzwords’

HRMS ‘buzzwords’
 Person
 Assignment
 Organization
 Element
 Element entry
 Grade Step
 Business Group
 Lookup
 LOV
 OVN
 EIT
 SIT
 Datetrack
 API

Core Entities in Oracle HRMS

Core HR Entities
 PERSON
 ASSIGNMENT
 PERIOD of SERVICE
 ORGANIZATION

PERSON
 Holds non-employment information
– Name
– Title
– Date of Birth
– Gender
– Nationality

PERSON
 Many different types of PEOPLE can be held within
HRMS
– Employee
– Ex-employee
– Applicant
– Contact
– Dependent
 Mandatory fields needed to create:
– ‘Employee’: Last name, sex, hire date, person type & Emp. No
– ‘Applicant’: Last name, person type, Applicant No.
 Employee Number generation: manual or automatic
– PER_NUMBER_GENERATION_CONTROLS

PERSON
 Data is held in the table PER_ALL_PEOPLE_F
 Primary key is:
PERSON_ID, EFFECTIVE_START_DATE,
EFFECTIVE_END_DATE

PERSON
 PERSON_TYPE indicates the type:
– EMP = Employee
– APL = Applicant etc.
 Links to PER_PERSON_TYPES table
– Column SYSTEM_PERSON_TYPE

ASSIGNMENT
 Holds person information specific to
Employment or (job) applications.
– Location
– Position
– Job
– Grade
– Payroll
– Organization

ASSIGNMENT
 Linked to a person via PERSON_ID
 A person may have multiple concurrent assignments at
any one point in time
– One must be designated PRIMARY – primary_flag = ‘Y’
 ASSIGNMENT_TYPE indicates the type:
– A = Applicant assignment
– E = Employee assignment
 ASSIGNMENT_STATUS
– Active
– Term

ASSIGNMENT
 Data is held in the table
PER_ALL_ASSIGNMENTS_F
 Primary key is:
ASSIGNMENT_ID,
EFFECTIVE_START_DATE,
EFFECTIVE_END_DATE
 Primary indicator is: PRIMARY_FLAG

PERIOD of SERVICE
 Records each period of employment
 Links the Person and Assignment
 Not directly visible to the end-user
– First of many ‘supporting’ tables within the
application
 Holds Hire-date and Termination-Date

PERIOD of SERVICE
 Data is held in the table
PER_PERIODS_OF_SERVICE
 Primary key is:
– PERIOD_OF_SERVICE_ID
 Foreign key to the Person (PERSON_ID)

ORGANIZATION
 Used to hold definitions of organisations
– Regions
– Departments
– Divisions etc
 Also used to hold definition of the Business
Group.
 A Business Group is the container for a company
or Enterprise

ORGANIZATION
 Data held in the table:
HR_ALL_ORGANIZATION_UNITS
 Primary Key is ORGANIZATION_ID
 Business Group identified by:
business_group_id = organization_id
 95%+ tables within HRMS suite have the
business_group_id column
 Employees can only be assigned to HR
organizations

How they ‘hang’ together
per_all_people_f per_periods_of_servicePERSON_ID
per_all_assignments_f
PERSON_ID
PERIOD_OF_SERVICE_ID
hr_all_organization_units
BUSINESS_GROUP_ID
BUSINESS_GROUP_ID
ORGANIZATION_ID

Have you been paying attention?
Quick Quiz #1

A Person is Hired as an employee. They are then terminated and later re-hired
(again as an employee).
 Q: How many rows in per_periods_of_service
will there be ?
 A: 2
 Q: How many rows in per_all_assignments_f will
there be ?
 A: 2
 Q: Will they have the same assignment_id?
 A: No

The Concept of Datetrack
Before we can cover other tables within
HRMS we need to de-mystify
Datetrack

Datetrack: What is it?
 A way of recording changes over time
 Preservation of history
 Allows viewing of data ‘as it was’ at any
given point in time
 Maintenance of future-dated records
 Set-up of known events in advance of them
happening

Datetrack: How to spot it
 All datetracked tables end with ‘_F’
 All datetracked tables have these columns:
– EFFECTIVE_START_DATE (ESD)
– EFFECTIVE_END_DATE (EED)
 Many datetracked tables have a corresponding
‘current data only’ view
– Signified by ‘_X’ instead of ‘_F’

Datetrack: How does it do it?
 In simple terms,
– Old row is UPDATED, setting the EFFECTIVE_END_DATE
to day before the change date
– New row is INSERTED, setting EFFECTIVE_START_DATE
to the start of change date
 An open row (one that has not been ended) will have
EFFECTIVE_END_DATE set to:
31-DEC-4712
– This indicates ‘End of Time’ - in Application.
 N.B. No overlaps, No gaps and ESD exactly one day
after EED.

Datetrack Modes
 Datetrack has several operating modes.
 Catering for all events, depending upon:
– Action being performed
 Updating
- CORRECTION
- UPDATE
- UPDATE_OVERRIDE
- UPDATE_CHANGE_INSERT
 Deleting
- ZAP
- DELETE
- FUTURE_CHANGE
- DELETE_NEXT_CHANGE
– Point in time of Action
– Existence of past, present and future rows

Datetrack Modes
 There are 8 Datetrack Modes
 Most ‘Common’ Modes used are:
 UPDATE
 CORRECTION
 DELETE

Datetrack Modes
 Not-so ‘common’ modes
 UPDATE_OVERRIDE
 UPDATE_CHANGE_INSERT
 FUTURE_CHANGE
 DELETE_NEXT_CHANGE
 ZAP

Datetrack Modes
 The following slides…
– Give a pictorial representation of each of the
datetrack modes
– Assume the Effective Date is 15th Jul 1994

Mode: Update
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
After:
02-Jan-1994 05-Feb-1994
Row A Row B
15-Jul-1994
Row C

Mode: Update
31-DEC-471205-FEB-1994100
04-FEB-199402-JAN-1994100
EEDESDperson_id
BEFORE
31-DEC-471215-JUL-1994100
14-JUL-199405-FEB-1994100
04-FEB-199402-JAN-1994100
EEDESDperson_id
AFTER

Mode: Correction
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
After:
02-Jan-1994 05-Feb-1994
No special Datetrack processing required as this is a standard
database row update.
Row A Row B

Mode: Delete
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
After:
02-Jan-1994 05-Feb-1994
Row A Row B
15-Jul-1994
15-Sep-1994
Row C

Mode: Update_Override
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
08-Aug-1994
Row C
05-Nov-1994
Row D
After:
02-Jan-1994 05-Feb-1994
Row A Row B
15-Jul-1994
Row C

Mode: Update_Change_Insert
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
08-Aug-1994
Row C
05-Nov-1994
Row D
After:
02-Jan-1994 05-Feb-1994
Row A Row B
08-Aug-1994
Row C
05-Nov-1994
Row DRow E
15-Jul-1994

Mode: Future_Change
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
08-Aug-1994
Row C
05-Nov-1994
Row D
After:
02-Jan-1994 05-Feb-1994
Row A Row B

Mode: Delete_Next_Change
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
08-Aug-1994
Row C
05-Nov-1994
Row D
After:
02-Jan-1994 05-Feb-1994
Row A Row B
05-Nov-1994
Row D

Mode: Zap
Before:
02-Jan-1994 05-Feb-1994
Eff. Date
Row A Row B
08-Aug-1994
Row C
05-Nov-1994
Row D
After:
Deletes all rows which match this unique ID.
Must satisfy internal referential integrity constraint rules before rows are
deleted. Most forms will prevent the total deletion of data due to constraint
references with other data items.

Controlling Datetrack
 Within the online application:
– User set their session ‘effective’ date with the ‘Alter
Session Date’ icon.
 All the transactions use this date (until this session
date is reset).
– Form logic determines the datetrack mode to use.
 User forced to select appropriate mode if multiple
options exist.

Controlling Datetrack
 From SQL (for retrieval of data)
– For each datetracked table within your query:
 for ‘current’ data only, use:-
trunc(sysdate) between table.effective_start_date
and table.effective_end_date
 otherwise, use:
<date_var> between table.effective_start_date
and table.effective_end_date

Workshop

Lookups

Lookups: What & Why ?
 A list of values for certain types of
information.
 Forces users to use same terminology
 Can speed-up data entry (marginal)
 Consistency of definitions
 Simplifies translation of seeded lookup data

Types of Lookups
 Three types of Lookups:
– User
 You can add codes and disable supplied codes
– Extensible
 You can add new codes but you cannot disable
supplied codes (as the system uses them)
– System
 You can neither add or disable supplied codes. You
can only alter the meaning of supplied codes.

What does one look like?
 Contains 4 essential components:
 LOOKUP_TYPE
 the collective name for a set of lookup values, such
as YES_NO or TITLE
 LOOKUP_CODE
 a specific code for a value within a lookup type
 MEANING
 the meaning for a specific lookup code
 ENABLED_FLAG
 is this lookup code active or not

Examples
Lookup_type Lookup_Code Meaning
YES_NO Y Yes
N No
TITLE MR. Mr
MRS. Mrs
DR. Doctor
MISS Miss

Other info
 Lookup data held in the table:
FND_LOOKUP_VALUES
 Lookup types held in
FND_LOOKUP_TYPES
 Lookup_type and Lookup_code are
VARCHAR2(30) fields

How to spot a lookup column
 Difficult, but not impossible
 Best reference is the HRMS TRM
 Datapump help
 Give-away clues are that the column in question
is VARCHAR2(30)
– Examples (from per_all_people_f) are:
 TITLE
 SEX
 NATIONALITY

Coding for Lookups
SELECT hrl.meaning, ppf.last_name
FROM hr_lookups hrl
, per_all_people_f ppf
WHERE ppf.person_id = 12345
AND trunc(sysdate) between ppf.effective_start_date
and ppf.effective_end_date
AND hrl.lookup_code = ppf.title
AND hrl.lookup_type = ‘TITLE’;
OR
SELECT hr_general.decode_lookup(‘TITLE’,ppf.title),
ppf.last_name
FROM per_all_people_f ppf
WHERE ppf.person_id = 12345
AND trunc(sysdate) between ppf.effective_start_date
and ppf.effective_end_date;

HR Tables
Some, not all, of the tables one is likely
to encounter

HR Tables
 Tables holding ‘work structure’ information
(i.e. set-up data)
 Tables specific to the PERSON
 Tables specific to the ASSIGNMENT
 How it all ‘hangs together’

HR Tables - Work structure
 Work structure tables cover:
– Organizations (already done)
– Jobs
– Grades
– Positions
– Locations
 Jobs, Positions & Grades are Key Flexfield
structures

Flexfields
 Two types:
– DESCRIPTIVE
– KEY
 DECRIPTIVE
– Provides additional user defined fields
 table column name is ATTRIBUTE1, ..20.
 KEY
– Provides additional structures for the application
 table column name is SEGMENT1, ..30
– Next few slides will illustrate how key flexfields are used in HR.

Flexfields - Key
 User-definable structures to represent business
data
 Configurable at implementation time
 Up to 30 segments of information
 Unique combination of segment data held in one
table (per structure)

Flexfields
 Linkage of segment-combination to Person held
in another table.
 Reduces data storage / increases reporting
complexity !
 more detail to follow later-on :-)

Flexfields - Example
GRADE: Segment1 “Stream” “M”=Management
“T”=Technical
Segment2 “Level” values 1 to 12
PER_GRADE_DEFINITIONS
Grade_Def_ID Seg1 Seg2 Seg3 Seg4 … Seg30
12345 M 8 Null Null Null
12346 M 12 Null Null Null
12347 T 2 Null Null Null
12348 T 7 Null Null Null
PER_GRADES
Grade_ID Grade_Defintion_Id Name
10001 12346 M.12
10002 12347 T.2
10003 12348 T.7

Flexfields - Example
PER_ALL_ASSIGNMENTS_F
Grade_ID Assignment_ID Person_ID
10001 789 789
10002 884 884
10003 1101 1101
10003 207 207
M.12
T.2
T.7
T.7

Work structures - Jobs
 Unique combination of Job segment data held in
PER_JOB_DEFINITIONS
– Unique key is JOB_DEFINITION_ID
 Intersection table for Job data held in PER_JOBS
– Unique key is JOB_ID
– Foreign key JOB_DEFINITION_ID
– Column of concatenated segment data: NAME

Work structures - Grades
 Unique combination of Grade segment data held
in PER_GRADE_DEFINITIONS
– Unique key is GRADE_DEFINITION_ID
 Intersection table for Grade data held in
PER_GRADES
– Unique key is GRADE_ID
– Foreign key GRADE_DEFINITION_ID
– Column of concatenated segment data: NAME

Work structures - Positions
 Positions are slightly different to Jobs and Grades
 Unique combination of segment data held in
PER_POSITION_DEFINITIONS
– Primary key POSITION_DEFINITION_ID
 A single instance of a position within an
organization is held in PER_ALL_POSITIONS
– Primary key POSITION_ID

Work structures - Positions
 PER_ALL_POSITIONS also contains keys to…
– A job (JOB_ID)
– An organization (ORGANIZATION_ID)
– A location (LOCATION_ID)
– The position definition (Position_definition_id)
– and the business group (Business_group_id)

Work structures - Locations
 Can be used to describe physical or logical
locations within an organisation.
 Location data held in the table:
HR_LOCATIONS_ALL
– Primary Key is LOCATION_ID
– Holds location name, description & address
 Table is shared across many applications

Tables for People data
 Addresses
 Phone numbers
 Contacts
 SIT’s (Special Information Types)
 EIT’s (Extra Information Types)
 Absences

Addresses
 Address data held in the table
PER_ADDRESSES
– Primary key is ADDRESS_ID
– Foreign key to Person (person_id)
 Addresses have a STYLE - this dictates the
country address format (e.g UK, US, FR etc)
 Addresses have an ADDRESS_TYPE
– e.g. Home, Work, Term-time etc
– Lookup_Type = ADDRESS_TYPE

Address - Styles
 The column STYLE maps to the table
fnd_territories (country codes)
 This dictates how certain columns are used
– REGION_1, REGION_2, REGION_3
 For GB address, REGION_1 will hold the
County
– Lookup_type = GB_COUNTY

Addresses - additional
 Addresses can be held for:
– Employees & Ex-employees
– Contacts
– Applicants & Ex-applicants
 Addresses are not datetracked, they are dated !
– Multiple concurrent addresses can be held
– DATE_FROM and DATE_TO columns
– One address must always be designated Primary
(PRIMARY_FLAG=‘Y’)

Phone Numbers
 Phone data is held in the table PER_PHONES
– Primary key PHONE_ID
– Dynamic composite foreign key
 PARENT_TABLE
 PARENT_ID
 In theory phones to be held against many entities
– However only Employees, Ex-employees, Contacts,
Applicants are supported !

Phone Numbers
 PARENT_TABLE should be set to
PER_ALL_PEOPLE_F
 PARENT_ID should be set to the
PERSON_ID of the person having the phone
number

Phone Numbers
 The column PHONE_TYPE indicates what type
of number is being stored
– This maps to lookup_type, PHONE_TYPE
– This is an extensible lookup type
– Values such as Home, Work, Fax are seeded
 Phones are not Datetracked, they are dated.
– DATE_FROM and DATE_TO
– No limit to number of phone numbers allowed

Contacts
 Contacts are People !
– Contact data is held in PER_ALL_PEOPLE_F
 Interaction between person and contact held in
PER_CONTACT_RELATIONSHIPS
– Primary key CONTACT_RELATIONSHIP_ID
– PERSON_ID is fk to Person having this contact
– CONTACT_PERSON_ID is fk to the Contact
person record

Contacts
 Person can have any number of contacts
 One contact must be designated Primary
– PRIMARY_CONTACT_FLAG = ‘Y’
 The relationship is identified by
CONTACT_TYPE column
– Maps to Lookup_type CONTACT_TYPE
 Such as SPOUSE, FATHER, CONTACT etc

Contacts
 Contact relationships are not Datetracked, they
are Dated
– DATE_START and DATE_END
 Contacts can also be Employees
– A husband & wife who are employees would require
2 rows to provide recipocal contact relationships
(see next slide)

Contacts - Example
Husband:
Employee No: 2218
Person_ID: 100123
Wife:
Employee No: 2219
Person_ID: 100124
PER_CONTACT_RELATIONSHIPS
Contact_Rel_ID Person_ID Contact_Person_IDContact_Type
378 100124 100123 HUSB
379 100123 100124 WIFE
Contact of Husband Contact of Wife

SIT’s
 Special Information Types
– a keyflexfield structure
– hold Person-level data that doesn’t have a specific
home in standard tables
 Up to 30 segments of data per ‘info type’
 Records are Dated to allow multiple occurrences
per ‘info type’

SIT’s
 Unique combinations of the segment data held in
PER_ANALYSIS_CRITERIA
– Primary key ANALYSIS_CRITERIA_ID
– FK to Structure definition (ID_FLEX_NUM)
 Intersection table linking combination with
person in PER_PERSON_ANALYSES
– Primary key PERSON_ANALYSIS_ID
– Foreign key to Person (PERSON_ID)
– Foreign key to comb. (analysis_criteria_id)

SIT’s - Uses of...
 Examples seen in other projects include:-
– Disciplinary Records
– Non-OTA Training Records
– Security clearance information
– Company Property
– Medical Certificates
– Driving Licence information
– Any historical data

SIT - Structures
 Special Information type (structure) defines:
– Which segments are used (Active)
– Which segments are displayed
– What each active segment holds (datatype)
– How each segment is validated (value_set)
– The ‘End User’ name (label) for the segment
 The SIT structures are defined through the online
application screens (queue demo!)

SIT - Structures
 Structure definition held in
FND_ID_FLEX_STRUCTURES
– Primary key ID_FLEX_NUM, ID_FLEX_CODE
 ID_FLEX_CODE = ‘PEA’ for SIT structures
 Structure Segment definitions held in
FND_ID_FLEX_SEGMENTS
– Same primary key as structure table

SIT - Example code
SELECT ppf.person_id “PersonID”
, TO_CHAR(TO_DATE(pac.segment4,'YYYY/MM/DD')
,'YYYY-MM-DD') “PassportExpiryDate”
, pac.segment2 “PassportNumber”
, TO_CHAR(ppa.date_from,'YYYY-MM-DD') “PassportDateFrom”
, TO_CHAR(ppa.date_to,'YYYY-MM-DD') “PassportDateTo”
, pac.segment3 “PassportNationality”
, TO_CHAR(ppa.last_update_date,'YYYY-MM-DD') “PassportDateUpdated”
, TO_CHAR(ppa.creation_date,'YYYY-MM-DD') “PassportDateCreated”
FROM per_all_people_f ppf
, per_analysis_criteria pac
, per_person_analyses ppa
, fnd_id_flex_structures_tl ifs
WHERE TRUNC(sysdate) BETWEEN ppf.effective_start_date
AND ppf.effective_end_date
AND ppf.person_id = ppa.person_id
AND pac.analysis_criteria_id = ppa.analysis_criteria_id
AND SUBSTR(pac.segment1,1,8) = 'Passport'
AND ifs.id_flex_structure_name = 'Documentation'
AND pac.id_flex_num = ifs.id_flex_num;

You sure about the spellings ?

EIT’s
 Extra Information Types
– Descriptive Flexfield configurable structures
 Hold additional data at the following levels:
 Person
 Assignment
 Location
 Organization
 Job
 Position
 Element (new for 11.5.4)

EIT’s
 20 segments of data per row per structure
 Configurable for multiple entries or single entry
per structure
 Suitable for bulk-data storage
– No unique combinations table
– More efficient (performance wise) online

EIT’s - Uses of...
 Examples seen in other projects include:-
– Payroll run item history
– Job History (where this is not loaded into
Assignment)
– Training History (where not loaded into OTA)
 Use is suited to large volume ‘raw’ data
– Where client cannot cleanse data or want data taken
over ‘as is’

EIT - Tables
EIT Data is stored in the following Tables:
Person PER_PERSON_EXTRA_INFO (Data)
PER_PEOPLE_INFO_TYPES (Structure)
Assignment PER_ASSIGNMENT_EXTRA_INFO (Data)
PER_ASSIGNMENT_INFO_TYPES (Structure)
Location HR_LOCATION_EXTRA_INFO (Data)
HR_LOCATION_INFO_TYPES (Structure)
Job PER_JOB_EXTRA_INFO (Data)
PER_JOB_INFO_TYPES (Structure)
Position PER_POSITION_EXTRA_INFO (Data)
PER_POSITION_INFO_TYPES (Structure)
Organization HR_ORGANIZATION_INFORMATION (Data)
HR_ORG_INFORMATION_TYPES (Structure)
HR_ORG_INFO_TYPES_BY_CLASS (Structure)

EIT - Example code
SELECT ppf.employee_number ,ppf.full_name
,paei.aei_information1 “Change_Date”
,paei.aei_information2 “Reason”
,paei.aei_information3 “Airport_Loc”
,paei.aei_information4 “Cond_Hrs”
,paei.aei_information5 “Job_Title”
,paei.aei_information6 “Annu_Sal”
,paei.aei_information7 “Grade”
,paei.aei_information8 “Point_Scale”
,paei.aei_information9 “Status_Code”
,paei.aei_information10 “Shift_Allow”
FROM per_assignment_extra_info paei
,per_all_assignments_f paf
,per_assignment_info_types pait
,per_all_people_f ppf
WHERE paf.person_id = ppf.person_id (+)
and paf.assignment_id = paei.assignment_id
and paei.information_type = pait.information_type
and pait.information_type = 'BAA Job History'
AND ppf.CURRENT_EMPLOYEE_FLAG = 'Y')
AND TRUNC(SYSDATE) BETWEEN paf.effective_start_date
AND paf.effective_end_date
AND TRUNC(SYSDATE) BETWEEN ppf.effective_start_date

Absences
 Absence data is held in
PER_ABSENCE_ATTENDANCES
– Primary key ABSENCE_ATTENDANCE_ID
– Foreign key to Person (person_id)
 Absences categorised by absence TYPES
– PER_ABSENCE_ATTENDANCE_TYPES
– Primary key
ABSENCE_ATTENDANCE_TYPE_ID
– This is an fk in per_absence_attendances

Absences
 Numerous Absence types
– Illness
– Holiday
– Unpaid Leave
– Civic duties
 Absence types are classified into Categories
– ABSENCE_CATEGORY column in the absence
types Table
– Maps to Lookup_Type ABSENCE_CATEGORY

Absences - Date columns
 Absence Dates
– DATE_START & DATE_END
 Sickness Dates
– SICKNESS_START_DATE &
SICKNESS_END_DATE
 Projected Dates (for holiday, say)
– DATE_PROJECTED_START &
DATE_PROJECTED_END

Absences - Other data
 Absences can be recorded in Days or Hours
– ABSENCE_DAYS or ABSENCE_HOURS
– Cannot be both at same time
 OCCURRENCE
– System controlled counter per employee per absence
type
 Linked Absences
– LINKED_ABSENCE_ID

Absences - Other data
 Absences of the same TYPE cannot have
overlapping dates
 Absences of differing TYPEs can overlap
– Can have concurrent absences of different types

How HR hangs together
Joining together the tables we’ve just
rushed through...

per_all_people_f per_periods_
of_service
PERSON_ID
per_person_
types
per_addresses
PERSON_ID
PERSON_TYPE
per_phones
per_contact_
relationships
PERSON_ID
CONTACT_ID
CONTACT_PERSON_ID
per_person_
analyses
per_analysis
_criteria
ANALYSIS_
CRITERIA_ID
per_people_
extra_info
PERSON_ID
per_people_
info_types
INFORMATION_TYPE
per_absence
_attendances
PERSON_ID
per_absence
_attendance
_types
ABSENCE_ATTENDANCE_TYPE

Payroll Tables
Some, not all, of the tables one is likely
to encounter

Payroll Tables
 Tables holding set-up & configuration
information
 Tables specific to the ASSIGNMENT

Payroll Tables - Set-up
 Time Periods
 Payroll definition
 Element Definitions
 Element Links
 Balance definitions

Time Periods
 A defined ‘slice’ of time
 Used as a basis for regular payroll
processing
 Limited by Legislative parameters

Time Periods
 Time periods are grouped into ‘Period Sets’
 A Period Set contains one-years worth of
Time Periods
 The number of Time Periods to a Period Set
is governed by ‘Period Type’
 Each Payroll will have its own set of ‘time
periods’

Time Periods
Period_Type No. of Time Periods
(per year)
Week 52
Calendar Month 12
Bi-week 26
4-week 13
Quarter 4

Time Periods
 Data held in table PER_TIME_PERIODS
– Primary key TIME_PERIOD_ID
– Foreign key to Payroll (PAYROLL_ID)
 Key columns are:
START_DATE Start date of the period e.g. 01-AUG-2001
END_DATE End date of the period e.g. 31-AUG-2001
PERIOD_NUM Number of period within year e.g 05
PERIOD_SET_NAME Name of set to which this period belongs to.

Payroll
“A payroll defines a group of employees who
share the same frequency of processing and
payment, defined by the payroll calendar
in PER_TIME_PERIODS. The definition
of the payroll includes the default processing
information for consolidation sets, payment
types, cost allocation, and offset dates.”

Payroll
 The Payroll definition is held in the table
PAY_ALL_PAYROLLS_F
 Primary key -
PAYROLL_ID
EFFECTIVE_START_DATE
EFFECTIVE_END_DATE
 This is a datetracked table, allowing changes to
the definition over time

Payroll
 The column PAYROLL_NAME uniquely
describes each payroll definition. eg
– ‘Staff Nurses Weekly’
– ‘Cleaners Monthly’
– ‘Executives Monthly’

Payroll
 The Payroll definition holds other info:
– Defaults for Payment Method & Cost Codes
– Offset dates for
 Payment Date
 Payroll Cutoff Date
 Pay Advice Date
 Direct Deposits Date

Time Period & Payroll Diagram
pay_all_payrolls_f per_time_periodsPAYROLL_ID
per_time_period_types per_time_period_sets
PERIOD_TYPE
PERIOD_SET_NAME

Payment Methods
 Details how an employee receives their pay
 e.g BACS, Cheque, Cash etc
 Lookup PAYMENT_CATEGORY
 Table PAY_PAYMENT_TYPES
 Includes details of the Bank / Building Society
accounts
 Multiple accounts can be held per assignment
 Allocation of Percentage or fixed amounts to
specific accounts.

Payment Methods
 Payment method types held in the table
PAY_ORG_PAYMENT_METHODS_F
 Primary key
ORG_PAYMENT_METHOD_ID
EFFECTIVE_END_DATE
 ORG_PAYMENT_METHOD_NAME holds
name of method, eg:
 Cash
 BACS etc

Payment Methods
 Payment method held in table
PAY_PERSONAL_PAYMENT_METHODS_F
 Primary key
PERSONAL_PAYMENT_METHOD_ID
EFFECTIVE_END_DATE
 Holds columns for:
– Amount
– Percentage
– Foreign key to Assignment

Payment Methods
 Actual Bank Detail information held in
PAY_EXTERNAL_ACCOUNTS
– Primary key EXTERNAL_ACCOUNT_ID
 This is a ‘developer’ key flexfield table whose
structure varies between legislations
 Foreign key ID_FLEX_NUM links to structure
 Data held in columns SEGMENT1 to
SEGMENT30

External Accounts structure
 ID_FLEX_CODE = ‘BANK’ for bank details

External Accounts - example
select seg.application_column_name,
seg.segment_name
from fnd_id_flex_segments seg,
fnd_id_flex_structures_tl struc
where struc.id_flex_structure_name = 'GB Bank Details'
and seg.id_flex_num = struc.id_flex_num
and seg.id_flex_code = 'BANK'
and seg.enabled_flag = 'Y'
order by seg.segment_num;
gives…
APPLICATION_COLUMN_NAME SEGMENT_NAME
------------------------------ ------------------------------
SEGMENT3 Sort Code
SEGMENT1 Bank Name
SEGMENT2 Bank Branch
SEGMENT4 Account Number
SEGMENT5 Account Name
SEGMENT6 Account Type
SEGMENT7 Bld Society Account Number
SEGMENT8 Bank Branch Location

Pay Methods table diagram
pay_external_
accounts
pay_org_payment
_methods_f
ORG_PAYMENT_METHOD_ID
per_all_
assignments_f
pay_personal_
payment_methods_f
ASSIGNMENT_ID
fnd_id_flex_
structures_tl
ID_FLEX_NUM
EXTERNAL_
ACCOUNT_ID

Payment Methods
Any questions ?

Can I have mine in cash in brown
envelopes please ?

Elements
 Elements are the building blocks for Pay and
benefits
 Used by HRMS and Payroll

Elements can represent
 Earnings, such as salary, wages & bonuses
 Benefits, such as employee stock & pension
plans
 Absences from work
 Non-payroll items, such as expenses
 Voluntary and involuntary deductions
 Employer taxes and other liabilities

Predefined Elements
 UK Payroll legislation provides many predefined
elements.
– Tax (PAYE)
– National Insurance (Employee and Employer)
– Court Orders
– Other Attachment-of-earnings orders
 These elements cannot be modified

Element Definitions
 An element definition can have up to 15 items of
information.
 These items of information are called ‘Input
Values’
 An Input Value can be defined to hold:
 Alphabetic characters or Words
 Integers or Numbers
 Money
 Hours or minutes
 Date, day or time

Element classifications
 Elements are grouped into Primary
Classifications
 Classifications are used by payroll to:-
– Control order they are processed
– Control the balance feeds
 Classifications can also be used to logically
group elements for reporting purposes

Element classifications
 Seeded element classifications are:-
Information
Direct Payment
Earnings
Employer Charges
Pre-Tax Deductions
NI
PAYE
Court Orders
Voluntary Deductions

Element Tables: Definition
 Element definitions are held in the table
PAY_ELEMENT_TYPES_F
 Primary key is
ELEMENT_TYPE_ID
EFFECTIVE_END_DATE
 Foreign key to classification
CLASSIFICATION_ID

Element Tables: Input Values
 Element Input Values are held in the table
PAY_INPUT_VALUES_F
 Primary key is
INPUT_VALUE_ID
EFFECTIVE_END_DATE
 Foreign key to element definition

Element Tables: Input Values
 Input values table also holds the following
information (for each input value):
NAME User name of the input value
LOOKUP_TYPE If this input is validated by a lookup
DISPLAY_SEQUENCE Order to display if multiple inputs are present
MANDATORY_FLAG Is a value for this input required or not
UOM Unit of measure for this input value
DEFAULT_VALUE The value to default if no entry is made
MAX_VALUE Maximum value allowable for this input
MIN_VALUE Minimum value allowable for this input
WARNING_OR_ERROR Whether to raise a warning or an error if the
value entered is beyond the min/max values.

Element Tables: Classification
 Element classifications are held in the table
PAY_ELEMENT_CLASSIFICATIONS
 Primary key is
CLASSIFICATION_ID

Element Eligibility
 Some elements may be available to all employees
 However some elements may only be allocated to
specific sub-sets of employees
 To determine this eligibility we build links to
components of assignments
 Employees must have these components of the
assignment to satisfy this eligibility link

Components of Eligibility
Assignment components to which you can link elements are:
Payroll If employees on all your payrolls are eligible
for an element, you can link it to all payrolls.
Salary Basis You may have an element you only want to give
to hourly-paid employees.
Employment Category e.g. Full-Time, Part-Time etc.
Organization e.g. to a specific department or region
Location e.g. London Allowance only for those employees
based in London location
Job e.g. Secretarial Staff
Grade You may want to restrict eligibility to a specific
grade or grades.
Position Or you may want to restrict to specific posts
within your organization.

Other Eligibility Rules
 You may have multiple links per element
definition.
 However, there is no overlap in eligibility criteria
for these links
– i.e. An employee could not receive the same element
via more than one link

Element Tables: Eligibility
 Element eligibility rules are held in the table
PAY_ELEMENT_LINKS_F
 Primary key is
ELEMENT_LINK_ID
EFFECTIVE_END_DATE

Element table diagram
pay_element_
classifications
pay_element_types
_f
CLASSIFICATION_ID
pay_element_
links_f
pay_input_values
_f
ELEMENT_TYPE_ID
ELEMENT_TYPE_ID

Element Entries
 We know element definitions (hopefully).
 Element entries are held in the table
PAY_ELEMENT_ENTRIES_F
– Primary key
ELEMENT_ENTRY_ID
EFFECTIVE_END_DATE
 Foreign keys to
– Assignment (assignment_id)
– Element definition (element_link_id)

Element Entries
 Entry values (for an entry) are held in
PAY_ELEMENT_ENTRY_VALUES_F
– Primary key
ELEMENT_ENTRY_VALUE_ID
EFFECTIVE_END_DATE
 Foreign keys to
– Entry (element_entry_id)
– Input Value definition (input_value_id)
 Actual value held in column
SCREEN_ENTRY_VALUE

Element entry concepts
 Two types of element entry
– Recurring
– Non-recurring
 Recurring entries can exist over many payroll
periods
 Non-recurring entries are valid for a single
payroll period only

Element entry types
 There are four element entry types:
 Normal Entry
 Override Entry
 Additional Entry
 Adjustment Entry
 Additive Adjustment
 Replacement Adjustment
 Balance Adjustment

Element entry creator types
 Apart from normal entry, element entries can
be created by several other processes
 This is indicated by the CREATOR_TYPE
column
 The CREATOR_ID column links to the
creating action (see next slide)

Element creators
Creator_id
Type Description Creator_ID links to...
A Absence per_absence_attendances.absence_attendance_id
B Balance Adjustment
D Advance Pay
EE Retropay by Element
F Element Override pay_element_entries_f.element_entry_id
H MIX
M SMP ssp_maternities.maternity_id
P BackPay
Q QuickPay pay_payroll_actions.payroll_action_id
R Retropay by Action
S SSP per_absence_attendances.absence_attendance_id
SP Salary Proposal per_pay_proposals.pay_proposal_id

Element entries table diagram
pay_element_
entry_values_f
pay_element_links
_f
ELEMENT_LINK_ID
per_all_
assignments_f
pay_element_entries
_f
ASSIGNMENT_ID
pay_input_values
_f
INPUT_VALUE_ID
ELEMENT_
ENTRY_ID
pay_element_
types_f
ELEMENT_TYPE_ID

Balances
 Show the positive or negative accumulation of
particular values over time
 Fed via results from payrun or directly from
element entry input values
 Can exist at either Person or Assignment
 Can exist for different time dimensions
 e.g current_run, period_to_date, year_to_date etc

Balances
 Standard UK Payroll Balance Dimensions
_ASG_RUN during one run
_ASG_CALENDAR_YTD since start of calendar year, reset each year
_ASG_YTD since the start of the payroll processing year
_ASG_PROC_PTD for payroll processing period
_ASG_TD_ITD since start of assignment or since transfer
from different tax scheme.
_PER_TD_YTD for the person, since start of tax year (useful
if emp has multiple assignments)
_ELEMENT_ITD since the start of the element entry

Balance Tables: Definition
 Basic definition of a balance is held in the table
PAY_BALANCE_TYPES
 This table holds the:
– Name (BALANCE_NAME)
– Currency (CURRENCY_CODE)
– Unit of Measure (BALANCE_UOM)
 Primary Key BALANCE_TYPE_ID

Balance Tables: Dimensions
 The core definition of balance dimensions are
held in the table
PAY_BALANCE_DIMENSIONS
 This table holds the:
– Name (DIMENSION_NAME)
– Type (DIMENSION_TYPE) - this indicates whether
the balance is ASG or PER
 Primary key BALANCE_DIMENSION_ID

Balance Tables: Defined Balances
 PAY_DEFINED_BALANCES is the
intersection table between types and
dimensions: combination of balance_type
and balance_dimension, e.g.
GROSS_PAY_ASG_YTD
 Primary key DEFINED_BALANCE_ID
 Foreign key BALANCE_TYPE_ID
 Foreign key BALANCE_DIMENSION_ID

Balance Tables: Others
 Details of which element inputs feed a balance
type are held in PAY_BALANCE_FEEDS_F
 Primary key is
BALANCE_FEED_ID
EFFECTIVE_END_DATE
 Balances are classified (in the same way elements
are) by PAY_BALANCE_CLASSIFICATIONS

Balance table diagram
pay_balance_types pay_defined_balancesBALANCE_TYPE_ID
pay_balance_feeds_f
pay_balance_dimensions
BALANCE_
DIMENSION_ID
pay_element_classificationspay_balance_classifications CLASSIFICATION_ID
pay_input_values_f
BALANCE_
TYPE_ID
BALANCE_
TYPE_ID
INPUT_VALUE_ID

People Group
 A flexible area for holding user-defined
assignment data
 Key flexfield structure - provides up to 30
segments of information
 Data can be used for ‘grouping’ sets of
assignments together
 People Group can be used for Element eligibility
 This information is used by the payroll run

People Group
 Data held in the table PAY_PEOPLE_GROUPS
 Primary key PEOPLE_GROUP_ID
– This is the foreign key column in the assignments
table
 Data held in columns SEGMENT1 to
SEGMENT30
 GROUP_NAME holds concatenation of segment
data

People Group - Structures
 ID_FLEX_CODE = ‘GRP’ for people group

People Group - Example code
SELECT ppf.full_name “EMPLOYEE_NAME”
, ppf.employee_number “EMPLOYEE_NUMBER”
, ppayf.payroll_name “PAYROLL”
, ppg.segment1 “SUPERANN_MARKER”
, ppg.segment2 “AL_REVIEW_MONTH”
, ppg.segment3 “PAY_DEAL_ELIGIBILITY”
, ppg.segment4 “PAY_PROGRESSION_TYPE”
, ppg.segment5 “PAY_PROGRESSION_MONTH”
, ppg.segment6 “MARK_TIME_MARKER”
FROM pay_people_groups ppg
, pay_payrolls_f ppayf
, per_all_people_f ppf
, per_all_assignments_f paf
WHERE paf.primary_flag = 'Y'
AND paf.person_id = ppf.person_id
AND paf.payroll_id = ppayf.payroll_id (+)
AND paf.people_group_id = ppg.people_group_id (+)
AND TRUNC(SYSDATE) BETWEEN paf.effective_start_date
AND paf.effective_end_date
AND TRUNC(SYSDATE) BETWEEN ppf.effective_start_date

Salary
 Salary is paid via an element entry
 However, the method of attaching a salary to
an assignment can vary…
 You can use Salary Administration, or…
 you can use Grade Rules and Spinal Points

Salary: Salary Admin
 Uses the Salary Administration facility within
HR
 Allows the creation of ‘proposed’ salaries
 These ‘proposals’ need to be approved before
salary becomes effective.
 Allows increments to be applied by amounts or
percentages
 Salaries can be broken-down into components
(rarely used)

 To use salary administration you need a salary
basis…
 Table PER_PAY_BASES holds definition of a
specific salary basis, e.g.
 basis name (‘Monthly’ etc)
 which element will hold the approved salary
 Primary key PAY_BASIS_ID
 This is a foreign key into the Assignment

 The Salary proposal records are held in
PER_PAY_PROPOSALS
 Primary key PAY_PROPOSAL_ID
 Foreign key to assignment (assignment_id)
PROPOSED_SALARY The new salary proposed by this record
PROPOSAL_REASON The reason for this new salary
CHANGE_DATE The effective date for the new salary
LAST_CHANGE_DATE Date of the last salary proposal
APPROVED Flag to indicate this proposal is approved

 What happens when the proposal is approved ?
 If existing Salary exists, performs a Datetrack
Update on it
 Using new Salary from the proposal
 Uses CHANGE_DATE as the Datetrack effective
date
 Otherwise, creates a brand new entry
 Sets APPROVED to ‘Y’

Salary Admin table diagram
pay_element_entry_values_f per_pay_bases
PAY_BASIS_ID
per_all_assignments_fper_pay_proposals ASSIGNMENT_ID
pay_input_values_f
INPUT_VALUE_ID
PAY_PROPOSAL_ID
CREATOR_ID (creator_type=‘SP’)
INPUT_VALUE_ID

Salary: Grades & Spines
 This method is generally used by Local
Authorities
 Uses Grades, Grade Spines and Spinal Points
 Allows the construction of complex Pay Scales
and progression steps
 Specific salaries can appear in different scales at
different steps
 To be given a salary, the assignment is given a
‘personal’ point placement (called a Grade Step
within the app)

 An assignment is given a specific Grade
(grade_id).
 The Grade is associated with a Grade Scale
(PER_GRADE_SPINES_F)
 A grade scale has a series of grade steps (or
spinal point steps) associated with it
(PER_SPINAL_POINT_STEPS_F)

 Each spinal point step is linked to a Spinal
Point (PER_SPINAL_POINTS) ...
 and an associated step salary value
(PAY_GRADE_RULES_F)

 An assignments spinal point placement (or Grade
Step) is held in
PER_SPINAL_POINT_PLACEMENTS_F
 Primary key is
PLACEMENT_ID
EFFECTIVE_END_DATE
 Salary is NOT held on an element entry !

Grades & Spines table diagram
per_spinal_point
_steps_f
per_grade_spines_f
per_all_
assignments_f
per_spinal_point_
placements_f
ASSIGNMENT_ID
per_spinal_points
SPINAL_
POINT_ID
PARENT_
SPINE_ID
GRADE_
SPINE_ID
per_grades
GRADE_ID
STEP_ID
per_parent_spines
pay_grade_rules_f
PARENT_
SPINE_ID
GRADE_ID
STEP_ID
CEILING_STEP_ID
GRADE_OR_SPINAL_POINT_ID(rate_type=‘SP’)
SPINAL_POINT_ID

WHO and OVN ??
A couple of things that go on behind
the scenes !

WHO
 In application, follow the following navigation
path:
Help=>About=>This Record (or something
similar)
 Where does this information come from ??
 The WHO columns.

WHO
 Virtually every table within the HRMS
application (and indeed apps in general) has
the following columns…
 CREATED_BY
 CREATION_DATE
 LAST_UPDATED_BY
 LAST_UPDATE_DATE

WHO
 Created_By and Creation_Date are set at the time
the record is first created
– Created_by being the USER_ID of the user
 Last_Updated_By and Last_Update_Date are set
every time that particular row is changed

WHO
 These columns are maintained by a database
trigger.
 Trigger name is <TABLE_NAME>_WHO
– e.g. per_all_people_f_who etc
 These are created and enabled at install time
 They are re-enabled every time a patch is applied
 It is not recommended that you disable them!

OVN
 Picture this senario…
 User A queries a person row within the
application.
 User B queries back the same row within the
application.
 User B then makes a change to the row and
commits it back to the database.
 User A then makes a change and tries to commit
it back.

OVN
 What happens ?
 Hopefully, User A’s transaction will fail with an
error similar to…
– “Record has been changed by another user. Please
requery to see changes”
 How is this done ???
 Through the use of
OBJECT_VERSION_NUMBER

OVN
 Object_version_number is a system-
generated version of the row
 Increments by one with each update
SQL> select effective_start_date, object_version_number from per_all_people_f
where person_id = 130
SQL> /
15-MAR-94 8
17-SEP-96 8
25-FEB-97 11
18-MAR-97 12
26-FEB-98 10
01-MAR-98 13
01-OCT-98 21

OTA - An Overview
ACTIVITIESACTIVITIES
RESOURCESRESOURCES
SUPPLIERSSUPPLIERS
ENROLMENTSENROLMENTS
CUSTOMERSCUSTOMERS
STUDENTSSTUDENTS
HRMSHRMS
EVENTEVENT

A Functional Demo
OTA - An Overview

OTA Tables
A look at the key entities and tables
within Oracle Training Administration

ota_suppliable_resources
OTA Table diagram
ota_resource_
usages
ota_events
ota_activity_
definitions
ota_activity_versions ACTIVITY_ID
ota_resource_
definitions
RESOURCE_
DEFINITION_ID
DELEGATE_
PERSON_ID ota_delegate_
bookings
EVENT_ID
per_all_people_f
SUPPLIED_
RESOURCE_ID
ACTIVITY_VERSION_ID
ota_resource_
bookings
EVENT_ID

OTA Tables - What we’ll cover
 Activities
 Events
 Resources
 Enrolments

Activities
 An educational offering that may improve
qualifications, competencies or experience
 An activity definition is made up of a number
of versions
 The definition determines whether a version
can run concurrently or not.

Activity Definition
 The definition of an activity is held in
OTA_ACTIVITY_DEFINITIONS
 Primary key is ACTIVITY_ID
 Foreign key to business group
 NAME holds name of activity definition

Activity Version
 Defines the content and nature of a particular
version of an activity
 Includes
 Objectives
 Intended audience
 Min and Max number of delegates allowed
 Actual and Budgeted costing information
 May supersede another version
 Validity dates allow for scheduling as an event

Activity Version
 May be categorised
 May belong to an external vendor (with
appropriate links into PO system)
 Data held in the table
OTA_ACTIVITY_VERSIONS
 Primary key is ACTIVITY_VERSION_ID

Events
 Several different types of events
 A scheduled event is a specific instance of an
activity version
 it allows booking of resources
 it allows enrolment of delegates
– with specified enrolment windows prior to event
running

Events
 A session (event) is a unit of time within a
scheduled event
 Allows independent booking of resources by
session, e.g.
 Mr Jones - Day 1
 Mr Smith - Day 2 AM session
 Mr Pink - Day 2 PM session etc
 An event can be made up of any number of
sessions

Events
 A development event enables the scheduling of
employee time and resources
 Enables the recording of time taken to develop
new training events or the updating of existing
events

Events
 A program is a group of events scheduled
together
 Delegates can enrol on a program enabling them
to attend some or all of the program events.
 A one-time event is a one-off, Ad Hoc event for
which there is no corresponding Activity
definition or version.

Events
 Events are held in the table OTA_EVENTS
 Primary key EVENT_ID
 TITLE holds the unique name for this specific
event
 EVENT_TYPE indicates the type of the event
 maps to ‘TRAINING_EVENT_TYPE’ lookup

Events
 Additional items of interest on events
– Event start & end dates
– Event start & end times (usefull for sessions)
– Duration
– Enrolment start & end dates
 Also has items that override the activity:
– Minimum attendees
– Maximum attendees

Resources
 A resource is any facility, person or item of
equipment needed for a training course
 Resources can be People
 Trainers, Reviewers etc
 Resources can be equipment
 OHP’s, BARCO’s, Pencils etc
 Resources can be facilities
 Training rooms, Conference halls etc

Resources
 Resources are defined by three components
 1) Resource Type
 Type of resource e.g Venue, Trainer
 2) Resource Definition
 A specific definition of a resource type
 3) A Suppliable Resource
 A specific instance of a resource that can be booked
to an event

Resource Types
 There are 2 predefined resource types
– Venue
– Trainer
 You can add additional resource types to suit
your needs
 Resource types are held as a Lookup
 Lookup_type = RESOURCE_TYPE

Resource Definitions
 A resource definition is a Keyflexfield structure
(Training Resource).
 Up to 30 segments of information available
 The name of the structure must be the same as
the name of the resource type
 Data is held in table
OTA_RESOURCE_DEFINITIONS
 Primary key RESOURCE_DEFINITION_ID

Resource definitions structure
 ID_FLEX_CODE = ‘RES’ for bank details

Definition structure examples
SQL> select id_flex_code, id_flex_num, id_flex_structure_name
2 from fnd_id_flex_structures_tl
3 where application_id = 810
4
SQL> /
RES 101 Trainer
RES 50132 Venue
RES 50133 Books
RES 50134 Videos
RES 50135 Others
RES 51018 PC

Definition structure examples
50132 50133 50134 101
SEGMENT1 Name Name
SEGMENT2 Center Title
SEGMENT3 Title License Type
SEGMENT4 Layout Publisher
SEGMENT5 Last
reviewed
SEGMENT6 Facilities Price Duration
SEGMENT7 Max Size X-Charge
rate
SEGMENT8 Currency
SEGMENT9 Fire Exits Format Role 1
SEGMENT10
SEGMENT11 Has Powerpoint Role 2
SEGMENT12 Classification
SEGMENT13 Has MSWord Email ID
SEGMENT15 Has Screencam

Suppliable resources
 A ‘suppliable’ resource is an ‘activated’ resource
definition
 As a suppliable resource, it can be booked to
events
 Data held in OTA_SUPPLIABLE_RESOURCES
 Primary key SUPPLIED_RESOURCE_ID
 Foreign key back to the resource definition

Suppliable resources
 Additional information can be held on a supplied
resource:
 Cost & Cost Unit
 Capacity (e.g the capacity of a room)
 Lead Time
 Supplier reference
 Start and End Dates

Resource uses
 Once you have a suppliable resource, it can
be ‘used’ in 2 ways
 As a Resource ‘Usage’
 As a Resource Booking

Resource Usages
 A resource usage is the requirement for a given
resource for an activity
 You can indicate if a resource is a mandatory
requirement for an activity
 Data held in OTA_RESOURCE_USAGES
 Primary key RESOURCE_USAGE_ID
 Foreign key back to suppliable resources

Resource Bookings
 You can book a resource for:
 A scheduled Event
 A Development Event
 A Session
 A resource can be booked for:
 A range of dates
 Specific start & end times (useful if resource is not
required for full duration of an event)

Resource Bookings
 Data held in OTA_RESOURCE_BOOKINGS
 Primary key RESOURCE_BOOKING_ID
 Foreign key back to suppliable resource
 Bookings can have a booking STATUS
 e.g PLANNED or CONFIRMED
 Resources booked as ‘Planned’ can be double-
booked

Resource Bookings
 A booking has additional information...
 Quantity
 e.g 24 writing Pads etc
 Delegates per unit
 e.g 2 delegates per PC
 Contact Name and number
 e.g contact responsible for resource
 Required Dates and times
 important if resource is required for additional time

Enrolments
 Enrolments are known as Delegate Bookings
 Allows the booking of Internal and External
persons onto an Event, Program, Session
 An internal enrolment can be either:
– An individual person enrolment
– A group enrolment, made by a manager

Enrolments
 An enrolment has one of the following statuses:
– Required (as in a provisional booking)
– Waitlisted (a confirmed booking onto a full event)
– Placed (a confirmed booking)
– Cancelled (this booking has been cancelled)
– Attended (successful attendance of this event)
 The system is capable of auto-enrolling waitlisted
bookings if places come available

Enrolments
 Enrolments are held in
OTA_DELEGATE_BOOKINGS
– Primary key BOOKING_ID
 Foreign keys are:
– to the event (EVENT_ID)
– to a person i.e. employee (delegate_person_id)

Agenda
 Introduction
 Uses of Custom Library
 Custom.pll
 Coding Standards
 Trigger points
 Schemas
 Directory structure

Introduction
 The Custom Library is a mechanism to extend
Oracle Applications without modification of
Oracle Application code.
 It is a library of PL/SQL procedures that allows
you to take full advantage of all of the
capabilities of the Oracle Forms Developer suite
of products and integrate your code directly with
Oracle Applications.

Introduction
 The library is a supported, upgradeable, user
definable, partitioned code repository for custom
code which can be easily ‘decoupled’ for
debugging purposes.
 The CUSTOM library allows extensions of
Oracle Applications without modification of
Oracle Applications code. This means that
support is not violated.

Introduction
 Custom Library Architecture
Application
Form
APPCORE
Library
Custom
Library

Introduction
 It works in the following way: The standard ‘events
triggers ’ in the Application forms call APPCORE
( Application INTERNAL library) routines, these in turn
call the Custom library. Custom library is a forms library
(it can call PL/SQL programs), that is referenced by the
Oracle Applications on a constant basis. Customising this
program library makes it possible to modify the look and
functionality of the Application.
 The custom library (custom.pll) is then
attached/referenced in the Application forms

Uses
 Zoom
– a mechanism to ‘jump’ from one form to another.
 Generic Events
– Change field prompts
 Product Specific Events
– Enforce specific business rules
 Setting Visual Attributes
– Making mandatory fields red for example
 Custom entries for special menus
– Open custom forms

Additional uses
 Changes form field properties e.g. hiding form fields,
changing colours
 Adding field and cross field validation
 Changing a default LOV or default where clause
 Setting of default values
 Update non-enterable fields
 Manipulating conditionally required fields
 Manipulating mutally exclusive fields

Events
 Generic
– Common to all forms in Oracle applications
 Product-specific HRMS
– WHEN-CREATE-RECORD
– PRE-INSERT
– POST-DELETE
– WHEN-FORM-NAVIGATE
– POST-QUERY

Events
– PRE-DELETE
– POST-FORMS-COMMIT
– WHEN-BUTTON-PRESSED
– KEY-DELREC
– POST-UPDATE
– PRE-UPDATE
– POST-INSERT
– SPECIALn
– NAVIGATE

CUSTOM.pll - Public Link Library
 This library resides in
– $AU_TOP/resource/plsql directory or platform equivalent
 The above directory will contain CUSTOM.pll and
CUSTOM.plx (compiled code). Forms always use the
.plx over .pll. If .plx does not exist, then .pll is used.
 Using .plx will provide better performance.
 Forms Developer needed to modify Custom.pll.
 Transfer from client to server in BINARY mode.
 Generate the PL/SQL library to create the .plx file.

Custom.pll (cont’d)...
Custom code is written within the procedure shells that
are provided. All logic must branch, based on the form
and block for which you want it to run. Custom code can
then take effect based on these events
e.g.
IF (form_name = ‘PERWESEPI’)
AND (block_name = ‘PER’ THEN)
custom code goes here …….
Important - you CANNOT change the specification of the
Custom package.

Custom.pll (cont’d …)
You cannot use SQL in the custom library, you may call
server side packages instead.
The custom library is global - shared by all the
Applications.
Document changes, this is vital when using custom
library to ensure that customisations are preserved.
Any custom packages used or called from the custom
library should use the naming convention XXHR or
XX_HR to indicate that this is a non-standard HR code.

Coding Standards
 Follow standards for Oracle Forms
Developer.
 Use FND_MESSAGE.set_name for
messages rather than MESSAGE
 Version Control

References
 Oracle Application Developer’s Guide
Release 11i , Volume 1, April 2001
( Chapter 28 )
 Other good sources are:
– Metalink - 73505.1, …..
– ACE
 Many documents on the Oracle intranet

Questions
Could you
repeat
that again
please?

Datamigration
 Components
– Extraction of legacy data
– Loading of data into temporary tables
– Translations/Lookups resolutions
– Wrapper scripts to load data using APIs and/or
Datapump
– Other components could include Workflow,
Portals and Concurrent Manager.
 We will only discuss APIs and Datapump in
this course.

Agenda
 Introduction
 Types
 Parameters
- IN
- OUT
 Flexfields
– Key
– Descriptive
 User Hooks
 Tips and Techniques
 References

Introduction
Application Program Interfaces
(APIs)
APIs are part of the Oracle Applications
development methodology for its multi-
tiered architecture
DatabaseDatabase
APIsAPIs
Client-Side
Server-Side
ProgramsPrograms

Introduction
Application Program Interface (API)
Published APIs
Oracle Applications
Internal Code Layers
Custom / Alternative Interface LayerCustom / Alternative Interface Layer
Business Process LayerBusiness Process Layer
Business Support LayerBusiness Support Layer
Row Handler LayerRow Handler Layer

Introduction
 PL/SQL packages containing procedures and functions
 Provide an insulating layer between the user and data-
model
 Enable one to capture and execute business rules
 Uses
data migration
interfaces
wherever the business rules need to be applied e.g.
bespoke forms , data validation, ….
 Guaranteed to maintain the integrity of database
 Two types of APIs
Generic
Legislation specific (e.g create_gb_employee).

Introduction
 Locating more information on APIs:
– $PER_TOP/admin/sql – file with ext. of PKH for header and
PKB for body
– SQL*Plus – describe <API_NAME>
 Metalink is a useful source of information:
– Complete list of API see note No. 157505.1
– FAQ see Note No. 130359.1

Types of API
There are 3 types of API to perform necessary
business processes :-
 CREATE - insert or create new records in
HR/Payroll
 UPDATE - amend or update records
 DELETE - delete or in some instances end-date
records in HR/Payroll.

Parameters
 Each API has a number of parameters as with most
PL/SQL code
– Most of the parameters within the HR API suite map onto a
database column (with a prefix of p_ )
– There are additional control parameters
 Parameters types:
– IN
– OUT
– IN/OUT

Parameters
 Not all parameters are necessary but mandatory ones must be
supplied.
 OUT parameters must also be catered for by declaration of local
variables to capture the resulting values.
 IN/OUT must be included in calling programs (even if not used).
Values are passed via local variables.
 Control parameters (ones which will not be used to populate database
columns
– p_validate – TRUE or FALSE
– object_version_number
– effective_start_date & effective_end_date
– datetrack_mode - UPDATE,CORRECTION,UPDATE_OVERRIDE
,UPDATE_CHANGE_INSERT
– language

The P_VALIDATE Parameter
This is an important parameter which can have
one of 2 values :-
 TRUE
 FALSE
TRUE - data is validated but not committed to
the database
FALSE - data is validated and then committed to
the database

Flexfield Validation via APIs
 Descriptive Flexfields

 At the moment there is no automatic validation of flexfield attribute
columns according to the flexfield definitions set up in the Application.
Validation routines should be written to do this.
 Skeleton flexfield validation packages are provided to be modified for
use with the APIs. These can be found in the following directory :-
 $PER_TOP/admin/sql
 If values are entered in the attribute columns of an API then the API will
error. If you do not wish to validate then the skeleton packages can be
amended to cater for this.

Flexfield Validation via APIs
 Key Flexfields
 Please note that there are equivalent skeleton flexfield validation
packages for key flexfields. i.e. pypgpfli.pkb for People Group. However,
these only validate against existing flexfield combinations, and do not allow
creation of new ones.
 Could do this using User Hooks !
 What a fantastic link !

User Hooks
 Hooks let you extend the standard business rules
that are executed by the APIs. You can include
your own validation rules or further processing
logic and have them executed automatically
whenever the associated API is executed.

User Hooks
 Uses of API hooks
- enforcing customer specific validation/business rules
- maintenance of data held in customer specific tables
 Types of User Hooks
– BEFORE - executed before the API
– AFTER - executed after API has completed
processing

User Hooks
 Implementing User Hooks
– Identify APIs and user hooks
– Identify available data
– Implement PL/SQL server-side package Procedure
– Register procedure with user hooks
 Register your extra PL/SQL packages with the appropriate
API user hooks by calling the
hr_api_hook_call_api.create_api_hook_call API. Define
the mapping data between the user hook and the server-
side package procedure.
– Execute user hook preprocessor

What Coding Standards?
 Follow SQL*Plus, PL/SQL coding standards.
 Application Naming standards
 Development standards
 Code should be well commented
 Best practice - look at standard APIs

Copyright (c) 2001 - Oracle Corporation UK Lim
What is Data Pump?
A mechanism for loading / updating data in to the
Oracle HRMS Application
Uses batch interface tables to store data to be
loaded / updated
All core HRMS Application data manipulation is
done using ‘published’ APIs
User readable values used ( in most cases )
Shields user from complexity of underlying data
structure
Has built in error handling and restartability

Data Loading Flow
DATADATA
FILE(s)FILE(s)
SQLSQL
LoaderLoader
CustomCustom
Load Table(s)Load Table(s)
CustomCustom
ProgramProgram
Batch Header TableBatch Header Table
Batch Line TableBatch Line Table
Data Pump RoutinesData Pump Routines
hr_pump_utils...hr_pump_utils...
hrdpp_....hrdpp_....
ApplicationApplication
TablesTables
Data PumpData Pump
EngineEngine

Data Pump Components
 A set of tables
 “Meta Mapper” component
 Data Pump PL/Sql interfaces
 A set of views
 Data Pump engine

Meta Mapper
 Generates Data Pump ‘meta’ layer views and
procedures ( like an install routine )
 Two modes of operation
–Generate meta layer for all supported APIs
HR_PUMP_META_MAPPER.GENERATEALL;
–Generate meta layer for individual API
HR_PUMP_META_MANAGER.GENERATE
(‘HR_EMPLOYEE_API’,
‘CREATE_GB_EMPLOYEE’);

Data Pump Generated PL/Sql
Interfaces
 The meta mapper generates a number of
package procedures for each supported API
–INSERT_BATCH_LINES
e.g. HRDPP_CREATE_GB_EMPLOYEE.INSERT_BATCH_LINES
Select distinct name from all_source
where name like ‘HRDPP%’

Data Pump Generated PL/Sql
Interfaces
 The meta mapper generates a corresponding view
for each meta-mapper package:
– e.g. HRDPV_CREATE_GB_EMPLOYEE
Select view_name from all_views
where view_name like ‘HRDPV%’
 Each view gives useful access to
HR_PUMP_BATCH_LINES
 You can Insert/Update/Delete through the views

Data Pump Tables
 HR_PUMP_BATCH_HEADERS
BATCH_ID Sequence generated unique Id
BATCH_NAME Unique name for batch
BATCH_STATUS ‘ACTION_STATUS’ lookup
.. ..
.. ..
Tip: Batch Name usefully derived from a File Name/File id
combination (Create a new File Header in a custom table
for each loaded legacy file)

Data Pump Tables..
 HR_PUMP_BATCH_LINES
BATCH_LINE_ID Sequence generated Id
BATCH_ID FK to batch headers table
API_MODULE_ID FK to HR_API_MODULES
LINE_STATUS U / C / E
USER_SEQUENCE Controls processing order
LINK_VALUE Important in parallel loads
PVAL001 Data item field
.. ..
.. ..
PVAL230 Data item field

Data Pump Tables...
 HR_PUMP_BATCH_LINE_USER_KEYS
USER_KEY_ID Sequence generated Id
BATCH_LINE_ID FK to batch lines table
USER_KEY_NAME e.g. ‘PER:000100’, ‘ASG:000100’
UNIQUE_KEY_ID e.g.person_id, assignment_id etc
.. ..
.. ..
• Only populated when rows are loaded into HRMS
• Non-DP loaded entities will not have corresponding user-key

Data Pump Tables….
 HR_PUMP_BATCH_EXCEPTIONS
EXCEPTION_SEQUENCE Sequence generated Id
EXCEPTION_LEVEL ‘MESSAGE_LEVEL’ lookup
SOURCE_ID Either BATCH_ID or
BATCH_LINE_ID
SOURCE_TYPE BATCH_HEADER / BATCH_LINE
EXCEPTION_TEXT Text of exception
.. ..
.. ..

Data Pump Utility PL/Sql Routines
 Create batch header
–HR_PUMP_UTILS.CREATE_BATCH_HEADER
 View meta mapper generated views and
PL/Sql routines
–HR_PUMP_META_MAPPER.HELP
(<API Package Name>,
<Procedure Name>);
e.g.HR_PUMP_META_MAPPER.HELP
(‘hr_employee_api’,
‘create_gb_employee’);

Current Data Pump Limitations
 Not all currently published APIs are
supported
 Care must be taken when purging Data
Pump tables
 Does not support already loaded systems
( issue with user key table )

Data Pump Workshop
 Load data from data_pump_emp_ld table
– exec data_pump_emp_pk.create_emp(‘USERx’,‘Ux’);
– x identifies your user number e.g. ‘U1’ etc
 select batch_id, batch_name from hr_pump_batch_headers;
 select batch_id, line_status, p_employee_number, p_last_name from
hrdpv_create_gb_employee;
 Submit ‘Data Pump Engine’ with ‘batch name’ & ‘Yes’ to validate
 Check line_status for change from ‘U’ to ‘C’ or ‘E’
– No errors? re-submit the batch with ‘No’ to validate
 Check hr_pump_batch_errors
– What do I do with my errors?

HRMS Data Pump Reference
White Paper: Metalink Note 223938

Security in Oracle HRMS
Business Group
What? Who?
MenusMenus
Task FlowsTask Flows
FormsForms
Custom FormsCustom Forms
Reports/ProcessesReports/Processes
OrganizationsOrganizations
PositionsPositions
PayrollsPayrolls
Responsibility

Secured Tables
 HR_ALL_ORGANIZATION_UNITS
 PER_ALL_POSITIONS
 HR_ALL_POSITIONS_F
 PER_ALL_VACANCIES
 PER_ALL_PEOPLE_F
 PER_ALL_ASSIGNMENTS_F
 PAY_ALL_PAYROLLS_F

Table and View Name Examples
 PER_ALL_PEOPLE_F
– Unrestricted base datetracked table (view all)
 PER_PEOPLE_F
– Secure view of person table
 PER_PEOPLE
– Secure view of person table at session date
 PER_PEOPLE_X
– Secure view of person table at system date
 PER_ALL_PEOPLE
– Unrestricted view of person table at session date

Secure View Clauses
SELECT ....
--
FROM PER_ALL_PEOPLE_F PAP
--
WHERE DECODE(HR_SECURITY.VIEW_ALL,'Y','TRUE'
,HR_SECURITY.SHOW_RECORD('PER_ALL_PEOPLE_F'
,PAP.PERSON_ID
,PAP.PERSON_TYPE_ID
,PAP.EMPLOYEE_NUMBER
,PAP.APPLICANT_NUMBER
)) ='TRUE'
AND decode(hr_general.get_xbg_profile,'Y', pap.business_group_id
,hr_general.get_business_group_id) = pap.business_group_id
PER_PEOPLE_F

Secure View Clauses
SELECT ....
--
FROM PER_PEOPLE_F
--
WHERE TRUNC(SYSDATE) BETWEEN EFFECTIVE_START_DATE AND
EFFECTIVE_END_DATE
PER_PEOPLE_X

Secure View Clauses
SELECT ....
--
FROM PER_PEOPLE_F
--
WHERE EFFECTIVE_START_DATE <=
(SELECT SS.EFFECTIVE_DATE
FROM FND_SESSIONS SS
WHERE SS.SESSION_ID = USERENV('sessionid'))
AND EFFECTIVE_END_DATE >=
(SELECT SE.EFFECTIVE_DATE
FROM FND_SESSIONS SE
WHERE SE.SESSION_ID = USERENV('sessionid'))
PER_PEOPLE

Security Profiles
 Restrict user access to a subset of people
 Linked to a Business Group
 Utilise Org and Position Hierarchies
 Utilise Payroll definitions

A Security Scenario
 Restrict user access to only those employees that are
assigned to a named payroll (HRTech Payroll)
 The main steps are:
– Create a Security Profile for the payroll ‘HRTech Payroll’
– Create a Responsibility for this Security Profile
– Assign this Responsibility to Users

Security Profiles
Security Profile
Responsibility
Profile Option:-
HR: Security Profile

Security List Tables
 PER_PERSON_LIST
 PER_POSITION_LIST
 PER_ORGANIZATION_LIST
 PAY_PAYROLL_LIST
 PER_PERSON_LIST_CHANGES
 All the above tables are refreshed by the running
of LISTGEN (‘Security List Maintenance’)

Security Example
 Create a Security Profile:
– ‘HRTech Payroll’ restricting to the payroll ‘HRTech
Payroll’
 Assign to Responsibility :
– ‘HRTech Payroll’ Responsibility
– ‘HR: Security Profile’ profile option
 Assign Responsibility to a User
 Assign employee to ‘HRTech Payroll’
 Run LISTGEN

select psp.security_profile_name
, ppx.employee_number
, ppx.full_name
, nvl(ppf.payroll_name,'No Payroll') payroll
from per_security_profiles psp
, per_people_x ppx
, per_assignments_x pax
, per_person_list ppl
, pay_payrolls_x ppf
where psp.security_profile_id=ppl.security_profile_id
and ppl.person_id=ppx.person_id
and pax.person_id=ppx.person_id
and pax.payroll_id=ppf.payroll_id (+)
and psp.security_profile_name =‘HRTech Payroll'
Example Query Script

References
 Us - steve.j.williams@oracle.com
- barry.cooper@oracle.com
- jasbir.grewal@oracle.com
- mark.riles@oracle.com
 Chapter 3 in Implementing Oracle HRMS,
RELEASE 11i December 1999.
 Metalink
 ACE

APPENDIX
 Product Directories
 Logical Diagrams

Copyright © Oracle Corporation, 2001. All rights reserved.
admin
driver import odf sql
<PROD>_TOP
java media
bin html lib mesg
patch
plsql
forms include log out reports
help
sql
resource
Product Directories

Q U E S T I O N S
A N S W E R S
&

Hrms for beginners

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (15)

Ähnlich wie Hrms for beginners

Ähnlich wie Hrms for beginners (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Hrms for beginners

Hinweis der Redaktion