Bookmark Fixed font Go to End

Doc ID: Note:134947.1 Content Type: TEXT/PLAIN

Subject: Purchasing Setup of Approval Creation Date: 05-FEB-2001
Hierarchies Last Revision
22-DEC-2004
Type: TROUBLESHOOTING Date:
Status: PUBLISHED
PURPOSE
-------

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 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 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

Postion: 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 already-
Assigned 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 aproval 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.
RELATED DOCUMENTS
-----------------
Oracle Purchasing User's Guide for Release 11, CR:216434
Oracle Purchasing User's Guide for Release 11i, CR:276301
Oracle Purchasing Employee Approval Setup Diagnostic Script, Note:167457.1
.