Oracle Core HR >

Date Tracking

Contents
1. 1 Date Tracking
1. 1.1 Concept of EOT
2. 1.2 Date Track Modes
3. 1.3 End Dating
4. 1.4 DATED Tables
2. 2 Keeping Person Records
3. 3 Keeping Employment Records
4. 4 Person Types

Date Tracking
Date tracking is a design / concept, which is used by Oracle E-Biz, in order to support the
storage of historical data, along with the current ones. It is a mechanism to store data
based on dates. Lets try this with an example. There was Mr. Joe, who used to work as a
Manager. He had been with the company since last 8 years. In this period of 8 years, he had
been working in a set of different positions. Initially he joined as an Analyst, then he got
promoted to senior analyst, then he became, the manager of a department.
If we were to know the position he was in, as of a date in 2008; how do we do that?
Imagine, we are making a database table to store the employee related data, or rather lets
take the well known Employee table (that we all played with, while learning SQL), all it
stores is the current position. Do we have a way to know the employees previous position?
The answer is No.
So here is an innovative way, if we introduce, two more columns to the employee table,
with names like START_DATE and END_DATE, and store the dates in there, it might
solve my problem.

The table will look like this:

EMP_ID

EMP_NAME

POSITION

Analyst

START_DATE

END_DATE

01-JAN-2002

31-DEC-2006

1234

Joe

1234

Joe

Sr. Analyst

01-JAN-2007

31-DEC-2009

1234

Joe

Manager

01-JAN-2010

Till Date

Now, if we ask the same question again, it tells me, oh yes, he was a Sr. Analyst in 2008.
This is a nice table, which is capable of storing the historical data as well, however our data
is repetitive. Its not greatly normalized. But well, thats the price we will have to pay, in
order to get the advantage of storing historical data.

Hick ups:

Yes our data is not normalized.

We will have to use a Composite Primary key, so that means, anytime we are
querying the table for current data, we will need a self join to say, "SYSDATE
between START_DATE and END_DATE"

There are a lot of tables in Oracle E-biz that need to store Historical data. All those tables
are date tracked. They hold two extra columns to store the start and end date of the record.
And the columns are named EFFECTIVE_START_DATE and EFFECTIVE_END_DATE
respectively. These columns do not accept null value. All Date Tracked table names end with
_F.

Concept of EOT
But now, how do we manage the Till Date thing? We need to store a date there, it does not
accept null. For that Oracle added another model, concept of EOT (End of Time). As per this
concept, 31st December 4712 is the end of time. So at any place, if we were to show the
record is the latest one, we would use, the 31-DEC-4712 in the EFFECTIVE_END_DATE
column.

The date track also makes us capable of storing Future data. Let's say, we will promote Mr.
Joe to Director as of 01-JAN-2014. So we will add another record in the table with Start
Date as 1-JAN-2014 and end date as 31-DEC-4712. And will update the manager record's
END_DATE column with 31-DEC-2013, right?
So having the EOT in the EFFECTIVE_END_DATE column does not always fetch us the
currently active record. We should always use the condition (SYSDATE between
EFFECTIVE_START_DATE and EFFECTIVE_END_DATE).

Date Track Modes

Lets talk about the application of date track concept? We will start with the modes. The
modes represent the different ways a particular record can be updated in a date tracked
table. For an example, we want to remove a record on a Date tracked table. We have two
options:

Purge : This removes the entire record from the database

End Date: This updates the EFFECTIVE_END_DATE on the currently active row to
today's date.

While inserting a new record, we will not be prompted for any modes.
EFFECTIVE_START_DATE is the today's date and EFFECTIVE_END_DATE is the EOT.

The

While updating a record; for an example, we want to make Mr. Joe a Sr. Manager. It
prompts for these options:

Update: This will add another row to the table, with an EFFECTIVE_START_DATE of
today, and EFFECTIVE_END_DATE as EOT; and it will update the currently active
record's EFFECTIVE_END_DATE to yesterday's date. So Mr. Joe's manager row will
get updated with the new EFFECTIVE_END_DATE as Yesterday's date; and a new
record will get created with the EFFECTIVE_START_DATE as Today, and
EFFECTIVE_END_DATE as EOT. Clear? Alright.

Correction: This is simple. It will simply go and update the column. It will not create
a record. Our previous column value will be lost. So in this case, Mr. Joe's record of
manager will be updated. The position field will get updated to Sr. Manager, and no
one will ever know, that Mr. Joe was a manager at one point of time.

If UPDATE was selected, the system checks, whether the record being updated has already
had future updates entered or not. If it has been updated in the future, we will further be

prompted for the type of update. Those options are

UPDATE_CHANGE_INSERT (Insert) - The changes that the user makes remain in

effect until the effective end date of the current record. At that point the future
scheduled changes take effect.

UPDATE_OVERRIDE (Replace) - The user's changes take effect from now until the
end date of the last record in the future. All future dated changes are deleted.

So for an example, we promoted Mr. Joe to Director as of 01-JAN-2014. Now, the currently
active row has an EFFECTIVE_END_DATE of 31-DEC-2013. We get a request from my
manager that Mr. Joe should get promoted to Asst Director First and then should get
promoted to the director.

Here is a diagrammatic representation that will explain it better. See Figure 2.1 Date Track
Modes.
Figure 1 Date Track Modes

(Figure 2.1 Date Track Modes)

As we are updating a record, that has changes in future, It will ask if we want to do an
Insert / Replace.
If we choose Insert, it will go ahead and insert the record from today to 31-DEC-2013. So a
new record gets created with EFFECTIVE_START_DATE of today and EFFECTIVE_END_DATE
of 31-DEC-2013, and the currently active record gets updated with an
EFFECTIVE_END_DATE of yesterday.
If we choose Replace, it will discard the future change. So a new record gets created with
EFFECTIVE_START_DATE of today and EFFECTIVE_END_DATE of 31-DEC-4712, and the
currently active record gets updated with an EFFECTIVE_END_DATE of yesterday. The
Record with Director as the position gets purged.

End Dating
Usually, we do not delete any data from system in HRMS. Although we should purge the
data that was never relevant to the enterprise or any given employee or assignment,
however we should just populate the end date in case of data, which was used earlier and
not being used anymore.
For an example, there is a date tracked table that stores the car hire details. In that table,
we are storing the data related to the options available to choose a car for hire. We are
giving 4 options to the employees to hire a car; for say, a Chevy, a Dodge, a Hyundai and
a Lamborghini. However from year 2010, due to low budget, we are not going to be giving
Lamborghini as an option anymore. In this case, we are going to populate an end date
(EFFECTIVE_END_DATE) on the Lamborghini record with a date of 31-DEC-2009. So that it
will tell me, the car was available in past, but is not available now (01-JAN-2010). This
feature is known as End Dating.

NOTE
Usually in a date track table, if we opt for a delete in forms; it will prompt us to
enter, whether its an End Date or a purge.

DATED Tables
Now, we know what a date tracked table is. Lets talk about DATED Tables. These are more
or less similar to the Date Tracked enabled tables; however these tables do not use the
composite primary key like the former. These tables use only one Primary key, but with two
date fields - DATE_FROM and DATE_TO.
So whats the use of these tables? Although they serve the same purpose of storing
historical and future records, unlike the Date Tracked tables, the consistency of data is not
maintained. So we can consider these to be partially date tracked. To make it simpler, lets
try Mr. Joe's example again. As we would need the position column to be maintained
without any hassle of dates, we created two new fields and then tried identifying individual
rows with the combination of EMP_ID and the date columns. So that enabled me with
features like, Update, Correction, Insert and Replace.
However imagine a case where, we do not need that much data consistency, so that
whenever we do some updates to a column, it adds a new row to the table. Like address.
So if we were to store Mr. Joe's address, we will keep it in a table, that can just tell me,
since when, till when did he live in a given address, we do not want any complexity of
Insert and replace. All we want to do is to be capable of updating the address (thats a new
record), and correct the address (Updating the same record). So in this case every time we
update an address, it creates a new ADDRESS_ID.
These are like a level lower than Date Track enabled tables. These tables do not have any
indicator in their names, unlike the date track enabled tables.
We will discuss more about these tables later, when we discuss about the technical aspect of
Core-HR.

