1

Technical Architecture of Oracle Approvals

Management

1. Abstract
This document provides technical overview of Oracle Approvals Management (AME) deals with
architecture, key features and Workflow business rules to control approvals process.
The process design of AME results in a more predictable, mature and defect-free performance
leading to a reduction in the development cycle time.

This document also provides how AME can be utilized to create both simple and complex
business cases involving the approval of Oracle Payables (AP) invoices. It also will discuss the
basic components of the AME application (i.e. attributes, conditions and rules) that are required
as part of AME setup for any integrating application. Finally, it will discuss how the invoice
workflow in the Oracle Payables module has been integrated with AME to drive invoice approval
routings. The current AME Implementation guide provides more in-depth information on the AME
engine and other advanced features which is outside the scope of this document.

2. Introduction
An approval with Correction V4.0 is the default behavior for modules in SSHR 4.0 and above.
Within the approvals process, the application uses rules to generate a list of approvers for the
SSHR transaction. The way in which the list is generated depends on the approvals mechanism
you are using (see Approvals Mechanisms in SSHR). The default approvals process also
includes dynamic approvals as standard. The dynamic approvals functionality works in two parts.
One part is the self–service user interface which enables the initiating manager to add additional
approvers and/or notification recipients. You can also display the approvers and limit the number
of approval levels.

The second part is an application which generates the default approvers. This is either Oracle
Approvals Management (AME) or a customizable PL/SQL package. The dynamic approval
workflow process then sends notifications to approvers and/or notification recipients based on the
approver list.

Oracle Approvals Management (AME) is a web–based application which is integrated with Oracle
Workflow and which enables you to define business rules to control your approvals processes.
With AME, you use the following components to define your approvals processes. They are
associated with a transaction type for a particular application.

• Attribute – this is a business variable, for example, a salary amount, user ID, or workflow
process name.
• Condition – a condition compares an attribute value with a set of allowed attribute values.
For example, a condition could look at a salary amount. If the salary is greater than a
specified value, a particular approver list is created.
• Approval type and approval specifications – these components define the type of
approver list that is generated. For example, to generate a supervisor–based approver
list with 5 levels, you use the ’supervisory level’ approval type with the ’requires approval
up to the first 5 approvers’ approval specification.
 • Rules – a rule links the other components together by associating one or more conditions
with the approval type and approval rule.

3. Prerequisites
The prerequisites of AME are like:

• Working knowledge of Workflow.

• Working knowledge of PL/SQL.
• Set up the approvals process using workflow attributes, to configure approvals in the
Workflow Builder.
• Need to know about Self-Service Human Resources (SSHR) functions.

4. Environment

1) Setup an AME Admin User

a) Login as sysadmin to the Oracle Application Home Page
b) Select User Management à Users from the Navigator
c) Search for a user from the User Maintenance page that you will want to make it the AME
Admin.
d) Click on the Update Icon
e) Click on the Assign Roles button
f) Search and assign Approvals Management Administrator Role
g) Go back Home to the Navigator
h) Select Functional Administrator Responsibility
i) From the Grants page, press on the Create Grant button
j) Create a grant with the following information:
· Name
· Grantee Type = Specific User
· Grantee = <The user which you just created>
· Object = AME Transaction Types
· Data Context Type = All Rows
· Set = AME Calling Applications

2) Create a Transaction Type with Approval Group Transaction Type

a) Login as that AME Admin and go to the Navigator to select Approvals Management
Administrator
b) Press the Create Transaction Type button
c) Enter the following information in Step 1 to create a transaction type:
· Application
· Transaction Type Key
· Transaction Type Name
d) Just Press Next to skip Step 2 and 3
e) Press Finish to create the transaction type Group
f) Go back Home to the Navigator.
g) Select Approvals Management Business Analyst
h) Select the transaction type that you just created
i) Click on the Approver Groups link and press the Create button
j) Create a Group by entering the following information:
· Name
· Description
· Order Number = 1
 · Voting Regime = serial
· Usage Type = static
· Query = <blank>
k) Press the Add Another Row to create an approver
l) Search an approver from the LOV and press the Apply button Action Type
m) Once the Group is created, click on the Action Types sub-tab
n) Click on the Use Existing Action Type button
o) Select the action named approval-group chain of authority and press on the Continue
button then the
Finish button
Rule
p) Click on the Rules tab
q) Press the Create button
r) Create a rule with the following information:
· Name
· Rule Type = List Creation
· Start Date = <today date>
· End Date = 12/31/4712
s) Press Next to skip step 2
t) Search for the action which you created. It should be something like Require approval from
<group
name>
u) Press the Finish button.

3) Create Transaction type with Supervisor Level Transaction Type

a) Repeat steps 2a – 2h
Attributes
b) Click on Attributes link and press the Use Existing Attribute button
c) Use an existing attribute named SUPERVISORY_NON_DEFAULT_ST
ARTING_POINT_PERSON_ID by select it and press the Continue button
d) Select Static for Usage Type and do not enter anything in the Value field
e) Press the Finish button
f) Repeat 3c – 3e for TOP_SUPERVISOR_PERSON_ID
g) Repeat 3c for TRANSACTION_REQUESTOR_PERSON_ID
h) Select Dynamic for Usage Type and insert the following query into the Value field:
select employee_id
from fnd_user
where user_id = umx_pub.get_attribute_value(:transactionId,
'REQUESTED_FOR_USER_ID')
i) Press the Finish button
Action Type
j) Click on the Action Types sub-tab
k) Press the User Existing Action Type button
l) Select the supervisory level action type and press the Continue then Finish button
Rule
m) Click on the Rules tab
n) Press on the Create button
o) Create a rule by entering the following information and click on the Next button:
· Name
· Rule Type = List Creation
· Start Date = <today date>
· End Date = 12/31/4712
p) Press the Next button to skip the Add Conditions
q) Search the Action for the Action Type of supervisory level. The Action should be something
like
Require approvals up to the first superior.
 r) Press the Next then Finish button

4) Create Transaction Type with Job Position Transaction Type

