ORACLE CORE HR

INTRODUCTION

Human resource management system, as the name suggests, is a system that accounts for the
human resource / the human capital / asset. This is very nice to count Employees to be an asset to
the enterprise. However like all other assets of the Firm, human resource also needs renewal and
maintenance. This module in Oracle E-Biz helps us manage our Human capital and lets us embed the
HR related data with other modules.

HRMS as a module is needed in almost all other modules in the enterprise. For an example, if we are
entering any data related to procurement, we might want to record the person details who wanted
it. Similarly for a Project request, we might want to record who the Project manager for the project
is. For an Order to be approved, we might need the manager's name of the person who punched that
particular order. So HRMS is everywhere. Progressively when we keep reading about the various
functionalities, we will be able to relate the concepts to the real world.

CHAPTER OVERVIEW

This chapter talks about:

 Core-HR as a module

 Concepts of Date Tracking

 Storing person data

 Building blocks of Core- HR: Organization, Location, Job, Position, Grades etc

 Tools used in Core-HR

 Security Profile and Multi-Org

 Technical aspect of Core-HR

 Summary

 Questionnaires

LEARNING OUTCOMES

After going through this Chapter, you should be able to:

 Understand the concept of Date tracking and the record structure

 Support and implement Core-HR components like Organization, Location, Job, Position,
Grades etc
  Use the tools associated with Core-HR

 Appreciate and implement the Security features in Core-HR

 Understand the Multi-org architecture

FLEX FIELDS

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.

Responsibility: Application Developer

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.

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, 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.
 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 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)

Setting up Jobs
Next task is to add jobs. See Figure 2.10 – Defining Jobs.

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Job -> Description

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.

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Position -> Description

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.

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 it’s
created. See Figure 2.8 – Defining Locations.

Figure 8 Defining Locations

 (Figure 2.8 – Defining Locations)

Responsibility: Super HRMS Manager

Navigation: Work Structure -> 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
Responsibility: Super HRMS Manager

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.

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 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.

ORGANIZATIONS

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.

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Organization -> Description

Steps:

Figure 7 Defining Organizations

 (Figure 2.7 – Defining Organizations)

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
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
 · 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.

Responsibility: Super HRMS Manager

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.

TOOLS IN HR

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.

Responsibility: Super HRMS Manager

Navigation: people -> Salary management

Figure 14 Security profiles

 (Figure 2.14 – Security profiles)

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.

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.

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 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.

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
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.

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.

Although we have considered all the important concepts of Core-HR there

are a lot to it. However those functionalities are there to help certain
modules only. Hence the attempt was to add those functionalities with the
modules they are used for. So keep on turning the pages and there are a
lot to come with Core- HR.

SUMMARY
In this chapter we discussed about the basic of Core HRMS including the
concepts like date tracking, how E-Biz stores different data, Person types
and the different flex fields used in Core-HR. We then moved our focus
towards the Implementation steps, we discussed about the job, position,
locations and grades. We also discussed about different Organization
classifications and Organization hierarchy. We then moved to salary
administration techniques, and discussed the different tools used in
Oracle Core-HR to make the administration simple and elementary. We
discussed about the Multi-Org architecture and how is it used to help big
enterprises. Finally the underlying tables are discussed with their usage
and relationship with others.