Keeping Person Records

Talking about the person records, the indicative details of all persons are stored in a table
named PER_ALL_PEOPLE_F. This is considered the base table to store the basic
information of any given person, associated with the enterprise, be it an employee or
spouse / child of an employee. However there are a lot of other tables that store additional
information related to the persons.
You must have guessed that, this is a date track enabled table, as it ends with _F. Hence
the table has a composite primary key, PERSON_ID along with EFFECTIVE_START_DATE
and EFFECTIVE_END_DATE. The table also contains foreign keys to a lot of related tables.
Along with that, fields like name, gender, date of birth, and all basic details are present in
this table. As per E-Biz design, this table is considered to be the pivot for all employee and
employee's contact records.

Question: What is a contact?

Anybody with any specific relationship with a person is its contact. If Jill is married to
Joe, Jill is Joes contact. The relationship can be of any type, spouse, children, domestic
partner, grand children, ex-spouse etc.

The other related tables to store person related details are:

PER_ADDRESSES: stores the address of a person. Its a DATED table.

PER_PHONES: stores the Phone numbers of a person.

PER_CONTACT_RELATIONSHIPS: stores the contacts of a person.

PER_DISABILITIES_F: stores the disability information of a person.

PER_PERSON_TYPE_USAGES_F: stores the person type of a person (example:

Employee, Ex-employee, Beneficiary etc.)

PER_QUALIFICATIONS: stores the qualification of a person.

These are some of the basic and frequently used tables, to store the Person level records,
however there are a lot of tables, and views that can be used to store any specific
information about a person. We will learn about those, as and when we come across them.
Again, there are a set of related tables/ views, that store similar information, but in a
different fashion. Lets jump on to examples.

PER_ALL_PEOPLE_F: Stores the Person data with Date Track

PER_PEOPLE_F: a view over PER_ALL_PEOPLE_F with additional security on records.

Like, which user can see what all records?

PER_PEOPLE_X: shows up only the currently active record as of SYSDATE.

PER_PEOPLE_V: a view used by E-Biz forms to show the data with additional security
using security profiles.

PER_ALL_PEOPLE_D: a view that shows the date track history.

Now we know, even though the data stored is same, various tables/ views are designed to
store the data in different fashions. The reason may be data abstraction or security or in
few cases just history.

Keeping Employment Records

The Employment records are very important to the enterprise, as these are going to be the
details about our employees and ex-employees. The way the data is stored in the
application is much normalized. When we talk about the employment, what are the details
that we need to take care of?

His Assignment

His Service with the Firm

His Salary

Lets discus these details one by one.

Assignment: This is the unit of an employment period. It starts with a Hire, and ends with
a termination / New Assignment. For an example, Mr. Joe works for three years in the firm,
and then gets terminated and then gets rehired in to the firm after 1 year, and continues for
another 5 years. In this case, Mr. Joe had two assignments with the firm. So every time Mr.
Joe got hired, he had a new assignment. These assignments related details are stored in
PER_ALL_ASSIGNMENTS_F. This table stores all the data related to the employment, like,
the Job, his Location, the Organization he is working for, his supervisor etc. Its a date track
enabled table and ASSIGNMENT_ID is the primary key.
Oracle E-Biz also creates assignments for the ones who are retired, sometimes for the
contacts as well. Those are called Benefit assignments; we will learn more about them later.
E-Biz also has something called Applicant assignment. Its the assignment details of an
applicant, who might become an employee in future. We can even have more than one
assignment for an employee in a given period. Its like; the employee is working for two
different roles / Jobs. An employee must have at least one and only one primary

assignment. All others are considered Secondary.

Talking about secondary assignments; these get created when an employee is assigned
more than one roles in an enterprise, provided the roles are governed by two different
Organizations / GRE or they use different Jobs and positions. The secondary assignment
helps the system to track time entered / salary / payroll etc.
Service: Every Hire created in the firm, will result is a period of Service record. The table
that is used for that is PER_PERIODS_OF_SERVICE. Its primary key is
PERIOD_OF_SERVICE_ID. This table stores the Hire date, term date and the Term reasons,
along with other details related to service. If a Person has multiple assignments but within a
single service (without being rehired), he will have multiple ASSIGNMENT_ID, however just
one PERIOD_OF_SERVICE_ID. A hire drives the period of service, but a new employment
instance / a change in role drives the assignment, along with the termination.
Salary: Now let's talk about the salary. This is the amount that a Person gets paid.
Although Oracle E-biz considers Annual Salary as the calculation standard; the defined
salary gets calculated based on the frequency of pay and the amount per pay period. The
pay frequencies are specific to pay basis and in turn depends on payrolls. These are some
very popular pay frequencies:

Monthly: Once a Month

Semi Monthly: Twice a Month

Bi-Weekly: Once in Two weeks

Weekly: Once in a week

To determine the Annual salary of any employee, Oracle uses something called as
Annualization Factor. Its a number, which is multiplied to the salary to get the Annual
Salary; so for Monthly, the Annualization factor will be 12 and for Biweekly, it will be 26.
How does the Salary get calculated?

It takes the PROPOSED_SALARY_N column from PER_PAY_PROPOSALS where

APPROVED_FLAG = Y with Employee's ASSIGNMENT_ID.

It gets the PAY_BASIS_ID from the PER_ALL_ASSIGNMENTS_F for the Employee

using its ASSIGNMENT_ID.

It then multiplies the amount with the

PER_PAY_BASES.PAY_ANNUALIZATION_FACTOR
PAY_BASIS_ID.

Then the Multiplication resultant is the Annual Salary.

Annualization
based
on

factor stored in
the
Employee's

Person Types
Person Type is a very powerful functionality through which we can identify and group the
persons we have in our system. First of all, what are the different types of persons we store
in our system? Many actually; we store the Employees, applicants, contingent workers, ExEmployees, Contacts and beneficiaries of the Employees etc. Now, we should have some
way to identify these different groups. Although we can identify an Ex-employee as
someone who used to work with the firm, and does not work anymore, it becomes a tedious
task to do the same number of checks every time, isnt it? So whats better? A Single
attribute that can tell us, on this person is an Ex-Employee. How nice would that be, that
when a person is currently working the attribute should say Employee, and soon after the
termination happens, the attribute should automatically change to Ex-Employee. Wouldnt
that be awesome? This functionality is there. The attributes are nothing but Person Types.
Lets see how to use it.
Oracle application comes with a seeded set of Person types that can be used to identify the
population. However we can further add new person types as and when we require them.
Like we can have Fixed-Term employee as a person type, which is different than Employee.
We can have Retirees different than Ex-Employees etc. the one that are seeded are called
the system person types; and the one that the user creates is called the user person type.
There are eight system person types in R12. And we can create as many user person types
as we want based on the requirement. Lets see how to.
Responsibility: Super HRMS Manager
Navigation: Other Definition -> Person Types

User Name

The name of the Person Type; choose a meaningful name.

System Name

The seeded Person type, of which we are creating a sub class; choose
a most appropriate type from here.

Active

To say if the Person type is active as of today.

Default

Each System Person Type will have one and only one default User
Person Type. So when the system finds a person to be falling in the
System Person type criteria, it will change it to the Default one.