a) Repeat steps 2a – 2h
b) Click on the Configuration Variables link in the Quick Links section of Business Analyst
Dashboard
page
c) Select transaction-type administration and Press the Continue button
d) Enter the transaction type which you created in step a in the Transaction Type input field
and press
Go button
e) Set Yes for allowAllApproverTypes of the Transaction Type and press the Apply button
Attributes
f) Select the transaction type in the Approval Process Setup section
g) Click on Attributes link and press the Use Existing Attribute button
h) Use an existing attribute named TOP_POSITION_ID by search, select, and press the Use
Selected
Name button
i) Select Static for Usage Type and do not enter anything in the Value field
j) Press the Finish button
k) Repeat 4g – 4j for NON_DEFAULT_STARTING_POINT_POSITION_ID
l) Run the following query:
select psv.position_structure_id,
cur_user.user_name as "Cur Username",
str.subordinate_position_id as "Cur Pos ID",
pos.name as "Cur Pos Name",
next_user.user_name as "Next Username",
str.parent_position_id as "Next Pos ID",
next_pos.name as "Next Pos Name"
from fnd_user cur_user,
per_pos_structure_elements str,
per_pos_structure_versions psv,
per_all_positions pos,
per_all_positions next_pos,
per_assignments_x cur_assign,
fnd_user next_user,
per_assignments_x next_assign
where str.pos_structure_version_id = psv.pos_structure_version_id
and trunc(sysdate) between psv.date_from
and nvl( psv.date_to , sysdate)
and pos.position_id = str.subordinate_position_id
and next_pos.position_id = str.parent_position_id
and cur_assign.position_id = pos.position_id
and cur_assign.person_id = cur_user.employee_id
and next_assign.position_id = next_pos.position_id
and next_assign.person_id = next_user.employee_id
order by next_user.user_name;
m) Repeat steps 4g – 4h for NON_DEFAULT_POSITION_STRUCTURE_ID
n) Enter the value of position_structure_id from the query result into the Value field as a Static
attribute
o) Repeat steps 4k – 4l for TRANSACTION_REQUESTOR_POSITION_ID and with value of
Cur
Pos ID from the query result
Action Type
p) Click on the Action Types sub-tab and press the Use Existing Action Type
q) Select hr position level action type and press the Continue then Finish button
 Rule
r) Click on the Rules tab and press Create button
s) Create a rule by entering the following information and click on the Next button:
· Name
· Rule Type = List Creation
· Start Date = <Today Date>
· End Date = 12/31/4712
t) Skip the Add Conditions by pressing the Next button
u) Search the Action for the Action Type of hr position level. The Action should be something
like
Require approval up to first position up
v) Press the Next then Finish button

5. Oracle Approvals Management (AME)

AME is a self-service web application (it’s not part of SSHR) which lets users
define business rules governing who should approve transactions that originate
in other Oracle applications eg in SSHR.

a. Overview
There are two AME responsibilities:
Approvals Management Administrator - full access to AME
Approvals Management Business Analyst - access to all areas of AME that do not require
technical knowledge;
AME allows users to create conditions and approval types. These can then be linked by rules.
For example a condition could say
WORKFLOW_PROCESS_NAME = 'MY_CUSTOM_LOA', or
Absence_Duration > 10
Attributes to be used in conditions can be defined if they do not already exist like
'Absence_Duration'.

There are several approval types eg supervisor level which goes up the supervisor chain, and an
approval specification will define how many approvers are required.
For example, a supervisor level approval style which requires approval up to the first 3 levels.

You would then define a rule to link the condition with the approval
eg If WORKFLOW_PROCESS_NAME = 'MY_CUSTOM_LOA' then use a supervisor hierarchy
approval style which requires approval up to the first 3 levels.
Each self service transaction requiring approval would have to meet the condition in one of the
rules that have been defined.
This note does not show how to modify and create approval lists. To understand those please
see Implementation Guide - AME.B (MetaLink Note 336901.1).

Does SSHR use AME?

SSHR provides a seeded AME Transaction Type called 'Oracle Self Service Human Resources'
which includes one rule.
The condition is
WORKFLOW_PROCESS_NAME in (<list of all seeded SSHR functions>)
and the approval style is supervisor level.

If a different approval style is required for some or all of the SSHR functions, the seeded rule can
be modified or new rules can be created.
Does other application use AME?
As mentioned earlier in this note, the calling application is responsible for getting AME to find an
approver and for notifying approvers. AME is only responsible for compiling a list of approvers.

SSHR functions generally require a WF attribute to be set to indicate whether approval is required
or not. Then the presence of the pAME parameters in the function definition will determine
whether AME should be used to generate the list of approvers.

Other applications have their own methods of using AME......

Requisitions
To enable AME approval for requisitions go to Setup -> Purchasing -> Document Type Form in a
Purchasing responsibility and enter the required approval details.
Invoices
In AP navigate to Setup -> Options -> Payables. In the Invoice tab tick the 'Use Invoice Approval
Workflow' checkbox to specify that AME approval is to be used.
Individual invoices will require approval if the Approval Status field in the Invoices screen is set to
'Required'

Expenses
Set the Profile Option AME:Installed, to Yes at the Application level for Oracle Payables and all
expenses will be approved via AME.

b. Architecture
 c. Key Features
 AME helps you maintain your business logic associated with approval transactions
globally from single window
 Lets you cut down approval related workflow customizations, hence reducing the cost of
ownership
 Helps you leverage common expenditure policies across modules, thus consolidating
your approval policy requirements
 Any transaction is assured to be approved under the latest conditions, regardless of
organizational changes, currency fluctuations or transaction data
 Built-in testing utility to check the correctness of setup performed for both real-time and
test transactions, hence reduces the need for elaborate testing cycles
 Intangible benefits derived from solution design
 Reduced requisition approval turnaround times, thereby increasing the efficiency
of our procure-to-pay process
 Increased visibility of spending traits upfront to management chain

