SSHR Ame Approval

Configuring Oracle Approvals
Management (R11i10) for Oracle

Self-Service Human Resources
V4
An Oracle White Paper
August 9th 2005
(Added example of Position Support & example
support functions)
Configuring Oracle Approvals Management for

Oracle Self-Service Human Resources V4
Executive overview............................................................................. 4
Introduction......................................................................................... 4
References....................................................................................... 5
SSHR Transaction Concepts............................................................... 5
Transactions Data Structures .......................................................... 5
Relating Transactions Data Across SSHR, Workflow, and AME.. 6
Approvals in SSHR............................................................................. 7
Basic Approvals Loop..................................................................... 7
Resolving Routing Decisions with AME or Customizable PL/SQL8
Calling AME from SSHR ............................................................... 8
Oracle Approvals Management .......................................................... 8
Overview......................................................................................... 8
Configuration .................................................................................. 9
Rules, Conditions and Attributes ................................................ 9
Operation......................................................................................... 9
Transaction Types and Transaction Categories ............................ 10
Headers and Line Items............................................................. 10
Reasons for Having Multiple Transaction Types.......................... 11
Different Attribute Usages ........................................................ 11
Reasons for Combining Multiple Transaction Categories............ 11
Common Attribute Usages........................................................ 11
Multiple Step Transactions Combining Different Transaction
Categories ................................................................................. 11
Default AME Configuration For SSHR........................................ 11
Example Scenario ......................................................................... 12
Example Hierarchy ................................................................... 12
Example Transaction 1 Default Configuration ...................... 13
Analyzing Your Business Requirements .......................................... 15
Planning Grid ................................................................................ 16
Mapping Business Requirements to AME Configuration ................ 17
Turning on Approvals ................................................................... 17
Starting Points for Chains for Authority....................................... 18
Authority Levels............................................................................ 19
Default Approval Policy ............................................................... 19
Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4
Page 2
Example Transaction 2 Personal Information........................ 20

Salary Change Policy .................................................................... 20
Example Transaction 3 Salary Change .................................. 21
Transfer Approval Policy.............................................................. 22
Example Transaction 4 Simple Transfer................................ 24
Example Transaction 5 Transfer Direct Reports.................... 24
Other Capabilities ......................................................................... 25
Configuring Attributes ...................................................................... 25
Identifying What Attributes Are Needed ...................................... 26
Policy Attributes ....................................................................... 26
Chain of Authority Attributes ................................................... 26
Conditional Attributes............................................................... 28
Attribute Usages............................................................................ 29
Transaction Categories.................................................................. 30
Header Level or Line Level .......................................................... 30
Transaction Types ......................................................................... 31
Migrating Configurations Between Instances ............................... 31
Summary of Configuration Methods and Skill Levels ..................... 32
Conclusion ........................................................................................ 32
Appendix A Attribute Usages ........................................................... 33
Appendix B Functions ...................................................................... 36
Appendix C Dynamic Approval Groups........................................... 39
Appendix D Position Hierarchy Support .......................................... 41
Appendix E Example Support Functions.......................................... 45
Page 3
EXECUTIVE OVERVIEW
Your enterprise employs thousands of people in many departments around the

world. Naturally, you require your Human Resources business processes to be
conducted as efficiently as possible so that employees and managers are free to
focus on their primary tasks. However, you also need assurance that all
transactions are subject to effective controls. This paper describes how, within
the Oracle e-Business Suite, you can exploit the flexibility of Oracle Approvals
Management (AME) across the breadth of Self-Service Human Resources
(SSHR) to establish and enforce appropriate approval rules for any kind of
transaction.
RELEASE LEVEL
Important: This document is meant for R11i10 customers and forward as there
are changes to the construction of line level attributes for this release.
INTRODUCTION
The decentralization that is possible with self-service applications is only

practical if transactions are subject to appropriate management approval before
they become effective. This requires an approval mechanism and the ability for
system administrators to configure it to match their enterprise approvals policies,
which may be different for different business process and in different
organizations.
Since the earliest releases, SSHR modules, where appropriate, have been
designed on top of an approvals workflow and provided with various
configuration options to allow system administrators to turn approvals on or off
for different processes. At certain points in the approvals workflow, SSHR calls
a customizable PL/SQL package which customers may choose to modify to
implement more complex approvals rules. A limitation of this approach is that a
business process owner wishing to make changes to approvals policies has to
enlist the services of a PL/SQL programmer.
To shift control of approvals as far as possible into the hands of the business
process owners (for all self-service applications in the e-Business Suite, not just
SSHR), Oracle has introduced the new Oracle Approvals Management (AME)
application. AME is a generic, rules based approvals engine with a user-friendly
configuration interface and an extensible architecture which is capable of
meeting the needs of the most complex enterprises.
AME was first released in December 2001 and is subsequently being integrated
into all e-Business Suite applications that use approvals. SSHR release 4.1 was
the first version of SSHR to integrate with AME. By default it uses AME
services to build and track the approval list for a transaction. (However,
customers have the option to revert to the customizable PL/SQL package if they
wish.)
Page 4
The AME configuration delivered with SSHR releases 4.1 and 4.2 simply
emulates the default logic delivered in the customizable PL/SQL package. The
purpose of this paper is to provide general guidance on further configuring AME
in association with SSHR. The paper begins with a review of SSHR transaction
concepts and in particular the handling of approvals. This is followed by an
overview of Oracle Approvals Management and an explanation of how AME
integrates with SSHR. Finally, the paper provides example approval rules to
support some typical business requirements in the Human Resources arena.
Note: Although this paper focuses on the integration of SSHR with AME, most of
the principles covered here would be applicable to the integration of any
application that calls AME. Conversely, this paper does not attempt to describe
all of the capabilities of AME.
References
This paper is intended to supplement the following reference materials which

should also be studied for a full understanding of the topic.
Implementing Oracle Approvals Management
http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?282964
Implementing Oracle Self-Service Human Resources (SSHR) 4.2
http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?284440
SSHR TRANSACTION CONCEPTS
A user-friendly interface guides the user through a series of options, gathering

input until the user is ready to submit the transaction. The details of the
transaction are held in temporary storage in the database until all necessary
approvals have been recorded, at which time the changes become permanent.
Meanwhile, attributes of the pending transaction may be used as the basis for
approval rules.
Transactions Data Structures
Although a business user should be able to configure rules and conditions

without concerning themselves with the underlying details, knowledge of where
an applications transaction details are stored is essential to the successful design
and implementation of the approval attributes on which rules and conditions will
be based.
Note: The information in this section applies specifically to SSHR, which
includes the self-service components of Benefits, HR, Payroll, and Training. If
you are creating attributes for another application (such as OTL, iRecruitment
or any non-HRMS application) you will need to research the relevant
documentation to determine the location of that applications temporary
transaction data.
Page 5
SSHR stores transaction data in a series of three master-detail-detail tables

which have names beginning with HR_API_TRANSACTION. The table
names and relationships are shown in the following diagram.
Figure 1 SSHR Transactions Tables
HR_API_TRANSACTIONS
HR_API_TRANSACTION_STEPS
HR_API_TRANSACTION_VALUES
Each individual SSHR transaction is represented by a single row in

HR_API_TRANSACTIONS and at least one row in
HR_API_TRANSACTION_STEPS. The header row in
HR_API_TRANSACTIONS contains a unique transaction_id and other
attributes common to all transactions such as the requestor and timestamp.
In general, each row in HR_API_TRANSACTION_STEPS corresponds to an
API used by the transaction to validate and/or commit data to the applications
tables. Complex transactions (for example, workflow chained processes such as
Employee Status Change V4.0) may have multiple steps. For example, one step
may correspond to an Assignment API and another to a Pay Rate API.
Specific transaction information relating to each step is held in
HR_API_TRANSACTION_VALUES in the form of parameter-value pairs. For
example, a salary proposal transaction step may have a value row with Name =
P_PROPOSED_SALARY and Number_Value = 50000.
These tables contain many of the attributes on which customers will want to
base approval rules and conditions. Other attributes may be stored in other tables
and derived by joining on foreign key information in the
HR_API_TRANSACTIONS tables (for example, to get person or assignment
information for the person selected in the current transaction).
Relating Transactions Data Across SSHR, Workflow, and AME
Some information about a SSHR transaction may also be found in the internal
tables of Oracle Workflow and Oracle Approvals Management. These other
Page 6
applications provide generic services to a wide range of applications and

therefore have their own methods of uniquely identifying a transaction as
depicted in Table 1.
Table 1 Transaction Identifiers
Application
Workflow
SSHR
AME
Unique Identifier
Example
Item Type
HRSSA
+ Item Key
12345
Transaction Id
65432
Transaction Type
SSHRMS
+ Application Id
800
+ Transaction Id
65432
For SSHR transactions, the Transaction Id used in the AME unique identifier
has the same value as the Transaction Id used in the
HR_API_TRANSACTIONS table.
Note: AME requires the calling application to supply three pieces of identifying
information with each transaction - Transaction Type, Application Id, and
Transaction Id and it is the responsibility of the calling application, in this
case SSHR, to ensure that the Transaction Id is unique within a Transaction
Type.
For each transaction, SSHR stores the corresponding Workflow Item Type and
Item Key as attributes in the HR_API_TRANSACTIONS table.
Note: SSHR generates the Item Key and Transaction Id values from different
sequences.
APPROVALS IN SSHR
Basic Approvals Loop
Note: The information in this section applies specifically to SSHR. For other
applications, consult the relevant documentation.
All approvals mechanisms used in SSHR follow the basic approvals loop shown
below. The logic checks whether the current approver is the final approver in the
hierarchy. If the current approver is not the final approver, the application
fetches the next approver who then receives the approval notification. The next
approver can either reject the transaction, approve the transaction, or (for
simplicity, not shown here) return the transaction for correction.
Page 7
Figure 2 SSHR basic approvals loop

Start
Get next
approver
No
Final
approver?
Yes
End
(Approved)
No
End
(Rejected)
Yes
Notify next
approver
Approved?
Refer to Approvals chapter of Implementing Oracle Self-Service Human

Resources (SSHR) 4.1 or later for more information on this workflow process.
Resolving Routing Decisions with AME or Customizable PL/SQL
The key decision points in this flow are the boxes labeled Final Approver? and
Get Next Approver in the above diagram. Prior to the availability of AME,
SSHR would resolve these decisions by executing corresponding functions in
the customizable PL/SQL package HR_APPROVAL_CUSTOM. However,
starting with release 4.1, it has been an option for SSHR to call equivalent AME
APIs instead.
Calling AME from SSHR
For any SSHR module to use AME, the AOL function that calls it must include
the parameters pAMETranType and pAMEAppId. (SSHR adds TransactionId,
the third element of the unique key, at runtime.)
Note: From SSHR release 4.1, seeded functions are delivered with these
parameters in place and set to pAMETranType=SSHRMS and
pAMEAppId=800. To revert to the customizable PL/SQL package you would
strip these parameters from your custom functions.
ORACLE APPROVALS MANAGEMENT
Overview
AME provides list management services to calling applications such as SSHR.