Did the Default flag make confusion? Ok lets try this. We have three types of Employees in
our system, and we want to make different person types for each of them.
So what we should do is, go to the Person Types Screen and add three records with the
System name as Employee. One for each type of user name Night Shift Staff, Mid-Shift
Staff and General Shift Staff. Now, we can make any one of these three as Default; for
example lets set General Shift Staff as default. Now whenever there is a hire, the system
will identify, oh, its an Employee, then what is the Default Person Type? Oh, its General
Shift Staff. So it will make the person type of new hire as General Shift Staff. But if later

he changes his shifts, we can just go and add a new person type usage in his record and
make him a Night Shift Staff from General Shift Staff manually. Simple, isnt it?
But how do we change it manually? Lets see.
Responsibility: Super HRMS Manager
Navigation: Fast Path -> Person Type Usages
Steps:

Query for the employee

Add a new Person Type usage / End date the old one.

Oracle Core HR >

Flex Fields
Contents
1. 1 Flex Fields in HRMS
1. 1.1 KFFs
2. 1.2 DFFs
3. 1.3 Extra Information Types
4. 1.4 Special Information Types
2. 2 Job
1. 2.1 Job KFF
2. 2.2 Job Groups
3. 2.3 Setting up Jobs
3. 3 Position
1. 3.1 Position KFF

2. 3.2 Setting up Positions

3. 3.3 Position Hierarchy
4. 4 Location
5. 5 Grades
1. 5.1 Grade KFF
2. 5.2 Setting up Grades
3. 5.3 Grade Rate
4. 5.4 Grade step progression

Flex Fields in HRMS

We already know about the flex fields; KFFs and DFFs, and also the related setup
instructions. However lets see the role of the flex fields in Core-HR implementation.

KFFs
Lets pick KFFs first. As we have discussed already, there are around ten KFFs in Oracle
HRMS; out of which six are mandatory for a successful Core-HR implementation. The
mandatory KFFs are:

Job

Position

Grade

People Group

Competence

Cost Allocation

Apart from the mandatory ones, there are a few optional KFFs present in the Oracle HRMS.
Like: Personal Analysis, Collectively Agreed Grades Flex field, Soft Coded Key Flex field,
Bank Details Key Flex Field, Training Resources and Item Contexts Key flex. Now the task is
to identify and define the different KFFs that we need for the implementation.

NOTE
For Even if we do not need segments of a particular KFF, it is advised that we
define a dummy segment and make the display as off. Because there will be cases
where presence of at least one KFF segment will be necessary; in order to make a
functionality work. So better have it ready from the beginning.

DFFs
Now, talking about the DFFs, The Descriptive Flex Fields are the ones that store the
additional information based on any table; the information that are not being captured by
the attributes supplied by Oracle.
There will be situations, where we will need a particular data to be captured somewhere and
the table would not have a seeded place to store it. We will have to figure out such data
fields and use that tables DFF to store the data. We must practice caution while using
contexts to relate them to appropriate segments.

Extra Information Types

The Extra Information Types or EITs are DFFs attached to six very important entities that
help us capture extra information, that are not available in our tables. It is kind of a DFF.
Now, the question, why something called an EIT is introduced, if there was a concept of DFF
already there?

EITs are stored in different tables, where as DFFs are stored in the
same very base table. So any changes the base table, creates extra
rows for DFFs, but EITs stay intact, making it more normalized.

EITs do not store historical information, neither are they date tracked.
So any information which is static (data that hardly changes) can be
put in EITs and others in DFF.

EITs are enabled at the responsibility level, enhancing the data

security a lot better than the way DFFs do.

EITs in HRMS are given to only six entities:

People

Assignments

Job

Position

Location

Organization

Lets see how to configure one. We will first learn the EIT creation for all other EITs except
the Organization one. We will discuss about the Organizations later. See Figure 2.5 EITs.
Responsibility: Application Developer
Navigation: Flex Field -> Descriptive -> Register
Steps:

Put the name of the table in the Table Name Field

And query the table.

It should list all the DFFs based on the table. From there, pick the one with
Extra Info. See Figure 2.5 EITs.

Figure 5 EITs

Copy the Title.

(Figure 2.5 EITs)

Now, go to the Segments.
Responsibility: Application Developer
Navigation: Flex Field -> Descriptive -> Segments
Steps:

Now create or update the contexts with new segments, with the same steps
we created a DFF.

Once done, freeze and compile the DFF.

Now the EIT is created.

Query for the Title in the table

However the EIT must be linked to the responsibility that we are using. Only after the EIT is
linked to the responsibility we will be able to use the EIT with that responsibility. This is an
additional security feature. For an example, we might not want to allow our Payroll User to
view /update someones location DFF. In that case just do not link the EIT to the payroll
user Responsibility. Lets see how to link EITs.
Responsibility: Super HRMS Manager
Navigation: Security -> Information Type Security
Steps:

Query for the Responsibility we want the EIT to be linked to. See Figure 2.6

Linking DFFs to Responsibilities

Add a new record with the EIT context name in the drop down.

Save the record.

Now we can use our EIT.

Figure 6 Linking DFFs to Responsibilities

(Figure 2.6 Linking DFFs to Responsibilities)

Before creating an EIT, we must make sure there are ample reasons for us to create an EIT.
We must know the segments we are going to need and the respective value sets as well.
Once we have all the information and we are convinced that we need an EIT to achieve
what we are looking for, only then we should go for it.

While creating the EIT for organization types, we need to consider the classifications;
because the EITs are actually linked to the HR_ORGANIZATION_INFORMATION table, not
the actual organization table. Now, what are organization classifications? These are the
different attributes that define an Organization better. We will discuss more about them
later in this chapter. As of now, lets consider adding up EITs on to them. The Organization
classifications are present in an extensible lookup type: ORG_CLASS.
To create the EITs, we must go to the Register screen and look for
HR_ORGANIZATION_INFORMATION table. Now we will find a title named: Org Developer
DF. Now open the segments and look for the EIT we want to update. Please remember,
Organization data are very sensitive for the reason that, they represent the firm with
respect to reporting to Government and Legalization. Hence before creating or updating an
EIT of that sort, we should always be very cautious.

Special Information Types

Special Information types or SITs are KFFs. These serve the same purpose as the EITs do,
which is additional data storage. However as it is a KFF; it stores data in form of
combinations unlike EITs do. We can use SITs for Job, Position and Personal analysis in
Oracle Core-HR. Lets have a look how to implement one.

Go to KFF Register

Register the new KFF, as an instance of the Personal Analysis KFF

Update/ add the segments that you need against the SIT

Enable the SIT in the business group

Please remember, SITs do not need any responsibility linking like EITs do, which makes SITs
less secured than EITs. Hence it is advised to chalk out the data design that we are planning
to store in SITs, consider the usage and security etc; before going ahead and creating the
SIT and the segments.

Job

As the enterprise has employees, there will be jobs to fill in; Positions to support the type of
job with details, People Group to classify a set of employees for a given purpose. However
all these are data fields/ columns, which are used to represent some or the other
characteristic of the Employee's assignment.
Job is a generic Role within a business group that tells us more about the assignment
carried out by the employee. It is independent of a Division / Department. Like, Manager,
Director and Programmer are Jobs. Jobs are stored in PER_JOBS. Its a dated table. The Job
Id is the primary key here, and acts as the foreign key to the PER_ALL_ASSIGNMENTS_F, to
link the job to a particular assignment. So lets shift our focus on how to create and use a
job.

