SSHR Approvals Using AME

Doc ID: Note:360515.1 Type: BULLETIN

Last Revision Date: 08-JUN-2006 Status: PUBLISHED

In this Document
Purpose
Scope and Application
SSHR Approvals Using AME
References

Applies to:
Oracle HRMS (Self Service) - Version:
Information in this document applies to any platform.

Purpose
This article gives a functional and technical view of how Self-Service Human Resources
(SSHR) uses AME for approvals

Scope and Application

This article is intended for technical consultants, analysts, and customers using SSHR
V4.1 or higher.

SSHR Approvals Using AME

1. Overview
2. What is AME?
3. How does SSHR use AME?
4. How do you control how SSHR transactions are approved?
5. How do other applications use AME?
6. Common Issues

1. Overview
A major change in SSHR approvals was introduced from SSHR V4.1 onwards.
This is that approvals default to using Oracle Approvals Management (AME) and
not the SSHR-specific method described in Note 111574.1

AME is a self-service web application (it’s not part of SSHR) which lets users
defineNote 111574.1
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.

SSHR (or any other application) communicates with AME whenever it needs either:
- a list of approvers, for example if the transaction uses dynamic approval, SSHR will
call AME to get the approver names;
- to get the next approver in the approval chain, for example when a manager in the
chain has approved the transaction.

AME records each approval and recalculates the list each time it is called.

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.

2. What is AME?

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 that
please see Implementation Guide - AME.B (MetaLink Note 336901.1).

3. How 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.

iLearning has it's own seeded transaction type called 'Learning Management' with a
seeded rule which also uses the supervisor hierarchy.
iRecruitment has a seeded transaction type called 'iRecruitment Vacancy Approval'
with several seeded rules.

4. How do you control how SSHR functions are approved?

To ensure a function goes through the approvals process you will generally need to set
the attribute HR_APPROVAL_REQ_FLAG in the Review function of the workflow
process to 'Y' (yes) or 'YD' (yes, dynamic). This is done in Workflow Builder.

Some functions are slightly different.

For example in Appraisals, the flag to indicate if approval is required is a parameter in the
function definition.
Query up the Standard Appraisals function (HR_STANDARD_APPRAISAL_SS) and in
the Parameters field (under the Forms tab) you will see a parameter
'&pApprovalReqd=YD'. The value of this parameter can be changed to any of the values
'YD' yes, dynamic;
'Y' yes;
'N' no approval.
This parameter is specific to the functional module which uses Workflow for approvals
only and not for page flow as done with most of the SSHR functionality.

Each menu option in the SSHR responsibilities is defined as a function.

These functions can be queried up in System Administrator ->Application->Functions.
In the Parameters field (under the Forms tab) you will see the AME parameters. They are
&pAMETranType and &pAMEApplid. They identify the transaction type and
application_id that are required by AME.
If you remove the &pAMExxx parameters from this field then AME will not be called to
identify the approvers. Instead the HR_APPROVAL_CUSTOM code will be used (Note
111574.1) which can be edited to generate a list of approvers using PL/SQL.

5. How do other Applications 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.

6. Common Issues

1. Workflow Attribute HR_DYNAMIC_APPROVAL_LEVEL is not taking effect.

Approval is required for a SSHR function so the attribute
HR_APPROVAL_REQ_FLAG has been set to 'Yes - Dynamic Approval'
and HR_DYNAMIC_APPROVAL_LEVEL has been set to 1 in the relevant workflow
process.
But the approval is sent to more than 1 manager.

The attribute HR_APPROVAL_REQ_FLAG must be set but the attribute

HR_DYNAMIC_PROVAL_LEVEL is not used if AME is called.
The number of levels of approval is defined in the Action for the AME rule.
2. ORA-20001: The approver identified by the following parameters is invalid:
originating system PER originating system ID PER_ID. Please delete or replace this
approver wherever they occur in AME including approval groups, list-modification
conditions, and substitution actions.
This approver does not have an entry in wf_role(ORIG_SYSTEM_ID = 9999)

This error will be generated if AME selects a person as an approver and that person has
no record in WF_ROLES.
To check WF_ROLES you can run the sql

