Cloud Procurement Approval Management

Cloud Procurement offers a new interface defining approval workflow for Requisitions, Purchase Documents (Order, Blanket, Contract) and Supplier Management. Approval rules are managed in a user friendly interface that integrates back-end Business Process Management (BPM) while keeping a logical and complete setup in front of the user. While relatively simple to define rules in Approval Management, it also supports comprehensive rule sets for more complex business process needs.

Key Components:

• Procurement Approval Rules Management
  • Setup approval rules with conditions and actions
• Approval Management extensions (AMX)
  • Perform routing for the business document in friendly user interface
• Business Process Management (BPM)
  • Application that allows users to access assigned tasks and perform actions (Approve, Reject, Request Information)
  • Email supported actions
• Human Capital Management
  • Defines person, position, jobs, levels and supervisor hierarchy

AMX contains a substantial list of attributes that can be applied to Rule Conditions for the various purchasing documents. (Complete list contained in Oracle Whitepaper below).

The Simple Approach

Every business operation establishes a Delegation of Authority where people, budget owners, project owners, jobs or positions are delegated an approval limit. These approval limits can be as simple as a single limit regardless of document type or an organizational condition such as Business Unit. It can also be complex where different rule sets are invoked based on attributes found within the document seeking approval. The following example utilizes minimal HR setup where each user is assigned a Job Name and Supervisor then each Job is assigned a Level.

Example Requisition Workflow construction:

Sample Requisition Approval Authority Chart

Using the above approval example, the requester creates a requisition in Business Unit 1 for total amount $6,000 and submits for approval. The requester’s assigned job name is “Individual” with Level 1 authority. Workflow assesses the requester reporting hierarchy and determines that approval requires Level 3 or above. Resulting Workflow routing contains requester’s Supervisor and Manager 1 in serial flow.

Example Business Unit 1 Requisition Approval Rules:

Example Purchase Order Workflow construction:

Sample Purchase Order Approval Authority Chart

Using the above approval example, Buyer creates Purchase Order from the example requisition for $6,000 in Business Unit 1. Purchase Order is auto-approved on Buyer submittal as the document is less than $75K limit.

Example Business Unit 1 Purchase Order Approval Rules:

Approval Rules application

The AMX application provides predefined Approval Rule Sets targeted for different stages, voting methods and participants within the workflow process.

Each Rule Set allows for multiple rules containing Conditions that identify target documents based on attributes and Actions for the qualifying documents.

Adding Complexity

One area of complexity involves defining approval for document changes. Changes to a procurement document are classified as ‘Internal’ or ‘External’. Internal changes have no impact to the value or the supply base such as altered charge accounts, changed Purchase Category or other internal focused changes. External changes would require communication to suppliers such as value change, delivery date change or other changes that need to be communicated to external parties. Using the attribute Change Order Type (Internal/External) along with other relevant attributes such as New Document Total or Change in Document Ordered Amount can be defined in conditions that determine approval requirements. Example of Change Document Rules:

Lessons Learned

• Develop comprehensive workflow process maps that identifies routing, decisions and document attributes that ensure two paths forward from every decision. Create separate process maps for each document type (Requisition, Purchase Order, Purchase Agreement, etc) and approval type (New vs. Changed Document).
• Within a rule set, Rules with conditions that define a specific group of document attributes MUST have a corresponding rule containing actions for documents that do not qualify (IF-THEN-ELSE). In the example below, Rule 2 exists to tell Workflow what to do with documents that do not meet the conditions of Rule 1. In the absence of Rule 2 the requisition would fail to create approval workflow routing and generate an error with automatic Reject action.

• Whenever possible, avoid variations in approval limits within a Business Unit for the same document type. Example Job Level 4 Limit $50K for Operational Expense but $25K for Capital Expense. While possible to create such a rule, it increases complexity for setup, maintenance and user understanding. Ask if it really makes sense for Executive Management to have conditionally varied authority limits.
• Avoid rule conditions for a named Participant. Example: Route to Jane when document Project Task equals 12345. Possible solutions include use of Approval Groups or attributes that dynamically reference to a Participant such as ‘Project Task Owner’.
• Always seek the simplest/fewest set of rules.

Resources

• Setting Up Document Approvals Oracle Fusion Procurement
  • Procurement Approvals Whitepaper – Release 11+
• Implementing Oracle Cloud Procurement
  • HTML
  • PDF
• Example Approval Workflow Details
  • Sample Purchasing Approval Setup