Note: AME does not manage the approvals flow, or the notification of
approvers. These remain the responsibility of the calling application.
Page 8
Configuration
Rules, Conditions and Attributes
Rules are defined in terms of conditions (expressed as an attribute

and a range of values) and the corresponding required approval
action.
Attributes and Attribute Usages
Attributes are defined in terms of an attribute name and attribute

usage which may be either a static value or a dynamic SQL
statement.
Approval Types and Approval Handlers
Approval actions are expressed in terms of an approval type, for

example, a chain of authority based on supervisor level, associated
with an approval handler. Approval types and handlers have been
seeded for several variations on pre approvers, chain of authority
approvers, and post approvers.
Operation
The operation of AME in conjunction with SSHR can be described at a high

level as follows. The description would apply equally well if you substituted
another calling application (for example, Web Expenses) in place of SSHR.
A user submits a transaction. The transaction is associated with a

specific transaction type (which can be configured by the system
administrator during set-up) and a unique transaction_id (which is
generated by the system at runtime).
SSHR passes the transaction type, application id, and transaction

id to AME which generates the list of approvers based on the rules
configured for this transaction type.
AME evaluates the conditions associated with the rules for the
current transaction. For any rule that satisfies all its conditions, AME
identifies the ordered list of approvers who must approve the
transaction. The results from multiple rules are merged into a single
ordered list in which pre approvers come before chain of authority
approvers and post approvers come last.
SSHR presents the list of approvers to the user in the Review page.
The user may choose to insert one or more additional approvers into
the list using the Dynamic Approvals functionality. If so, SSHR
passes this information on to AME to modify the list.
SSHR notifies each approver in turn. SSHR notifies each approver in

turn. SSHR tracks each approvers response (approved or rejected)
Page 9
and subsequently returns the Id of the next person on the list who has
not yet approved the transaction. AME is iteratively called to set
each approvers response (approved or rejected) status.
When there are no more approvers to be notified, SSHR records the

transaction as complete.
Transaction Types and Transaction Categories
AME is able to partition the approvals configuration for dissimilar transactions

into different Transaction Types. Generally there will be at least one
transaction type, possibly more, per calling application. For example, the
transaction type SSHRMS is seeded for SSHR, but you may need additional
transaction types depending on your requirements.
As you start to analyze your business requirements for approvals management
you may find it useful initially to group your transactions into transaction
categories and only later decide how many different transaction types you need
to accommodate them.
Note: Transaction Category is not a defined term in either SSHR or AME.
However it is used throughout this paper to identify distinct categories of
transactions from a business perspective and as a stepping-stone to identifying
distinct transaction types.
Start by formulating an approval policy (in other words, a set of rules) for each
transaction category in a format that can be reviewed by the business owners.
Next identify the attributes, conditions, and rules that will be needed to
implement the rules for these policies.
Headers and Line Items
A single transaction may consist of a header record and multiple detail records,
for example, an expense report. Transaction types for these categories of
transactions need to define a line item query which AME will use to retrieve
individual line items associated with a transaction id.
In SSHR you should consider taking advantage of this feature for transaction
categories that have multiple lines in HR_API_TRANSACTION_STEPS for
each row in HR_API_TRANSACTIONS (see Figure 1 in the Transactions Data
Structures section), unless you have no need to reference step level attributes in
your rule conditions.
A line item query would look like this:
Page 10
select hats.transaction_step_id
from hr_api_transaction_steps hats,
hr_api_transactions hat
where hats.transaction_id = hat.transaction_id
and hat.transaction_id = :transactionId
order by hats.transaction_step_id
Refer to Implementing Oracle Approvals Management for guidance on the syntax of
a line item query. You will need to create an Item Class of Line Item since this is not
seeded via the SSHR Integration.
Reasons for Having Multiple Transaction Types
Different Attribute Usages
If you find that your transaction categories have quite different attribute usages
and unrelated rules, you will probably find it convenient to separate them into
different transaction types. One advantage of this approach is that you can
specify a transaction type as a securing attribute on the Limited Business User
responsibility and use this to limit the scope of the configuration changes that a
particular business user can make.
Reasons for Combining Multiple Transaction Categories
Common Attribute Usages
There is currently no provision in AME to share or copy attribute usages among

transaction types. Consequently, if you discover significant commonality
between the attribute usages of several transaction categories you may find it
convenient to lump them all into a single transaction type.
Multiple Step Transactions Combining Different Transaction Categories
SSHR is unusual in that a single transaction may consist of several steps which
are quite different in nature and have different attribute usages. For example, the
Employee Status Change V4.0 function allows the user to combine assignment
changes, a salary proposal, a change of manager, and other activities into a
single transaction. You will need to combine all the transaction categories that
can occur in a single transaction into a single transaction type.
Default AME Configuration For SSHR
The AME configuration delivered for SSHR in releases 4.1 and 4.2 comprises
the following components:
A single AME transaction type SSHRMS with multiple attribute usages,
A single condition (WORKFLOW_PROCESS_NAME attribute is in a
configurable list of process names), and
Page 11
A single rule (if the WORKFLOW_PROCESS_NAME condition is true,

require approvals, using the approval type 'chains of authority based on
number of supervisory levels', up to the top of the approval hierarchy or to
10 levels above the initiator, whichever comes sooner).
Example Scenario
The concepts involved in approval routings are best understood in the context of
example scenarios using a typical hierarchy.
Example Hierarchy
For the example scenarios described in this paper we will use the example
hierarchy depicted in the following diagram. Each block represents a person and
the lines represent the supervisor relationships between them.
Note: To avoid over complicating the diagram, each person has only a primary
assignment. However, SSHR and AME can function equally well if people have
more than one assignment.
The label on each person block indicates the name of the Person (for example,
P21), the name of their current Job (for example, JB denotes Job B) and the
Approval Authority level associated with that job (for example, L2 indicates
approval authority level 2).
In the example scenarios we will generally select person P21 (highlighted in the
diagram), initiate a transaction (which may involve other people) and then
consider which people should approve the transaction.
Page 12
Figure 3 Example Supervisor Hierarchy

P51
JE L5
P55
JZ L5
Legend
P21 = Person 21
JB = Job B
L2 = Approval Authority level
2
P01
JH L3
P41
JD L4
P31
JC L3
P25
JX L2
P21
JB L2
P11
JA L1
P12
JA L1
P35
JY L3
P13
JA L1
P26
JX L2
P27
JX L2
P15
JA L1
Example Transaction 1 Default Configuration
In example transaction 1, person P31 logs into SSHR, selects the Change Base
Salary V4.0 function, and initiates a transaction for person P21. The Change
Base Salary V4.0 function is configured to use workflow process
HR_P_RATE_JSP_PRC and AME transaction type SSHRMS.
The user progresses through the transaction to the Review page at which point
SSHR calls AME and passes the Application ID (800), Transaction Type
(SSHRMS) and Transaction ID (system generated).
AME builds the list of approvers for transaction 1 based on the rules defined for
transaction type SSHRMS. There is only one rule, with a single condition based
on the WORKFLOW_PROCESS_NAME attribute which, in this case, evaluates
to the value HR_P_RATE_JSP_PRC. Since this process name is in the
conditions configurable list, the condition is true, the rule executes and AME
runs the approval handler for the 'chains of authority based on number of
supervisory levels approval type. The default configuration requires AME to
start with the transaction requestor (P31) and go up the supervisor hierarchy 10
Page 13
levels (or to the top if there are fewer than 10 supervisors above the requestor).
The initial list of approvers is, therefore, as shown in Table 2a below.
Table 2a Approvals for Example Transaction 1, Initial Status
Sequence
Approver
Notes
Approved?
P41
Transaction requestors supervisor
No
P51
2nd supervisor above the requestor
No
Successive chain of authority approvers
No
<=10
Pn
10th supervisor above the transaction
No
requestor, or top supervisor in the chain.
AME returns this list of approvers to SSHR which displays the names to the user
in the Review page.
At this time, the user would have the option to insert any dynamic approvers into
the list. Lets say that P31 wants the transaction to be pre-approved by someone
unrelated to the supervisor hierarchy, such as an HR representative, who is
represented in the example as P01. P31 inserts P01 into the list ahead of P41 and
SSHR passes this information to AME which modifies the list as follows:
Table 2b Approvals for Example Transaction 1, After Inserting Dynamic
Approver
Sequence
Approver
Notes
Approved?
P01
Inserted Dynamic Approver
No
P41
No
P51
No
No
<=10
Pn
No
SSHR displays the modified list of names to the user who then submits the
transaction for approval. SSHR uses workflow to notify the first approver, P01,
whose response is passed to AME which updates the status of the list.
Page 14
Table 2c Approvals for Example Transaction 1, After First Approval

Sequence
Approver
Notes
Approved?
P01
Yes
P41
No
P51
No
No
<=10
Pn
No
SSHR then asks AME for the name of the next approver who has not yet
approved the transaction and AME responds with P41. The process is repeated
until all approvers have approved.
Note: If the top of the supervisor hierarchy is reached before the specified
number of levels, AME compares this persons ID with the value configured in
the TOP_SUPERVISOR_PERSON_ID attribute and raises an error if they are
not the same. (This prevents a transaction being approved at an unintended
level in the case of an unplanned break in the supervisor hierarchy.)
Table 2d Approvals for Example Transaction 1, after Final Approval
Sequence
Approver
Notes
Approved?
P01
Yes
P41
Yes
P51
Yes
Yes
<=10
Pn
Yes
When AME responds to SSHR that there are no more approvers who have not
approved the transaction, SSHR applies the transaction data to the application
tables (using the appropriate API) before clearing it from the transaction tables.
ANALYZING YOUR BUSINESS REQUIREMENTS
Actual business requirements for approvals are likely to differ in one way or
another from the behavior described in the above example. Listed below are
some common variations:
Determine final approver in terms of job level rather than the number
of steps up the hierarchy
Page 15
Require pre and/or post-approval by one or more people, perhaps

identified by their roles in relation to the transaction requestor.
Require different approvals for different kinds of transaction
Require different approvals based on transaction attributes (for

example, the size of a proposed salary change)
Base chain of authority on position hierarchy instead of supervisor

hierarchy
Note: A position hierarchy based approvals handler is not among the handlers
that have been delivered with AME at the time of writing this paper, although
future delivery is intended. Customers wishing to take advantage of AMEs
extensible architecture to write their own approvals handlers should conform to
the development guidelines provided by the Approvals Management
development team.
Planning Grid
Before starting to set up AME, it is a good idea to organize your approval

policies into a planning grid, such as the one shown below, to clarify the level of
approval (and any pre or post-approvers) required for each category of SSHR
transaction, taking into account any particular conditions that might apply.
Page 16
Table 3 Approvals Policy Planning Grid

Transaction
Details
Pre
Mgr
VP
HR
HR
SVP
Post
Notes
Category*
Salary Change
Pct increase
<=30%
Salary Change
Pct increase
>30%
Transfer
Reassign
Must be
selected
approved in
employee to a
both from
different
and to
manager
management
hierarchies
Transfer
Assign new
Various
Must be pre
direct reports to
approved by
the selected
the various
employee. The
managers
direct reports
involved
currently report
to various
different
managers
Other
Default Policy
The selected
persons
manager
*Note: Refer to the earlier section Transaction Types and Transaction

