Requisition Approval Using AME

Requisition Approval using AME An Oracle White Paper March 2008

Requisition Approval using AME

Introduction Introduction ....................... ................................... ..................... ..................... ....................... ....................... ....................... .................... ............. .... 4 Requisition Requisition Approval Approval Process Process in AME............................... AME.......................................... ....................... ................ .... 5 Approval Approval Routing Chooser Chooser in Requisition Approval Approval Workflow: Workflow: ..... 6 AME Approval Approval List Routing: Routing: ....................... .................................. ...................... ....................... .................... ........ 6 What AME Does and Does not do? ...................... ................................. ...................... ....................... .................. ...... 8 W hat AME Does?.............. Does?.......................... ....................... ..................... ..................... ....................... ....................... ................... ........ 8 What AME Does Not Do? ...................... ................................. ...................... ...................... ....................... .................. ...... 8 Setup in Core Purchasing:.................... Purchasing:.............................. ...................... ....................... ....................... ....................... ............... .... 9 AME-A AME A Concepts............ Concepts....................... ....................... ...................... ..................... ...................... ....................... ...................... ............. ... 10 A ME- B Concepts................ Concepts............................ ...................... ..................... ....................... ....................... ....................... ................... ....... 10 OAF Approach: Approach: ....................... .................................. ..................... ...................... ....................... ....................... ...................... ............ 10 Administrat Admini strator or Dashboard: Dashboard: ....................... ................................. ...................... ....................... ....................... ............10 10 Business Analyst Analyst Dashboard: Dashboard: ...................... ................................ ..................... ....................... .................... ........ 11 Functional unctional Components:............... Components:.......................... ..................... ...................... ....................... ....................... ..................... ......... 12 Transactio Trans action n Type: ...................... ................................. ..................... ...................... ....................... ....................... ..................... .........13 13 Attributes: Attributes: ...................... .................................. ..................... ..................... ....................... ....................... ....................... .................... ............. 14 Conditions:......... Conditions:..................... ....................... ..................... ...................... ....................... ....................... ....................... .................... ............. 15 Actions:...... Actions:.................. ....................... ....................... ..................... ..................... ....................... ....................... ..................... .................... ...........16 16 Pre-defined Pre-defined Action Action Types ....................... ................................ ..................... ....................... ....................... ................ 16 Approver Appr over Group:................................ Group:.......................................... ...................... ....................... ....................... ....................... ...........17 17 Approver Appr over Lists:................. Lists:............................. ...................... ..................... ....................... ....................... ....................... ................... ....... 17 Rules: ....................... .................................. ....................... ....................... ....................... ....................... ...................... ..................... ................. ....... 19 Item Class:................ Class:............................ ....................... ..................... ..................... ....................... ....................... ..................... ................. ....... 22 Configuratio Configuration n Variables: Variables: ...................... ................................ ...................... ....................... ....................... ..................... ......... 23 General General Configuratio Configuration n Variables:..................... Variables:................................ ....................... ....................... ................. ...... 23 Parallelizat Parallelization ion Concepts: Concepts: ...................... ................................ ...................... ....................... ....................... ....................... ............... 24 Voting Voti ng Methods/Regim Methods/Regimes: es: ...................... ................................ ..................... ....................... ....................... ................. ...... 24 Serial................................. Serial............................................ ..................... ..................... ....................... ....................... ..................... ................. ....... 24 Consensus.............. Consensus.......................... ....................... ..................... ..................... ....................... ....................... ....................... ............... ... 24 First Responder Responder Wins ...................... ................................. ..................... ...................... ....................... ..................... .......... 24 Order-Numbe Order-Numberr ...................... ................................. ..................... ...................... ....................... ...................... ..................... .......... 25 Diagnostics: Diagnostics:........... ...................... ....................... ..................... ..................... ....................... ....................... ....................... ..................... ............. ... 25 AME in R12: ...................... ................................. ..................... ...................... ....................... ....................... ....................... .................... ............. 25 References References : ....................... .................................. .................... ..................... ....................... ....................... ....................... ..................... ............. ... 26 Test Case Scenario (Demo in Viewlets): .......................... ............ ........................... ......................... ............... ... 26 Employee Employee : ....................... .................................. ..................... ..................... ....................... ....................... ....................... ..................... .........26 26 Attribute Attr ibute : ....................... ................................... ..................... ..................... ....................... ....................... ....................... .................... ............. 26

Requisition Approval using AME AME

