Hello Team, Here I am creating two employees, EMP 1 and EMP2. EMP 2 supervisor of EMP1.

Can I know the steps to setup the requisition approval. I want the setup steps for employee/supervisor relationships. When ever as Emp1 am trying to forward it to Emp2 its not gng. Can anyone let me know what is that m missing here. Following is what I have done. I am creating emp 1 and emp 2 Emp2 is supervisor of Emp1. Creating jobs and positions and assigning it to EMP1. Creating Job Groups with Amount and account range. Assigining it to to job by job assingment. Settings unchecked the check box approval hirarchies under HR tab.

Hi, This is a copy of metalink note This article describes the basics of how Approval Hierarchies work in Oracle Purchasing. Please review Chapter 2 of the Oracle Purchasing User's Guide to get a detailed explanation of this functionality. SCOPE & APPLICATION ------------------This article is intended to help users setup hierarchies for the purpose of routing articles to the proper authority for document approval. Purchasing Setup of Approval Hierarchies ----------------------------------------There are two methods to route documents for approval. [1] Approval Hierarchies (uses job/positions) [2] Employee/Supervisor Relationships [1] Approval Hierarchies ======================== Approval Hierarchies are hierarchies that have a JOB/POSITION relationship. Purchasing utilizes jobs and 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 an approval limit, 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 JOB/POSITIONS is defined on the Position Hierarchy form. When this is complete or is changed, the Fill Employee Hierarchy concurrent process 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. PO Navigator -> Setup -> Personnel -> Position Hierarchy Please Note: The Approval Hierarchies described in the example below is a very simple, basic, hierarchy. In the real world - Approval Hierarchies can be very large and complex, but the same operational principles still apply. [2] Employee/Supervisor Relationships ===================================== This type of hierarchy does not use the Approval Hierarchy form, but is defined by the employee /supervisor relationship. The supervisor of an employee is defined on the Assignment zone of the Employee form. If the purchase order raised 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 Please Select a Forward To Employee. SELECTING AN APPROVAL ROUTING METHOD ===================================== There are two forms that determine the route that an approval will take: [1] Financial Options (PO -> Setup -> Options -> Financial -> Human Resources) [2] Document Types (PO -> Setup -> Purchasing Options -> Document Types) [1] Financial Options: ====================== 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 Position Hierarchy is used and when unchecked the Supervisor Hierarchy is used. [2] Document Types: =================== Each Purchasing document has its own set of attributes that are defined on the Document Type form. For this article, we will refer to the Standard PO document. There are two attributes on this form that determine the approval path of the document. [A] Forward Method: =================== This field has two options that apply regardless as to whether you use a Position Hierarchy or a Supervisor Hierarchy. [i] Direct: when set to Direct, the document will pass to the next position or supervisor in the hierarchy who has high enough limits to approve the document. [ii] Hierarchy: when set to Hierarchy, the document will pass to the next person in the hierarchy regardless to whether that position or supervisor has high enough limits to approve. [B] Default Hierarchy: ====================== The Default Hierarchy option will only appear on the Document Type form if the option "Use Approval Hierarchies" is checked on the Human Resources zone on the Financial Options form. The Default Hierarchy field has a LOV. This list is derived from the hierarchies created using the Position Hierarchy form. 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" is checked on the Document Type form -

and this attribute is only enabled if the "Use Approval Hierarchies" is checked. 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 will first be searched for the employee attempting the approval. This default hierarchy is defined on the Document Types form: Responsibility: Purchasing Super User Navigation: Setup -> Purchasing -> Document Types Thus, 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. Alternatively, the checkbox 'Can Change Approval Hierarchies' should be selected on the Document Types form. With this checkbox enabled, the user has the option to specify an alternate approval hierarchy, provided that the user belongs to one or more additional hierarchies. (The Approval Hierarchy list of values in the Document Approval window will only contain the hierarchies that this user belongs to.) If the low-end user is not part of the default hierarchy specified in the Document Types form and chooses to Approve the document, the end result will be a notification to the user stating 'No Approver Found'. A similar scenario of 'No Approver Found' will result if the 'Owner Can Approve' checkbox (on the Document Types form) is disabled and the person attempting to approve the document is not in the Default Hierarchy. When the Approve button is clicked, this setting is validated and enforced; it is at this time that the requisition and purchase order approval workflows will look to the default approval hierarchy, searching for the current approver's position in the hierarchy in order for the next approver in line to be located. EXAMPLES: Approval Hierarchy Setup Example ================================ For the following two examples we will use the following Approval Hierarchy. The name of the hierarchy is "Buyer Approval Hierarchy" User Reports to Approval Limit -------------------------------------------------------------Junior Buyer Senior Buyer 50.00 Senior Buyer Chief Buyer 100.00 Chief Buyer - Unlimited The option "Use Approval Hierarchies" is checked on the Financial Options form. Approval Example One: ===================== On the Document Type form "Forward Method" is set to "Hierarchy" and "Default Hierarchy" is set to "Buyer Approval Hierarchy" Junior Buyer raises a PO which has a total value of 150.00. The PO is then submitted for approval. As J.Buyer does not have a high enough approval limit, the PO is automatically forwarded to S.Buyer because S.Buyer is the next person in the hierarchy S.Buyer responds to the PO that appears in the notification screen. If S.Buyer selects "Approve", the PO is automatically forwarded on to C.Buyer as S.Buyer does not have a high enough approval limit. The PO