Job KFF
This is the first step. Job KFF stores the basic information related to the jobs available in the
firm; like we have job like a manager, a technical assistant etc. So this is the place where
we define those jobs. The first thing that we need is the list of segments we want to use in
the Flex Field. So the question we ask ourselves / the business is, what all do we want to
store in a Job? Do we need the job name, the occupational function, the title s/he shares,
etc? Once the segments are determined, the next step is to figure out the valid values for
each and every segment; and create corresponding value sets.
For an example, if we were to create a job, and our firm wants us to store the job name,
job code and a functional title, we will define the different job names, codes and titles
available at my firm, and then create value sets based on that. We can go for a quick code
that stores the job names and codes, and another quick code to store the titles. We will
configure the value set in such a manner that, it will show me the values that are in the
quick code. And will attach the value set with the segments.
Now, as the segments are decided and the value sets are defined, the next stage is to
configure the KFF. See Figure 2.2 KFF definition.
Responsibility: Application Developer
Navigation: Flex Field -> Key -> Segments
Steps:

Query for the FF titled: Job Flex field

Create a new row with appropriate data

Figure 2 KFF definition

(Figure 2.2 KFF definition)

We have already discussed the steps to create a KFF, so we are not going to revisit that;
however we must understand the application of the segments, which will be added to the
Job KFF. So lets go to the Segments tab and start adding the segments one by one, with a
sequence. The name and window prompts are self explanatory. Column is the segment with
which the data will actually be stored in the table. We can choose segment 1 to 30. And
value set field is the place where we attach our value set. If we wish we can save a
segment without a value set that will allow the users to enter any alphanumeric value in it,
up to 150 chars. However it is always advisable to create a value set even if its a free text.
If we continue with our example, we will create three segments, somewhat similar to the
Figure 2.3 KFF Segments.
Figure 3 KFF Segments

(Figure 2.3 KFF Segments)

Once the Segments are defined, close the segments window and freeze the KFF Definition.
And Compile it. Finally run the Run Create Key Flex field Database Items Process. Do not
forget to update our lookup types used in our Value sets with available values.

Job Groups
The Job Groups are a collection of jobs. Every business group must have a default job group
so that all the jobs can be grouped under the same. However in a case where there is a
different line of jobs needed, we can go for a new job group altogether. See Figure 2.9
Defining Job Groups.
Responsibility: US Super HRMS Manager
Navigation: Work Structure -> Job -> Job Group
Figure 9 Defining Job Groups

(Figure 2.9 Defining Job Groups)

Job Group
Job
Structure

Name of the Job Group; should be unique

KFF

The Job KFF it uses. We might have more than one Job KFFs

Business Group

Add a Business Group. If the HR:Cross Business Group profile

option is set to Y, this should populate automatically.

Master
Group

This is to make the Job Group as a Master Job Group. Master Job
Groups are used in Oracle Projects to make job mappings. So it is
advised to contact to PA consultant before making the Job group a
master one.

Job

Setting up Jobs
Next task is to add jobs. See Figure 2.10 Defining Jobs.
Responsibility: Super HRMS Manager
Navigation: Work Structure -> Job -> Description

Job Group

Enter the Job Group name, which holds this job

Name

Enter the name of the Job; if there are any segments in the KFF
used in the Job group, we need to enter a unique combination of
segments to create a new job.

Dates

Enter the start and end dates

Approval Authority

This will be a number. This number will be referenced by the AME

(Approval Management Engine) in Oracle to determine if any person
attached to this job has ample authority to approve a request. It is
advised to use 10 for the base workers and then keep on adding 0
to the right as and when the position increases. Like line managers
will have 100, senior managers will have 1000 and so on.

Additional
Employment
Rights

This flag is added when there is any extra Employment Rights

Benchmark Job

Add if its a Benchmark Job. This is helpful in surveys

Evaluation

The Evaluation information about the job can be entered here. This
is like a score matching available in Oracle that enables us to
evaluate and compare employees in one job.

Requirements

Requirements is an SIT; that helps us to track competencies about

the employees

Grades

This is the place where we define the various grades available in the
particular job

Work Preferences

The work preference explains the job requirements a little bit more.
These details are then further used by the iRecruitment for hiring
into the job

Extra Information

This is the Job EIT, to store extra information. If you have the EIT
segments defined, you can now start storing data into those.

Figure 10 Defining Jobs

(Figure 2.10 Defining Jobs)

Position
Position is a specific instance of Job, within an Organization. Like, Accounts Manager,
Information Security Manager are Positions, where as Manager is the Job. If we excavate a
little more, its more like a specific type of Job that an assignment is assigned to, with
specifics related to Organization / Location / Departments. Job is the superset of the
positions. Positions are stored in PER_POSITIONS, and like Jobs have JOB_ID, the linkage to
assignments for positions is done through POSITION_ID.

Question: Is it a Role?
No. Although Role is just a concept, often used in HRMS, there is no such table that
stores roles in here. We are not talking about User-Roles here. Role, as the name suggest is
the type of act the concerned assignment is doing. Its very different than a position.

One example will help us understand it better.

An accountant, who is a Finance Manager, is acting as a CFO in ABC Inc.
In the statement above, Accountant is the JOB, Finance Manager is a POSITION and CFO is
the role he is acting.

Position KFF
As we had discussed earlier, Position represents a particular instance of the job. It is time to
capture the positions and the underlying segments. We know the steps,

And then create the value sets and if necessary the lookup
types as well

Go to KFF screen, look for Position Flex field

Create a new one with the new segments

Then freeze it and compile it

Figure out the segments we will be using in a Position KFF

Do not forget about the Create Key Flex field Database Items Process

Setting up Positions
As we have the KFF defined, lets see how to create a new position.
Responsibility: Super HRMS Manager
Navigation: Work Structure -> Position -> Description

Date Effective
Name

Enter the name of the position. If there are any segments in the
position KFF, we need to enter a unique combination of segments to
make a new position.

Start Dates

Enter the start date.

Type

Depicts the type of the position:

Single Incumbent: Only one employee is allowed to hold the
position at any point of time
Shared: It can have several incumbents
Pooled : Position is loosely defined and is available to a set of
employees
None: Default

Permanent

Use this flag to make the position Permanent and to be budgeted

every year.

Org and Job

Add the Org and job name in these fields. Once entered these
details will never be changed.

Hiring Status

This tells about the hiring status of the positions. Along with the
dates since which the status is active and up until when.

Location

Enter a Location if the position is fixed to a location.

Status

The status of the position. Mark Valid/ leave blank.

Hiring Information
FTE

The number of Full Time Equivalent needed for the position.

Headcount

The planned number of FTEs in the field

Bargaining Unit

If the employees in this position have to be in a particular

bargaining unit then it must be defined here.

Earliest Hire Date

Enter the date by which the Applicants must be hired for the
position.

Fill by Date

Enter the date by which the position should be filled in.

Permit Recruiting

Information Only.

Payroll

The Payroll into which the hired employee for the position will go to.

Salary Basis

Salary basis for the position

Grade

The Grade in which the employee must go in. The Grade must be
one of the valid grades for the Job to which this position belongs to.

Grade Steps

The rest of the Grade step Progression data must be entered.

Probation

The period up to which a new employee must be in Probation.

Overlap

Define the required transition period for the new employee and the
leaving employee.

Rest of the tabs

The rest of the tabs are self explanatory; however very rarely used
in HRMS.

Position Hierarchy
The Position hierarchy is more or less similar to what we have in the Organizational
hierarchy, but here, the structure is based on the Positions. Like, for an example, our firm
has clerks, then Senior Clerks, Line Mangers, Managers, Senior Managers etc, and the
reporting structure is in the same order, isnt it? Now where do we store this information?
This is where it is done. We define the positions and define a hierarchy.
The configuration of position hierarchy is exactly the same way we do the Organization
Hierarchy, so is the Diagrammer. So we are not going to explain anything on this one, we
can try it by ourselves and it should be very simple.
Responsibility: Super HRMS Manager
Navigation: Work Structure -> Position -> Hierarchy / Diagrammer

