0% found this document useful (0 votes)
303 views23 pages

AME My Notes

This document provides an overview of Approval Management Engine (AME) and how it relates to Oracle Self Service Human Resources (SSHR). AME is a rules engine that builds approval workflows using business rules defined through conditions, actions, attributes, and rules. It takes complex approval logic and exposes it through a simple function call. For SSHR, AME governs approval processes for transactions initiated in SSHR. When a transaction begins in SSHR, it triggers a workflow called "HR" which guides the user through screens. AME rules are defined and applied to this workflow to dynamically determine the appropriate approvers depending on the transaction details.

Uploaded by

Ravindra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
303 views23 pages

AME My Notes

This document provides an overview of Approval Management Engine (AME) and how it relates to Oracle Self Service Human Resources (SSHR). AME is a rules engine that builds approval workflows using business rules defined through conditions, actions, attributes, and rules. It takes complex approval logic and exposes it through a simple function call. For SSHR, AME governs approval processes for transactions initiated in SSHR. When a transaction begins in SSHR, it triggers a workflow called "HR" which guides the user through screens. AME rules are defined and applied to this workflow to dynamically determine the appropriate approvers depending on the transaction details.

Uploaded by

Ravindra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 23

What is AME?

http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/395-ame
Note: Setup and Application Screenshots at the end
AME by definition is a Approval Management Engine that Builds a list of approvers for a specific transaction using
business rules. However in simple words, AME is a "IF THEN....ELSE....END IF" condition - wrapped into an API.
That's exactly what AME is. It is a IF THEN ELSE CONDITION wrapped up into a lets say Function Call to produce a
list of approvers. The complexities are taken care of by the Approval Management Engine itself. However this "IF
CONDITION" definition holds true when talking about the simplest possible definition of AME. Therefore if you can
understand "IF Condition", then you can understand AME. Further to that, if you know how to write IF Conditions and
how to write SQL, then you will be able to implement most of the AME Business requirements with ease. Lets have a
look into IF CONDITION from another perspective.
The example below is for explanation purpose only, not the exact definition of AME.
Imagine there is a FUNCTION that returns the approver
FUNCTION get_requisition_approver_id (transaction_id IN INTEGER ) RETURN INTEGER IS
BEGIN
IF get_requisition_amount(transaction_id) < 1000000 THEN
return 1000 ;-- calculated from person_id from the supervisor_id of the person that created requisition
ELSE
return 1001,1003 ; --person_id from a static approver group that contains list of people, like Director followed by a
CEO to approve orders over 1Million
END IF ;
END get_requisition_approver_id ;
The above function builds a list of approvers for a specific transaction using business rules, and returns one of more
approvers.

AME consists of certain building blocks that are


Building Block Name

AME Transaction Type

Purpose

An application that uses AME to govern its transactions approval processes


is termed an Integrating application. An integrating application may divide
its transactions into several categories where each category requires a
distinct set of approval rules. Each set of rules is called a Transaction Type.
e.g. Oracle Self Service Human Resources, Learning Management etc.

AME Attributes

Attributes are variables used to hold business facts of interest for the
transaction in progress. Most attributes are dynamic, meaning they will be
evaluated at run time, thus, they can change for each transaction. Oracle
provides over 50 seeded attributes for SSHR which can be used directly or
as the basis of creating the users own. These Attributes can be used for
building the AME Conditions.

AME Conditions

Attributes are used in Conditions. Conditions are the IF part of rule.


Conditions evaluate the Attribute and return a value of True or False. All
Conditions must be true for a rule to fire.

AME Action Type

Action Types provide two important aspects of the generated approval chain.
Action Types, by their nature, indicate HOW approvers are generated, i.e.,
whether by utilizing an existing hierarchy, or by a user specified list of
persons.
The second aspect is regarding the order in which approvers are notified.
Pre-chain Action Types will be triggered before Chain of Authority action

types, which are triggered before Post-chain type.