d. Approvals Process
Approvals with Correction V4.0 are the default behavior for modules in SSHR 4.0 and above.
Within the approvals process, the application uses rules to generate a list of approvers for the
SSHR transaction. The way in which the list is generated depends on the approvals mechanism
you are using (see Approvals Mechanisms in SSHR). The default approvals process also
includes dynamic approvals as standard. The dynamic approvals functionality works in two parts.
One part is the self–service user interface which enables the initiating manager to add additional
approvers and/or notification recipients. You can also display the approvers and limit the number
of approval levels.

The second part is an application which generates the default approvers. This is either Oracle
Approvals Management (AME) or a customizable PL/SQL package. The dynamic approval
workflow process then sends notifications to approvers and/or notification recipients based on the
approver list.

e. Configuring Approvals in the Workflow Builder

If required, you can configure the predefined approvals processes in the Workflow Builder. You
set up the approvals process using workflow attributes.
To configure approvals in the Workflow Builder:
1. Open the workflow item type.
2. Navigate to the process you want to modify and double click to open the workflow diagram.
3. Open the Review Page V4.0 activity for your workflow process.
Note: You may have to drill down through several sub processes until you reach the
correct Review Page V4.0 activity.
4. Make a copy of the process and any affected sub processes. For example, if you are modifying
the approvals for the Process Personal Information V4.0 process, you would have to copy the
Process Personal Information V4.0 process, and the related sub processes, for example, the
Process Basic Details sub process.
5. Select the Review Page V4.0 activity for your process/subprocess and set the Approval
required workflow attribute (HR_APPROVAL_REQ_FLAG) to YES. This activates approval for
your process/subprocess.
6. Decide how a process should pass through the entire approval chain, in other words, how
many levels of approval are required. Set the approval level using the Approval Level attribute
(HR_DYNAMIC_APPROVAL_LEVEL). Add an approval level value to the Default Value field. A
value of 1 for example will pass the approval one level up the supervisor chain.
Note: The default number of level is 0, meaning that the number of levels is unlimited.
7. Save your work.
As part of the approvals process, you can choose to enable dynamic approvals by configuring the
Review activity for the workflow process in question.

f. Review and Confirm

Most functions display the Review and Confirm pages. The Review page displays a
corresponding region for each Web page section that you have updated as part of the preceding
transaction. Inside each region is a list of current database and proposed transaction data. If you
have configured approvals, you can enter approvals comments in this page. If you have enabled
the Dynamic Approvals function, the user can see the default approval chain and add further
approvers and notifiers. When the user chooses the Submit button from the Review page, the
transaction is committed to the Human Resources system or sent for approval. The Confirm page
is then displayed. The Confirm page contains a confirmation message describing the status of the
transaction. The user can print a copy of the submitted transaction for their records if required.
You can set up the approval properties for a process by changing the activity level attributes for
the Review workflow functions.
HR_DYNAMIC_APPROVAL_LEVEL:
This attribute is used to specify the number of levels to which this transaction needs to be
forwarded for approval in the approval hierarchy. For example, if the value is 1, the transaction is
submitted for approval to one level higher than the initiating person. When the transaction has
been approved, it is committed to the HRMS application. By default, this attribute reads the
approval level from the APPROVAL_LEVEL (Approval Level) item level attribute. If you specify a
value for the item level attribute, you can control the approval level for all the processes. If you
specify a value for the HR_DYNAMIC_APPROVAL_LEVEL attribute, it overrides the item level
attribute for the process for which you have specified the value.
HR_APPROVAL_REQUIRED_FLAG:
This attribute is used to specify whether the current transaction requires an approval. The valid
values are:
• No: the process does not require approval
• Yes: the process requires approval but the dynamic approval user interface will not be shown in
the review page. This means that the initiator cannot add additional approvers or notifiers.
• Yes – Dynamic Approval: the process requires approval and the dynamic approval user
interface will be shown in the review page. The initiator can add additional approvers and
notifiers.
Confirm Instruction Application Short Name:
In addition to the standard confirmation message shown in the confirmation page, you can also
configure messages that are specific to the process. You can specify one for a scenario for which
approval is required and one for a scenario for which no approval is required.
Processes can be set to either Approval Required or Approval Not Required, but not both, using
the HR_APPROVAL_REQUIRED_FLAG.
For example, you can define a message for Confirm Save Instruction Name and Confirm Send for
Approval Instruction Name. You register this message under your custom application.
Confirm Send for Approval Instruction Name:
The text associated with this message name is displayed in the confirmation page immediately
after the standard confirmation message. This text is only displayed when the process does not
require approval. The text associated with this message name is displayed in the confirmation
page immediately after the standard confirmation message. This text is only displayed when the
process requires approval.

g. Approvals Mechanisms in SSHR

SSHR 4.1 uses the Oracle Approvals Management (AME) application to define and manage
approval logic. For more information on AME, see: Implementing Oracle Approvals Management
(available on Metal ink).
Note: If you are an existing SSHR customer, the customizable PL/SQL package for
approvals, which was the default approvals mechanism in previous releases of SSHR, is
still supported in this release as an alternative to AME.
All delivered SSHR version 4 functions are now linked to AME. If required, you can also link any
existing custom functions that you may have based on earlier version 4 functions to AME.
Note: You cannot link SSHR version 3 functions such as Appraisals, Apply for a Job,
Succession Planning, or Suitability Matching, to AME.
Alternatively, you can choose to continue to use the customizable PL/SQL package for new
functions, even if they are modeled on SSHR version 4 functions.

h. Oracle Approvals Management (AME)

Oracle Approvals Management (AME) is a web–based application which is integrated with Oracle
Workflow and which enables you to define business rules to control your approvals processes.
With AME, you use the following components to define your approvals processes. They are
associated with a transaction type for a particular application.

• Attribute – this is a business variable, for example, a salary amount, user ID, or workflow
process name.
• Condition – a condition compares an attribute value with a set of allowed attribute values. For
example, a condition could look at a salary amount. If the salary is greater than a specified value,
a particular approver list is created.
• Approval type and approval specifications – these components define the type of approver list
that is generated. For example, to generate a supervisor–based approver list with 5 levels, you
use the ’supervisory level’ approval type with the ’requires approval up to the first 5 approvers’
approval specification.
• Rules – a rule links the other components together by associating one or more conditions with
the approval type and approval rule.

