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
Subscribe to:
Post Comments (Atom)
Please enter your email address to subscribe
You won't repent doing this!
hi
ReplyDeletethanks for providing useful info post somemore regarding po,inv modules
Hi,
ReplyDeletePlease accept my wishes for your blog. These have been some very useful posts.
I guess another way to make people understand is by first telling all the basic set up in a module and then showing the corrosponding transactions that the setups done earlier, enable.
I'm looking forward to see more posts on your blog.
Thanks
Nimesh
Hi Nimesh,
ReplyDeleteThanks for your encouragement. Shall surely try to put in some notes on setups.
Actually, I am focusing on posting short articles on different topics so that it remains short enough and not too short too !! :)
Do let me know if you want me to work and post on any specific topics as well.
Regards,
SAM
Hi Sam,
ReplyDeleteReally very thanks for the posts...its really very helpful. If possble try to post the setups steps in sequence on PO and OM. It will be very useful for a beginer like me in oracle apps. Though I am not new to ERP, im new to Oracle apps.