Oracle Core HR‎ > ‎

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)

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.

Comments