i. Default Use of AME Configuration in SSHR

Oracle SSHR delivers AME configuration which has been designed to emulate functionality
delivered in the PL/SQL package. The default behavior is to use a supervisor–based approvals
hierarchy which is now delivered using AME rules.

The default AME configuration consists of:

• a single AME transaction type ’SSHRMS’ with
• a single condition WORKFLOW_PROCESS_NAME
• a single rule which requires approvals to the top of the approval hierarchy or to 10 levels above
the initiator, whichever comes first.
– this is based on the standard AME approval type ’chains of authority based on number of
supervisory levels’

j. Configuring SSHR Approval Levels in AME

To meet your business needs, you may add additional rules, conditions, or attributes within the
delivered SSHRMS transaction type, or you can define a custom transaction type. It is relatively
easy to make minor changes to the delivered AME configuration and some examples are
provided below.
To define a different approval level for all SSHR workflow processes:
• For example, to specify two approval levels: The approval level is currently defined in the rule
’SSHR Rule for at most 10 approvers in Supervisor chain’. You would edit this default rule and
change the approval level for the supervisory level approval type to ’requires approval up to the
first two superiors at most’.
To define a different approval level for a specific workflow process:
• first you create a new condition with the attribute WORKFLOW_PROCESS_NAME and enter
the workflow processes which will have the different approval level as the attribute values.
• Then you create a new rule, for example, ’2 approvers in supervisor chain’.
– Use the ’supervisory level’ approval type with the ’requires approval up to the first two
superiors at most’ approval
– Finally, attach your new condition to the rule.
To define a new approval level (if the delivered approvals do not meet your requirements):
• you create a new approval (for example, ’requires approval up to the first 15 superiors at most’)
in the ’supervisory level’ approval type.
To define a particular user as the final approver, or final authority (even if they are not the last
person in the approval chain):
• you create a List Modification Condition and specify a user, for example, a manager, as the final
approver. You would add this list modification condition to your rules so that the approval chain
would stop at this specified approver. Alternatively, you could create a new rule, add the approval
type for final approver and add the WORKFLOW_PROCESS_NAME condition so that this final
approver rule would apply to selected processes.
 k. Configuring SSHR Functions to Use Oracle
Approvals Management (AME)
Any custom functions you created prior to release 4.1 will use the customizable PL/SQL package
as the default approvals mechanism. However, you can modify any custom SSHR 4.0 functions
to point to AME by adding two new function parameters. You define the additional parameters in
the Form Functions window.

You should also check the workflow attributes for your workflow process using the Workflow
Builder. The AME rules and conditions always override any other workflow attribute settings that
apply to approvals, for example, the attribute settings for the Review activity. If the Approvals
Required workflow attribute is set to Yes for a workflow process but AME does not return any
approvers, the process completes without requiring approval. As a general set–up
recommendation, you should set up processes that currently do not require approval as follows:
• Set the Approvals Required workflow attribute to Yes
• Configure AME so that no approvers are returned
Note: If you subsequently need to add approvals to your process, you can simply use a
different AME condition.
To link your function to AME in the Form Functions window (required):
1. Query your function.
2. Navigate to the Form tabbed region.
3. Add the following parameter information to the Parameters field for your function:
• pAMETranType=SSHRMS
• pAMEAppId=800
4. Save your work.
To add your custom workflow process to the list of values for the condition attribute for
the SSHRMS AME transaction type (required if using the delivered SSHR transaction type):

1. Log on to Oracle Approvals Management.

Note: You need to use one of the following AME responsibilities:
– AME Application Administrator
– AME General Business User
– AME Limited Business User
2. Select the SSHRMS transaction type.
3. Select the Conditions tab and click on the WORKFLOW_PROCESS_NAME condition.
4. Choose the Add Text Value button and enter the name of your new workflow process as an
attribute value.
5. Save your work.
To set the Approvals Required attribute in the Workflow Builder:
1. Display your function in the Workflow Builder.
2. Display the attributes for the Review function.
3. Set the Approvals Required attribute to Yes or Yes – Dynamic Approvals.

l. AME components
In order for a business user to develop business scenarios in AME that determine approval
routings, it is important to understand the different components within AME. These components
are often required to be modified or created as part of the development of business cases. A brief
description of these components will be discussed in the following paragraphs.

Transaction Types
A transaction type describes the type of transaction for which business cases (rules) and
approval routings will be based. This can include Oracle Application transactions such as
purchase orders, sales orders or accounting journals. For the sake of this discussion, the
transaction type that is provided with AME is the Payables Invoice Approval transaction type.
Oracle provides many seeded transaction types to satisfy many of the common transactions that
occur within a particular application. The creation of new transaction type in AME is available for
those business users that want to integrate custom applications with AME. However, Oracle does
not encourage the development of new transaction types because of the significant programming
effort involved to integrate with the AME application.

Attributes
Attributes within AME are business variables that represent the value of a data element of a given
Transaction .In the case of an AP invoice transaction, a typical attribute would be invoice amount
or supplier name. Attributes can be thought of the as the ‘building blocks’ of business case
development. The reason being is that the value of an attribute(s) for a transaction can ultimately
determine whether a business case (approval rule) has been met because approval rules use
conditions which in turn use attributes.

Attributes in AME can be created as being static or they can be dynamic in nature. Static
attributes have a constant value that remains the same for each and every transaction associated
with the attributes transaction type. Dynamic attributes use a SQL query to retrieve the value of
an attribute at runtime whenever a transaction is created. Most attributes in a transaction type are
dynamic. There are several different attribute types that exist within AME. String attributes are
alphanumeric in nature and can have a total length of 100 characters. Numeric attributes are
considered to be any numeric value that is acceptable in PL/SQL. This includes numbers
containing decimal or sign operators (+/-). AME requires that any numeric attribute that is
dynamically generated to be converted to a canonical form. This can be done by using the syntax
fnd_number.number_to_canonical function as part of the dynamic SQL query. An example
dynamic SQL query for a numerical attribute would be in the following syntax:
SELECT fnd_number.number_to_canonical(:requester_id)
FROM ap_invoices_all
WHERE invoice_id =: transactionId.