Location
Locations are the physicals addresses / sites where we have our Firm placed. It could be
our corporate office, our Manufacturing centre or Sales Office. Location is a very simple
concept to understand.
There are two types of locations, Global and Local. A location with Global Scope can be seen
and used in more than one business groups; however the one with Local scope can be used
only with the business group its created. See Figure 2.8 Defining Locations.
Figure 8 Defining Locations

(Figure 2.8 Defining Locations)

Responsibility: Super HRMS Manager
Navigation: Work Structure -> Location

Scope

Choose Global or Local.

Name

Name of the Location.

Description

Self Explanatory.

Inactive Date

Date after which the location will no longer be used.

Address Style

Type of address style, based on country.

Address

The Physical address.

Time zone

The Time zone of the location.

Shipping Details

Choose the flags based on the type of the location.

Extra
Information

The EITs can be used to add more information to location.

Grades
The enterprise uses grades to compare roles within their organizational structure and
relate compensation to grades to pay their employee in groups. Grades are stored in
PER_GRADES. The primary key GRADE_ID acts as the foreign key in assignment table to
create a relationship with in grade and assignments.
Lets start with an example. A firm has different positions. And in one position, there are
different levels. Like someone who is a Production manager, might have a level as L5, but
another Production manager might have 3 years of experience in the same position and he
might have a level as L6. So L6 is a higher level than L5. The levels are usually called
grades.
Grade is a part of grade step progressions functionality. Although in todays world Grade is
used across firms, however grade step progression is not used a lot. So in this section we
will focus only on grades and their usages. We will discuss about grade step progression
though, but only after we understand Grades completely.

Grade KFF
This is the KFF that is going to hold our grade related information of our firm. For an
example it might look like this: L6.Senior.Technical. This typically de[ends on the business
reqirement. Oracle E-Biz gives us the liberty to store as much information to store as we
wish to in the Grades. Thats why its a KFF. Now, on the setup part of the KFF, the steps are
similar to the Job and Position KFFs.

Figure out the segments we will be using in a Grades KFF.

And then create the value sets and if necessary the lookup types as well.

Go to KFF screen, look for Grades Flex field.

Create a new one with the desired segments

Then freeze it, compile it and run Create Key Flex field Database Items
Process

Setting up Grades

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Grade -> Description
Steps:

Enter a name of the grade. If there are more than one segment in grades
KFF, fill them in.

A Short name can be entered.

Enter the From and To Date.

Add in the details in any of the EITs if any.

Enter the sequence number.

That should be all. Simple, isnt it?

There will be instances where one grade has spun across positions. Meaning, two people
might be in a single grade but with two different positions; so we cannot really say, grades
belong to positions; unlike the relationship between jobs and positions.

Grade Rate
Once the Grade is defined; the next task is to define the grade rates. The Grade rates
define a salary range for each of the grades. An employee of that grade is liable to be within
the salary limits. If the Employee crosses the salary limits, system throws a warning, not an
Error.
Lets go define it.
Responsibility: Super HRMS Manager
Navigation: Work Structure -> Grade -> Grade Rate
Steps:

Enter Name of a rate.

Put units as Money.

Select a Grade from the drop down with a currency

Key in a Minimum and maximum value, and the mid value must get
calculated automatically.

Grade Rates are very useful for Salary surveys, to tell the employees manager, where he
stands in his grade scale, and how far he is from the mid value etc.

Grade step progression

Usually the Performance Management planning flow is to promote a Person from one grade
to another when there is a performance review. Once the grade increases the salary is also
increased. However in some firms, where the promotions are managed through the years of
experience or points, the grade step progression comes handy.
How it works is, we set up rules of eligibility to get into a Grade. So if someone passes the
criteria he will be moved to next grade. The eligibility can be based on Years of Service,
points etc. Once the Employee gets the value, he moves to the next grade and so does his
salary.
For an example, we will set it up like this: If someone is a Production Manager since one
year, the grade is L4, if two years, it is L5 and likewise, so If Mr. Joe is L4 and completes his
second anniversary as a Production engineer, he should get promoted to L5 automatically,
and his salary should also change to the band of L5. So the promotion becomes an
automated process, but now-a-days, the competition defines the promotion not the Years of
Service; so Grade Step Progression is not a widely used functionality.

Oracle Core HR >

Organizations

Contents
1. 1 Organizations
1. 1.1 Organization Classification
2. 1.2 Configuring an organization
3. 1.3 Business Group

4. 1.4 Legal Entity

5. 1.5 HR Organization
6. 1.6 Operating Unit
2. 2 Organization Hierarchy
1. 2.1 Creating a Hierarchy
2. 2.2 Using Diagrammer

Organizations
An Enterprise might have a set of child Organizations attached to it. Similarly, it might have
operations in more than one country with the expanded business. In these cases, each
entity, which operates with its own business rules, is called an Organization. Again, there
could be internal and external Organizations. Internal Organizations are the divisions and
departments inside the enterprise. Externals are the ones that are not directly under the
enterprise umbrella; however peripheral entities with which our enterprise deals on a
frequent basis. For an example, a Life Insurance Provider might be an External
Organization.
Organizations are stored in HR_ALL_ORGANIZATION_UNITS, with ORGANIZATION_ID as
the primary key. Its a DATE_TO Enabled table. The Type of the Organization informs us
whether its an Organization / Department / Division.
To understand it better, lets take an example of an enterprise that manufactures car tyres.
In the enterprise, there will be a registered executive office that manages all the judicial
and legal relations of the firm. Then there will be big departments / pillars that are focused
into one type of activity / business for the firm, like sales, marketing, manufacturing,
systems etc. Now each of these big departments will have smaller departments / divisions
and further those departments divide further into smaller sub-divisions. This might go on
and on to the most granular level of the firm. If we sort them graphically, that will look like
an inverted tree, wont it? This is known as Organizational hierarchy and the structure in
them, like our divisions, sub-divisions are known as Organizations.

NOTE
Organizations are not essentially Internal. There will be clients and vendors that
are connected to the firm by a business Channel; and if we need to capture
information of them, we should define them as Organizations as well.

Organization Classification
Organization classification is like a tag attached to the Organizations that specify the
purpose and usage of the Organization in the application. Lets take an example. We have
our Manufacturing Department. Which is an Operating unit, because it has its own set of
managers managing it, a Company Cost centre, because it maintains its own ledger books
for costing, and an Inventory Organization, as it maintains its own inventory structure. Now
the same organization is classified as three different types of classifications and the
classifications tell us more about the organization.
But why need classification? Simple, we need classification to capture Information. For an
Example, if we have to make an organization, a Legal Entity, we will have to store the name
of the CEO, the Remuneration heads name, the tax id number, the Employer id number etc.
and we need all these because of the Government requirements. Because our Seeded
reports and interfaces that are sent to the Government/ tax entities will look for Information
like that in our system, and we must store them. Again, we do not need these details for all
the Organizations. We just need the details for the Organizations that are legal entities.
The simplest way, one can think of, is to create a classification named Legal Entity and
add an EIT to it, and then just add the classification whenever necessary so that we can
capture the information. If we have four different legal entities in the firm, we will have to
attach it to the four different organizations. Oracle has designed it the same way.
Legal Entity was just an Example, there are many such classifications that need specific
information to be stored, in order to get the system working as expected.

Configuring an organization
Now, lets create an organization. See Figure 2.7 Defining Organizations.
Responsibility: Super HRMS Manager
Navigation: Work Structure -> Organization -> Description

Steps:
Figure 7 Defining Organizations

(Figure 2.7 Defining Organizations)

Name

Name of the Organization.

Type

Type of the Organization, is it a department, a division, subdivision

etc.

From

The start date.

To

The end date; can be left blank

Location

The Location where it is situated; we will create locations later in

this chapter.
Internal Or
External

To specify if it is an Internal Organization or something external.

Location Address

This gets populated automatically once the location is entered.

Internal Address

Internal address, if any. Like an Office Number or Identifier.

Classifications

This is where we list the classifications.

Enabled

To say if the classification is enabled in here.

Others

This is the place where the EITs related to the Classifications open.

The Organization table has a DFF that can be used to store more information that we are
unable to store with in Organizational Attributes. This is time to add Classifications. A
normal firm needs a different set of classifications based on the localization. Like if our firm
is in UK, we must have an Education Authority; if we are in India, we must have a PTO
(Professional Tax Organization) etc. So based on our localization, we must choose our
classifications.

NOTE:
For the list of required organizations for a particular Localization; please
refer to Oracle documentation.

Lets discuss the mandatory classifications that are needed for every HRMS set up: like
Operating Company, Business Group, Legal Entity, HR Organization, Operating unit etc.
Lets discuss them one by one.

Business Group
Business group is an entity that represents an instance of the enterprise. A business group
enables us to group and manage data in accordance with the rules and reporting
requirements of each enterprise model, and to control access to data. Business Groups are
also a type of Organization. They are stored in the same HR_ALL_ORGANIZATION_UNITS
table.
A Business Group is like the backbone of the firm. This is the classification that uniquely
identifies the firm in one particular country / localization. For an Example, if we have XYZ
Corp. in India, Poland and UK, we should have three different entities with us, isnt it? So
that each entity deals with the legal compliance with the Government of each of the
countries we operate in. Those entities will manage the reporting, data management and

rules of the country. That entity is known as Business Group. In this case we will create
three Organizations with business Group as a classification added to them.

NOTE:
Each localization should, however not necessarily hold its own Business Group.
Creation of business group entirely depends on the design of the HR Organization
structure.

Almost all the details that we store in our system can be classified based on Business
Groups. The system looks at the business group we are working in, and then filters the set
up and data based on that while in use.
The Business Group EITs / BG EITs hold a lot of set up attributes. These set up are used by
the system, based on the business group we are using. For an example, in XYZ, Poland, we
may not want the employee numbers to be generated automatically, but in UK, we want it
to be generated automatically whenever there is a new employee created; based on the last
number used. This can be added in the BG EITs, and later can be referred by the system.
Not only that, there are a lot of defaults that can be used in BG EITs.
Once we have added Business Group as a Classification in an Organization (The one that we
want to use as a BG); click on others and we will see a lot of EITs in there. Those EITs store
the default values. Here are the some important ones:

Business Group Info EIT

1.

Employee number Generation Automatic / Manual.

2.

Applicant number Generation Automatic / Manual.

3.
The KFF names of Job, Position, Grade, People Group, Cost allocation and
Competency.
4.

The Legislation code: defines the Government it should report to.

5.

The Currency to be used in the BG.

6.

The start of the Fiscal Year.

Benefits defaults EIT

1.

Default Payroll name.

2.

Do we want to create the benefits assignment or not.

PTO Balance Types

1.
Balance type: date earned / date paid: this is where we instruct our
system to pick the date, based on which the accruals will be calculated in Payroll.
Dont worry about accruals and payroll now; we have an entire chapter based on
it. : )

