Position Details. Position Management Check Boxes The check boxes at the top of the window are for information purposes only. They are checked if the position belongs to an organization selected for position control. The check boxes indicate whether the position is: Open: Unfilled Under Review: Changes to the position definition are in process using a position transaction Approved Future Actions: The position or changes to it are approved for a future effective date

2. Select the position type. The choices are: Single Incumbent, meaning that only one employee is allowed to hold the position at any time Shared, meaning there can be several incumbents, up to the value of the FTE field Pooled (Public Sector only), meaning the position is loosely defined so rules about FTE and hours are not enforced by the system None, which you can select if you do not need to record position types 3. If the position is permanent and budgeted every year, select the Permanent check box.

4. If the position is only used in one season each year (such as a summer teacher), select the Seasonal check box. You can enter the season dates in the Seasonal Information extra information type. 7. Select the organization and job for this position. They must have a start date on or before the start date of this position. Note: You cannot change the organization or job once you have saved the definition. You can set up several positions that have the same job in the same organization. Each position name must be unique 8. Select a location for the position, or leave the default, which is the location of the organization. 9. Optionally, select a status for the position. Selecting Valid or leaving the Status field blank enables employees to be assigned to the position, provided other conditions (such as an Active hiring status) are met. If the status is Invalid or any other status defined at your site, employees cannot be assigned to the position Entering Hiring Information 1. Enter the number of Full Time Equivalents to be assigned to this position. If the Position Type is Single Incumbent, FTE must be 1.0 or less.

2. You can enter the number of incumbents that are planned for the position in the Headcount field. 3. If appropriate, select a bargaining unit code for the position. This is usually the legally recognized collective negotiating organization. Note: You set up your different bargaining units as values for the Lookup type BARGAINING_UNIT_CODE. 4. If required, enter the earliest date at which incumbents can be hired into this position. If you have created a requisition and vacancy for this position, the earliest hire date must be within the vacancy dates. 5. Enter the date by which the position should be filled. This date must be on or after the Earliest Hire Date. 6. Use the Permit Recruiting check box to identify, for your own information, a position that is frozen but due to become active in the near future. Note: The Permit Recruiting check box is for information purposes only.

Proposed Entry Salary 1. Select the payroll to which the position's incumbents are normally assigned. This payroll's calendar can be used for calculations of budgeted amounts and commitments. 2. Select the salary basis to which the position's incumbents are normally assigned. 3. Select the default grade to be used to determine the entry salary of position incumbents. Note: If you maintain information about valid grades for the position or the position's job, this grade must be one of the valid grades.

4. Do one of the following, or leave these fields blank: If the position is paid from a pay scale, select the grade step and scale rate that represent the entry level salary for this position. The system displays the value of the step on the scale rate you selected.

If you maintain a grade rate to hold entry salary for this position, select the appropriate grade rate. The value or range (minimum, maximum and midpoint values) for this grade rate are displayed. Probation If there is a probation period for this position, you can enter its length in the Probation region. Overlap Select the length of time a new incumbent can overlap with a leaving incumbent for transfer of skills. Note: You can enter proposed start and end dates for particular periods of overlap using the Extra Information Types window.

POSITION DEFINE IN HRMS

POSITION DEFINE :Job Positions ==== ========== Director = Managing Director Manager = Finance Manager Production Manager Clerk = Senior Clerk Assisten Clerk operators = Mechine Operator System operator 1)Open the Position Form Work structure=>position=>Description 2)Select New Button =>Set Effective date 3)Enter the Position Name as per the Position KFF structure 4)Select Position type (Ex : Shared) Single Incumbent : meaning that only one employee is allowed to hold the position at any time Shared : meaning there can be several incumbents, up to the value of the FTE field Pooled (Public Sector only) : meaning the position is loosely defined so rules about FTE and hours are not enforced by the system None : which you can select if you do not need to record position types 5)Select the Organization Name where we can use the Position 6)Select the Job Under which Job we are defining this Position 7)Select Hiring Status = 'Active' Active : We can Recruit the Employees

Praposed : We can not recruit Employees Position is Under Process. 8)Goto Hirng Information Tab enter the FTE and Heade Count FTE =FUll Time Equivalent Head Count =Number of Employes we can recruit under this Position. Define Position hierarchy: ========================== Workstructures=>Position=>Hierarchy 1)Enter the Position hierarchy Name and check the Primary check Box Save 2)Enter the Version number and Date From save 3)Place the Cursor in the Position Name Field Press CTRL+F11 4)Go for Defining the Subordinates as per the requirement by using Down and Up Arrow marks Save. 5)open the Diagrammer form we can find the Position Hierarchy Diagramatically chart wise and we can also find the Position Holder Details. MD FM SC JC PM MO SO