Page 2

Condition : ...................................................................................................27 Rule: ..............................................................................................................27 Acknowledgement........................................................................................... 28


Page 3

INTRODUCTION

AME provides a central business rules repository and a common execution engine, integrated with Oracle Workflow, to manage approvals for the business processes delivered within the Oracle eBusiness Suite. Oracle Approvals Management (AME) is available for Purchasing and iProcurement from Family Pack 'J' (11.5.10) onwards. Current limitation in 11.5.10.2 is, AME is integrated only with Purchasing Requisitions when using Employee/Supervisor relationships. AME does not support Position Hierarchies nor Purchase Order Approvals workflow at this time. However in R12 Position Hierarchy is supported.

FEATURES

•

•

•

•

•

•

Provide accountability and integrity - for key business transactions Enable a consistent method of approval policy definition across the whole of the eBusiness suite Allow customer to define comprehensive approval policies without resorting to code Rules engine able to handle organizational structure changes as they occur in the approval flow Approval rules can be dated and prioritized to reflect changes in organizational requirements Centralize storage of approval policies, improves audit and accountability


Page 4

REQUISITION APPROVAL PROCESS IN AME

Requestor creats a Requisition and submits it for Approval. REQAPPRV workflow checks whether AME is used for Approval or normal approval process is used. If AME is used for approval, a call is made from the workflow to AME Engine. AME engine will evaluate the applicable rules and generates an approver list. It also returns the next approver. A notification now goes to the next approver. Approvers can Approve, Reject or Return. REQAPPRV workflow repeats this process until no more approvers are found (i.e. Requisition gets Approved).


Page 5

Approval Routing Chooser in Requisition Approval Workflow:

This process in Requisition Approval Workflow is used to choose the route it has to follow to get the approvers. There are two routes AME Approval list route or normal Approval list route. AME Approval List Routing:


Page 6

The calling application (Requisition Approval) calls AME from Workflow to get next approver. Firstly the Requisition Approval workflow (REQAPPRV) validates the setup for this document type / sub-type (AME_TRANSACTION_TYPE from table PO_DOCUMENT_TYPES) and sets the workflow attribute (IS_AME_APPROVAL) accordingly. To retrieve the next approver, the workflow makes a call to procurement PL/SQL procedure, which in turn makes a call to AME (using API getNextApprover) to find the right values. The results (or 'No Approver Found' warning) are returned, and placed into the workflow attributes, for onward processing. When workflow responses are processed, after validation and initial processing, the PL/SQL calls again go to AME API's to update the approver list and return the next approver. AME evaluates applicable rules and generates an approver list. It then returns the next approver. The calling application notifies next approver. The calling application deals with approver’s response Approve, Reject or Return and sends response to AME.The calling application repeats these steps until no more approvers are found. The function called here is “Get Next Approver Using AME”.

Function: POR_AME_APPROVAL_LIST_WF1S.GET_NEXT_APPROVER This function generates the list of approvers and from that it gets the next approver to whom Notification is to be sent. Most of the processing between iProcurement and AME is done in PL/SQL package POR_AME_APPROVAL_LIST_WF1S (file: POXAME1B.pls). Package POR_AME_APPROVAL_LIST_WF1S in file: POXAME1B.pls Package POR_AME_APPROVAL_LIST in file: POXAPL2B.pls Package REQAPPROVAL_INIT1 in file: POXWPA1B.pls Package PO_APPROVALLIST_S1 in file: POXAPL1B.pls Package PO_AME_SETUP_PVT in file: POXAMESB.pls (Release 12.x) Package AME_API in file: ameeapin.pkb (and later ameeapi2.pkb) Package AME_ENGINE in file: ameeengi.pkb Workflow REQAPPRV in file: poxwfrqa.wft


Page 7

WHAT AME DOES AND DOES NOT DO? What AME Does? •

•

Provides API’s for products to interface with Accepts a Transaction ID and Transaction Type

•

Generates a List of Approvers based on the defined Rules and Setup

•

Returns the WF Role and reference for the next approver

•

Provides various functionality which products can choose to implement (eg Parallel Approvals, FYI Notifications)

What AME Does Not Do? •

•

Decide what AME functionality products choose to implement (eg Parallel Approvals, FYI Notifications) Sending and receiving of notifications


Page 8

SETUP IN CORE PURCHASING:

If Approval transaction type is given a value, then Requisition will use AME for approvals. For Purchase Requisition, the value is “PURCHASE_REQ” For Internal Requisition, the value is “INTERNAL_REQ” These are seeded values defined in the table “ame_calling_apps”. If Approval transaction type is Blank, AME will not be used for approvals.


Page 9

AME-A CONCEPTS

AME-A is the first version on AME. AME-A provides a single web page for administration and setup. So, both the AME Business Analyst and Administrator will have the rights to use the same responsibility. There are seven tabs in the Approvals Management page. They are Attributes, Conditions, Actions, Groups, Rules, Test and Admin.These will be covered later on in the whitepaper document. Users have to select the transaction type and proceed with either setup or testing or administration. AME- B CONCEPTS OAF Approach:

There are two entry points to AME. These are role based. One for Business Analyst and another for Administrator. •

•

Administrator Dashboard. Business Analyst Dashboard.

Administrator Dashboard:

This is for Administrator. This dashboard allows the administrator to modify the runtime characteristics of AME as well as review error logs and define new transaction types. For this release the admin dashboard more or less mimics the features of the Admin Tab in the old UI but with the addition of the AME Setup Diagnostic report. Previously the user required apps account privileges to obtain this report. Transaction types are defined within this screen and represent whole business flows to which approval rules can be attached. These flows may represent an overall process such as iExpenses or can be more granular where it defines sub flows within an overall process. Typically the Oracle application teams, that require integration to AME, define the transaction type and not the customer.


Page 10

Business Analyst Dashboard:

This is for Business Analyst. This dashboard is aimed toward the business analyst, the person typically tasked with interpreting an organization approval policy and entering and maintaining them within AME. The process steps are split into three main groupings, Setup, Rules and Test. A content container is provided container detailing these main grouping as well as providing launch points to the various AME objects they interact with. Recently touched transaction types to which the user has access to are displayed within the dashboard as well as rules that have been modified, are due to come into effect or expire.


Page 11

Within setup the user / Oracle Dev teams, would define the objects that are required before approval rules can be created.

FUNCTIONAL COMPONENTS: •

Transaction Type

•

Attributes

•

Condition

•

Action

•

Approver Group

•

Rules


Page 12

Transaction Type:

Transaction Type is the root entity under which all the approval policies and related setup for a particular transaction flow are grouped together.

Transaction Types are seed by the individual Product Teams. For example, •

Purchase Requisition Approval.

•

Internal Requisition Approval.

•

Creation or Updating of an Vacancy.

•

SSHR flow like changing a Manager of an Employee.


Page 13

Attributes:

An attribute in AME is an object which holds a business fact. For example, •

Requisition Total.

•

Item UOM.

Attributes are of 5 data types – Number, String, Currency, Date and Boolean.Attributes can be Static or Dynamic.Attributes can be linked to an Approver.Attributes can be based on a value set. Attributes belong to a certain item class. Attributes are categorized in one of the following category – Mandatory, Required and Others.


Page 14

Conditions:

Conditions in AME are statements against which the business facts are evaluated against for a transaction. For example, •

•

TOTAL_REQ_AMOUNT > 5,000 COST_CENTER in {YAX1, YEC1}

All Conditiions defined are based on Attributes.Conditions are of 3 types – Ordinary & Exception (Regular), List Modification (List Modifiers). List Modifiers are not transaction type specific. List Modifiers are like ‘If any approver is’, ‘If final approver is’ and are used for List Modification Actions.


Page 15

Actions:

An Action in AME is an instruction to AME to do something when all the conditions are evaluated as true for a transaction. For example, 1) Get Approval from 2 superiors 2) Get Approval from FINANCE group 3) Substitute John as approver, wherever Tim exists as an approver. Actions are grouped into Action Type. All the actions under a particular Action Type generate the same type of Approver. Action Types can be ordered within a transaction type. Action Types have sublist mode. They can have one of the three voting Regime (serial, consensus, first-responder-wins) Pre-defined Action Types

Chain of Authority (List Creation/Exception) Supervisory/Job Level based •

Absolute Job Level

•

Relative Job Level

•

Manager then Final

•

Final Approver Only

•

Supervisory Level

•

Dual Chain of Authority

•

Line-Item Job-Level (deprecated)

Position Based •

HR Position Level

•

HR Position

Group Based •

Approval Group Chain of Authority

You can create your own Action Types, however you will need to write your own PL/SQL handlers to tell AME how to handle this Action Type. This is not an easy task. Anyhow, AME Development has seeded an extensive list of Action Types to