Categories for an explanation of this term.
MAPPING BUSINESS REQUIREMENTS TO AME CONFIGURATION
We will now examine how to configure each of the above policies in AME.
Although these represent only a few examples, they can be extrapolated to cover
most eventualities. In this section, we discuss at a high level some of the
attributes that will be needed in AME. A more detailed description of each
attribute comes later.
Turning on Approvals
SSHR provides workflow attributes with which you can turn approvals on or off
for individual functions. However, configuring workflow attributes requires
levels of skill and access not generally held by business users. An alternative
strategy, once you have made the decision to use AME, is to have a system
Page 17
administrator set all the relevant workflow attributes to Yes (or Yes Dynamic
Approvals) so that the business users are able to exercise full control in AME.
Refer to Implementing Oracle Self-Service Human Resources (SSHR) 4.0 or
above for guidance on how to change the workflow attributes.
Starting Points for Chains for Authority
If you are using a chain-of-authority approval type you need to consider with
whom you wish the chain to begin. For single chains of authority, AME defaults
to the transaction requestor (in other words, the person initiating the transaction),
but you can override this if you wish. For dual chains of authority (useful, for
example, when a person is being transferred from one manager to another) you
need to define usages for first and second starting point attributes.
In designing your policy for chains-of-authority starting points, you need to
consider what to do in a variety of situations. For example, the selected persons
manager may or may not be the requestor. In a transfer, the selected persons
current or proposed manager may be NULL.
In our examples we adopt the policy shown in the table 4 below. (The attribute
usages to achieve the above policy will be described later.)
Table 4 Starting Points for Chains of Authority
Subjects
Current
Supervisor
Requestor
Subjects
Proposed
Supervisor
<NULL>
Not Requestor
<NULL>
<NULL>
Requestor
<NULL>
Not Requestor
Requestor
Not Requestor
Starting Point
(Supervisory
or Job)
Requestors
Supervisor
Subjects
Supervisor
Requestors
Supervisor
Proposed
Supervisor
N/A
Not Requestor
Not Requestor
N/A
Not Requestor
Requestor
N/A
First Starting
Point
(Dual Chains)
N/A
Second
Starting Point
(Dual Chains)
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Requestors
Supervisor
Subjects
Supervisor
Subjects
Supervisor
Proposed
Supervisor
Proposed
Supervisor
Requestors
Supervisor
In general, this means starting with the selected persons supervisor, or the next
higher supervisor if the transaction is initiated by the selected persons
supervisor. If there is no selected person for the current transaction, we start with
the transaction requestors supervisor.
When transferring the selected person from one manager to another we use dual
chains of authority using the selected persons current manager as the first
starting point and the proposed manager as the second starting point. If either the
current or proposed supervisor is NULL, we revert to a single chain of authority.
Page 18
Authority Levels
Rather than requiring transactions to be approved by some predetermined

number of supervisors above the starting point, you may prefer them to be
approved by someone having a certain level of authority. This concept is
implemented in AME and SSHR using Absolute Job Level approval types in
conjunction with an Approval Authority column on the Job table. It is up to each
customer to decide what numbers to use to represent different authority levels
and then to assign an appropriate number to each job in Oracle Human
Resources. In our example scenarios we use the approval authority levels shown
in Table 5.
Table 5 Example Approval Authority Levels

Job
Job Name
Approval
Authority
Senior Vice President, Operations
Senior Vice President, Sales
Vice President, Operations
Director, Operations
Director, Sales
Manager, Operations
Manager, Sales
Associate
Default Approval Policy
It is good practice to start by considering whether some minimum level of

approval is required for all transactions. You may have a policy allowing SSHR
transactions by default to be accepted without approval. However, if this is not
the case, you may want to define a default rule (in other words, a rule with no
specific condition) so that at least one approval is required in all cases.
Here we have chosen a default policy which requires approval by the supervisor
one level above the starting point. This can be accomplished using the rule in
Table 6a.
Page 19
Table 6a Rules for Default Approval Policy

Conditions
<None>
Rule Type
Approval
Approval Type
List
Require approvals up to
Chains of authority
Creation
at most one level
based on supervisory
level
Example Transaction 2 Personal Information
In example transaction 2, person P31 logs into SSHR, selects the Change
Personal Information V4.0 function, and initiates a transaction for person P21.
This transaction satisfies none of the conditions of the more specific rules so
only the default rule executes and the initial list of approvers contains a single
approver as shown in Table 6b.
Table 6b Approvals for Example Transaction 2
Sequence
Approver
P41
Notes
Approved?
Supervisor of the selected persons
No
supervisor (since the selected persons

supervisor is the transaction requestor)
Salary Change Policy
The example policy for salary changes involves a pre-approver in addition to

chain-of-authority approvers. This example illustrates how the results from
overlapping rules are combined to produce a single ordered list.
Here, we introduce a Transaction Category attribute which you can use to
identify transactions that may involve a change in salary.
Since the policy specifies different approvals for increases above and below a
threshold of 30%, we need an attribute representing Salary Increase Pct.
The policy requires pre-approvals by the HR Rep for all changes in salary. Since
the HR Rep may be different depending on the selected person, we need to
create a dynamic approval group (in other words, it is based on a SQL query
which returns the correct person Id at runtime).
This policy can now be implemented with the rules shown in Table 7a.
Page 20
Table 7a Rules for Salary Change Approval Policy

Conditions
Rule Type
Approval
Approval Type
Transaction Category
Pre-List
Require Pre-Approval
Group approval
in {SALARY}
Approval-
from HR Rep
before chain of
Group
AND
authority
Salary Increase Pct

<0
Pre-List
Group approval
in {SALARY}
Approval-
from HR Rep
before chain of
Group
AND
authority
0<Salary Increase Pct

List
Chains of authority
in {SALARY}
Creation
at most level 4
based on absolute job

level
AND
0<Salary Increase Pct
<=30
List
Chains of authority
in {SALARY}
Creation
at most level 5

level
AND
30<Salary Increase
Pct
Example Transaction 3 Salary Change
In example transaction 3, person P31 logs into SSHR, selects the Change Base
Salary V4.0 function, and initiates a transaction for person P21 specifying a
salary increase of 15%. This transaction satisfies the conditions of the default
rule and the second and third of the four salary-policy rules. Altogether, three
rules fire and AME merges the results to produce the initial list of approvers
shown in Table 7b.
Sequence
Approver
Notes
Approved?
P01
HR Rep
No
P41
No
supervisor. (Approval Authority level is 4

so there is no need to go higher)
Page 21
If the proposed salary increase had been above 30%, the 4th rule in Table 7a
would have fired in place of the 3rd rule, requiring approvals up to level 5. The
list of approvers would have added an entry for P51 after the other two
approvers in Table 7b.
Transfer Approval Policy
The example policy for Transfers demonstrates the use of dual chains of
authority and dynamic approval groups.
The key participants in a transfer (also known as a Change Manager or
Change Supervisor) transaction are the selected person and their current and
proposed managers. In addition, there may be other current (or proposed)
managers for the selected persons proposed (or current) direct reports.
For a simple transfer, in which the selected person is assigned to a different
manager, the example policy requires approvals up to VP level on both sides of
the transfer, in other words, starting with the current manager and the proposed
manager in turn. This can be accomplished using the dual chains of authority
approval type.
The policy can now be implemented with the first three rules in Table 8a.
Page 22
Table 8a Rules for Transfer Approval Policy

Conditions
Rule Type
Approval
Approval Type
List
Chains of authority
in {TRANSFER}
Creation
at most level 4 in the first
includes two chains,
chain
each based on job
AND
level
Current Supervisor >0

AND
Transfer Proposed
Supervisor >0
List
Require approvals at
Chains of authority
in {TRANSFER}
Creation
most 3 levels up the
includes two chains,
second chain
each based on job
AND
level
Current Supervisor >0

AND
Transfer Proposed
Supervisor >0
List
Chain of authority
in {TRANSFER}
Creation
at most level 4

level
Pre-List
Group approval
in {TRANSFER}
Approval-
from
before chain of
Group
TRANSER_PRE_APPRO
authority
VERS
Note that dual chains require two matching rules; one for each chain. For our
example policy we have added conditions to these rules to prevent them firing in
the event that we cannot identify both starting points, in which case, only the
third rule fires and we have a single chain of authority. The third rule is intended
to generate the same approvers as the first chain rule so that when both fire, the
effect is the same as if either rule had fired.
Page 23
Example Transaction 4 Simple Transfer
Manager V4.0 function, and initiates a transaction for person P21 specifying
P35 as the new manager. This transaction satisfies the conditions of the default
rule and all of the transfer policy rules. These rules all fire and the initial list of
approvers will contain the approvers shown in Table 8b.
Sequence
Approver
P41
Notes
Approved?
No
supervisor (Starting point for first chain,

AND general transfer rule AND default
rule)
Final approver in this chain, since this
person has level 4 approval authority
2
P35
Selected persons proposed supervisor
No
(Starting point for second chain)

person has level 3 approval authority,
next higher approver is level 5 and the
rule requires at most level 4.
For a transfer involving the assignment of direct reports to, or away from, the
selected person, the example policy requires the various other managers
involved to pre-approve the transaction. This can be accomplished by defining a
dynamic approval group based on a SQL query which identifies the supervisors
in question. For the example, well call this group
TRANSER_PRE_APPROVERS. The related query should be constructed to
exclude any supervisor who is also included in one of the dual chains (for
example, the current or proposed supervisor of the selected person) to avoid
including the person both as a pre-approver and as a chain of authority approver.
The full transfer policy can now be implemented with the addition of the fourth
rule in Table 8a.
Example Transaction 5 Transfer Direct Reports
Manager V4.0 function, initiates a transaction for person P21 and reassigns
direct reports P11, P12 and P13 to managers P25, P26 and P27 respectively.
This transaction satisfies the conditions of the default rule and all of the transfer
policy rules. These rules all fire and the initial list of approvers contains the
approvers shown in Table 8c.
Page 24
Table 8c Approvals for Example Transaction 5

Sequence
Approver
P25
Notes
Proposed manager of one of the direct
Approved?
No
reports (included in
TRANSFER_PRE_APPROVERS
dynamic approvals group)
2
P26
(same as previous)
No
P27
(same as previous)
No
P41
No
supervisor (Starting point for first chain ,

AND general transfer rule AND default
rule)
person has level 4 approval authority
5
P35
Selected persons proposed supervisor
No
(Starting point for second chain)

person has level 3 approval authority,
next higher approver is level 5 and the
rule requires at most level 4.
Other Capabilities
The example transactions demonstrated many of the capabilities of AME. Refer

to Implementing Oracle Approvals Management for details on these and other
features including:
Chains of authority using relative job levels
Substitution rules
List modification rules
List Creation Exception rules
Priorities
CONFIGURING ATTRIBUTES
Having identified the rules and conditions that the business users require to
enforce their approvals policies, you need to ensure that the necessary attributes
are in place.
Page 25
Identifying What Attributes Are Needed
When considering which attributes are needed to support your approval rules it
can be helpful to break them down into groups according to their purpose.
Policy - attributes for setting overall policy,
Chain of Authority attributes used by certain approval types, for