Currency attributes are used whenever the transactions of an organization involve multiple
currency values. This allows for Oracle to use currency conversion between denominations when
retrieving the value of an attribute. AME requires that any dynamic attribute setup as a currency
attribute must include the following columns as part of the SQL query: numeric column, currency
and conversion method. One caveat to mention regarding currency attributes; any AME
conditions that are developed using a currency attribute must include a condition for each
currency this particular transaction attribute value might have. Boolean attributes have only two
allowable values; true and false. Any dynamic attribute defined as a Boolean must return one of
these two allowable results. AME provides a format string that can be used in the SQL query of a
dynamic Boolean attribute. The syntax format is in the form of either
me_util.booleanAttributeTrue or ame_util.booleanAttributeFalse.
Date attributes are commonly used on transaction data that contains a date value, such as
invoice date. AME requires that date attributes be returned in the format ‘YYYY: MON: DD: HH24:
MI: SS’. AME provides a format string that can be used in the SQL query of a dynamic date
attribute. The format string ame_util, versionDateFormatModel can be used to return the proper
date format at runtime. All transaction types currently defined in AME use several mandatory
attributes that can be thought of as runtime parameters because they often determine various
facets of AME runtime behavior. These attributes can control AME behavior such as whether to
allow an approver to appear multiple times on an approval hierarchy or whether to allow a
requester to approver his/her own transactions (invoices). The following mandatory attributes are
defined in AME for all transaction types:
ALLOW_DELETING_RULE_GENERATE_APPROVERS
ALLOW_REQUEST_APPROVAL
AT_LEAST_ONE_RULE_MUST_APPLY
REJECTION_RESPONSE
USE_RESTRICTIVE_ITEM_EVALUATION
EFFECTIVE_RULE_DATE
EVALUATE_PRIORITIES_PER_ITEM
USE_WORKFLOW
WORKFLOW_ITEM_KEY
WORKFLOW_ITEM_TYPE
REPEAT_SUBSTITUION
The AME Implementation guide provides additional detail on each of these mandatory attributes
and how they are interpreted by AME.
Required Attributes are similar to mandatory attributes in that they determine runtime behavior of
AME. The only difference being that required attributes are defined specific to a transaction type.
In the case of the Payables Invoice Approval transaction types, the following require attributes are
defined.
ALLOW_EMPTY_APPROVAL_GROUPS
FIRST_STARTING_POINT_PERSON_ID and SECOND_STARTING_POINT_PERSON_ID
INCLUDE_ALL_JOB_LEVEL_APPROVERS
JOB_LEVEL_NON_DEFAULT_STARTING_PERSON_POINT_ID
NON_DEFAULT_POSITION_STRUCTURE_ID
SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID
TOP_POSITION_ID
TOP_SUPERVISOR_ID
TRANSACTION_REQUESTER_PERSON_ID
The AME Implementation guide provides details of each of these mandatory attributes and how
they are interpreted by AME.
Both mandatory and required attributes come seeded with default values. They can be modified
to meet the needs of a specific transaction type.

Conditions
The next major component of AME setup is conditions. Conditions are used to evaluate the value
of attributes in a particular transaction. The result of a condition can either be true or false.
Conditions are precursors to AME business rules. The result of a condition helps to determine
whether a business case (rule) has been satisfied. The conditions within AME can be better
thought of as the IF part of an approval rule. For example,
If invoice supplier is Vendor a, then require approvals from Approver a, Approver B
In this example, AME would retrieve and evaluate the value of the attribute invoice_supplier to
determine if the value was equal to Vendor A.

There are three different types of conditions that exist in the AME application: Ordinary-Regular,
Ordinary-Exception and List Modifier. Ordinary-Regular conditions associate an attribute with a
defined value or range of values (e.g. invoice_amount > 100). Ordinary-Exception conditions are
similar to Ordinary-Regular conditions in how they are defined, but differ in that they are limited to
the types of rules with which they can be associated. This will be discussed later in the document.
Finally, List-Modifier conditions provide the ability to create conditions based on the existence of a
specific approver in an approver list that is built by AME for a specific transaction. For example, a
List-Modifier condition could be defined as follows:
If Approver B is final approver, require approver up 1 level
This condition would evaluate to true if Approver B was the last approver in an approver list built
by AME at runtime.

Action Types and Actions

Actions within the AME application describe the nature of what should be done in AME if a
particular condition and rule is satisfied by a transaction. It is the actions that dictate the approver
list that is generated by AME for the given transaction. Actions not only provide instruction as to
who the approvers are, but how many approvers are requires for a given transaction and in what
order should they be notified.
Action types are groupings of actions that have a similar functionality such as the approval
hierarchy that should be traversed when building an approver list. An example of this would be
actions that pertain to building an approval based solely on the supervisor tree in HR. The
multiple actions for this action type would all pertain to traversal of the supervisor hierarchy, but
would express in terms of how many levels to traverse. Typically, each action that describes how
many levels of a hierarchy to move up would be defined separate unto itself. All of the defined
actions would be grouped into an action type based on their relationship to the hierarchy being
used.

m. AME Testing Workbench

One of the very powerful features of the AME application is the Testing Workbench. The
workbench provides the ability to test the business rules that have been defined in AME against
test or real transactions in your Payables application database. This allows you to preview the
results of your AME definitions to verify certain aspects such as:

• Are attribute values, particularly custom attributes retrieving values correctly?
• Does the invoice satisfy the appropriate rule?
• Is the proper approver chain(s) being generated for the transaction based on the rule
chosen?
The testing workbench can be accessed from the AME Dashboard. The AME Dashboard can
be found under the Approvals Management Business Analyst role discussed earlier in the
document.