Mass Move: ========== If we are going to Transfer the Position from One organization to Another Organization then we will go for using the Massmove to transfer the Positions Enter the Name and Select Source and Target Organization select Positions Button and select Positions which we would like to transfer select the button called Execute.

Positions in Oracle HRMS 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_FThis 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 The rows in this table are generated by the 'Security List Maintenance' process. security profile.

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

Purchasing Setup of Approval Hierarchies

(Thanks,Meta Link ID: 134947.1) Purpose This article describes the basics of how Approval Hierarchies work in Oracle Purchasing. It is intended to help users to setup hierarchies for the purpose of routing articles to the proper authority for document approval. Last Review Date June 22, 2010 Instructions for the Reader A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting. Troubleshooting Details Purchasing Setup of Approval Hierarchies There are three methods to route documents for approval:. Approval Hierarchies (uses position hierarchies) Employee/Supervisor (uses employee/supervisor relationship) AME Approval Management Engine (for requisitions only)

The first two methods Approval and Employee/Supervisor pertain to all Purchasing document types, including requisitions. This document will not include information on the 3rd method, Approval Management Engine (AME) for requisition approval. Additionally this note will only review approvals for single business groups. Refer to Note 726618.1 Unable to Allow Approver to be seen Across Business Groups for information about approvals across business groups. This document will include the following sections: Initial Setup: Basic setup you need to complete in order to use the Approvals functionality in Purchasing Employee/Supervisor Relationships: A narrative explaining the employee/supervisor relationship and examples. Position Hierarchy: A narrative explaining the position hierarchy and examples. Approval Setup: Basic requirements for setting up both the Approval and Employee/Supervisor Relationship. If you want a quick reference with screenshots of the setup go directly to this section. Initial Setup - Enable the Approval Method The Human Resources zone on the Financial Options form has an option called Use Approval Hierarchies. This option determines which type of hierarchy is used for the approval process. When checked, the Approval Hierarchy is used and when unchecked the Employee/Supervisor relationship is used. Go to the Financial Options form Navigation: PO Responsibility -> Setup -> Organizations -> Financial Options a. Select or deselect Use Approval Hierarchies. b. Save your work. - Define Jobs / Positions Use the Job window to create each of the job titles in your organization (for example: Buyer, Supply Base Engineer). If you are not using positions, you assign one or more employees to each job. If you are using positions, you assign one or more positions to each job, and later assign one or more employees to each position. Navigation if using shared HR: Purchasing Responsibility -> Setup -> Personnel -> Jobs If using a full install of HR: Human Resources Responsibility -> Work Structures -> Jobs -> Description

Note: You assign authorization rules to jobs or positions based on your approval method. If you are using employee supervisor method the authorization rules are assigned to the jobs. Use the Position window to create each of the positions in your organization. This step is required if you plan to use either security or position approval hierarchies. Navigation if using shared HR: Purchasing Responsibility -> Setup -> Personnel -> Positions If using a full install of HR: Human Resources Responsibility -> Work Structures -> Positions -> Description Note: Refer to Representing Jobs and Positions, Oracle HRMS Enterprise and Workforce Management Guide for more information about setting up jobs or positions. - Build Position Hierarchies Use the Position Hierarchy window to build and administer your position hierarchies. There are two distinct uses for position hierarchies in Purchasing: Document approval routing and Document security control. You can use a single position hierarchy for both purposes. Navigation if using shared HR: Purchasing Responsibility -> Setup -> Personnel -> Position Hierarchy. If using a full install of HR: Human Resources Responsibility -> Work Structures -> Position Hierarchy Note: Refer to Representing Jobs and Positions, Oracle HRMS Enterprise and Workforce Management Guide. - Security Hierarchies Security Hierarchy is used to determine who can access the purchasing document. If you want to specify a Security Level of Hierarchy for any of your document types, you must first define all positions. Important: Even if you are using jobs (i.e. Employee/Supervisor relationship) to route documents, you must define positions before you can enable this Security Level) The Security Hierarchy is selected from a list of values in the Control zone of the Purchasing Options form (Navigation: Purchasing Responsibility -> Setup -> Organizations -> Purchasing Options). Here, select a Security Hierarchy, which is a position hierarchy from the Position Hierarchy window. When the Security Level is set to Hierarchy for a document in the Document Controls window, this position hierarchy governs access security for that document. The Security Hierarchy field will only be enabled when the Hierarchy option is selected for the Security Level on the Document Types form. Employee/Supervisor Relationships