example for identifying the starting points of various approval
hierarchies.
Conditional - attributes that form the basis for your rule conditions.
These can be further broken down into:
o
General useful for any kind of HR transaction
Specific for a particular category of transaction
Policy Attributes
AME uses several attributes to control overall policy in certain areas. Typically
these will have static Boolean usages. You need to determine whether to set
them to true or false depending on your enterprises policies.
Table 9 Example Policy Attributes
Attribute Name
Type
Description
ALLOW_DELETING_RULE_GENER
ATED_APPROVERS
boolean
Determines whether AME allows an

application to delete approvers
required by the appropriate transaction
types rules from a transactions
approver list (at runtime).
ALLOW_EMPTY_APPROVAL_GRO
UPS
boolean
ALLOW_REQUESTOR_APPROVAL
boolean
AT_LEAST_ONE_RULE_MUST_AP
PLY
INCLUDE_ALL_JOB_LEVEL_APPR
OVERS
boolean
USE_RESTRICTIVE_LINE_ITEM_E
VALUATION
boolean
Determines whether AME lets a

requestor approve their own
transaction, if they have sufficient
signing authority.
Set to False to deny users the
authority to approve a transaction they
initiate EVEN IF they are otherwise
qualified.
Whether to require that at least one
rule apply to each transaction
If False, will skip over successive
people in the approval chain until
reaching the first person with the next
higher job level.
If True, a rule containing line-item
conditions applies to a transaction
only if one of the transactions line
items satisifies all of the rules lineitem conditions
boolean
Chain of Authority Attributes
Chains of authority approval types use attributes to define the starting point of
each chain. For the approval types you plan to use, you need to ensure that any
corresponding attributes are appropriately defined. Refer to the section on
Page 26
Starting Points for Chains of Authority for an overview of the concepts

involved.
Table 10 includes the AME attributes for starting points, another AME attribute
which provides an independent check for a broken supervisor hierarchy, and
several suggested attributes which may be used as stepping stones to defining
usages for the others. For example, you might set up and test a usage for
TRANSACTION_SUBJECT_PERSON_ID before attempting to define the
usage for
SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID.
Table 10 Chain of Authority Attributes
Attribute Name
Type
Description
TRANSACTION_REQUESTOR_PER
SON_ID
number
TRANSACTION_REQUESTOR_SUP
ERVISOR_ID
CURRENT_ASSIGNMENT_ID
number
(Required by Supervisory and any

Job-Level-based approval types)
Person ID of user initiating the
transaction.
Person ID of the supervisor of the user
initiating the transaction.
Assignment ID of user initiating the
transaction.
Person ID of person selected in the
transaction.
Person ID of current supervisor of the
person selected in the transaction.
Assignment ID of person selected in
the transaction.
(Used by Job-Level-based approval
types)
If NULL, supervisory approval chain
starts with requestors supervisor
(supervisor of the
SON_ID).
(Used by Supervisory approval type)
If NULL, supervisory approval chain
starts with requestors supervisor
(supervisor of the
SON_ID).
(Required by Dual Chains of Authority
approval type)
Person with whom to start the FIRST
chain of authority. Note: chains follow
primary assignments.
(Required by Dual Chains of Authority
approval type)
Person with whom to start the
SECOND chain of authority. Note:
chains follow primary assignments.
(Required by Supervisory approval
type)
Identifies the person at the top of the
supervisor chain. Guards against
accidental gaps in the supervisor
hierarchy.
number
TRANSACTION_SUBJECT_PERSO
N_ID
N_SUPERVISOR_ID
TRANSACTION_SUBJECT_ASSIGN
MENT_ID
JOB_LEVEL_NON_DEFAULT_STA
RTING_POINT_PERSON_ID
number
SUPERVISORY_NON_DEFAULT_S
TARTING_POINT_PERSON_ID
Number
FIRST_STARTING_POINT_PERSO
N_ID
Number
SECOND_STARTING_POINT_PER
SON_ID
Number
TOP_SUPERVISOR_PERSON_ID
Number
number
number
Number
Page 27
Conditional Attributes
Examine your approval polices and wherever you have specified a condition you
will need to make sure that you have set up the appropriate attribute on which to
base it.
You may want to start by identifying attributes that are generally applicable for
all transactions regardless of functional area. For example, if your approval
policies differ across the enterprise, you may have conditions based on
organizational entities such as organization, business group, and legislation
code.
Table 11 Example Conditional Attributes - General

Attribute Name
Type
Description
TRANSACTION_ORG_ID
number
TRANSACTION_ORG_NAME
number
TRANSACTION_GROUP_ID
number
TRANSACTION_GROUP_NAME
number
TRANSACTION_SUBJECT_ORG_ID
number
TRANSACTION_SUBJECT_ORG_N
AME
TRANSACTION_SUBJECT_GROUP
_ID
TRANSACTION_SUBJECT_GROUP
_NAME
number
Organization ID of user initiating the

transaction.
Name of organization of user initiating
the transaction.
Business group ID of user initiating
the transaction.
Name of business group of user
initiating the transaction.
Organization ID of person selected in
the transaction.
Name of organization of person
selected in the transaction.
Business group ID of person selected
in the transaction.
Name of business group of person
selected in the transaction.
number
number
Table 11 lists some examples of general conditional attributes.

Note: Attributes based on entity names are generally easier for business users
than those based on ID, but there may be performance implications.
After identifying all general attributes, consider the attributes specific to each
category of transaction. To support the example policies in Table 3 we need an
attribute to identify transaction category and one for percentage increase in
salary.
Table 12 Example Conditional Attributes Category Specific
Attribute Name
Type
Description
HR_TRANSACTION_CATEGORY
string
SALARY_INCREASE_PCT
number
Category of transaction (e.g. Salary,

or Transfer)
**Line item attribute **
Salary increase expressed as a
percentage (30 indicates that
proposed salary is 30% higher than
current salary.)
Page 28
As you examine policies for other functional areas you will uncover the need for
more attributes.
Attribute Usages
We are now ready to define the usages for our attributes.

The task of defining attribute usages must be performed initially by someone (or
a combination of people) with system administration and PL/SQL skills and
access privileges. Once the attribute usages have been defined and tested, the
conditions and rules may be successfully completed by a business user.
In this section, we provide a few examples of usages to support the example
attributes identified earlier. (A more complete listing appears in Appendix A.)
Keep in mind the following general advice:
It is best to encapsulate complex logic in a PL/SQL package which

can be referenced from AME attribute usages. Many lines of SQL
can be reduced to a simple usage of the form:
select <package name>.<function name>(:transactionId) from dual
Note: In the examples below, we use the package name custom_package, but
you would substitute the name of your own package.
Conversely, avoid burying in a PL/SQL package any details that are

more conveniently held at the configuration level.
For example, a Boolean attribute based on a function that detects a
specific condition is less flexible than a number attribute based on a
function that returns a value on which a variety of conditions can be
based.
Ensure that attribute usages return NULL (or a specific value such as
zero) rather than no rows returned when the attribute is not found
on the current transaction.
Header-level dynamic usages will typically involve the where

clause:
where hr_api_transactions.transaction_id = :transactionId
Line-level dynamic usages must include the ordering by line item id

as defined in the line-item item class
Note: Refer to Implementing Oracle Approvals Management for details and

examples of the syntax rules you must follow.
Page 29
Table 13 Example Attribute Usages

Attribute Name
Type
Query
ALLOW_EMPTY_APPROVAL_GROUPS
FIRST_STARTING_POINT_PERSON_I
D
boolean
number
true
select
decode(custom_package.get_subject_
sup_id(:transactionId),
custom_package.get_requestor_perso
n_id(:transactionId),
custom_package.get_requestor_sup_i
d(:transactionId),
string
SALARY_INCREASE_PCT
number
WORKFLOW_PROCESS_NAME
string
custom_package.get_subject_sup_id(:
transactionId)
)
from dual
select
custom_package.get_transaction_cate
gory(hats.transaction_step_id)
from hr_api_transaction_steps hats
where hats.transaction_id =
:transactionId
select
custom_package.get_salary_increase_
pct(:transactionId) from dual
SELECT
HR_WORKFLOW_SS.GET_PROCESS_N
AME(:transactionId)
FROM DUAL
Transaction Categories
To determine the category of transaction, the

HR_TRANSACTION_CATEGORY attribute uses the function
get_transaction_category. This function, for which a code fragment is provided
in Appendix B, makes the assumption that the api_name column in the
HR_API_TRANSACTION_STEPS table is a good indicator of the category of
transaction. For example, a Salary change transaction will use
HR_PAY_RATE_SS.PROCESS_API while a transfer will use
HR_SUPERVISOR_SS.PROCESS_API.
Header Level or Line Level
This attribute is defined at the line level, for obvious reasons. Note, however,
that since there can only be a single salary step in a given transaction it is
permissible to define the SALARY_INCREASE_PCT attribute at the header
level. The logic for the underlying function can be written to retrieve only rows
for a step with transaction category of SALARY. The same approach can be
taken for any other transaction category-specific attributes when it is known that
there can only be one such step in the transaction.
Page 30
Transaction Types
The examples selected in this paper are all from within the Manage Employee
Events area of SSHR in which any of these example transaction categories may
be combined in a single transaction. Consequently these transaction categories,
and their supporting attribute usages must be defined in a single transaction type.
However, you may choose to create separate transaction types for other
functional areas such as Training.
Migrating Configurations Between Instances
An enhancement is under development to allow you to use the FNDLOAD

utility to download all or parts of your AME configuration to a text file which
you will then be able to upload to another Oracle Applications instance.
For further information, refer to enhancement request number 2603610.
Page 31
SUMMARY OF CONFIGURATION METHODS AND SKILL LEVELS
The following table indicates the methods and skill levels required to perform
the various tasks involved in setting up and maintaining approvals policies.
Table 14 Skill Levels Required to Perform Configuration Tasks
Task
Insert additional
name(s) into a
default approval list.
Configure approval
Method
SSHR Review page
SSHR
Business
System
Pro-
User
User
Admini-
gramme
strator
(Dynamic
Approvals)
AME configuration
rules and conditions

Define transaction
AME configuration
types and attribute
and PL/SQL
usages
Turn Approvals on
Workflow Builder
or off for a specific
Function
SSHR function
configuration
Make Dynamic
Workflow Builder
Approvals available
Function
(or not) in a specific
configuration
function.
Add a new approval
AME configuration
type and handler
and PL/SQL
CONCLUSION
In this paper you have seen how to take advantage of Oracle Approvals
Management to put in place a powerful set of controls to govern transactions in
Self-Service Human Resources. You have also seen how, once the initial setup
has been performed, it is feasible for a non-technical business user to fine-tune
the approval rules to reflect changing business requirements. The examples
presented here are representative of typical business practices, but are by no
means exhaustive. To learn more about Oracle Approvals Management, refer to
Implementing Oracle Approvals Management.
Page 32
APPENDIX A ATTRIBUTE USAGES
The following table represents an alphabetical listing of attributes along with