Pay slip Information

1.
If there is some balance/information that is not appearing on the Pay slip
and we want it to be added on to it, this is the EIT where we need to do it.

SOE Information
1.
Same as the Pay slip EIT, however this manages the SOE- Statement of
Earning.

Self Service preference

1.
This is a place to configure some details on our SSHR. Like the following
questions.
2.

Do we need paper pay slips / online pay slips / both?

3.
Do we want to have the pay slip available based on date paid / pay slip
view date?
4.
Do we want the Address on pay slip to be the address from Legal Entity or
the HR Org?

There are many more to it; however we are discussing some basic ones that are used most
frequently.
We can associate our business group with the responsibility we are using, so that the data

and configuration filtration can happen accordingly.

Legal Entity
A legal entity is a representation of an employer. A Country knows each and every legal
entity as independent Employers and the various rules and regulations are attached to this
entity. So If XYZ Poland, has a Marketing team, that operates parallel to the Manufacturing
team, however is considered a separate employer, then manufacturing team will be a
separate legal entity. On the flip side, if we are employing in a country, we must have a
legal entity.
The Legal Entity has EITs as well; however most of them are based on the localizations.
Lets discuss the most important one: Tax Information. In this EIT we specify the Company
tax Reference number, Registration number, the Trade classification: telling the system the
type of trade our company does etc. We might also need to key in the Income tax Number
for the tax departments (IRS/ ITD / SARS etc) based on the localization.

HR Organization
This is the entity that is assigned to the employees. This is the actual organization that
appears on the assignment screen; so all departments, divisions, subdivisions etc are
actually HR Organizations. We must create all the internal organizations (Departments,
Pillars, and Verticals) with this classification on them.

Operating Unit
An Operating unit classification is used in a case, where we have a Multi-Org application. In
that case, a set of operating units operate like independent units that works under an
umbrella of a big organization. Usually each Operating unit is also classified with the HR
Organization. So that employees in that HR Organization or below are considered part of
that Operating unit. Although the Operating unit does not relate a lot to HRMS, it has a very
vital role in Finance and SCM modules.

Organization Hierarchy
Every firm follows a hierarchy. It is the structure with which the Departments, Divisions and
sub divisions are sorted in the firm. It is the reporting structure that looks like an inverted
tree. Once the organizations are created, we create a hierarchy, which can be called as
Primary Reporting Hierarchy. This is the basic way with which the entire reporting has to
work. However we can create a number of secondary hierarchies to support other laterals of
the business.
Question, is this just to make sure that the reporting is defined? Or are there other usages
of Organizational hierarchies?

There are many. However lets focus on the two important ones here.

Security: In many security profiles, we use the parent organization name, and all the
children Organizations are considered automatically. For an Example HR-Global is our
parent Organization for HR, and there are other HR children Organizations like, HRNew York, HR-Philadelphia, HR-SFO, HR-Colorado etc. Now, we do not want the
Colorado HR people to see the data of HR-New York. So we will create a security
profile just based on HR-NY and add that to HR-NY responsibility. Similarly we will
create one for each of the Organizations. But what about the HR-Head of our
Organization, he needs to be able to see everything. Here, we will create a new
security profile called: HR-Global, and use the same in Hr-Heads responsibility. As
HR-Global is the parent and all others are children, HR-Head can now, access all
children organization data as well. It is similar to the Folder structure, where one
folder when locked, locks all the subfolders accordingly.

Reports: While running reports to include all children organizations we can just key
in the Parent Org along with the hierarchy, and it does it all. For example, if we want
to run a report for all HR data, we can just run it on the HR-Global and all children
organizations will be included automatically.

So those were the two additional advantages of Organizational hierarchies. Lets see, how to
define and control one.

Creating a Hierarchy
Responsibility: Super HRMS Manager
Navigation: Work Structure -> Organization -> Hierarchy
Steps:

Create a new hierarchy; add a name in the name field

Mark it as primary

Add the Version number (Initially one), from date and to date

Save the changes

Now in the Organization field, query for the top most Organization

And in the subordinate block, keep on adding the organization reporting to

the parent one

Now query one of the secondary organizations (Organizations reporting to the

top Org) and keep on adding its child organizations

The up and down buttons can be used to move an Organization up or down in

the hierarchy.

Lets say, our Organization hierarchy changes after two years, and then we do not
have to create a new organization all over again. We can just create a new version.

Click on the version number, and press the down arrow to go to the next
record.

Now add the new version number with new start and end dates.

We know the rest of the steps, keep on adding the organizations.

Else we can just copy the hierarchy using the copy hierarchy button and then
structure as per our requirement.

