Positions in Oracle HRMS
Positions are used to define employee roles within Oracle Human Resources.position is a specific occurrence of one job, fixed within one organization,Positions are independent of the employees
A position will need to be defined for every unique combination of:
· Job
· Organization
· Reporting To Position Hierarchy
· Valid Grades (Valid Grades to which incumbents are assigned)
· Position Requirements (Required qualifications or valid experience)
· Position Evaluation (Evaluation information and overall evaluation score for the Position)
· Position Key Flex Field (Name Field components, such as Position Title, Position ID or other client defined keys)
· Position Successor
· Probation Periods (To define the length of the Probation Period for incumbents holding this position)
Advantages:
Position definition with no override attributes, ensures derivation from the position. It is more accurate because the definition focuses on the position and is not affected by the employee in the position
Position attributes change less often than employee movement. When the position attributes change, the system automatically updates incumbent records with the new value.
Types of Positions
Pooled: This approach is very good for organizations where groups of people are doing the same work (many employees assigned to one position), have the same reporting relationship (predominate in manufacturing and transportation industries). This approach allows multiple people to occupy a single position that has the same attributes and reporting relationship.
Shared: This approach supports the ability to assign employees to several part-time positions. This approach is becoming more common. In some companies, an employee works part-time (20 hours) in one department and then part-time in another department. In essence the company divides the employee and distributes the cost across the two departments. The company benefits from only having to pay benefits to one person.
Single Incumbent: This approach is usually used for positions, which are managerial or at least static. This approach is usually needed for those positions, which will have spending authority levels, and defined succession planning. This approach assumes on position per person
Table Information
1)PER_POSITION_DEFINITIONS
This is a key flexfield combinations table. It stores segment combinations for positions that are stored in the HR_ALL_POSITIONS_F table.
2)HR_ALL_POSITIONS_F
This table holds datetracked position definitions.
Column POSITION_DEFINITION_ID links this table to PER_POSITION_DEFINITIONS to identify the segment values.
This table was introduce in R11i and prior to that the non-datetracked table PER_ALL_POSITIONS was used.
3)PER_POSITION_EXTRA_INFO
This table holds details of extra information for a position.
4)PER_POSITION_INFO_TYPES
This table holds the definitions of extra information types that may be held against a position.
4)PER_POSITION_LIST
Holds the list of positions that can be accessed by a specific security profile.
The rows in this table are generated by the 'Security List Maintenance' process.
5)PER_POSITION_STRUCTURES
Holds information about position hierarchies defined for each Business Group.
6)PER_ALL_POSITIONS
PO still uses this table and a concurrent request 'Synchronize Positions Process' is available to keep the two tables in synch.
APIs
1)hr_position_api (peposapi.pkh)
create_position
delete_position
update_position
2)hr_position_extra_info_api (pepoiapi.pkh)
create_position_extra_info
delete_position_extra_info
update_position_extra_info
3)hr_position_requirement_api (pepsrapi.pkh)
create_position_requirement
per_position_structure_api (pepstapi.pkh)
create_pos_struct_and_def_ver
create_position_structure
delete_position_structure
update_position_structure
4)per_pos_structure_version_api (pepsvapi.pkh)
create_pos_structure_version
delete_pos_structure_version
update_pos_structure_version
5)hr_pos_hierarchy_ele_api (pepseapi.pkh)
create_pos_hierachy_ele
delete_pos_hierachy_ele
update_pos_hierachy_ele