their usages. (The list includes all the attributes used in the examples in this
paper as well as some from the Training functional area.)
Attribute Name
Type
Attribute Usage
ALLOW_DELETING_RULE_GENER
ATED_APPROVERS
ALLOW_EMPTY_APPROVAL_GRO
UPS
ALLOW_REQUESTOR_APPROVAL
AT_LEAST_ONE_RULE_MUST_AP
PLY
EFFECTIVE_RULE_DATE
FIRST_STARTING_POINT_PERSO
N_ID
boolean
false
boolean
true
boolean
boolean
false
true
date
number
select
decode(custom_packagecustom_pack
age.get_subject_sup_id(:transactionId
),
custom_packagecustom_package.get
_requestor_person_id(:transactionId),
d(:transactionId),
string
OTA_ACTIVITY_TYPE
string
OTA_ENROLLMENT_STATUS
string
OTA_EVENT_STANDARD_PRICE
number
OTA_EVENT_STANDARD_PRICE
string
OTA_PRIMARY_DELIVERY_METH
OD
string
INCLUDE_ALL_JOB_LEVEL_APPR
OVERS
boolean
transactionId)
)
from dual
select
custom_package.get_transaction_cat
egory(hats.transaction_step_id)
:transactionId
select
ot_workflow_ss.get_activity_type(:tran
sactionId) from dual
select
ot_workflow_ss.get_enrollment_status
(:transactionId) from dual
Select
ot_workflow_ss.get_event_standard_p
rice(:transactionId) from dual
select
ot_workflow_ss.get_act_pm_category(
:transactionId) from dual
select
ot_workflow_ss.get_act_pm_delivery_
method(:transactionId) from dual
false
Page 33
Attribute Name
Type
Attribute Usage
JOB_LEVEL_NON_DEFAULT_STA
RTING_POINT_PERSON_ID
number
select decode(
nvl(custom_package.get_subject_sup
_id(:transactionId),
custom_package.get_transfer_propos
ed_sup_id(:transactionId)),
NULL,
d(:transactionId),
d(:transactionId),
SALARY_INCREASE_PCT
number
SECOND_STARTING_POINT_PER
SON_ID
number
ed_sup_id(:transactionId))
)
from dual
select
custom_package.get_salary_increase
_pct(:transactionId) from dual
select
decode(custom_package.get_transfer
_proposed_sup_id(:transactionId),
d(:transactionId),
SUPERVISORY_NON_DEFAULT_S
TARTING_POINT_PERSON_ID
number
ed_sup_id(:transactionId) )
from dual
select decode(
ed_sup_id(:transactionId)),
NULL,
d(:transactionId),
d(:transactionId),
TOP_SUPERVISOR_PERSON_ID
TRANSACTION_DATE
number
date
ed_sup_id(:transactionId))
)
from dual
<person_id of top supervisor (Static)>
Page 34
Attribute Name
Type
Attribute Usage
TRANSACTION_GROUP_ID
number
TRANSACTION_ORG_ID
number
TRANSACTION_PROPOSED_SUPE
RVISOR_ID
number
SON_ID
number
TRANSACTION_REQUESTOR_SUP
ERVISOR_ID
number
select ppf.business_group_id
from hr_api_transactions hat,
per_people_f ppf
where hat.transaction_id =
:transactionId
and ppf.person_id =
hat.creator_person_id
and
custom_package.get_effective_date(:t
ransactionId)
between ppf.effective_start_date
and ppf.effective_end_date
select paf.organization_id
from hr_api_transactions hat,
per_assignments_f paf
where hat.transaction_id =
:transactionId
and paf.person_id =
hat.creator_person_id
and paf.primary_flag = 'Y'
and
custom_package.get_effective_date(:t
ransactionId)
between paf.effective_start_date
and paf.effective_end_date
select
ed_sup_id(:transactionId)
from dual
select
n_id(:transactionId) from dual
select
d(:transactionId)
from dual
TRANSACTION_REQUESTOR_USE
R_ID
TRANSACTION_SET_OF_BOOKS_I
D
N_ID
number
N_SUPERVISOR_ID
number
USE_RESTRICTIVE_LINE_ITEM_E
VALUATION
WORKFLOW_ITEM_KEY
boolean
WORKFLOW_ITEM_TYPE
string
WORKFLOW_PROCESS_NAME
string
number
number
string
select
custom_package.get_subject_person_
id(:transactionId)
from dual
select
transactionId)
from dual
true
SELECT ITEM_KEY
FROM HR_API_TRANSACTIONS
WHERE
TRANSACTION_ID=:transactionId
SELECT ITEM_TYPE
FROM HR_API_TRANSACTIONS
WHERE
TRANSACTION_ID=:transactionId
SELECT
HR_WORKFLOW_SS.GET_PROCES
S_NAME(:transactionId)
FROM DUAL
Page 35
APPENDIX B FUNCTIONS
The following table lists several example functions with descriptions of the
underlying logic. (The list includes all the functions used in the example
attributes in this paper as well as some from the Training functional area.)
Sample queries have been provided in representative cases. Appendix E is an
example package header and detail that supports these functions.
Function Name
Parameters
Description
get_assignment_id
transaction_id
get_current_hour
transaction_id
get_current_salary
transaction_id
get_effective_date
transaction_id
get_number_increase_pct
get_person_id
number1,
number2
transaction_id
get_proposed_hour
transaction_id
get_proposed_salary
transaction_id
get_requestor_person_id
transaction_id
get_requestor_sup_id
transaction_id
get_salary_increase_pct
transaction_id
get_subject_person_id
transaction_id
get_subject_sup_id
transaction_id
Get the Assignment ID of the selected

person
Get the current hour for the
assignment
Get the current salary for the
assignment
Get the effective date of this
transaction
Calculate the percentage increase
number 2 over number 1
Get the Person ID of the selected
person
select number_value
from wf_item_attribute_values wiav,
where hat.item_type =
wiav.item_type
and hat.item_key = wiav.item_key
and hat.transaction_id =
p_transaction_id
and name =
'CURRENT_PERSON_ID';
Get the proposed hour for the
assignment
Get the proposed salary for the
assignment
select get_trans_step_number_value(
hats.transaction_step_id,
'P_PROPOSED_SALARY')
p_transaction_id
and
get_transaction_category(hats.transac
tion_step_id) = 'SALARY';
Get the id of the person
creating/requesting/initiating the
transaction
select creator_person_id
from HR_API_TRANSACTIONS
where
transaction_id=p_transaction_id;
Get the id of the supervisor of the
person creating/requesting/initiating
the transaction
Calculate increase in salary as a
percentage
Get the id of the person selected in
the transaction
Get the id of the supervisor of the
person selected in the transaction
Page 36
Function Name
Parameters
Description
get_trans_step_Boolean_value
Transaction_s
tep_id,
attribute_nam
e
Transaction_s
tep_id,
attribute_nam
e
Transaction_s
tep_id,
attribute_nam
e
Transaction_s
tep_id,
attribute_nam
e
Return the value of a boolean attribute
get_trans_step_date_value
get_trans_step_number_value
get_trans_step_value
Return the value of a date attribute
Return the value of a number attribute
Return the value of any attribute

converted to varchar2.
select decode(hatv.datatype,
'NUMBER',to_char(hatv.number_value
),
'VARCHAR2',hatv.varchar2_value,
'BOOLEAN',hatv.varchar2_value,
get_trans_step_varchar2_valu
e
get_transaction_category
Transaction_s
tep_id,
attribute_nam
e
Transaction_s
tep_id
get_transfer_current_sup_id
transaction_id
get_transfer_proposed_sup_id
transaction_id
'DATE',ame_util.versionDatetoString(h
atv.date_value),
NULL)
into l_attribute_value
from hr_api_transaction_values hatv
, hr_api_transaction_steps hats
where hatv.transaction_step_id =
hats.transaction_step_id
and hats.transaction_step_id =
p_transaction_step_Id
and hatv.name = p_attribute_name;
Return the value of a varchar2
attribute
Derive the category of transaction
based on the api_name used.
select decode(hats.api_name,
'HR_PAY_RATE_SS.PROCESS_API'
,'SALARY',
'HR_PROCESS_ASSIGNMENT_SS.P
ROCESS_API','ASSIGNMENT',
'HR_SUPERVISOR_SS.PROCESS_A
PI','TRANSFER',
,
OTHER)
where hats.transaction_step_id =
p_transaction_step_id;
Get the id of the current supervisor of
the person selected for transfer
Get the id of the proposed supervisor
of the person selected for transfer
Page 37
Function Name
Parameters
Description
get_activity_type
transaction_id
Get the name of the activity definition

for the current event.
select oad.name
from ota_events evt,
ota_activity_versions oav,
ota_activity_definitions oad
where evt.event_id = c_event_id and
evt.activity_version_id =
oav.activity_version_id and
oav.activity_id = oad.activity_id;
get_enrollment_status
transaction_id
get_event_standard_price
transaction_id
get_act_pm_category
transaction_id
get_act_pm_delivery_method
transaction_id
c_event_id :=
wf_engine.GetItemAttrNumber(
itemtype => c_item_type ,
itemkey => c_item_key,
aname => 'OTA_EVENT_ID');
Get the name of the current booking
status type for the current booking.
Get the standard_price of the current
event.
Get the activity category for the
current event.
Get the delivery method of the current
event.
Page 38
APPENDIX C DYNAMIC APPROVAL GROUPS
The TRANSFER_PRE_APPROVERS group used in the Transfer policy

examples uses the following dynamic query:
select distinct 'person_id:'||to_char(supervisor_id)
from ( select hatv.number_value supervisor_id
from hr_api_transaction_values hatv,
hr_api_transaction_steps hats
where hatv.transaction_step_id = hats.transaction_step_id
and hats.transaction_id = :transactionId
and apps.xyz_sshr_functions.get_transaction_category(
hats.transaction_step_id) = 'TRANSFER'
and hatv.name like 'P_SUPERVISOR_ID%'
and hatv.number_value >0
UNION select paaf.supervisor_id
hr_api_transaction_steps hats,
per_all_assignments_f paaf
and (hatv.name like 'P_EMP_ASG_ID%')
and paaf.assignment_id = hatv.number_value
and sysdate between paaf.effective_start_date and
paaf.effective_end_date
and paaf.primary_flag = 'Y' ) supervisors
where supervisor_id not in (
select hatv.number_value
and (hatv.name = 'P_SELECTED_PERSON_OLD_SUP_ID'
or hatv.name = 'P_SELECTED_PERSON_SUP_ID')
)
and supervisor_id is not NULL
order by 1
Page 39
Page 40
APPENDIX D POSITION HIERARCHY SUPPORT
R11i10 of AME delivers Position Hierarchy Support. However, until such time
as it is supported within SSHR, here are a couple of examples of how to provide
such support.
The first example shows how a function can be created which returns the
approver(s) at a specific level.
First create a function which will return the Position id for a given transaction id.
This function will then be used in conjunction with Dynamic Approval groups to
return Approvers who exist in the position hierarchy.
Here is the function. The parameters to the function are the transaction id and
the level to which you want the Position(s) returned.
create or replace function getApproverPositionId(transactionIdIn in integer,
levelIn
in integer) return
integer is
requestorId integer;
positionLevel integer;
positionId integer;
parentPositionId integer;
begin
select
into
from
where
creator_person_id
requestorID
HR_API_TRANSACTIONS
transaction_id = transactionIdIn;
select position_id
into positionId
from per_all_assignments_f
where person_id = requestorId
and primary_flag = 'Y'
and trunc(sysdate) between effective_start_date and
nvl(effective_end_date,trunc(sysdate))
and rownum < 2;
positionLevel := 0;
while(positionLevel <> levelIn) loop
select str.parent_position_id
into parentPositionId
from
per_pos_structure_elements str,
per_pos_structure_versions psv,
per_position_structures
pst
where
str.subordinate_position_id = positionId
and str.pos_structure_version_id = psv.pos_structure_version_id
and pst.position_structure_id
= psv.position_structure_id
and pst.primary_position_flag
= 'Y'
and trunc(sysdate) between psv.date_from and nvl( psv.date_to , sysdate);
positionId := parentPositionId;
positionLevel := positionLevel+1;
end loop;
return positionId;
exception
when others then
ame_util.runtimeException(packageNameIn => 'getApproverPositionId',
routineNameIn => 'getApproverPositionId',
exceptionNumberIn => sqlcode,
Page 41
exceptionStringIn => sqlerrm);