AME provides many Action Types. Three of most common include:
1) Pre-chain of authority approvals,
2) Supervisory level, and
3) Post-chain of authority approvals.
Chain of Authority Action Types are typically those which include authority
figures who are dependent upon the person initiating the transaction, for
example, the employees immediate supervisor, the next immediate
supervisor, and so on.
Pre- and Post Chain Action Types are normally used for approvers in
functional areas who have an interest in the transaction because of the type
of change being done, not because of the specific employee. An example of
typical pre- and post-chains are Human Resource personnel.
Users will not generally create new Action Types. It may be necessary,
however, to ensure that the desired Action Type is made available to Oracle
Self-Service Human Resources. It is strongly suggested that at least the
three types mentioned above have been selected for use by SSHR. If they
do not appear in the Action Types screen, add them with the Use Existing
Action Type button.

AME Approval Groups

If Action Types give the HOW to generate a list of approvers, Approval


Groups specify the WHO to include. Approval Groups are not needed for
Chain of Authority Action Types, since these are implicit as should already be
assigned in your database, i.e., if using a supervisor level action, AME
assumes that supervisors have been assigned to all employees via normal
data processing. Pre- and Post-chain Action Types do require the user to
specify a list of persons, since these are normally not reliant on the
employee making the transaction.
The simplest way to identify the approvers in the group is to just list them by
name. A list of HR and Benefit personnel who must approve the transaction
is static enough that changes to the Approver Group definition can be made
as they occur.
However, if approval is needed by, say, the chairperson of a specific
department, and this changes each academic year, a user may want to set
up the Approver Group as dynamic. Dynamic group definitions require a SQL
query which is executed at run-time. A dynamic Approval Group which
returns the current Biology Chairperson would not require a change to the
Approval Group definition itself as individuals move in and out of this
position, but would rely on a change made to position codes on the
Assignment screen.

Actions

Actions are combinations of Action Types and Approver Groups, and are the
THEN statement of a rule. Actions are automatically generated for Pre- and
Post-chain Action Types. For example, if an Approver Group of HR
personnel, named MUSS Benefit Specialists is created, Oracle
automatically creates Actions called Require pre-approval from MUSS
Benefit Specialists and Require post-approval from MUSS Benefit
Specialists.
Many seeded Actions for Chain of Authority Action Types are available. For
the Action Type supervisor_level, Actions exist to specify from 1- to 10-up
supervisor levels. Other chain actions involve job or position hierarchies
again, information that should already be recorded in your database.

AME Rules

Combines the "AME Condition" and "AME Approval Groups". Indirectly


though it references all the building blocks of AME. You can say that every
piece of AME building block is glued together in an "AME Rule".

There are six different types of Rules. The most commonly used ones would
include List-Creation (based on Chains of Authority Actions), Pre-List
Approver Group, and Post-List Approver Group. Substitution Rules are used
to replace a specific approver, however generated, with another person. A
Combination Rule can be used to combine pre-chain, chain, and post-chain
actions as long as conditions and the rule category are the same

Profile option "AME:Installed" must be set to Yes, at application level to the calling application to be able to use AME.
The "AME Transaction Type" can be defined using a responsibility named "Approvals Management Administrator".
Remainder of the building blocks can be defined and configured using responsibility named "Approvals
Management Business Analyst".

Back end Package: hr_ameutil_ss

AME Concepts (For Reference)

AME Concepts.pdf

How AME relates to Self Service HR?


http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/396-sshr-approval-management-engine
In Self Service Oracle Human Resources there is a workflow named "HR". The short code of this workflow is HRSSA.
This workflow is initiated as soon as any business activity is initiated in Self Service HRMS. Steps within this
Workflow process can be mapped to specific screens in OA Framework. Therefore the HR workflow guides which
screen the user navigates through when making changes to data in self-service HRMS.