Page 16

be used, so there should no need to do this. If there were a Business Case for a new Action Type, it would be best to contact the AME Development team. Approver Group:

An Approver Group is a ordered set of one or more approver; Usually contains those approvers who do not fall under a certain hierarchy. For example, For certain in a company, for certain chemical items procurement, R&D department manager needs to approve the Requisition. But there exists no relationship between preparer and R&D Manager. This relationship can be defined using Approver group. Approver Lists:

A complete list of approvers generated by AME for a transaction is called as its approver list. The initial approver list may not be same as the final approver list when the approval process completes.An approver list can be divided into 3 sub parts (or sub-lists) – they are ‘pre’, ‘chain-of-authority’ and ‘post’ A chain-of-authority (COA) is the sub list, which is generated using one of the chain of authority/list creation based action type (like supervisory action type). ‘Pre’ and ‘Post’ sub lists are usually approvers generated by a group. Step 1: Create New Approver Group:


Page 17

This is the first page for Approver Group creation. An unique name for the Approver Group is specified here along with Description Order Number in which this Approver Group needs to be given preference, Voting method & Usage Type. Usage type is of two types. •

Static

•

Dynamic.

If Usage Type is given as dynamic, a query needs to be specified in Query field that will be executed to generate approvers. If Usage type is Static, Approvers are manually added which can be seen in the next picture.

Approver Type can be FND Users, Nested Group, HR People, HR Positions & Position Control Roles. Order Number decides to which approver, Requisition should be sent first. Note: Upto 11.5.10.2, Voting method should be Serial for Requisition Transaction types.


Page 18

Rules:

Approval Policies translates into a Rule in AME and are made up of the following components

•

•

•

•

Rules belong to a certain item class Rules can be dated (can specify the life span of it). This is called as Rule Usage Rules can be defined for future (future dated) Multiple conditions have a logical AND between them when associated to a rule

Step 1: (Enter Rule Details)


Page 19

This is the first page for rule creation. An unique name for the rule is specified here along with Rule type Item Class & Effective dates. Step 2: (Add Conditions)

Conditions defined for the transaction type is linked to the rule here. On clicking “Add Condition”, the following page is displayed.


Page 20

The required condition is selected here .

Step 3: (Add Actions)

Actions defined are linked to the Rule in this page. Action type is selected from the combo and appropriate Action is also selected.


Page 21

Step 4: (Review)

This is the Review page that shows that the Conditions and Action Type linked to the Rule. On clicking Finish, the Rule will be created for the corresponding transaction type specified. Item Class:

A grouping of certain info about a transaction constitutes to a class. Or An item class aggregates a certain type of items/information that a transaction can have. For example, Line Items of a transaction can be categorized into an item class called as ‘line-item’ Cost Center can be another categorization of an item class •

Header (default – always exists)

•

Line


Page 22

Configuration Variables:

A configuration variable is a parameter that controls a certain behaviour within AME. For example, adminApprover – The user to who should be notified in the event of an error. allowFyiNotification – whether to allow generating of approvers with FYI category.

They work similar to FND Profiles in Applications (in the fact that they override each other at different levels). They are delivered at the following levels: 4) Global (default) 5) Transaction Type General Configuration Variables: •

adminApprover

•

allowAllApproverTypes

•

allowAllItemClassRules

•

allowFyiNotifications

•

productionFunctionality

•

repeatedApprovers


Page 23

•

forwardingBehaviour

•

rulePriorityModes

•

purgeFrequency

•

currencyConversionWindow

•

distributedEnvironment

PARALLELIZATION CONCEPTS:

Parallelization is the process of sending notifications and getting approval response from more than one approver at a time.The parallelization is maintained internally in AME via an approval tree and parallelization can be done at 6 levels in this tree. For all practical purposes, we can assume the parallelization can be done at the following levels – Item Class, Sub-list, Action Type and Group/Chain.

Note: Requisition Approval does not support Parallelization upto 11.5.10.2. However, from R12, parallelization is supported. Voting Methods/Regimes:

Voting method in AME determines in what order the notifications are to be sent to approvers and how the approver responses should be tackled. AME provides the voting methods for action-types and approver groups. The following 4 voting methods •

Serial

•

Consensus

•

First Responder Wins

•

Order-number

Serial

Sent out 1 at a time. All approvers must Respond Consensus

Sent to all approvers at once. All approvers must respond. First Responder Wins

Sent to all approvers at once. Only 1 approver needs to respond.


