Oracle Core HR

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

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.

Responsibility:  Super HRMS Manager

Navigation: Fast Path -> Person Type Usages

Steps:

• ·         Query for the employee
• ·         Add a new Person Type usage / End date the old one.

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)

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.

Responsibility:  Super HRMS Manager

Navigation: Work Structure -> Job -> Description

Job Group	Enter the Job Group name, which holds this job
Name	Enter the name of the Job; if there are any segments in the KFF used in the Job group, we need to enter a unique combination of segments to create a new job.
Dates	Enter the start and end dates
Approval Authority	This will be a number. This number will be referenced by the AME (Approval Management Engine) in Oracle to determine if any person attached to this job has ample authority to approve a request. It is advised to use 10 for the base workers and then keep on adding 0 to the right as and when the position increases. Like line managers will have 100, senior managers will have 1000 and so on.
Additional Employment Rights	This flag is added when there is any extra Employment Rights
Benchmark Job	Add if 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.

Responsibility:  Super HRMS Manager

Navigation: Work Structure -> Position -> Description

Date Effective Name	Enter the name of the position. If there are any segments in the position KFF, we need to enter a unique combination of segments to make a new position.
Start Dates	Enter the start date.
Type	Depicts the type of the position: • Single Incumbent: Only one employee is allowed to hold the position at any point of  time • Shared:  It can have several incumbents • Pooled : Position is loosely defined and is available to a set of employees • None: Default
Permanent	Use this flag to make the position Permanent and to be budgeted every year.
Org and Job	Add the Org and job name in these fields. Once entered these details will never be changed.
Hiring Status	This tells about the hiring status of the positions. Along with the dates since which the status is active and up until when.
Location	Enter a Location if the position is fixed to a location.
Status	The status of the position. Mark Valid/ leave blank.
Hiring Information
FTE	The number of Full Time Equivalent needed for the position.
Headcount	The planned number of FTEs in the field
Bargaining Unit	If the employees in this position have to be in a particular bargaining unit then it must be defined here.
Earliest Hire Date	Enter the date by which the Applicants must be hired for the position.
Fill by Date	Enter the date by which the position should be filled in.
Permit Recruiting	Information Only.
Payroll	The Payroll into which the hired employee for the position will go to.
Salary Basis	Salary basis for the position
Grade	The Grade in which the employee must go in. The Grade must be one of the valid grades for the Job to which this position belongs to.
Grade Steps	The rest of the Grade step Progression data must be entered.
Probation	The period up to which a new employee must be in Probation.
Overlap	Define the required transition period for the new employee and the leaving employee.
Rest of the tabs	The rest of the tabs are self explanatory; however very rarely used in HRMS.

Position Hierarchy

The Position hierarchy is more or less similar to what we have in the Organizational hierarchy, but here, the structure is based on the Positions. Like, for an example, our firm has clerks, then Senior Clerks, Line Mangers, Managers, Senior Managers etc, and the reporting structure is in the same order, 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               

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

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

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)

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

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.

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)

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.

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.

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 Tracked?	Primary Key	Description
HR_ALL_ORGANIZATION_UNITS	No	ORGANIZATION_ID	Stores the details of the Organizations defined in the system, including the type and BUSINESS_GROUP_ID.
HR_LOCATION_EXTRA_INFO	No	LOCATION_EXTRA_INFO_ID	Location EIT table
HR_LOCATIONS_ALL	No	LOCATION_ID	Stores the locations defined in the system with address.
HR_ORGANIZATION_INFORMATION	No	ORG_INFORMATION_ID	Stores the EIT attached to HR Organization Classifications.
PER_ADDRESSES	No	ADDRESS_ID	It is a DATE_TO table and stores the address of persons with Primary flag and address style.
PER_ALL_ASSIGNMENTS_F	Yes	ASSIGNMENT_ID	Stores the assignment details of the Person. More details can be found in Lexicons.
PER_ALL_PEOPLE_F	Yes	PERSON_ID	Stores the person related information. More details can be found in Lexicons.
PER_ASSIGNMENT_EXTRA_INFO	No	ASSIGNMENT_EXTRA_INFO_ID	Stores the Assignment EITs
PER_BUSINESS_GROUPS	No	BUSINESS_GROUP_ID	Stores the Business Group information, it is a DATE_TO table
PER_GRADES	No	GRADE_ID	Sores Grades related information
PER_JOB_EXTRA_INFO	No	JOB_EXTRA_INFO_ID	Stores the Job EIT
PER_JOBS	No	JOB_ID	Stores the Job related information
PER_ORGANIZATION_STRUCTURES	No	ORGANIZATION_STRUCTURE_ID	Stores the Organization hierarchy
PER_PAY_BASES	No	PAY_BASIS_ID	Stores the Pay Basis related information along with the Annualization factor
PER_PAY_PROPOSALS	No	PAY_PROPOSAL_ID	Stores the Salary of the Employees along with approval details.
PER_PERIODS_OF_SERVICE	No	PERIOD_OF_SERVICE_ID	Stores the service related information, from hire to termination.
PER_PERSON_TYPE_USAGES_F	Yes	PERSON_TYPE_USAGE_ID	This table stores the user Person type with a link to the PERSON_ID for the person. So if we wish to see the valid person types of one person as of a date, this is the table we should look for.
PER_PERSON_TYPES	No	PERSON_TYPE_ID	This table stores the valid System and user person types, along with the BUSINESS_GROUP_ID
PER_PHONES	No	PHONE_ID	This table stores the phone numbers of persons.
PER_POSITION_EXTRA_INFO	No	POSITION_EXTRA_INFO_ID	Stores Position EIT
PER_POSITIONS	No	POSITION_ID	Stores Position details.
PER_SECURITY_PROFILES	No	SECURITY_PROFILE_ID	Stores the security profiles.

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.