2.
AME – What is it?
i. AME is a simple to
use Rules Engine for Defining Approval Policy
ii. AME is generic
engine can be used where no integration currently exist, even with non EBS modules
iii. Standardizing on
one engine reduces costs for customer as well as consulting since only one set
of skills required
iv. None or only
minimal coding required to setup rules
3.
AME – When can it be used?
a. AME can be used to
derive lists of approvers based on user defined rules and maintain a history of
approvers statuses when: -
i. Transferring
employees from one division/cost centre to another
ii. Authorizing
expenses
iii. Paying invoices
iv. Approval of
Purchase Requisition
v. Much more – review
EBS Module Integration List
4.
AME – Module Integration List
i. 11i8/9 11i10
b. E-Records (ERES)
User Management iSupplier
c. Quoting ODM – BOM
Sourcing
d. Accounts Payable
ODM – Engineering iProcurement
e. Credit Management
ODM – Inventory R12
f. iExpenses ODM –
Quality Mgt E-Tax
g. Lease Management
ODM – Receiving Grants
h. iRecruitment ODM –
WIP Core Pay
i. Training
Administration (SS) AR – Credit Memo Public Sector
j. Self Service HR
(4.1) Internal Controls Mgr Proposals
k. OPM – Inventory
OTA – Learner UI Distribution
l. OPM - New Product
Dev OTA – Manager UI GL-Journals
m. OPM – Process
Execution iAssets (Transfer) Account Planning
n. OPM – Quality Mgt.
Deal Registration Service Contracts
o. Oracle Partners
Mgt Referral Management Collections
p. AR – Credit Mgt PO
- Requisitions Incentive Comp
5.
Business Processes for Transactions and approvals Create Transaction Manage Approvals
and Notifications
a. Approve
b. Reject
c. Return
6.
Submit for Approval Update when approved 1 3 2 4
7.
Approval Policies
– AME Rules Approval
Policies translate to rules in AME and are made up of the following components:
if and then Transaction Category In {Salary} Salary Increase Pct > 15
require approvals up to the first two superiors Rule Conditions Action Types
Attributes require post approval from CIO
8.
Setup Details – Profile Options
i. AME
responsibilities can be directly assigned in 11i.AME.A. But in 11i.AME.B &
R12 &
higher, the
responsibilities are assigned through roles.
ii. AME: Installed
– Set this profile value to ‘Yes’ at required application level.
iii. HR:Defer
Update After Approval: Set this profile value to ‘No’ to avoid the
status ‘Pending Approval’ after transactions’ approval.
iv. AME: Append to
List option on Approvers region – To control the requesters/initiators to append
approvers to the approval list. If set to the value ‘No’ would not allow
the users to append the list.
9.
AME – How to assign the role?
a. Login as ‘System
Administrator’ (not a responsibility) & navigate to ‘User Management
>
Users > Query the
user and click Update > Search & Add the AM Admin roles as shown below
10.
AME – How to grant transaction type access to users?
a. AME restricts
access to transaction types using Data Security. Grant users access to the transaction
types using the Grants page.
b. Login as ‘Functional
Administrator’ responsibility & click on ‘Create Grant’
11.
AME – How to grant transaction type access to users?
12.
Setup Details – Configuration Variables
i. Important
configuration variables are shown below:
ii. Please note the
values for these variables can vary for each transaction type.
13.
Setup Details – New Transaction Type
a. A new transaction
type can be created using ‘Approvals Management Administrator’
responsibility
14.
Setup Details – New Transaction Type
a. There are 4 steps
in creating a new transaction type
b. The new
transaction type can be created with different item classes like Header, Line
Item, Cost Center, Project, etc depending on the requirement
15.
Setup Details – New Transaction Type
a. There are 11
mandatory attributes whose values can be derived using SQL queries
16.
Setup Details – Approval Process
a. The approval
process for the newly created transaction type can be setup using ‘Approvals Management
Business Analyst’ responsibility.
17.
Setup Details – Attribute
a. Attributes are the
base element for an AME Rule. Attribute values are retrieved from the EBS Applications
database
b. AME is seeded with
attributes relevant to the transaction type and the user can create new attributes
in AME for use in AME rule
18.
Setup Details – Condition
a. Conditions
identify values and value ranges for some or all of the attributes available
b. AME rules refer to
these conditions to determine if a particular rule is applicable for the specific
document (requisition) being approved
c. There are 2 types
of conditions – Regular & List Modifiers
19.
Setup Details – Action Type
a. An action type is
a collection of actions having similar functionality
b. Every action
belongs to an action type. Action types are enabled or disabled for a
particular transaction type
c. Voting method (or
regime) decides how the responses to the action types are treated
20.
Setup Details – Approver Group
a. It is an optional
setup. Required only when additional approvers are required for particular conditions
The rules defined for
the transaction can be based on Approver Groups, Jobs defined in HR setup, or
Positions defined in HR setup Additional approvers are added here
21.
Setup Details – Rule
Rules specify
approvers to be included in the approval list under specific conditions Rule category
can be either approver or FYI
22.
Setup Details – Rule
a. Actions are added
from action type associated with the transaction type
23.
Setup Details – Test Workbench
a. This is used to
determine which AME rules apply to a specific document (requisition)
24.
Test cases with values for various attributes can be saved for repeated use
Setup
Details – Test Workbench
a. For real
transaction test, requisition’s header ID need to be entered as transaction ID.
This would pull values for all the attributes
25.
Setup Details – Test Workbench
a. Final approver
list is displayed along with the applicable rules
26.
Setup Report
a. A setup report can
be run from Business Analyst’s dashboard which would show all the attributes,
conditions, rules used in the transaction type.
b. A sample output of
the report is attached below
27.
Implementation Guidelines
i. Read the
Implementation Guide – never go in blind, you will make mistakes
ii. Some SQL and EBS
entities knowledge required if additional Attributes or Dynamic Approval Groups
needed
iii. Design approval
matrix / decision tree on paper and use that as basis for your rules
iv. Don’t create
custom Action Types unless you really have to
v. If DFF’s need to
be used in AME, then custom attributes need to be created using SQL query
vi. Purge transaction
data using the concurrent program ‘Approvals Management Transaction Data Purge’
vii. In 11.5.10 AME
supports only employee-supervisor hierarchy. But in R12, position
hierarchy & FYI
notifications are supported.
28.
Implementation Guidelines – Approval Decision Tree
i. Model the decision
tree based on the approval rules.
ii. Path from the
root node to a leaf node represents a rule
29.
Error Messages
i. Approval List
could not be generated. Please contact your System Administrator to review AME
rules setup.
ii. The procedure
getNextPosition could not find parent position for : HR Positions:
MM400.Materials
Manager
30.
Limitations
a. Terminations (of
the initiators) are not handled efficiently though AME would rebuild the chain
of approval after each approval
b. Not possible to
create custom AME responsibilities because of RBAC limitations other than the 2
seeded responsibilities – ‘Approvals Management Administrator', 'Approvals
Management Business Analyst'
c. It is not possible
to have ‘Notification TimeOuts with Reminders’ within AME.
31.
References
i. How to Create the
Approval Transaction Type for AME.B or higher ( Metalink Note: 420387.1 )
ii. How To Setup And
Use AME For Purchase Requisition Approvals ( Metalink Note: 434143.1 )
iii. How To Diagnose
Issues in Building The Requisition Approval List ( Metalink Note: 412833.1 )
iv. How to Create the
Approval Transaction Type for AME.A ( Metalink Note: 420381.1 )
v. Frequently asked
Questions on AME 11i ( Metalink Note: 431815.1 )
vi. 11.5.10 FAQ for
Approvals Management (AME) Integration For iProcurement and
Purchasing ( Metalink
Note: 293315.1 )
32.
Case Study
i. Requirements /
Approval Policies:
ii. If the total
requisition value is more than 25,000 USD, then it requires approval from 2
positions above the
requestor. If it is less than 25,000 USD, then it can be approved by the requestor
himself if he has enough approval authority
iii. If any of the
requisition line has an item category ‘COMPUTER.PC’, then it needs to be approved
by a specific user
iv. If any of the
line item has an item category ‘COMPUTER.MISC’, then ‘IT Director’ position needs
to be notified
v. Let us now see in the application,
how these policies are modeled
No comments:
Post a Comment