appears in the notification screen for C.Buyer where it can be approved or rejected. Approval Example Two: ===================== The "Forward Method" is changed to "Direct" and the "Default Hierarchy" remains unchanged. J.Buyer raises another PO with a total value of 150.00 The PO is then submitted for approval. As neither J.Buyer or S.Buyer have a high enough approval limit, the PO is sent directly to C.Buyer for approval. Employee/Supervisor Relationship Setup Example ============================================== Although J.Buyer reports to S.Buyer for approvals, S.Buyer is not the manager of J.Buyer. Senior Manager is the manager of J.Buyer and Group Manager is the manager of S.Manager. User Is managed by Approval Limit -----------------------------------------------------------------------------Junior Buyer Senior Manager 50.00 Senior Manager Group Manager 100.00 Group Manager - Unlimited The "Use Approval Hierarchy" is now unchecked on the Financial Options form. The "Default Hierarchy" field is now disabled on the Document Type form The "Forward Method" is set to Hierarchy Employee/Supervisor Example One: ================================= Junior Buyer raises a PO which has a total value of 150.00. The PO is then submitted for approval. As J.Buyer does not have a high enough approval limit, the PO is automatically forwarded to S.Manager because S.Manager is J.Buyer's supervisor as defined on the Employee form S.Manager responds to the PO that appears in the notification screen. If S.Manager selects "Approve", the PO is automatically forwarded on to G.Manager as S.Manager does not have a high enough approval limit. The PO appears in the notification screen for G.Manager where it can be approved or rejected. Employee/Supervisor Example Two: ================================ The "Forward Method" is changed to "Direct". J.Buyer raises another PO with a total value of 150.00 The PO is then submitted for approval. As neither J.Buyer or S.Manager have a high enough approval limit, the PO is sent directly to G.Manager because G.Manager is S.Manager's supervisor as defined on the Employee form and S.Manager is J.Buyer's supervisor. Security Hierarchy - Document Security and Access ================================================= 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 which should access to the documents you want to restrict in this manner. (Even if you are using jobs to route documents, you must define positions before you can enable this Security Level.)

The Security Hierarchy is selected from a LOV in the Control zone of the Purchasing Options form (PO -> Navigate -> 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 Type form.) Page 2-8 thru 2-10 of the Rel 11 Purchasing Users Guide provides more detail regarding the effects of Security Level. Alternative Situations ====================== Multiple Employees Tied to One Position: ---------------------------------------Something else that must be considered is one where the application chooses the forward-to person when multiple employees are tied to one position. The application will select the forward-to person based on alphabetical name order. Here is an example to better clarify how the system chooses the next approver name when multiple approvers are assigned to one position: Position: Clerk Employees Assigned: Many Reports To: Vice President, Materials Position: Vice President, Materials Employees Assigned: Dough, John S. Smith, Bob A. In this example, if a clerk chooses the Approve button without entering a forward-to person, and the next position above the clerk is the Vice President of Materials, the document would be routed to John Dough. John Dough is selected because the system will choose the employee assigned to the position in alphabetical order, and since Dough comes before Smith, John Dough is selected. Therefore, unless the clerk selects a specific person to forward the document to, the document will always be routed to the first person alphabetically assigned to the position. Multiple Logins Tied to One Employee: ------------------------------------In Release 10.7, it was possible to have multiple logins tied to a single employee without causing problems; however, this is not the case with Releases 11 and higher. When a second login is created and tied to an employee name already in use by another login, a breakdown will occur in the workflow notification processing. If an employee is tied to duplicate logins, there will be no notifications in the Notifications Summary window for the employee in question. Currently, the following error occurs in the System Administrator responsibility when attempting to assign an alreadyAssigned employee name to a second login: APP-09999: This employee is already assigned to user USERNAME. Employees assigned to more than one user may cause errors in the applications.

To check directory services data model for all know problems run the script $FND_TOP/sql/wfdirchk.sql as stated below: cd $FND_TOP/sql sqlplus <usr>/<passwd>@db @wfdirchk.sql Troubleshooting =============== Use the 'Oracle Purchasing Employee Approval Setup Diagnostic Script', Note: 167457.1 to troubleshoot employee approval setup problems. The purpose of this script is to verify that a User is setup for approving Oracle purchasing documents for a given Operating Unit.