return null;
end;
You then need to create a dynamic approval group that will call the function and
will return the approvers at the level selected in the call to the function.
The approval group shown below will return the person(s) who holds the
position, one level above the transaction requester.
Required SQL in Dynamic Approval Group
select distinct 'person_id:'||wf.orig_system_id
from wf_roles wf,
per_all_assignments_f paf
where paf.position_id = getApproverPositionId(:transactionId,3)
and paf.person_id
= wf.orig_system_id

and paf.assignment_type in ('E','C')
and paf.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 paf.effective_start_date
and nvl(paf.effective_end_date,trunc(sysdate))
and wf.status = 'ACTIVE'
and (wf.expiration_date is null or sysdate < wf.expiration_date)
and wf.orig_system
= 'PER'
Replace the position number in the call (currently set to 3 in the above example)
to the function with the desired position. If you want to climb n levels it is
possible to create a dynamic approval group for each level and then create a
static approval group and include as the members, a dynamic approval group for
every level you want to include. It is also worthy of note that we only want to
include active assignments and not job applicants.
This approval group can then be used within an Approval Rule as either
Pre/Post Approval Group or Chain of Authority Includes an Approval Group
Action type.
However, the second example below is a cleaner version of the same although it
does require a substantial piece of SQL for each level you require to ascend.
Page 42
The second example is where it is required to return approvers up to n level.