Save the changes

Likewise, keep on establishing the relationship between the organizations

Query our primary hierarchy; populate the end date and save it.

Using Diagrammer
This is a screen where we can go and see the hierarchy in a tree like structure for better
understanding. The screen also has search settings to search for the particular organization.
Responsibility: Super HRMS Manager
Navigation: Work Structure -> Organization -> Diagrammer
Steps:

Go on to the next record, until we find the correct version number with start
and end dates.

Click on Open editor.

This will show us a diagrammatic representation of the Organization

Query the name of the Organization hierarchy.

hierarchy.

We can use the find button to look for the organizations and their child ones.

Oracle Core HR >

Tools in HR

Contents
1. 1 Security Profiles
2. 2 People Group
3. 3 Salary Administration
1. 3.1 Salary Basis
2. 3.2 Salary Proposals
3. 3.3 Calculating Salary per Pay Period
4. 4 Tools in Core HR
1. 4.1 Mass Update
2. 4.2 Mass Move
3. 4.3 Salary Management Web ADI
4. 4.4 Checklist
5. 5 Multi-Org Architecture

Security Profiles
The Security Profiles, as the name suggests, are profiles for Data security. Do you
remember the HR-Head example? The requirement was, HR Department of New York,
should not see the data from HR department of Colorado. To manage this we can take help
of Security Profiles. We can create a Profile for HR-Colorado with eligibility rules attached to
it. If our responsibility passes the eligibility profiles, we will be able to see the HR-Colorado
data else we wont. Those profiles are known as Security Profiles. The profiles act like an
access control system to Organization, Position, payroll, supervisor data and many more
inside a business group.
It is just an example; we can do wonders with security profile. Although this is a system
administrators job, lets just see the options available to us. See Figure 2.14 Security
profiles.
Responsibility: Super HRMS Manager
Navigation: people -> Salary management
Figure 14 Security profiles

(Figure 2.14 Security profiles)

Name

Enter the name of the security Profile

Business group

The business group in which the profile will be used

View Flags

Restrict the view to employees, Applicants etc, if any

Organization security

Here we can specify the Organization hierarchy / Organization

names etc based on which the Data will be encapsulated.

Position Hierarchy

This can be based on position hierarchy and other positions.

Payroll hierarchy

We can add a Payroll here, so Participants who are with this

security profile will be able to see persons from the mentioned
payroll only

Supervisor hierarchy

This can be based on supervisors view of employee as well.

Custom

Here we define the code, which is similar to a AND / OR Condition

mapping. If the condition satisfies, the person will be able to see
the data.

People Group
We discussed about jobs, positions, location etc to classify the employees and this is
another handle to classify employees. We need People Groups to group employees of
certain similarities together, in order to achieve a classification. This is mostly used in
Payroll. The table that stores the People Group Information is: PAY_PEOPLE_GROUPS. The
PEOPLE_GROUP_ID being the Primary key here acts as a foreign key in assignment table.

Question: We already have so many ways to classify people, why again People Group?
People group are one of the criteria in the Element links window; which enables the
system architects to attach particular elements based on the people group id. So if you wish
to classify employees in order to use the classification to assign elements, people group is
your key.

Salary Administration
Salary is one of the most important aspects of HRMS. Employees/ contingent workers do
work for the enterprise and in return, the firm gives them a monetary compensation. That
compensation as a return of their assignments is known as Salary. Although enterprises
may pay for a lot of other non-monetary benefits, the salary stays as one of the prime
ingredient of the compensation.
The salary can be given in any frequency. It can be monthly, semi-monthly, weekly etc. So
the frequency is known as the Salary Basis. The Salary basis is stored
in PER_PAY_BASES. The PAY_BASIS_ID is the primary key here, and acts as the foreign key
to the PER_ALL_ASSIGNMENTS_F, to link the salary basis to a particular assignment.
Lets discuss some of the typical salary administration models that Oracle E-Biz supports.

Grade Dependent: This model enables the enterprises to use grades to define the
salary of the employees. Employees in one grade have same salaries. Although this
model is not so popular in competitive market, where performance plays a big role in
calculating salaries, it is very popular amongst fixed compensation moulds.

Grade Bands: In this model, grades represent a particular band, and then salaries of
employees in a particular grade, stays in the bands. Even though the salaries stay in
the band, it varies based on the different criteria like Location, Performance, and
Responsibilities etc.

Grade Independent: Even though the grade is used to classify employees, this model
enables the enterprises to define salaries independent of the grades. Change in
grade does not trigger a change in salary. The salary is typically calculated
individually. The enterprise defines a particular salary and the employee is paid
based on that. For this, the firm can use the enter salary screen, and the payroll
engine calculates the payment based on the defined salary amount.

Payroll Matrix: In this model, the enterprise can create a matrix of different
attributes that influence the salary. Criteria like Overtime, Position, Location etc.
Finally based on the matrix, the salary is paid out to the employee.

Salary Basis
The salary basis is nothing but the duration for which a salary is quoted. Like some
employees might get paid some amount per hour, some are paid some amount annually. So
salary basis is the one that defines the time span on which the salary is being defined.
However someone being on hourly salary does not mean, he gets paid every hour, it means
he gets paid per hour.
To take an example, an employee might be on a weekly salary, and get paid every week,
but the salary will be based on the number of hours he worked and the rate per hour. To
take the example little further, if an employee is in Annual salary basis, he might get paid
every month / week, based on the calculated salary per pay period.
Lets see how to define a salary basis.

Name

Enter the name of the Salary Basis

Basis

Should be one of the following:

Hourly Salary ; Paid per hour

Monthly Salary: Paid per month
Annual Salary: Paid per Annum
Period Salary: Based on the Pay Period
Pay annualization
factor

Enter the factor with which the salary can be converted to

annual salary.
For an example, if the salary is monthly, this field will be 12,
for annual it will be 1. For hourly salary, it should be 2080 (52
weeks X 40 hours each week)
Leave the filed blank, if you are opting for Period Salary basis,
E-Biz will be able to figure this out based on the pay periods.

Element Name

Use the name of the salary element

Input Value name

The name of the input value that stores the basis. Please
make sure not to use the Pay Value as the Input value here.
Oracle payroll does not do the calculation on the input value,
if the Pay Value is assigned here.

Grade Rate

This is the place where we link the grades to the Salary Basis.

Grade Rate Basis

The range mentioned in the grade rate must relate to a basis.

That gets populated here.

Grade annualization
factor

This is the annualization factor of the grade rate based on the

Grade basis

Salary Proposals
Once an applicant is hired, and becomes an employee, his/her salary proposal must be
entered to commence the salary administration. The salary proposal is nothing but a
proposed salary, which is entered by the Compensation manager / admin department, for
the employee. Once the proposed salary is approved, it becomes the actual salary and from
then on, that salary amount is used for the payroll calculations.
Apart from the initial salary, there could be many reasons to propose a change in salary.
The reasons could be Promotion, demotion, annual salary revision, market correction, cost
of living revision etc. There can be as many reasons as an enterprise wishes to have. These
reasons are stored in a lookup type called PROPOSAL_REASON.
While you enter a salary proposal for an employee, it must have a Proposal reason, and an
effective date associated with it. After the proposal is entered, it goes for the employees
supervisors approval. Once the supervisor approves it, the proposed salary becomes the
actual salary as of the effective date.
Other than keeping the record one an employees change in salary, the Proposal reason also
helps in reporting purpose. It can be used to answer a lot of compensation related
questions. Like, how much money was given as part of this years bonus cycle. What is
average hike given to employees in sales department this year? Salary proposals are stored
in PER_PAY_PROPOSALS table.

Calculating Salary per Pay Period