This type of hierarchy is defined by the employee/supervisor relationship. The supervisor of an employee is defined on the Assignment region of the Employee form. If the purchase order entered by the employee exceeds the approval limits, the purchase order is forwarded onto the employees supervisor, as defined on the Employee form. To implement this form of approval routing, you need only to define jobs. The job will then serve as the tie to the approval group, and based on the approval limits from the Approval Group, the document will either be approved or forwarded to the Employees Supervisor. If no supervisor is able to be located and the job assigned to the employee does not have approval authority, then the approving employee must enter a forward-to person, or the Document will be returned to an Incomplete status and a notification will be sent to the approving employee, stating No Approver Found.

Employee/Supervisor Relationship Setup Example For this example Senior Manager is the manager of Junior Buyer and Group Manager is the manager of Senior Manager. Employee Junior Buyer Senior Buyer Group Manager Is Managed by Senior Manager Group Manager Approval Limit 50.00 100.00 Unlimited

Employee/Supervisor Example One: The Forward Method is set to Hierarchy on the Document Type form. a. Junior Buyer raises a purchase order that has a total value of 150.00. b. The purchase order is then submitted for approval. c. As Junior Buyer does not have a high enough approval limits, the purchase order is automatically forwarded to Senior Manager (because Senior Manager is Junior Buyers supervisor as defined on the Employee form) d. Senior Manager responds to the approval notification for this purchase order. e. If Senior Manager selects Approve, the purchase order is automatically forwarded on to the Group.Manager as Senior Manager does not have a high enough approval limit. f. The purchase order appears in the notification screen for Group Manager where it can be approved or rejected. Employee/Supervisor Example Two: The Forward Method is changed to Direct. a. Junior Buyer raises another purchase order with a total value of 150.00. b. The purchase order is then submitted for approval.

c. As neither Junior Buyer or Senior Manager have a high enough approval limit, the purchase order is sent directly to Group Manager because Group Manager is Senior Managers supervisor as defined on the Employee form and Senior Manager is Junior Buyers supervisor. Position Hierarchies Position Hierarchies are hierarchies that have a position relationship. Purchasing utilizes positions as a roadmap to determine how and where documents will be routed once the approval process has been initiated. It is first necessary to have created all positions that are going to be used in the system. Once all positions have been created, it is necessary to build the position hierarchy. Each position has approval limits, so when a purchase order exceeds the limits of the position, the purchase order is forwarded onto the next position in the Hierarchy. The hierarchy for positions is defined on the Position Hierarchy form. Purchasing does not check for the primary checkbox on Position Hierarchy form. When this setup is complete or is changed, the Fill Employee Hierarchy concurrent program must be run for the new hierarchy to come into effect. You must set up Positions if you plan to use either security or approval hierarchies. Position Hierarchy Setup Example For the following two examples we will use the following Approval Hierarchy. The name of the hierarchy is Buyer Approval Hierarchy. Employee Position Junior Buyer Senior Buyer Chief Buyer Approval Example One Manager Position Senior Buyer Chief Buyer Approval Limit 50.00 100.00 Unlimited

On the Document Type form Forward Method is set to Hierarchy and Default Hierarchy is set to Buyer Approval Hierarchy. a. Junior Buyer raises a purchase order that has a total value of 150.00. b. The purchase order is then submitted for approval. c. As Junior Buyer does not have a high enough approval limit, the purchase order is automatically forwarded to Senior Buyer because it is the next position in the hierarchy. d. Senior Buyer responds to the approval notification for the purchase order. e. If Senior Buyer selects Approve, the purchase order is automatically forwarded to Chief Buyer because Senior Buyer does not have a high enough approval limit. f. The purchase order notification appears in the notification screen for Chief Buyer where it can be approved or rejected. Approval Example Two

On the Document Type form The Forward Method is changed to Direct and the Default Hierarchy remains unchanged. a. Junior Buyer raises another purchase order with a total value of 150.00. b. The purchase order is then submitted for approval. c. As neither Junior Buyer nor Senior Buyer has a high enough approval limit, the purchase order is sent directly to Chief Buyer for approval. Approval Setup Document Types Forwarding Method: The forwarding method is set under document types. This field has two options that apply regardless as to whether you use an Approval Hierarchy or an Employee/Supervisor relationship. Direct: the document will pass to the next position or supervisor in the hierarchy who has enough authority to approve the document. Hierarchy: the document will pass to the next person in the hierarchy regardless as to whether that position or supervisor has enough approval authority to approve the document. Navigation: Purchasing Responsibility -> Setup -> Purchasing -> Document Types a. From the list of values choose the purchasing document you want to assign the forwarding method to. b. In the field Forward Method choose Hierarchy or Direct and save your work. Default Hierarchy In the screenshot above we additionally see the Default Hierarchy set to Materials. When choosing the action of Approve for a document, if a Forward-To person is not defined and the person taking action does not have sufficient approval authority, the default hierarchy is first searched by the employee attempting the approval. The Default Hierarchy option will only appear on the Document Type form if the option Use Approval Hierarchies is selected as shown in the section Enable the Hierarchy Method above. The Default Hierarchy field has a list of values. This list is derived from the hierarchies created using the Position Hierarchy form which will be discussed under the Position Hierarchies section of this document. The Default Hierarchy is the one that will be used by the approval process unless the person who submits the document for approval changes it in the Approval Modal form. But, the hierarchy can only be changed on the Approval Modal form if the attribute Can Change Approval Hierarchy (additionally shown in the screenshot above) is checked on the Document Type form.