Page 24

Order-Number

You can manually set the Order in which approvers receive their notifications.

For example: A1, B1, C2, D3, E3 The order would be as follows 1st:

A and B

2nd:

C

3rd:

D and E

All approvers must Respond

Note: Requisition Approval supports only Serial Method.

DIAGNOSTICS: •

•

•

•

Note 361880.1 - Oracle Purchasing Approval Data Collection Test Note 224583.1 - iProcurement Requisition Approval Workflow Status Activity Test Note 287255.1 - Approvals Management Reporting Utility Support Tool Note 338508.1 - Error "Oracle Approvals Management has found parallelization configuration..."

AME IN R12:

In R12, following are the main features implemented in Requisition Approval. Position hierarchy support - Prior to R12, only employee - supervisor hierarchy was used in AME. In R12, customers can configure position hierarchy approver group for Requsition Approvals. Customers who use position hierarchy for their regular approval process are greatly benefitted by this. Parallel approval support -Requisition approvals with AME integration supports parallel approvals. This means send parallel notifications (notify all members of the group at the same time). Support for FYI Notifications - AME can now send FYI Notifications to required persons.


Page 25

REFERENCES :

•

•

http://hcmwiki.uk.oracle.com/ame/index.php/Main_Page Note.428552.1 How To Diagnose Issues With Approvals Management Engine (AME) In Procurement

TEST CASE SCENARIO (DEMO IN VIEWLETS):

Employee :

Created three employees. •

EMPLOYEE BYR

•

EMPLOYEE APR

•

EMPLOYEE MGR

EMPLOYEE BYR reports to EMPLOYEE APR. EMPLOYEE APR reports to EMPLOYEE MGR.

Attribute :

Created one attribute. Demo_Requisition_total. This will accommodate the Requisition’s total value. Name

DEMO_REQUISITION_TOTAL

Item Class

Header

Description

RequisitionTotal

Data Type

Currency

Approver Type

Usage Type

None Dynamic

Value Set Category

Action Types Value

Others None The following query is used :


Page 26

SELECT nvl(SUM(decode(order_type_lookup_code, 'RATE', amount, 'FIXED PRICE', amount, quantity * unit_price)), 0), po_ame_setup_pvt.get_function_currency(max(requisition_header_id)), po_ame_setup_pvt.get_rate_type(max(requisition_header_id)) from po_requisition_lines_all where requisition_header_id = po_ame_setup_pvt.get_new_req_header_id(:transactionId) and nvl(cancel_flag, 'N') ='N' and nvl(modified_by_agent_flag, 'N') = 'N'

Condition :

Created one condition.

Condition Type

Ordinary

Item Class

Header

Attribute Name

Data Type

DEMO_REQUISITION_TOTAL Currency

Condition DEMO_REQUISITION_TOTAL is greater than 10000 and less than or equal to 50000,USD

All the rules will be tested based on the above attribute and condition. Rule:

Name

Demo Rule

Rule Type

List Creation

Item Class

Header

Start Date

18-Oct-2007

End Date

31-Dec-4712

Priority

1

Condition DEMO_REQUISITION_TOTAL is greater than 10000 and less than or equal to 50000,USD Action Type

Action type will be changed for each scenario

Following action types are covered in the Viewlets:


Page 27

Action Type:

Supervisory Level

Action :

Require approvals upto the first superior.

Action Type:

Supervisory Level

Action:

Require approvals upto the first three superiors.

Action Type:

Manager then final approver.

Action:

The final approver must at least have job level 2.

Action Type:

Manager then final approver.

Action:

The final approver must at least have job level 1.

Action Type:

Final approver only.

Action:

The final approver must at most have job level 2.

Action Type:

Approval group - Chain of authority

Approvers:

Employee Byr , Employee Apr, Employee Mgr.

Action Type:

Approval group - Chain of authority

Approvers:

Employee Byr , Employee Mgr.

ACKNOWLEDGEMENT

I wish to record my sincere appreciation towards: Clarina Allen and Varkey Joseph from Procurement Support team for reviewing this whitepaper and for making it complete with their feedback. Thanks to Varkey Joseph for providing guidance at various situations. I am grateful to my manager Chandu Tadanki for his constant encouragement and support.


Page 28

Requisition Approval using AME May 2008 Author: Selvan Jayakumar

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2007, Oracle. All rights reserved. This document is provided for information pur poses only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Requisition Approval Using AME

Recommend Documents