The salary proposal is entered based on the salary basis. So for someone in Hourly basis,
will have proposed salary based on rate per hour. Similarly, for someone in annual salary
basis, will have the proposed salary in numbers that represent the annual salary of the
person. As the proposed salary is not linear across the board, Oracle E-biz uses a particular
calculation mechanism to calculate the Annual salary of an employee.

Tools in Core HR
There are many powerful tools in HRMS, to help us migrate data from one form to another,
and as well do a lot of other things, that saves a lot of time and coding. : ) here is a list:

Mass update

Mass move

Salary Management- Web-ADI

Checklist

Security Profiles

Lets go through them one by one.

Mass Update
Imagine a situation where a particular department in our firm decides to go for a new
position, for an example, 98 employees in our firm who were in Fund Manager position
will now be moving to Senior Fund Manager. How are we going to do it? There are three
ways.

Go to all 98 employee records one by one and update them manually with the new
position.
Run an API to update the 98 employees with new position
Go to Mass update and update the position.

The option 1 is not a good choice, because it is manual. Option 2 is a very good one,
however one must know a little bit of PL/SQL in order to get that API thing sorted out. But if
for someone who knows PL/SQL, option 2 is the best. : )
Option 3; lets see what a mass update is.
Mass update is a functionality that allows us to update a set of assignments is a single go.
The procedure is very simple. See Figure 2.11 Mass Update.

Responsibility: Super HRMS Manager

Navigation: people -> Mass update of Person -> Mass Update of Employee Assignments
Figure 11 Mass Update

(Figure 2.11 Mass Update)

Steps:

Put a name for the update process in the name field.

Put an effective date of change.

Choose selection criteria, with which we want to filter the Employees for
whom the change is intended. As per our example, we will pull all the employees
with position as Fund Manager.

Now, press query.

This should now list all the employees who are Fund Managers.

Now, select the employees we want to make a change to. As per our
example, we will select just the targeted 98 of them.

We can use the selection drop down to invert selection / all/ none.

Now click on the new tab.

This tab should list us all the employees we selected in the first tab.

Now change the field we want to change in here. As per example, we will
change the position to the new one.

Add a date track mode and process it.

This is it. Now, all the 98 employees will have the new position in there.

Mass Move
Mass move is similar to that of mass update, however the former is designed just for
reorganizing the employees (Especially position updates) in the firm, where as the later is
designed to update anything in an assignment. See Figure 2.12 Mass Move.
Responsibility: Super HRMS Manager
Navigation: people -> Mass update of Person -> Mass Update of Employee Assignments
Figure 12 Mass Move

(Figure 2.12 Mass Move)

Steps:

Put a source and a Target Organization. They both can be same, in case we
want to change the positions of employees inside an Organization.

Put an effective date of change.

Click on Positions.

Choose source job and positions along with Target job and positions.

Now, save the record and Execute.

Put a description.

This should move all our employees from one position to another across Organizations.

Salary Management Web ADI

Salary Management becomes an issue, when there are a lot of salary proposals in line and
we have to enter the same in the system. We can easily use an API to do so, but as we
discussed, one must be good at PL/SQL to do it. What if someone is not? There is a tool
called, Web-ADI, with which updating salaries can be done in a jiffy.

Responsibility: Super HRMS Manager

Navigation: people -> Salary management
Steps:

Open the screen

Query with any criteria based on the available fields.

If we cannot see the column we wanted to query with then add the required
field, with the Folder Menu -> Show Field.

Now, as the query pulls the Salary details of the employee we have queried
for go to file menu and click on Export Data.

It should open up a web page asking us the format we want to export the file
to. Choose the Excel version based on our machine and press next. See Figure 2.13
Web-ADI.

Figure 13 Web-ADI

(Figure 2.13 Web-ADI)

Now it will save the excel document on our machine.

Once we open the file, it will download all the data that we could see in the

applications screen.

Now, go and update the Proposed Salary and approve it based on our
requirements.

Once done, go to Add ins Menu in your Excel

Click on Oracle and say Upload

This should be all, all our salary updates are done within seconds and couldnt
have been easier than excel.

Checklist
When someone gets hired in our firm, he goes through a lot of different processes right?
Like getting his email id created, getting an ID card made, system gets assigned, Company
orientation etc. Now, how do we track it? Our HR team just remembers the flow or may be
puts it in an excel sheet.
Oracle application comes with an awesome toll called checklist, where we can define the
tasks related to a particular event, like new hire, and associate that with the employee.
Then we can set up a flow where the tasks are executed one after another with
dependencies attached. It is very similar to the MS-Project. Now, as and when the tasks get
assigned, we can send emails to the task owners as reminders, and do a lot of other stuff
with that.

Multi-Org Architecture
Multi-Org is an acronym for Multiple Organization. As the name suggests this architecture
enables the Oracle E-Biz users to implement the product for more than one organization
within the Enterprise. In most cases an enterprise holds different organizations / business
units with in it. Those Organizations represent one particular business function or a
business location or both. For an example, the Finance department of Germany could be
one organization and the Finance department of Australia could be another. In this case, we
would need some kind of data security between these two organizations; like we wouldnt
want the Finance clerk at the Germany office to be able to see or modify the Australia data,
and vice versa. Oracle E-Biz provides the solution to this security issue with a feature called
the multi-org architecture. Lets discuss this feature in details.
First of all we must identify the clerks location in order to provide / revoke access to a set
of data. We can do that using Responsibilities. So the Finance clerk at Germany will log in
with a responsibility, something like Germany Finance User which is related to the
Germany data only, and the Australian one logs in with the Australian responsibility. So with
the responsibilities we should be able to differentiate between the users. And we already
know we can define the screens accessible to those responsibilities through menus. With
the responsibilities and menus in hand, we will be able to control the screens and requests

that the Germany Clerk can run. However we have no control over the data yet.
To encapsulate the data based on organizations, E-Biz labels all the important and secured
data with the Organizations / operating unit associated with it. As each record will have the
name of the organization that owns the record, it becomes very easy to identify, whether it
belongs to Germany or Australia. With that logic, security profiles will be able to segregate
the data to be shown from the protected data. Finally those security profiles are attached to
the respective responsibilities. So finally, based on the responsibility that a person is logged
in, s/he will be able to see the data that are related to the organization to which he belongs.

NOTE
Not all tables are Multi-Org enabled in Oracle E-Biz; so all the tables do not store
the Organization name in the records. This functionality is limited to the
appropriate tables that are needed to be secured.

Both 11i and R12 use two different ways to encapsulate the data based on Responsibilities.
Oracle 11i uses the security profiles to be directly associated with the responsibilities, which
establishes a one to one relationship between them. Where as Oracle R12 uses a modern
approach to handle that.
In a case where you have the one common financial controller sitting Europe, who controls
the financial data across Europe, Middle East, Africa and Australia, you might want him to
see the data for both Germany and Australia. For him, it might be difficult to switch
responsibilities every time he wants to see the data for a different country. Oracle R12 gives
the solution with an approach called the Multi-Org Access Control. With which a particular
responsibility is allowed to have more than one Organization linked to it, using the
Organization hierarchy. As the organization hierarchy would have a tree like structure that
lists all the Children organizations under the parent one; that comes handy for the MultiOrg Access Control. Hence using the same responsibility across more than one organization
becomes possible in Oracle R12.

Oracle Core HR >

Summary

Contents
1. 1 Technical Aspect of Core-HR
2. 2 Summary

Technical Aspect of Core-HR

Lets see the tables that are used in Core-HR.
Note:

In the table below, if the Date tracked column is marked as Yes, assume the Primary
key to be Composite. The given Primary will bind with the two date tracked columns
to make the Composite Primary key.

Some of the values in the column Table could be a view / synonym.

Table Name

Date
Tracke
d?

Primary Key

Description