Note: it is imperative that the low-end users (those with little approval authority) be present in this default hierarchy so the next Forward-To approver can be found. User Setup Regardless if Approval (Position) or Employee/Supervisor hierarchies are used, there are some basic setups required for the approvers: Step 1: Create the employee record: Go to the People form Navigation if HR is fully installed: HR Responsibility > People > Enter and Maintain. Navigation if HR is shared: Purchasing Responsibility > Setup > Personnel > Employees a. Either query the employee by name or if the employee record has not been entered, enter the required detail. b. If e-mail notifications are to be sent then enter the users email address in the Email field in the Office Details tab. c. Choose the Assignment button d. Assign a Job if using Employee/Supervisor or Job and Position if using Approval Hierarchies. Note: For information on creating jobs or positions see the Oracle Purchasing Users Guide, section Define Human Resource key Flexfields (Required). e. If Employee/Supervisor is used the Supervisor must be assigned (unless this approver is the last approver in the hierarchy chain). Save your work. Step 2: Create the User record: Go to the Users form Navigation: System Administrator -> Security -> User -> Define a. If the user has already been entered then query the user in the User Name field. If the user has not been entered fill in the required information and link the human resources record in the Person field. b. If e-mail notifications are to be sent ensure that the e-mail field is populated. This information will default from the e-mail address entered in the human resources record above. c. Add the responsibilities needed for the user. Save your work. Step 3: Setup the user as a Buyer: Go to the Buyers form: Navigation: Purchasing Responsibility -> Setup -> Personnel -> Buyers

a. Enter the Buyer name and Effective From date. Category and Ship-To are not required. b. Save your work.

Note: If the user is an off-line approver it is not required to enter the user as a Buyer here. Step 4: Run the Fill Employee Hierarchy process if using Approval Hierarchies: Go to the Submit Requests form: Navigation: Purchasing Responsibility -> Reports -> Run a. Choose the Single Request Fill Employee Hierarchy. b. Submit the request and make sure it completes successfully from View -> Requests. Note: It is required to run this report if creating or making changes to the Position hierarchy. It is not required to run this report if using Employee/Supervisor hierarchy. Approval Assignment: Once the Approvers position or job is assigned in the HR record it is necessary to assign the Approval Group for the document type. Go to the Assign Approval Groups form: Navigation: Purchasing Responsibility -> Setup -> Approvals -> Approval Assignments a. From the list of values choose the position (Approval Hierarchies) or job (Employee/Supervisor). b. Save your work. There are 6 document types which can be assigned to approval groups, if necessary. It is also possible to assign multiple approval groups for document types if different approval limits are needed. In this example the same Approval Group is assigned to all document types. Approval Groups: Next it is necessary to set the rules for the Approval Groups. Go to the Approval Groups form: Navigation: Purchasing Responsibility -> Setup -> Approvals -> Approval Groups a. From the list of values choose the Approval Group seen in the previous Approval Assignment form. b. Assign at least one Document Total and one Account Range. Save your work. In the screenshot below we see there is an unlimited Amount Limit and account range for approval. For more information on assigning approval rules see Note 1107338.1 How to Verify

that Document Charge Account and Approval Groups Setup is Valid in Order to Prevent no Approver Found. What articles, white papers, or manuals should I read for more information on Approval Hierarchies in Oracle Purchasing? Note 293315.1 11.5.10 FAQ for Approvals Management (AME) Integration For iProcurement and Purchasing Note 396808.1 Oracle Approvals Management Documentation Resources, Release 12 Note 395405.1 Oracle HRMS Documentation Resources, Release 12 Oracle Purchasing Users Guide, Release 11.5.x Oracle Purchasing Users Guide, Release 12 Oracle Human Resource Management Systems Users Guide What are the Metalink keywords I should use when searching for content on Approval Hierarchies in Oracle Purchasing? APPROVALS, SETUP, HIERARCHY, POSITION, EMPLOYEE SUPERVISOR, ROUTING, SECURITY