Well there is no official explanation from Oracle for usage of a workflow to drive the flow of the screens. However
prior to using OA Framework in Self Service HRMS, SSHR was built using PL/SQL Web Cartridges and latter AK
Developer was included. Those days OA Framework did not exist in the current form. When the very first version of
SSHR was built by Oracle, back then the methodology of transaction state management of web based applications
was not standardised across e-Business Suite modules. Use this link to understand how OA Framework evolved.
Therefore Oracle HRMS Product Development team decided to use a "Workflow process" to keep all the loose bits of
screens tied together into one single transaction. If you open the HR [HRSSA] workflow, you will notice that there are
many Workflow Activities that are mapped to PL/SQL Function named HR_WORKFLOW_SERVICE.BLOCK. These
activity/steps in workflow correspond to a screen. This is how user navigation from one screen to other is controller in
Self Service HRMS.
The image shown above uses a workflow process named Person Information. However, for each distinct menu item
in Self Service HRMS, there exists a corresponding Workflow Process. Thus there are numerous processes within
this HRSSA workflow. For example there is another workflow process that starts when user navigates to "Extra
Information Types" screen
How does Oracle know which workflow process to initiate when a user enters "Person Information" screen in
SSHR
When user clicks on SSHR Menu Item, the name of the workflow process is passed as a parameter to the form
function. Therefore, the sequence of events are

User clicks on a menu in SSHR responsibility

Form Function attached to Menu is invoked.

This Form Function invokes AK Region HR_CREATE_PROCESS_TOP_SS [See Web HTML of Form
Function HR_PERINFO_SS]

This AK region is mapped to OAF Page /oracle/apps/per/selfservice/workflowservice/webui/CreateProcessPG


In some cases SSHR Function directly invokes an OA Framework page, specifically holds true for pages developed
post-AK-Developer era

Parameter pProcessName is read and the Workflow Process named "Personal Information" is initiated

All these steps are illustrated in image below

How does Oracle know which AME Transaction Type to use for that screen
As shown in image above, two parameters named pAMETranType and pAMEAppId are passed as parameter to the
Form Function. This tells which AME Transaction Type will be used by the SSHR screen. However the decesion of
whether AME is switched ON or OFF is decided by a Wokflow Activity named "Review Page". Every SSHR Workflow
Process as a step named "Review Page". As shown in image below, when you double click on activity Review Page
you will notice that this Workflow Function is passed a parameter named HR_APPROVAL_REQ_FLAG. If this WF
Activity parameter is Yes or "Yes - Dynamic Approval" then the AME is called for Approval processing. To change the
standard Approval processing in Oracle Self Service HRMS, you can customize this property to enable or disable the
Approval Processing for specific screen in HRMS.

Further details of how you can implement differing AME logic for different SSHR screens will be covered in a future
article.
Note- It is in Self Service HR [HRMS] that the AME Trx Type is passed as passed as parameter to the screen
function. Every calling module can have its own specific way using which the AME Trx Type to be used is configured.
For example, in iRecruitment we have the following profile options that dictate the AME Transaction Type being used
IRC: Vacancy Approval Transaction Type
-Identifies the vacancy approvals transaction type to be is used.
IRC: Offer Details Approval Transaction Type -Offer Details Approval Transaction Type
IRC: Extend Offer Duration Transaction Type -Extend Offer Duration Transaction Type

Do we directly customize the Workflow Process to change the AME behaviour for a screen?
Not really. You will copy the existing workflow process and create a new workflow process. For example a new
workflow process named XX will be created. The review page property within this workflow process will be modified
to use/remove AME. Thereafter you will create a new custom Form Function and attach that Custom Form Function
to the Menu. This Custom Form function will be passed in the parameter pProcessName with Custom Workflow
Process Name. This function must also be included within the menu named
"HR_GLOBAL_SS_FUNCTIONS_CUSTOM". This will facilitate usage of the custom Form Function in SSHR.

Firstly, what is the purpose of this workflow in Self Service HRMS ?