The first step in using the Test Workbench involves defining a new test case in AME. Defining a
test case is simple as it involves supplying a name for the test case and description (optional).
After entering a name for the test case and description, choose the Save for Later button to save
the test case definition. Although a Run Test Case button is available at this point, it is best to
save the definition to the database first and then execute a test case after receiving the
confirmation page below. The best approach to demonstrating the AME Test Workbench is by
entering a new invoice in the Payables application and executing a test against this invoice. The
invoice will be created to test the second business case rule defined earlier in the document. Our
test case will allow us to verify whether our business case rule has been defined properly and if
the approver list is built correctly by AME.

Now that an invoice has beencreated, we can execute a test from the workbench to see if our
AME components have been defined correctly and produce the results we expect. To execute a
test against this invoice, navigate to the testing workbench. From the workbench, choose a test
case against which the testing will be conducted. Choose the Run Real Transaction Test button.
The next screen prompts the user for the transaction id which AME uses to evaluate previously
defined rules and generates an approver list. This transaction id as mentioned previously is the
invoice_id from AP_INVOICES_ALL
It is important to note that upon entering a transaction id, you must choose the Go button which
retrieves information about your transaction. In particular, it retrieves the values of all attributes
that have been defined for the current transaction type. The values of the header attributes are
shown on the next page to demonstrate how AME retrieves and displays the values of the
attributes. These values are consistent with the data entered for your invoice transaction.

After reviewing the values retrieved for the various attributes of the transaction, choose the Run
Test Case button to execute and evaluate the rules and action defined for the transaction.
Based on the results of the test, it appears that the business test case was defined properly. The
SB Sales Tax Approval Rule was applied to this transaction because the invoice had a sales tax
distribution line. Additionally, the approval list has been built correctly. The first approver is the
individual included in the Tax Approver group defined earlier in the test case. The next approver
in the approval chain is the supervisor of the requester of the invoice. As previously stated, the
Testing Workbench can be a very useful during the process of implementing and developing AME
rules for invoice approval routing. Having the ability to evaluate and see the results of your AME
setups using real transaction prior to implementation in a production environment is quite
valuable.

n. Invoice Approval Workflow and AME

So how does Oracle Payables integrate with Oracle Approvals Management? The simplest
answer is to mention that they integrate through use of the AP Invoice Approval workflow.
Whenever AP is configured to use workflow, all invoices (manual and imported) are subject to
invoice approval. This is done by initially setting the approval status of the invoice to require.
Once the invoice is validated and approval is initiated for the invoice either online or via the
Invoice Approval Workflow concurrent program, the invoice falls into the workflow cycle. The
approval logic can best be explained by reviewing the Invoice Approval workflow.

Approval Logic
When an invoice transaction falls into the approval workflow, the workflow determines if the
invoice transaction is fully matched to a purchase order. If it is, then the workflow ends and the
approval status of the invoice is updated to Not Required. However, if the invoice is not matched
to a purchase order, then the workflow tries to identify the first or next individual responsible for
review and approval of the invoice. The workflow node Identify Approver is where AP and AME
are integrated. It is at this point that the workflow calls AME to determine either a) does the
invoice initially meets any of the currently defined rules in AME for invoice approvals or b) are
there any additional approvers left on the approval chain hierarchy.

For any AME rule satisfied by the invoice transaction, AME attempts to build an approver list
based on the applied rule and the associated action type and actions that define the appropriate
approvers. If a successful approver list is built, then the workflow sends a notification to the first
approver in the list. The workflow itself remains active and continues to call AME as long as:

There are more approvers left on the approver chain

The workflow has not been rejected by any approver
The workflow has not expired due to non-responses by an approver

As you can see, the components that are defined in AME, especially the business rules have a
direct impact on the approval routings within AP invoice workflow. It is very important to plan and
define your rules carefully to ensure that the organizational approval requirements are met and
approval routings flow as intended.

One thing that is important to note is the behavior of AME and workflow for invoices that do not
satisfy any predefined rule. By default, the approval status of any new invoices is set to
‘Required’. One the invoice is sent for approval either manually by the user online or via the
Invoice Approval Workflow program, the approval status of the invoice changes to ‘Initiated’.
When the workflow begins, if the invoice transaction does not initially satisfy any approval rules in
AME, the workflow ends and the status of the invoice remains ‘Initiated’. This is the behavior of
the AP Invoice workflow delivered with Oracle. It is important to mention this because whenever
an organization decides to require approvals of invoices, the invoices cannot be paid until the
invoice is approved. So for any invoices that fall into the category of not satisfying any approval
rules, this could potentially prevent these invoices from ever being paid.

There are a couple of alternatives an organization could choose to resolve this issue. The first of
which is to modify the AP Invoice workflow to deal with any invoices that do not initially meet the
conditions of an approval rule. Modification to the workflow is beyond the scope of this document.
The second alternative has to do with the setting of the mandatory attribute
AT_LEAST_ONE_RULE_MUST_APPLY. Setting the value of this attribute to True will cause the
workflow to raise an exception for any invoice transactions that do not satisfy at least one defined
rule. In this case, an organization could at least be aware that their rules defined in AME do not
cover any all business cases that exist in regards to invoices
transactions.

o. Implementing AME for AP Invoice Approval

In order to use AME to facilitate AP invoice approval routings, there are some setup steps that
must be completed in both the AME application as well as within the Payables applications.

AME Setup

The first step in implementing AME is to install the AME application. As of release 11.5.9, AME
comes seeded and is installed as part of the overall applications install. The setups that are
described in this document are for the latest version of the AME applications. (As of this writing,
AME.B is the latest RUP (Roll-Up Patch) available).

You can find the most recent patch for AME at site by using the Simple Search function under the
Patches & Updates tab on Metal ink.
The next step in setting up the application is to set up AME security. The current version of AME
uses Oracle Role Based Access Model (RBAC) which is part of the new User Management
model to provide access to the various AME component functions. An AME role must be attached
to the user account of any person utilizing AME to develop application business rules. The
following roles are predefined in AME.B.

Approvals Management Administrator

Approvals Management Analyst
Approvals Management System Viewer
Approvals Management System Administrator
Approvals Management Process Owner
Approvals Management Business Analyst1

