Oracle core-hr

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. Let’s 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 let’s
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 employee’s 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 START_DATE END_DATE
1234 Joe Analyst 01-JAN-2002 31-DEC-2006
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. It’s not greatly normalized. But well, that’s 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
Let’s 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. The
EFFECTIVE_START_DATE is the today's date and EFFECTIVE_END_DATE is the EOT.
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 it’s an End Date or a purge.

DATED Tables
Now, we know what a date tracked table is. Let’s 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 what’s 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, let’s
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 (that’s 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 Joe’s 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. It’s 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. Let’s 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
Let’s 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. It’s 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. It’s 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. It’s 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. It’s 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 Annualization factor stored in
PER_PAY_BASES.PAY_ANNUALIZATION_FACTOR based on the Employee's
PAY_BASIS_ID.
 Then the Multiplication resultant is the Annual Salary.

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, Ex-
Employees, 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, isn’t it? So what’s 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”. Wouldn’t
that be awesome? This functionality is there. The attributes are nothing but “Person Types”.
Let’s 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. Let’s 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 let’s 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 let’s set “General Shift Staff” as default. Now whenever there is a hire, the system
will identify, oh, it’s an Employee, then what is the Default Person Type? Oh, it’s “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, isn’t it?
But how do we change it manually? Let’s see.
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 let’s see the role of the flex fields in Core-HR implementation.
KFFs
Let’s 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 table’s 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
Let’s 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.
 · Copy the Title.
Figure 5 EITs

(Figure 2.5 – EITs)
Now, go to the Segments.
Navigation: Flex Field -> Descriptive -> Segments
Steps:
 · Query for the Title in the table
 · 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.
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 someone’s location DFF. In that case just do not link the EIT to the payroll
user Responsibility. Let’s see how to link EITs.
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, let’s 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. Let’s 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. It’s 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 let’s 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.
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 let’s 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 it’s 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 Name of the Job Group; should be unique
Job KFF
Structure
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 Job
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.
Setting up Jobs
Next task is to add jobs. See Figure 2.10 – Defining Jobs.
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 it’s 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, it’s 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. It’s 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,
 · Figure out the segments we will be using in a Position KFF
 · 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

 · Do not forget about the “Create Key Flex field Database Items Process”
Setting up Positions
As we have the KFF defined, let’s see how to create a new position.
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, isn’t 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.
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 it’s created. See Figure 2.8 – Defining Locations.
Figure 8 Defining Locations

(Figure 2.8 – Defining Locations)
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.
Let’s 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 today’s 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. That’s why it’s 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

Navigation: Work Structure -> Grade -> Description
Steps:
 · Enter the sequence number.
 · 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.
That should be all. Simple, isn’t 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.
Let’s go define it.
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 employee’s 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. It’s a DATE_TO Enabled table. The Type of the Organization informs us
whether it’s an Organization / Department / Division.
To understand it better, let’s 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. Let’s 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 head’s 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, let’s create an organization. See Figure 2.7 – Defining Organizations.
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.
Let’s discuss the mandatory classifications that are needed for every HRMS set up: like
Operating Company, Business Group, Legal Entity, HR Organization, Operating unit etc.
Let’s 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, isn’t 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.
Don’t 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.
Let’s 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 let’s 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, HR-
New 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-Head’s 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. Let’s see, how to
define and control one.
Creating a Hierarchy
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

 · Save the changes
 · Now query one of the secondary organizations (Organizations reporting to the
top Org) and keep on adding its child organizations
 · Likewise, keep on establishing the relationship between the organizations
 · The up and down buttons can be used to move an Organization up or down in
the hierarchy.
 Let’s 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.
 · Query our primary hierarchy; populate the end date and save it.
 · 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.
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.
Navigation: Work Structure -> Organization -> Diagrammer
Steps:
 · Query the name of the Organization hierarchy.
 · 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

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 won’t. 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
administrator’s job, let’s just see the options available to us. See Figure 2.14 – Security
profiles.
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 supervisor’s 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.
Let’s 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.
Let’s 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 employee’s
supervisor’s 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 employee’s 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 year’s 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
Let’s 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; let’s 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.

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.
Navigation: people -> Mass update of Person -> Mass Update of Employee Assignments
Figure 12 Mass Move

(Figure 2.12 – Mass Move)
Steps:
 · Put a description.
 · 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.
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.

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 couldn’t
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 wouldn’t
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. Let’s discuss this feature in details.
First of all we must identify the clerk’s 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 Multi-
Org 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
Let’s 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

Oracle core-hr

Recommended

Recommended

More Related Content

Similar to Oracle core-hr

Similar to Oracle core-hr (20)

Recently uploaded

Recently uploaded (20)

Oracle core-hr