There is a historic reason for usage of Workflow named HRSSA in Self Service HRMS. Self Service HRMS product
development was done slightly ahead of OA Framework. In the early days of Self Service HRMS, OA Framework did
not exist in its current form, and therefore PL/SQL web Cartridges were used for developing the initial set of pages in
SSHR. Thereafter AK Developer was used to configure the components of the pages in SSHR. However, Self Service
HRMS team was looking for a framework that could give State Management for the data in Web Application. OA
Framework was not quite ready by then, therefore Oracle Workflow was hooked onto the Self Service HRMS screens
to manage user sessions. Given that workflow instance is persistent in the database tables, therefore the HRMS
team was able to leverage the persistency offered by Oracle Workflow for managing the state of Web Pages in Self
Service HRMS.
Some further info
When a user makes changes to the data via SSHR, the following tables are populated.
HR_API_TRANSACTIONS
HR_API_TRANSACTION_STEPS
HR_API_TRANSACTION_VALUES
The table HR_API_TRANSACTION_VALUES contains the old and the new values of the each possible
column/attribute that was changed by the user.

Steps to Access AME functionality in Apps


http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/397-rbac-ame
1.

Add Responsibilities to user SUBSINGH:

Approvals Management Administrator

Approvals Management Business Analyst

2.

No functions will however be visible when accessed through the responsibilities. This is resolved using RBAC
(Role Based Access Control)
Go to User Management Users Search for SUBSINGH Update
Click on Assign Role. Search for Roles with name %Approval% and assign all the roles found to
SUBSINGH.
Apply Changes. Now the functions will be visible. However NO DATA will be visible as of yet.
For data to be visible go to Functional Administrator Create Grant.
Grantee Type = Single User and then enter SUBSINGH as user. Select Object = AME Transaction Type.
Click Next. Select All Rows as context type. Click Next. Set = AME Calling Applications.
Save the Grant. Clear cache to see DATA.

3.
4.
5.
6.
7.
8.
9.

Self Service HRMS Workflow Explained


http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/420-hrssa-workflow-employee-self-service
In this article, we will continue with the HRSSA workflow, and see how it integrates with the AME. You will also see
the best practices steps to customize this workflow in an upgrade safe manner. In all the HRSSA processes, there is
a Workflow activity named "Review Page..." as shown below. If you double click to open the properties of this WF
Activity, you will find that Node Attributes tab contains a two Attributes i.e. HR_DYNAMIC_APPROVAL_LEVEL and
HR_APPROVAL_FLAG. In the context of our example, the Special Information Type WF process has AME Approvals
switched off, because HR_APPROVAL_FLAG is set to NO. However as per our requirements we need to enable
AME for our Holiday Rejection Complaint screen. Effectively, we are trying to achieve a result whereby our custom
workflow process is kicked off from the screen we created, and this custom workflow process will ensure that AME is
invoked. In order to enable AME approval for our custom screen, you must not modify the standard HRSSA
workflow process. Instead you should adhere to some best practices as detailed in this article

Why am I not allowed to change the HR_APPROVAL_FLAG in WF Builder?


There are two reasons for this
1. If you change the AME Flag in WF Process HR_SIT_JSP_PRC, then subsequent patches from Oracle will override
your change, and all of a sudden your Approval process will stop working
2. Oracle have developed these items at Access Level 20, whereas your Workflow access level as an implementer is
100+.
Therefore you will not be allowed to change the WF Attribute, unless you decide to set the access level to 20 for your
development as well. Reducing the access level below 100 is not recommended, because such changes are not
upgrade safe.
To learn about Workflow access levels, see the presentation in this link
How do I change the AME Flag, without modifying the standard workflow process?
In order to do so, you must implement the following steps. We will latter see these steps in detail
1. In WF Builder, set your Workflow Access Level to 100
2. Make a custom copy of the WF process HR_SIT_JSP_PRC and name it as XXFT_HR_SIT_JSP_PRC
3. Within Workflow process XXFT_HR_SIT_JSP_PRC, open Review activity, and in Node Attribute tab set the
HR_APPROVAL_REQ_FLAG to "Yes-Dynamic Approval"
4. Save this workflow file as XXFT_SSHRA.wft
5. Upload this workflow in UPGRADE Mode using the WFLOAD command.
6. Change the AOL Function that you created in Part 1/2 of this article.
http://www.apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/418-self-service-hrms-ame-sit-oaf
In the parameter field of AOL Function, ensure that the value of pProcessName is changed as below

Old Value pProcessName=HR_SIT_JSP_PRC