Granting a role to a user does not automatically provide access to the setup components within
AME. As part of the RBAC model, once a role has been granted to a user, specific access must
be granted, to access functions within the role in order to ‘activate’ access to the functions. In
terms of AME, this means granting access to either all or a specific transaction type. For
example, if a business user is responsible only for the setup of the Payables Invoice Approval
transaction type, then a specific access to this transaction type can be granted, thus allowing the
user to only access and modify components of this one transaction type.

1 This role comes inherit will access to all of the components needed to develop AME rules. This
includes attributes, conditions, rules and the testing workbench.
After the roles are granted and access is established, the profile option AME: Installed must be
set at the application level for Payables. This profile option change can be made under the
System Administrator responsibility in the applications.
AP Setup

In addition to the setup steps that must be followed in the AME application, there are some
additional steps that must be done in the Payables application to enable AP invoice approval
routing. Fortunately, all of these setups are done from one form within the application module, the
Payables Options form.

The Payable Options form is typically located under the Payables manager or equivalent
responsibility in the applications.

There are three options on this form that dictate how Invoice Approval is facilitated in the
Payables applications. The first option Use Invoice Approval Workflow is the primary option
because it informs the Payables application to force all invoices to go through the invoice
approval workflow. As mentioned previously, when this option is enabled, all invoices are set to
require and must initially fall into the workflow cycle.

The next option is Allow Force Approval. This allows a user to automatically set the approval
status of an invoice to Approved, which allows an invoice to be automatically approved without
having go through the workflow cycle. The last option, Require Validation Before Approval
requires that an invoice be fully validated before it can be placed in the workflow approval cycle.

p. Defining Business Case Scenarios

In the current version of the AME application (AME.B), the Approvals Management Business
Analyst role provides access to the Business Analyst Dashboard

The dashboard can be thought of as a ‘birds eye view’ of the AME application.
Along with displaying an overview of the various transaction types that are currently defined, the
dashboard also displays any rules that have recently been defined, updated or deleted along with
any rules that are slated to become active at a future date. More importantly, the dashboard
provides links to all of the setup components required when defining new business case rules in
AME, including attributes, conditions, approver groups and rules.

Whenever a business user begins the process of defining rules that represent organization
business cases, it is important to have an understanding of the transaction type of which business
rules will be based. As part of this understanding, a user should determine two important
elements of the transaction type:
• · What does the transaction type’s transaction id represent?
• · How does the transaction type determine the requester of a transaction?
The answer to the first question would require some research (i.e. Metalink, Application specific
guides, etc.) to discover what value in a particular transaction is used to represent the transaction
id. In the case of the Payables Invoice Approval transaction type, the invoice_id in
AP_INVOICES_ALL is used as the transaction type. The importance of knowing the value of the
transaction id lies in the fact that most of the dynamic attributes use the transaction id as part of
the WHERE clause of the SQL statement used to retrieve the their value. Remember, an attribute
must return a single value. In the case of invoice transaction, using the invoice_id will ensure that
a single value will be retrieved.

As far as determining the requester initiating a transaction, there is a required dynamic attribute
defined for most if not all transaction types that contains the logic to retrieve this value. The
required attribute is TRANSACTION_REQUESTOR_PERSON_ID. In the Payables Invoice
Approval transaction type, the value of this attribute is retrieved by the following SELECT
statement:

Select requester_id
From ap_invoices_all
Where invoice_id =: transactionId

This means that the person populated in the requester field on the invoice header in Payables will
be flagged as the initiator of a transaction. Any approver lists that are built from an invoice
transaction will begin using the requester id as the basis.

For each of the following business case demonstrations, the paper assumes the HR supervisor
hierarchy is used as the basis for building approval lists. Additionally, there is the assumption that
only one currency (USD) is used.

q. Business Case # 1: Require Approvals up 1 level from

invoice requester for any invoice $100 or greater.
For this demonstration, the following components need to be defined:

Attributes: Total Invoice Amount

Condition: Total Invoice Amount >= $100
Rule: If Total Invoice Amount >= $100, then require approvals up to the first supervisor

Since this is an amount field, the SQL statement must return the number using the
fnd_number_to_canonical function.

Condition: Total Invoice Amount >= $100 (SB_INVOICE_AMT is greater than or equal to 100)

Any condition that uses a numeric attribute as its basis must provide a lower and/or upper limit. In
the business case, we are only concerned with invoices that are $100 or more.