select orig_system, orig_system_id, name,

display_name, status, expiration_date
from wf_roles
where orig_system_id = 9999
and orig_system = 'PER';

If the above query does not return any rows then no role exists for person_id=9999.
This may be because the person (person_id=9999) has been terminated in which case he
should be removed from any groups used in AME.
If the person is a current employee then ensure the person has an fnd user name.
If they already had a user name then run the Synchronize WF LOCAL tables concurrent
process.

3. Loop in supervisor chain

oracle.apps.fnd.framework.OAException: java.sql.SQLException:
ORA-01436: CONNECT BY loop in user data
ORA-06512: at "APPS.AME_DYNAMIC_APPROVAL_PKG", line 502
ORA-06512: at line 1

This error is given if there is a loop in the supervisor chain, for example, A -> B -> C ->
B.
You can use the AmeSupervisorChain.sql below to check the supervisor chain for any
given employee and you will need to then correct the Supervisor field on the assignment
screen where necessary to remove the loop.

4. SQL to use to display a chain of supervisors

Below is the code required to create a procedure to calculate and display the people
included in the supervisor chain from a specified starting person.

create or replace procedure ameSupervisorChain(personIdIn in integer) as

currentPersonId integer;
jobLevel varchar2(50);
loopCounter integer;
personId varchar2(50);
stringLength integer;
supervisor varchar2(500);
supervisorPersonId integer;
begin
dbms_output.enable(1000000);
loopCounter := 0;
currentPersonId := personIdIn;
dbms_output.put_line('PERSON_ID NAME JOB LEVEL');
loop
loopCounter := loopCounter + 1;
if(loopCounter > 50) then
dbms_output.put_line('That''s 50 approvers; there''s probably a loop in the chain of
authority.');
exit;
end if;
select
to_char(person_id),
substrb(first_name || ' ' || last_name, 1, 50)
into
personId,
supervisor
from per_all_people_f
where
person_id = currentPersonId and
trunc(sysdate) between effective_start_date and effective_end_date;
stringLength := lengthb(supervisor);
loop
if(stringLength = 50) then
exit;
end if;
supervisor := supervisor || ' ';
stringLength := stringLength + 1;
end loop;
stringLength := lengthb(personId);
loop
if(stringLength = 20) then
exit;
end if;
personId := personId || ' ';
stringLength := stringLength + 1;
end loop;
begin
select to_char(nvl(per_jobs.approval_authority, 0))
into jobLevel
from
per_jobs,
per_all_assignments_f
where
per_jobs.job_id = per_all_assignments_f.job_id and
per_all_assignments_f.person_id = currentPersonId and
per_all_assignments_f.primary_flag = 'Y' and
per_all_assignments_f.assignment_type = 'E' and
per_all_assignments_f.assignment_status_type_id not in
(select assignment_status_type_id
from per_assignment_status_types
where per_system_status = 'TERM_ASSIGN') and
trunc(sysdate) between
per_all_assignments_f.effective_start_date and
per_all_assignments_f.effective_end_date;
exception
when no_data_found then
jobLevel := '[not found]';
end;
dbms_output.put_line(personId || supervisor || jobLevel);
begin
select supervisor_id
into supervisorPersonId
from
per_all_assignments_f
where
person_id = currentPersonId and
per_all_assignments_f.primary_flag = 'Y' and
per_all_assignments_f.assignment_type = 'E' and
per_all_assignments_f.assignment_status_type_id not in
(select assignment_status_type_id
from per_assignment_status_types
where per_system_status = 'TERM_ASSIGN') and
trunc(sysdate) between
per_all_assignments_f.effective_start_date and
per_all_assignments_f.effective_end_date;
if(supervisorPersonId is null) then
exit;
end if;
currentPersonId := supervisorPersonId;
exception
when no_data_found then exit;
end;
end loop;
end ameSupervisorChain;
Compile the procedure in the APPS schema, get the person_id of the person performing
the SSHR transaction that requires approval and run it like this:

SQL> set serveroutput on;

SQL> execute ameSupervisorChain(&person_id);