New Value pProcessName=XXFT_HR_SIT_JSP_PRC
By implementing the above steps, you will notice that our custom screen will now be calling the custom workflow
process named XXFT_HR_SIT_JSP_PRC. This workflow process name can be used in AME Set to build the desired
approval logic.

Now, the steps in detail....


Open the HRSSA workflow in workflow builder, and set your access level to 100 or above.

Right click on the Workflow Process that you wish to customize and click "Copy" as shown below

Give this newly copied WF process a name, as shown below.


Internal Name=XXFT_HR_SIT_JSP_PRC
Display Name=XXFT SIT Holiday Complaint

For the "Review Page 4.0" activity, set the HR Approval required property to "Yes - Dynamic Approval"

Preserve Customizations to Oracle Workflows


http://apps2fusion.com/apps/workflows/193-preserve-customizations-to-oracle-workflows

Preserve_Customizat
ions_in_Oracle_Workflow.ppt

Self Service HRMS and AME Part 5 - Understanding


HR_API_TRANSACTIONS
http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/422-hrapitransactions
When a Self Service HRMS user creates any data from the screens, such data goes and resides in some temporary
tables. This data is retained within the temporary tables until the transaction is Completed. A transaction in this
example gets completed when Holiday Rejection complaint is either Rejected or Approved. These temporary table
names begin with name HR_API%. In reality, the data entered by the user is either stored within just one table i.e.
HR_API_TRANSACTIONS or within HR_API_TRANSACTION_VALUES. When the data is stored in just the
HR_API_TRANSACTIONS then the entire data entered by the user is captured in a CLOB column. This feature was
introduced couple of years ago, whereby for performance reasons the temporary data is captured in a clob column
named HR_API_TRANSACTIONS within HR_API_TRANSACTIONS. This CLOB column contains XML contents. By
now, you might have the following questions

1. What exactly is captured in CLOB column hr_api_transactions.transaction_document


2. How does Self Service HRMS decide whether the transaction data which is in-transit goes into CLOB or
HR_API_TRANSACTION_VALUES.
3. How is this temporary data used by AME
4. How is the data transferred from temporary tables to base tables in HRMS.
In this article I will answer these questions, so that you can proceed with the AME bits that depends upon this
information. In addition to this, you will also learn how the "SAVE FOR LATTER" feature works in HRMS.
As soon as you enter any data in Self Service HRMS screens and navigate to the next page, an entry is created in
HR_API_TRANSACTIONS. Of course, the AME API's are called "during" the approval process which happens after
the data has been submitted for approval. This means at the time of "AME Engine processing" the data entered by
the Self Service HRMS Screen is in-transit, i.e. in temporary tables. In fact, within the AME, you will be passed the
transaction_id from hr_api_transactions. Therefore the AME engine has a handle to the entire in-transit data via
hr_api_transactions.transaction_id. Using this TransactionId handle, you can either query the CLOB XML in SQL or
you can query HR_API_TRANSACTION_VALUES.
1. What exactly is captured in CLOB column hr_api_transactions.transaction_document
In this column the entire state of the Application Module is captured. Application Module in OA Framework manages
the transaction state and also serves as a cache of the data in the memory. In this example, when the user enters a
Holiday Rejection Complaint and submits for approval, then entry is created in table HR_API_TRANSACTIONS,
HR_API_TRANSACTION_STEPS and HR_API_TRANSACTION_VALUES. This also serves the purpose of SAVE
FOR LATTER. When you save a transaction for latter, effectively the entire data in the cache is dumped into
temporary tables. If the self service user wants to restart the transaction after few hours/days, then entered data is requeried from these HR_API temporary tables

2. How does Self Service HRMS decide whether the in-transit transaction data goes into XML CLOB
HR_API_TRANSACTIONS.TRANSACTION_DOCUMENT or into HR_API_TRANSACTION_VALUES.
In the old version of Self Service HRMS, all the temporary information is captured in the following tables.
HR_API_TRANSACTIONS
HR_API_TRANSACTION_STEPS
HR_API_TRANSACTION_VALUES
3. How is this temporary data used by AME
Inside AME, you usually write SQL statements against AME Attributes and AME Approval Groups. In
those SQL statements, you can reference HR_API_TRANSACTIONS.TRANSACTION_ID by using convention
:transactionId
4. How is the data transferred from temporary tables to base tables in HRMS.
Oracle executes an API named hr_transaction_swi.commit_transaction which takes the transaction_id as parameter.
This transfers the data from temporary tables to the base tables.