Rule: Total Invoice Amount >= $100, then require approvals up to the first supervisor (SB Invoice
Rule (>$100)

Several items on the figure above are highlighted to show that the rule is consistent with the
original business case requirement to force an approval by the immediate supervisor of the
requester for any invoice $100 or greater.
 r. Business Case # 2: Require approvals from the Tax
Approver group, along with the normal chain-of-
authority for any invoices greater than $100 with
Sales Tax distribution Lines.
For this demonstration, the following components need to be defined:

Attributes: Sales Tax Present on Invoice

Total Invoice Amount (Already defined)

Conditions: Sales Tax Present on Invoice > 0

Total Invoice Amount >= $100 (Already defined)

Approver Group: Sales Tax Group

Rule: If Sales Tax Present on Invoice > 0, then require pre-approval from the sales tax approver
group, then up to the first supervisor

Attribute: Sales Tax Present on Invoice (SB_SALES_TAX_PRESENT)

This attribute could have been defined as a Boolean attribute to return either True or False. For
simplicity it has been defined as a numeric field that returns the # of invoice distribution lines that
are line type ‘TAX’ with a tax code equal to ‘SALES TAX’. If the count returned is zero, then it is
assumed the invoice has no sales tax lines. Any value greater than zero is assuming the invoice
has at least one or more sales tax lines.

Condition: Sales Tax Present on Invoice > 0 ( SB_SALES_TAX_PRESENT is greater than 0)

As mentioned in the previous example, any condition that is associated with a numeric attribute
must define a lower and/or upper limit. In this case, we define a lower limit that the value retrieved
in the SB_SALES_TAX_PRESENT attribute must be greater than 0 for the condition to be
considered true.

Approver Group: Sales Tax Group (SB Sales Tax Group)

Important to remember is that an approver group allows an organization to setup hierarchies that
include specific individuals required to be included in an approval list. This approver group has
been defined to include one employee in the approver group to represent the sales tax group.
Additional people can be added or removed as needed.

Rule: If Sales Tax Present on Invoice > 0, then require pre-approval from the sales tax approver
group, then up to the first supervisor
The definition of this rule really demonstrates the flexibility of the AME application when defining
complex or unique approvals. There are a couple of items worth noting regarding this setup.
The first of which is the rule type associated with the rule which is a combination rule type. This
important to note because a combination rule type allows a rule to include different action types
that may use different approval types as discussed earlier in the document. For this rule, a
combination rule type was necessary to allow the pre-approval group to be notified (Sales Tax
Group) prior to the notifying the immediate supervisor of the invoice requester.

The other item worth noting is that rule can use as many conditions as necessary to satisfy the
most complex or unique approval requirements of an organization. For this rule, notice that we
are using both the most recently defined condition that counts the number of sales tax
distributions lines, but also uses the previously defined condition that verifies whether the invoice
amount is greater than $100.

6. Reusable Components
SQCs are like functional library files which we can include in our SQR programs. We need to
include the SQC in the SQR program using #include function.

Few important SQCs that need to be attached are:

#include 'setenv.sqc'

#include 'stdapi.sqc'

#include 'prcsdefn.sqc'

#include 'prcsapi.sqc'

#include 'curdttim.sqc'

#include 'hrctlnld.sqc'

#include 'datwtime.sqc'
7. POC and Prototypes
Not Applicable

8. Additional Deliverables (Optional)

Not Applicable

9. Assumptions & Dependencies

1. Access to all resources
2. A clear idea of the SQR syntax while working on the requirements
3. Thorough understanding of functionality or purpose
4. SQR application is available and in place for use.
5. Preparation of Requirements document
6. Leave scope for modifications to accommodate future changes

10. Integration Management

SQR is not an integration tool.

11. Tips and Techniques

Not Applicable

12. Estimation Revisions

In SQR estimation revisions take place whenever Client raises a Change Request. This change
request can be analyzed with the following list of impact parameters:
o Volume and size of the transactions to a certain degree
o Business Requirement as well as Interface complexity

The above factors help in revising estimations.

Interface Complexity
N/A
Table 1 Interface Complexity
Light Medium Heavy Elaborate
Condition N/A

13. Skill Set

Primary Skills Acquaintance with SQR

Generic Business Skills Strong organizational and time management

skills, Excellent problem and incident
management skills, Typical candidate should
be a self-starter, pro-active and detail
 orientated, Prior experience working with
PeopleSoft Technologies

14. Technical Review Criteria

1. Thorough review of the documents and templates
2. Statements supplemented with supportive documents
3. Criteria check to be authorized with measured/measurable estimates
4. Version# and name of the document should be updated wherever required (check in
footer as well).
5. Prepared by and reviewed by should be mentioned.
6. Version history should be properly maintained.
7. Provide Reference FDD document name in Functional Description section.
8. Table of content should be updated and should be correct.
9. Mention where these changes are going to be done.
10. Review comments should be captured in review template and tracked. Review doc's
name should: Should be decided.

11.

15. Conclusion
It was the intent of this paper to provide the reader with enough high level understanding of AME
Functionality and how organizations can use AME to control their approval requirements for
invoice approval routing in Oracle Payables. As with any other Oracle application, mastery of the
application comes through practice and experimentation. Hopefully, the paper has demonstrated
how thorough planning of business case rules and further understanding of AME can allow
business users to develop their most unique or complex approval requirements in this powerful
application.

16. References
i. White Papers

Table 2 White Papers

Title White Paper Link
Oracle Approvals Management Implementation Metal ink Note 336901.1
Guide Rel 11i Part No. B25324-01,
Approvals Management Developers Guide Metal ink Note 289927.1
Release AME.B
MetaLink Note 336901.1

ii. Web Sites

Table 3 Web Sites

Title URL
Google, a popular search engine, is a tool for http://www.google.com
finding resources on the World Wide Web.
Official Website http://www.oracle.com
 iii. Documents

Table 4 Documents
Title Document Link
Understanding www.peoplesoftcity.com/hr88books_eng/eng/psbooks/tsql/htm/tsql10.htm
SQR messages
Understanding www.peoplesoftcity.com/fin84books_eng/eng/psbooks/tsqr/htm/tsqr22.htm
Dates
Meta SQL www.peoplesoftcity.com/fin84books_eng/eng/psbooks/tpcr/htm/tpcr05.htm
 iv. Customers

Table 5 Customers
Customer Name Customer Type (PPP/P/G)
RSMeans Corp. G
Oceaneering G
IDEA RC G

v. Projects

Table 6 Projects
Project Title Description
1. RSMeans Project Integration Between CRM and FIN
2. Oceaneering Finance Module
3. IDEA RC Finance Module

17. Open Issues

Table 7 Open Issues
Sno IssueID Description Status Owner’s Comments Dt.Close
(Open/Close) Name

1 SFS_R188 Relieving 1.Make Emplid NA NA NA

Letter Mandatory in the Run
Control Page
2.Active EE s are also
coming in the EE Lookup
page.It should show only
Terminated EE s.
3.The Paragraph is not
properly aligned in the
Report.

2 SFS_R176 Weekly Report 1.This Report is not NA NA NA

From running.Its Showing Run
Operations Status as 'Processing'
forever.

SFSPAYRL Payroll Not able to run the NA NA NA

Register Report.Im getting this
3 SQL Error

(SQR 5528) ODBC SQL

dbdesc:
SQLNumResultCols error
208 in cursor 20:
[Microsoft][ODBC SQL
Server Driver][SQL
Server]Invalid object
name
'PS_SFS_ST_PAYROLL'.

Error on line 337:

 (SQR 3716) Error in
SQL statement.

Errors were found in the

program file.

SQR for PeopleSoft:

Program Aborting.

18. Glossary
Table 8 Glossary
Term Definition
AME Oracle Approvals Management
AP Oracle Payables
SSHR Self-Service Human Resources
RUP Roll-Up Patch
RBAC Oracle Role Based Access Model