Create a dynamic approval group with a meaningful name that reflects the
number of levels you want to climb up the position hierarchy from the
transaction requester. The SQL for the Dynamic Approval group should be as
follows:-
select 'person_id:'||wf.orig_system_id
from wf_roles wf,
where paf.position_id in
(
select parent_position_id from
(
select parent_position_id,pos_structure_version_id
from
(
select
pos_structure_version_id,subordinate_position_id,parent_position_id,to_char(level) pos_level
from per_pos_structure_elements
start with subordinate_position_id =
(
select position_id
from per_all_assignments_f x
where person_id =
(
where transaction_id = :transactionId
)
and trunc(sysdate) between x.effective_start_date
and nvl(x.effective_end_date,trunc(sysdate))
)
connect by prior parent_position_id = subordinate_position_id
and pos_structure_version_id =
replacewithStructureVersionID
)
where to_number(pos_level) <=
replacewithActualPositionLevel
where pos_structure_version_id =
(
select str.pos_structure_version_id
from per_pos_structure_elements str,
per_pos_structure_versions psv,
per_position_structures
pst
where str.subordinate_position_id in
(
select position_id
from per_all_assignments_f x
where person_id =
(
where transaction_id = :transactionId
)
Page 43
and trunc(sysdate) between x.effective_start_date

and nvl(x.effective_end_date,trunc(sysdate))
)
and
and
and
and
and
and
and
and
and
and
and
and
str.pos_structure_version_id = psv.pos_structure_version_id
pst.position_structure_id
= psv.position_structure_id
pst.primary_position_flag
= 'Y'
trunc(sysdate) between psv.date_from and nvl( psv.date_to , sysdate)
)
)
paf.person_id
= wf.orig_system_id
paf.primary_flag = 'Y'
paf.assignment_type in ('E','C')
paf.assignment_status_type_id not in
(select assignment_status_type_id
from per_assignment_status_types
where per_system_status = 'TERM_ASSIGN')
trunc(sysdate) between paf.effective_start_date
and nvl(paf.effective_end_date,trunc(sysdate))
wf.status = 'ACTIVE'
(wf.expiration_date is null or sysdate < wf.expiration_date)
wf.orig_system = 'PER'
The text replacewithActualPositionLevel in the above SQL should be replaced

with the integer specifying number of levels to be climbed from the transaction
requester.
The id replacewithStructureVersionID in the above SQL should be

replaced with the integer specifying the structure version id. This can be derived
with the by querying the table
PER_POS_STRUCTURE_VERSIONS and PER_POS_STRUCTURES and
writing a simple query as follows: select pos_structure_version_id, Version_Number
from per_pos_structure_versions
where position_structure_Id =
(select position_structure_Id
from per_position_structures
where business_group_id = << BusinessGroup Id >>
and Name = PositionHierarchy Name
and primary_position_flag = 'Y')
Note : This query is just a guideline. Customers may want to use a Non
Primary Position Hierarchy in which case the above query needs to be changed
appropriately.
Page 44
APPENDIX E EXAMPLE SUPPORT FUNCTIONS
Reproduced below is a sample package header and body which supports the
examples in this document. The code herein is not supported and is supplied
without warranty.
First the package header and then the package body.
REM
REM
REM
REM
REM
REM
REM
REM
REM
REM
REM
REM
+======================================================================+
|
Copyright (c) 1997 Oracle Corporation
|
|
Redwood Shores, California, USA
|
|
All rights reserved.
|
+======================================================================+
Application : Human Resources Self Service Applications
File Name
: xyz_sshr_functions.pkb.pkh
Package Name : xyz_sshr_functions
Purpose
: To be called from AME to determine attribute values
Owner
: APPS
========================================================================
Set Scan Off

Set Verify Off
WHENEVER OSERROR EXIT FAILURE ROLLBACK;
WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
CREATE OR REPLACE package xyz_sshr_functions AUTHID CURRENT_USER as
------------------------------------------------------------------- General Functions
------------------------------------------------------------------- Name: Get_Number_Increase_Pct
-- Desc: Calculate the percentage increase number 2 over number 1
-- Params: number value1
-number value2
-- Returns: number
-----------------------------------------------------------------function get_number_increase_pct (
number_value1 number,
number_value2 number)
return number;
------------------------------------------------------------------- Transaction level functions
------------------------------------------------------------------- Name: Get_Effective_Date
-- Desc: Get the effective date of this transaction
-- Params: transaction_id
-- Returns: date
-----------------------------------------------------------------function get_effective_date
(p_transaction_id IN hr_api_transactions.transaction_id%TYPE)
return date;
------------------------------------------------------------------- Name: Get_Person_ID
-- Desc: Get the Person ID of the selected person
-- Returns: number
-----------------------------------------------------------------function get_person_id
return number;
------------------------------------------------------------------- Name: Get_Assignment_ID
-- Desc: Get the Assignment ID of the selected person
Page 45
-- Returns: number
-----------------------------------------------------------------function get_assignment_id
return number;
------------------------------------------------------------------- Name: Get_Current_Salary
-- Desc: Get the current salary for the assignment
-- Returns: number
-----------------------------------------------------------------function get_current_salary
return number;
------------------------------------------------------------------- Name: Get_Current_Hour
-- Desc: Get the current hour for the assignment
-- Returns: number
-----------------------------------------------------------------function get_current_hour
return number ;
------------------------------------------------------------------- Name: get_requestor_person_id
-- Desc: Get the id of the person
-creating/requesting/initiating the transaction
-- Returns: number
-----------------------------------------------------------------function get_requestor_person_id
return number;
------------------------------------------------------------------- Name: get_requestor_sup_id
-- Desc: Get the id of the supervisor of the person
-- Returns: number
-----------------------------------------------------------------function get_requestor_sup_id
return number;
------------------------------------------------------------------- Name: get_subject_person_id
-selected in the transaction
-- Returns: number
-----------------------------------------------------------------function get_subject_person_id
return number;
------------------------------------------------------------------- Name: get_subject_sup_id
-- Returns: number
-----------------------------------------------------------------function get_subject_sup_id
return number;
------------------------------------------------------------------- Name: get_transfer_current_sup_id
Page 46
-- Desc: Get the id of the current supervisor of the person

-selected for transfer
-- Returns: number
-----------------------------------------------------------------function get_transfer_current_sup_id
return number;
------------------------------------------------------------------- Name: get_transfer_proposed_sup_id
-- Desc: Get the id of the proposed supervisor of the person
-- Returns: number
-----------------------------------------------------------------function get_transfer_proposed_sup_id
return number;
------------------------------------------------------------------- Name: Get_Proposed_Salary
-- Desc: Get the proposed salary for the assignment
-- Returns: number
-----------------------------------------------------------------function get_proposed_salary
return number;
------------------------------------------------------------------- Name: Get_Proposed_Hour
-- Desc: Get the proposed hour for the assignment
-- Returns: number
-----------------------------------------------------------------function get_proposed_hour
return number;
------------------------------------------------------------------- Name: Get_Salary_Increase_Pct
-- Desc: Calculate increase in salary as a percentage
-- Params: transaction_step_id
-- Returns: number
-----------------------------------------------------------------function get_salary_increase_pct
return number;
------------------------------------------------------------------- Transaction Step level functions
------------------------------------------------------------------- Name: get_trans_step_value
-- Desc: Return the value of an attribute converted to varchar2
-attribute_name
-- Returns: varchar2
-----------------------------------------------------------------function get_trans_step_value (
p_transaction_step_id IN hr_api_transaction_steps.transaction_step_id%TYPE,
p_attribute_name IN hr_api_transaction_values.name%TYPE)
return varchar2;
------------------------------------------------------------------- Name: get_trans_step_number_value
-- Desc: Return the value of a number attribute
-attribute_name
-- Returns: number
-----------------------------------------------------------------function get_trans_step_number_value (
Page 47
return number;
------------------------------------------------------------------- Name: get_trans_step_varchar2_value
-- Desc: Return the value of a varchar2 attribute
-attribute_name
-----------------------------------------------------------------function get_trans_step_varchar2_value (
return varchar2;
------------------------------------------------------------------- Name: get_trans_step_date_value
-- Desc: Return the value of a date attribute
-attribute_name
-- Returns: date
-----------------------------------------------------------------function get_trans_step_date_value (
return date;
------------------------------------------------------------------- Name: get_trans_step_boolean_value
-- Desc: Return the value of a boolean attribute
-attribute_name
-----------------------------------------------------------------function get_trans_step_boolean_value (
return varchar2;
------------------------------------------------------------------- Name: get_transaction_category
-- Desc: Derive the category of transaction
-----------------------------------------------------------------function get_transaction_category (
p_transaction_step_id IN hr_api_transaction_steps.transaction_step_id%TYPE)
return varchar2;
-----------------------------------------------------------------PRAGMA RESTRICT_REFERENCES(get_effective_date, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_person_id, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_assignment_id, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_current_hour, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_current_salary, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_proposed_salary, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_proposed_hour, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_requestor_person_id, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_requestor_sup_id, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_subject_person_id, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_subject_sup_id, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_transfer_current_sup_id, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_transfer_proposed_sup_id, WNDS, WNPS, RNPS);
-PRAGMA RESTRICT_REFERENCES(get_salary_increase_pct, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_number_increase_pct, WNDS, WNPS, RNPS);
--PRAGMA RESTRICT_REFERENCES(get_trans_step_value, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_trans_step_number_value, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_trans_step_varchar2_value, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_trans_step_date_value, WNDS, WNPS, RNPS);
PRAGMA RESTRICT_REFERENCES(get_trans_step_boolean_value, WNDS, WNPS, RNPS);
Page 48
PRAGMA RESTRICT_REFERENCES(get_transaction_category, WNDS, WNPS, RNPS);

end;
/
COMMIT;
EXIT;
REM +======================================================================+
REM |
Copyright (c) 1997 Oracle Corporation
|
REM |
Redwood Shores, California, USA
|
REM |
|
REM +======================================================================+
-----------------------------------------------------------------REM Application : Human Resources Self Service Applications
REM File Name
: xyz_sshr_functions.pkb
REM Package Name : xyz_sshr_functions
REM Purpose
: To be called from AME to determine attribute values
REM Owner
: APPS
REM
========================================================================
REM
Set Scan Off
Set Verify Off
WHENEVER OSERROR EXIT FAILURE ROLLBACK;
WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
CREATE OR REPLACE package body xyz_sshr_functions as
------------------------------------------------------------------- General Functions
------------------------------------------------------------------- Name: Get_Number_Increase_Pct
-- Desc: Calculate the percentage increase number 2 over number 1
-- Params: number value1
-number value2
-- Returns: number
-----------------------------------------------------------------function get_number_increase_pct (
number_value1 number,
number_value2 number)
return number is
l_increase_percent number;
begin
if number_value1 != 0 then
l_increase_percent := 100*(number_value2 - number_value1)/number_value1;
return l_increase_percent;
else
return 0;
end if;
exception
when others then return 0;
end;
------------------------------------------------------------------- Transaction level functions
------------------------------------------------------------------- Name: Get_Effective_Date
-- Desc: Get the effective date of this transaction
-- Returns: date
-----------------------------------------------------------------FUNCTION get_effective_date
return date is
Page 49
c_effective_date date;
cursor current_date_old is
select date_value
where hat.item_type = wiav.item_type
and hat.transaction_id = p_transaction_id
and name = 'CURRENT_EFFECTIVE_DATE';
cursor current_date_new is
select TO_DATE(TEXT_value, 'YYYY/MM/DD')
and name = 'P_EFFECTIVE_DATE';
begin
open current_date_old;
fetch current_date_old into c_effective_date;
close current_date_old;
if c_effective_date is null then
open current_date_new;
fetch current_date_new into c_effective_date;
close current_date_new;
end if;
return c_effective_date;
end;
------------------------------------------------------------------- Name: Get_Person_ID
-- Desc: Get the Person ID for the affected employee
-- Returns: number
-----------------------------------------------------------------FUNCTION get_person_id
return number is
c_person_ID NUMBER;
begin
select number_value
into c_person_id
and name = 'CURRENT_PERSON_ID';
return c_person_id;
EXCEPTION
WHEN OTHERS THEN
RETURN NULL;
end;
------------------------------------------------------------------- Name: Get_Assignment_ID
-- Desc: Get the Assignment ID for the affected employee
-- Returns: number
Page 50
-----------------------------------------------------------------FUNCTION get_assignment_id
return number is
C_ASSIGNMENT_ID PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID%TYPE;
c_person_id PER_ALL_PEOPLE_F.PERSON_ID%TYPE;
c_effective_date date;
begin
C_PERSON_ID := get_person_id(p_transaction_id);
c_effective_date := get_effective_date(p_transaction_id);
SELECT DISTINCT ASSIGNMENT_ID
INTO C_ASSIGNMENT_ID
FROM PER_ALL_ASSIGNMENTS_F
WHERE PERSON_ID = C_PERSON_ID
AND PRIMARY_FLAG = 'Y'
AND ASSIGNMENT_TYPE = 'E'
and c_effective_date between effective_start_date and effective_end_date;
return c_assignment_id;
EXCEPTION
WHEN OTHERS THEN
RETURN NULL;
end;
------------------------------------------------------------------- Name: Get_Current_Salary
-- Desc: Get the current salary for the assignment
-- Returns: number
-----------------------------------------------------------------function get_current_salary
return number is
c_salary number;
C_EFFECTIVE_DATE DATE;
begin
C_ASSIGNMENT_ID := get_assignment_id(p_transaction_id);
select
into
from
where
and
and
and
and
and
and
and
and
and
and
to_number(peev.screen_entry_value)
c_salary
pay_input_values_f piv,
pay_element_types_f pet,
pay_element_entry_values_f peev,
pay_element_entries_f pee,
per_all_assignments_f pa,
pay_element_links_f pelf,
per_pay_bases ppb
pet.element_type_id = piv.element_type_id
ppb.input_value_id = piv.input_value_id
pelf.element_link_id = pee.element_link_id
ppb.pay_basis_id = pa.pay_basis_id
pa.assignment_id = pee.assignment_id
peev.element_entry_id = pee.element_entry_id
peev.input_value_id = piv.input_value_id
c_effective_date between pa.effective_start_date and pa.effective_end_date
c_effective_date between pee.effective_start_date and pee.effective_end_date
c_effective_date between peev.effective_start_date and
peev.effective_end_date
c_effective_date between pelf.effective_start_date and
pelf.effective_end_date
Page 51
and
and
c_effective_date
between pet.effective_start_date and

pet.effective_end_date
pa.assignment_id = c_assignment_id;
return c_salary;
exception
when others then
return 0;
end get_current_salary;
------------------------------------------------------------------- Name: Get_Current_Hour
-- Desc: Get the current hour for the assignment
-- Returns: number
-----------------------------------------------------------------function get_current_hour
return number is
c_hour per_all_assignments_f.normal_hours%TYPE;
begin
C_ASSIGNMENT_ID := get_assignment_id(p_transaction_id);
select DISTINCT normal_hours
into
c_hour
from
per_all_assignments_f
where
assignment_id = c_assignment_id
and
assignment_type = 'E'
and primary_flag = 'Y'
and c_effective_date between effective_start_date and effective_end_date;
return c_hour;
exception
when others then
return 0;
end get_current_hour;
------------------------------------------------------------------- Name: get_requestor_person_id
-- Returns: number
-----------------------------------------------------------------function get_requestor_person_id
return number is
begin
into c_person_id
where transaction_id=p_transaction_id;
return c_person_id;
EXCEPTION
WHEN OTHERS THEN
RETURN NULL;
Page 52
end;
------------------------------------------------------------------- Name: get_requestor_sup_id
-- Returns: number
-----------------------------------------------------------------function get_requestor_sup_id
return number is
c_supervisor_id PER_ALL_PEOPLE_F.PERSON_ID%TYPE;
begin
c_person_id := get_requestor_person_id(p_transaction_id);
select paf.supervisor_id
into
c_supervisor_id
from
where
paf.person_id = c_person_id
and
paf.assignment_type = 'E'
and c_effective_date between paf.effective_start_date and paf.effective_end_date;
return c_supervisor_id;
EXCEPTION
WHEN OTHERS THEN
RETURN NULL;
end;
------------------------------------------------------------------- Name: get_subject_person_id
-- Returns: number
-----------------------------------------------------------------function get_subject_person_id
return number is
begin
select hat.selected_person_id
into c_person_id
from hr_api_transactions hat
where hat.transaction_id = p_transaction_id;
return c_person_id;
EXCEPTION
WHEN OTHERS THEN
RETURN NULL;
end;
------------------------------------------------------------------- Name: get_subject_sup_id
-- Returns: number
-----------------------------------------------------------------function get_subject_sup_id
Page 53
return number is
c_supervisor_id PER_ALL_PEOPLE_F.PERSON_ID%TYPE;
begin
c_person_id := get_subject_person_id(p_transaction_id);
select paf.supervisor_id
into
c_supervisor_id
from
where
paf.person_id = c_person_id
and
paf.assignment_type = 'E'
and c_effective_date between paf.effective_start_date and paf.effective_end_date;
return c_supervisor_id;
EXCEPTION
WHEN OTHERS THEN
RETURN NULL;
end;
------------------------------------------------------------------- Name: get_transfer_current_sup_id
-- Desc: Get the id of the current supervisor of the person
-- Returns: number
-----------------------------------------------------------------function get_transfer_current_sup_id
return number is
begin
c_person_id := get_subject_sup_id(p_transaction_id);
return c_person_id;
EXCEPTION
WHEN OTHERS THEN
RETURN NULL;
end;
------------------------------------------------------------------- Name: get_transfer_proposed_sup_id
-- Desc: Get the id of the proposed supervisor of the person
-- Returns: number
-----------------------------------------------------------------function get_transfer_proposed_sup_id
return number is
begin
hats.transaction_step_id, 'P_SELECTED_PERSON_SUP_ID')
into c_person_id
where hats.transaction_id = p_transaction_id
and get_transaction_category(hats.transaction_step_id) = 'TRANSFER';
return c_person_id;
EXCEPTION
Page 54
WHEN OTHERS THEN

RETURN NULL;
end;
------------------------------------------------------------------- Name: Get_Proposed_Salary
-- Desc: Get the proposed salary for the assignment
-- Returns: number
-----------------------------------------------------------------function get_proposed_salary
return number is
c_salary hr_api_transaction_values.number_value%TYPE;
BEGIN
/*select hatv.number_value
INTO
c_salary
where hatv.transaction_step_id = p_transaction_step_id
and hatv.name = 'P_PROPOSED_SALARY';*/
hats.transaction_step_id, 'P_PROPOSED_SALARY')
into c_salary
and get_transaction_category(hats.transaction_step_id) = 'SALARY';
RETURN c_salary;
EXCEPTION
WHEN OTHERS THEN
RETURN 0;
END get_proposed_salary;
------------------------------------------------------------------- Name: Get_Proposed_Hour
-- Desc: Get the proposed hour for the assignment
-- Returns: number
-----------------------------------------------------------------function get_proposed_hour
return number is
c_hour hr_api_transaction_values.number_value%TYPE;
BEGIN
/*select
number_value
INTO
c_hour
FROM
HR_API_TRANSACTION_VALUES HATV
WHERE HATV.TRANSACTION_STEP_ID = p_transaction_step_id
AND
HATV.NAME = 'P_NORMAL_HOURS';*/
hats.transaction_step_id, 'P_NORMAL_HOURS')
into c_hour
and get_transaction_category(hats.transaction_step_id) = 'ASSIGNMENT';
RETURN C_HOUR;
EXCEPTION
WHEN OTHERS THEN
RETURN 0;
Page 55
END get_proposed_hour;
------------------------------------------------------------------- Name: Get_Salary_Increase_Pct
-- Desc: Calculate increase in salary as a percentage
-- Returns: number
-----------------------------------------------------------------function get_salary_increase_pct
return number is
/*l_transaction_id hr_api_transactions.transaction_id%TYPE;
*/
l_current_salary number;
l_proposed_salary number;
l_current_hour number;
l_proposed_hour number;
l_increase_pct number;
begin
/*
select hats.transaction_id
into l_transaction_id
where hats.transaction_step_id = p_transaction_step_id;
*/
l_current_salary := get_current_salary(p_transaction_id);
l_proposed_salary := get_proposed_salary(p_transaction_id);
l_current_hour := get_current_hour(p_transaction_id);
l_proposed_hour := get_proposed_hour(p_transaction_id);
if l_current_hour = 0 then
l_increase_pct := 0;
elsif (l_proposed_hour = 0 or l_proposed_hour = l_current_hour) then
l_increase_pct := ROUND(get_number_increase_pct(l_current_salary, l_proposed_salary),2);
else
l_increase_pct := ROUND(get_number_increase_pct(
l_current_salary/l_current_hour, l_proposed_salary/l_proposed_hour),2);
end if;
return l_increase_pct;
EXCEPTION
when others then
return 0;
END;
------------------------------------------------------------------- Transaction Step level functions
------------------------------------------------------------------- Name: get_trans_step_value
-- Desc: Return the value of an attribute converted to varchar2
-attribute_name
-----------------------------------------------------------------function get_trans_step_value (
return varchar2 is
l_attribute_value hr_api_transaction_values.varchar2_value%TYPE;
begin
select decode(hatv.datatype,
'NUMBER',to_char(hatv.number_value),
'VARCHAR2',hatv.varchar2_value,
'BOOLEAN',hatv.varchar2_value,
'DATE',ame_util.versionDatetoString(hatv.date_value),
NULL)
Page 56
,
and hats.transaction_step_id = p_transaction_step_Id
return l_attribute_value;
exception
when others then return NULL;
end;
------------------------------------------------------------------- Name: get_trans_step_number_value
-- Desc: Return the value of a number attribute
-attribute_name
-- Returns: number
-----------------------------------------------------------------function get_trans_step_number_value (
return number is
l_attribute_value number;
begin
select hatv.number_value
,
and hatv.datatype = 'NUMBER'
exception
end;
------------------------------------------------------------------- Name: get_trans_step_varchar2_value
-- Desc: Return the value of a varchar2 attribute
-attribute_name
-----------------------------------------------------------------function get_trans_step_varchar2_value (
return varchar2 is
begin
select hatv.varchar2_value
,
and hatv.datatype = 'VARCHAR2'
exception
end;
------------------------------------------------------------------- Name: get_trans_step_date_value
Page 57
-- Desc: Return the value of a date attribute

-attribute_name
-- Returns: date
-----------------------------------------------------------------function get_trans_step_date_value (
return date is
l_attribute_value date;
begin
select hatv.date_value
,
and hatv.datatype = 'DATE'
exception
end;
------------------------------------------------------------------- Name: get_trans_step_boolean_value
-- Desc: Return the value of a boolean attribute
-attribute_name
-----------------------------------------------------------------function get_trans_step_boolean_value (
return varchar2 is
begin
select hatv.varchar2_value
,
and hatv.datatype = 'BOOLEAN'
exception
when others then return 'FALSE';
end;
------------------------------------------------------------------- Name: get_transaction_category
-- Desc: Derive the category of transaction
-----------------------------------------------------------------function get_transaction_category (
p_transaction_step_id IN hr_api_transaction_steps.transaction_step_id%TYPE)
return varchar2 is
l_transaction_category varchar2(50);
l_category_undefined varchar2(50) :='OTHER';
begin
/* This statement derives the category of a transaction which can then be
used as a condition by users defining approval rules.
Since different transaction steps in SSHR may be different categories, this
function is designed to be referenced by a line item level attribute.
The logic in this function considers all transaction steps that use the same
Page 58
API to be of the same category. Multiple APIs can be lumped into the same
category depending on the level of granularity that is appropriate.
The function may be modified to use other criteria to derive the
category of a transaction if needed by the customer.
*/
select decode(hats.api_name,
'BEN_CREATE_PTNL_LER_SS.PROCESS_API','BENEFITS',
'BEN_PROCESS_COBRA_PERSON_SS.PROCESS_API','BENEFITS',
'BEN_PROCESS_COMPENSATION_W.PROCESS_API','BENEFITS',
'BEN_PROCESS_USER_SS_API.PROCESS_API','BENEFITS',
'HR_APPLY_FOR_JOB_APP_WEB.PROCESS_API','BENEFITS',
'HR_ASSIGNMENT_COMMON_SAVE_WEB.PROCESS_API',l_category_undefined,
'HR_BASIC_DETAILS_WEB.PROCESS_API',l_category_undefined,
'HR_CAED_SS.PROCESS_API',l_category_undefined,
'HR_CCMGR_SS.PROCESS_API',l_category_undefined,
'HR_COMP_PROFILE_SS.PROCESS_API',l_category_undefined,
'HR_COMP_REVIEW_WEB_SS.PROCESS_API',l_category_undefined,
'HR_EMP_ADDRESS_WEB.PROCESS_API',l_category_undefined,
'HR_EMP_CONTACT_WEB.PROCESS_API',l_category_undefined,
'HR_EMP_MARITAL_WEB.PROCESS_API',l_category_undefined,
'HR_LOA_SS.PROCESS_API',l_category_undefined,
'HR_PAY_RATE_SS.PROCESS_API','SALARY',
'HR_PAY_RATE_SS.PROCESS_API_JAVA','SALARY',
'HR_PERCMPTNCE_REVIEW_WEB.PROCESS_API',l_category_undefined,
'HR_PROCESS_ADDRESS_SS.PROCESS_API',l_category_undefined,
'HR_PROCESS_ASSIGNMENT_SS.PROCESS_API','ASSIGNMENT',
'HR_PROCESS_CONTACT_SS.PROCESS_API',l_category_undefined,
'HR_PROCESS_CONTACT_SS.PROCESS_CREATE_CONTACT_API',l_category_undefined,
'HR_PROCESS_EIT_SS.PROCESS_API',l_category_undefined,
'HR_PROCESS_PERSON_SS.PROCESS_API',l_category_undefined,
'HR_PROCESS_PHONE_NUMBERS_SS.PROCESS_API',l_category_undefined,
'HR_PROCESS_SIT_SS.PROCESS_API',l_category_undefined,
'HR_PROF_UTIL_WEB.PROCESS_API',l_category_undefined,
'HR_QUA_AWARDS_UTIL_SS.PROCESS_API',l_category_undefined,
'HR_SALARY_WEB.PROCESS_API','SALARY',
'HR_SALARY_WEB.process_API','SALARY',
'HR_SIT_WEB.PROCESS_API',l_category_undefined,
'HR_SUPERVISOR_SS.PROCESS_API','TRANSFER',
'HR_SUPERVISOR_WEB.PROCESS_API','TRANSFER',
'HR_SUPERVISOR_WEB.process_API','TRANSFER',
'HR_TERMINATION_SS.PROCESS_API','TERMINATION',
'HR_TERMINATION_SS.PROCESS_SAVE','TERMINATION',
'HR_TERMINATION_WEB.PROCESS_API','TERMINATION',
'PAY_PPMV4_SS.PROCESS_API','PAYROLL',
'PAY_US_OTF_UTIL_WEB.UPDATE_W4_INFO','PAYROLL',
'PAY_US_WEB_W4.UPDATE_W4_INFO','PAYROLL',
'PQH_PROCESS_ACADEMIC_RANK.PROCESS_API',l_category_undefined,
'PQH_PROCESS_EMP_REVIEW.PROCESS_API',l_category_undefined,
'PQH_PROCESS_TENURE_SS.PROCESS_API',l_category_undefined,
'PQH_PROCESS_TENURE_STATUS.PROCESS_API',l_category_undefined,
l_category_undefined)
into l_transaction_category
where hats.transaction_step_id = p_transaction_step_id;
return l_transaction_category;
exception
when others then return l_category_undefined;
end;
-----------------------------------------------------------------end;
/
COMMIT;
EXIT;
Page 59

May 2003
Author: Bob Eagles
Contributors: Phil Snowball, Linda Zhao, Todd Morley, Geoff Nelson, Satish Ramasamy, Srinivas Nachuri, Kathyrn ODonoghue, Bill Kerr, Murthy Boggavara
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Oracle is the world's largest enterprise software company. For more information
about Oracle, visit our Web site at http://www.oracle.com.
Copyright 2002 Oracle Corporation

SSHR Ame Approval

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSHR Ame Approval

Uploaded by

Copyright:

Available Formats

Configuring Oracle Approvals

Management (R11i10) for Oracle

Configuring Oracle Approvals Management for

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

Example Transaction 2 Personal Information........................ 20

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

Your enterprise employs thousands of people in many departments around the

The decentralization that is possible with self-service applications is only

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

This paper is intended to supplement the following reference materials which

A user-friendly interface guides the user through a series of options, gathering

Although a business user should be able to configure rules and conditions

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

SSHR stores transaction data in a series of three master-detail-detail tables

Each individual SSHR transaction is represented by a single row in

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

applications provide generic services to a wide range of applications and

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

Figure 2 SSHR basic approvals loop

Refer to Approvals chapter of Implementing Oracle Self-Service Human

AME provides list management services to calling applications such as SSHR.

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

Rules are defined in terms of conditions (expressed as an attribute

Attributes and Attribute Usages

Attributes are defined in terms of an attribute name and attribute

Approval Types and Approval Handlers

Approval actions are expressed in terms of an approval type, for

The operation of AME in conjunction with SSHR can be described at a high

A user submits a transaction. The transaction is associated with a

SSHR passes the transaction type, application id, and transaction

SSHR notifies each approver in turn. SSHR notifies each approver in

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

When there are no more approvers to be notified, SSHR records the

Transaction Types and Transaction Categories

AME is able to partition the approvals configuration for dissimilar transactions

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

There is currently no provision in AME to share or copy attribute usages among

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

A single rule (if the WORKFLOW_PROCESS_NAME condition is true,

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

Figure 3 Example Supervisor Hierarchy

Example Transaction 1 Default Configuration

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

Transaction requestors supervisor

2nd supervisor above the requestor

Successive chain of authority approvers

10th supervisor above the transaction

requestor, or top supervisor in the chain.

Inserted Dynamic Approver

Transaction requestors supervisor

2nd supervisor above the requestor

Successive chain of authority approvers

10th supervisor above the transaction

requestor, or top supervisor in the chain.

Configuring Oracle Approvals Management for Oracle Self-Service Human Resources V4

Table 2c Approvals for Example Transaction 1, After First Approval

Inserted Dynamic Approver

Transaction requestors supervisor

2nd supervisor above the requestor

Successive chain of authority approvers

10th supervisor above the transaction

requestor, or top supervisor in the chain.

Inserted Dynamic Approver