DECLARE
v_trans_api_result VARCHAR2(1);
BEGIN
v_trans_api_result :=
hr_transaction_swi.commit_transaction
(
p_transaction_id => n_hr_api_transaction_id --pass the transaction_id here
,p_validate

=> hr_api.g_false_num

,p_effective_date => sysdate


);
END;
The above API is usually called when Self Service HRMS Transaction is completed, for example when Approved.
This is executed via one of the activities in HRSSA workflow after AME processing is completed.
In the event AME approval is not required, hr_transaction_swi.commit_transaction is called immediately after the user
submits the data from Self Service HRMS screen

Self Service HRMS - Design and Unit test AME


http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/423-sshr-ame-approval-group-workflowhr-api-transactions
Understanding AME Concepts (Already covered above. These are just the links.)
http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/395-ame
http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/396-sshr-approval-management-engine
http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/397-rbac-ame
How will the AME calculate the Manager's manager?
In AME, the approver list is calculated using something known as Approver Group. The approver group can be a
static list of people or a dynamic list of people. The dynamic list of approvers is calculated by executing a SQL
statement. This SQL statement and its unit testing will be shown as a video demo in the next article.
In this case, we will write a SQL Statement that returns the name of the Manager's Manager of the person that
created the Holiday Rejection Complaint record.
The AME is called from a specific screen, i.e. in this case Special Information Types screen. How will the AME
get a handle to the original transaction/records for which AME is being called?
In AME, each AME Flow can be considered as an "AME Transaction Type". The SSHR screens pass a parameter to
the AME Transaction Type. The name of the parameter passed by Self Service HRMS to AME is called TransactionId.
This Transaction Id gives a handle back to the original transaction, which in this case is data entered via Holiday
Rejection Complaint screen. Therefore by using the TransactionId, the AME Engine/AME SQL's can reference the
originating transaction for which Approver List is being calculated.

While the Approval is in progression, the data remains in temporary tables named
HR_API_TRANSACTION_VALUES [in case of SIT. Some other screens use XML CLOB in
hr_api_transactions.transaction_document]. Therefore if your custom logic within the AME wants to access the
original transaction data, that can be done by either querying HR_API_TRANSACTION_VALUES or by parsing the
XML within the CLOB column.
The primary key for table HR_API_TRANSACTIONS is Transaction_id. This Transaction Id is passed as a parameter
to the AME Engine for SSHR AME Transaction Type. Therefore AME Trx Type will be passed the TransactionId using
which it can get the handle to contents of HR_API_TRANSACTIONS

How do we know which AME Transaction Type will be called by our Custom Screen?
If you revisit Part-2 of this article, you will notice that the AME Transaciton Type and AME Trx Type ApplicationId are
passed as parameters to the AOL Form Function.
The parameters field in AOL Function definition contains AMETranType=SSHRMS&pAMEAppId=800
How do we build the logic for our solution?
We will be building a logic in AME that is similar to below
IF WORKFLOW_PROCESS_NAME='XXFT_HR_SIT_JSP_PRC'
THEN
Return Approver Name from AME Attribute XXFT_MANAGERS_BOSS_GROUP
END IF ;
What is XXFT_MANAGERS_BOSS_GROUP?
XXFT_MANAGERS_BOSS_GROUP will be a custom defined AME Approval Group that you can define. To this AME
Approver Group, you can attach the following SQL Statement. This SQL statement returns the FND_USER.USER_ID
of the Manager's manager for the employee that created a record in "Holiday Rejection Complaint" screen.

select 'user_id:' || fu.user_id


from hr_api_transactions

hat,

per_all_assignments_f

paaf,

per_all_assignments_f

paaf2,

