Setup - Approval Hierarchies in Oracle Purchasing

Purchasing setup of approval hierarchies

There are two most commonly known methods to route documents for approval.
1. Approval Hierarchies (uses position hierarchies)
2. Employee/Supervisor Relationships (use employee/supervisor relationship)
* Third method of Advanced Approval Support for Requisitions (Release 12 use integration with Oracle
Approvals Management) . However in this article, focus here is set on above two most commonly used
methods.
1. 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. When this 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. If you are using Shared HR navigate, Purchasing: Setup:
Personnel: Position Hierarchy. Otherwise, if you are using a full install of HR then navigate, Human
Resources: Work Structures: Position: Hierarchy.
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 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 jobassigned 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 (Purchasing: Setup: Organizations: Financial Options)
2. Document Types (Purchasing: Setup: 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 Employee/Supervisor relationship (i.e.
Jobs) is used.
2. Document Types

There are three attributes on this form that determine the approval path of the document:
a) Forward Method
b) Default Hierarchy
c) Transaction Type (for Requisitions only)
* Each of these 3 options are described in some details below
a) Forward Method
This field has two options that apply regardless as to whether you use a Position 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 to whether that
position or supervisor has enough approval authority 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 screen. 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:
Purchasing: 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 (i.e. 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.
c) Transaction Type
For requisitions only, select the Approval Transaction Type. If you have implemented Oracle Approvals
Management, this selection associates the transaction type with the requisition document type. Leave
the field blank to use the standard Oracle Purchasing approval logic
Posted by OracleOnDemand at 2:04 PM