PER_ASSIGNMENT_STATUS_TYPES past,
PER_ASSIGNMENT_STATUS_TYPES past2,
fnd_user

fu

where hat.transaction_id = :transactionId


and hat.selected_person_id = paaf.person_id
and paaf.effective_start_date <= sysdate
and nvl(paaf.effective_end_date, sysdate) >= sysdate
and paaf.primary_flag = 'Y'
and paaf.assignment_status_type_id = past.assignment_status_type_id
and past.user_status = 'Active Assignment'
and paaf.supervisor_id = paaf2.person_id
and paaf2.effective_start_date <= sysdate
and nvl(paaf2.effective_end_date, sysdate) >= sysdate
and paaf2.primary_flag = 'Y'
and paaf2.assignment_status_type_id = past2.assignment_status_type_id
and past2.user_status = 'Active Assignment'
and paaf2.supervisor_id = fu.employee_id

What are the AME Implementation Steps for this solution?


These are listed below
1. Create AME Condition that checks if the workflow process name = XXFT_HR_SIT_JSP_PRC
5. Create AME Approver Group XXFT_MANAGERS_BOSS_GROUP returns the name of Manager's Manager
FND_USER.USER_ID
2. Create an AME Rule named "XXFT Holiday Rejection Complaint"
3. Attach this rule to the condition of Step 1
4. Add an action to this rule get the approver from XXFT_MANAGERS_BOSS_GROUP
6. When the end user initiates a "Holiday Rejection Complaint", then the custom HRSSA workflow process is
instantiated. This calls the AME Engine to get next approver.
The condition of Step (2) above is evaluated to be TRUE. Therefore the approver is returned by executing the SQL
Statement against XXFT_MANAGERS_BOSS_GROUP

Creating the AME Rule in Self Service HRMS - Part 7

http://apps2fusion.com/apps-training/apps-functional-documents/ame-sshr/424-ame
See Presentation

Setup and Concepts and Testing


Approval Process Setup
1.
2.

Select the transaction type


Define the components
Approvals Management uses these components within the approval rules.
a. Attributes - Define attributes to fetch business facts for a specific transaction.
b. Conditions - Define conditions to evaluate attributes within rules. If all conditions in a rule are true
then the rule is active for the transaction.
c. Action Types - Enable action types to specify the action to take if a rule is active for a transaction.
d. Approver Groups - Define approver groups to contain approvers who are usually members of
peer groups such as payroll or expenses department.

3.

Define the approval rules (AME Rule) - Approval Rules determine the approvers or FYI notification recipients
required for a business transaction.
Test Workbench - Define test cases or test real transactions to verify the approval setup, rules and
associated approvers.

4.
5.

Approvals Management Business Analyst Responsibility


Attribute + Conditions + Action Type + Approver Group AME Rule
Approvals Management Administrator Responsibility
AME Rule AME Transaction Type

Attributes Screen

It can be any package.function in the query with transactionId being the parameter. This transaction ID is from the
table HR_API_TRANSACTIONS. Against the transactionId we can get several other values like person_id etc.

Condition Screen

Approver Group Screen

Action Type Screen


There are several Rule Types here e.g. (Chain of Authority, Substitution, Pre List Approval Group etc.). For regular
supervisory approval, we choose Rule Type = Chain of Authority.
Now this has got 2 Action Types in it.
Chains of authority
approval-group chain of authority

Based on number of supervisory levels


Chain of authority includes an approval group

Actions within Chain of Authority action type are Require approvals up to the first superior, at most, Require
approvals up to the first two superiors, at most etc.
Actions within approval-group chain of authority action type are Require approval from XXHR First Approver where
XXHR First Approver is the Approver Group created.

Rule Creation Screen


Step1: Define Name of AME Rule, Rule Type etc.

Step 2: Add Conditions

Step 3: Add Action. Select action type as Chains of authority or approval-group chain of authority and add the
appropriate action.

Step 4: Review and Submit the rule.

Test Screen
Screen 1: Landing Page. Create a new test case here.

Screen 2: Test case creation screen

Approval Management Administrator Responsibility - Dashboard Page

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy