Oracle Enterprise Asset

Management
Approval Management in
eAM
An Oracle White Paper
May 2013

Table of Contents
1. OVERVIEW .............................................................................................................................................................................................................................. 1
2. WHERE ARE AME APPROVALS USED IN EAM? ................................................................................................................................................................. 1
3. WHAT ABOUT WORK REQUEST APPROVALS? ................................................................................................................................................................. 2
4. WHAT ABOUT WORK ORDER COMPLETION APPROVALS? ............................................................................................................................................ 2
5. BRIEF OVERVIEW OF APPROVAL MANAGEMENT (AME) ............................................................................................................................................... 3
5.1. AME: TRANSACTION TYPES .............................................................................................................................................................................................. 3
5.2 AME: ATTRIBUTES, CONDITIONS, ACTIONS, ACTION TYPES....................................................................................................................................... 3
5.3 AME : GENERATION OF APPROVERS................................................................................................................................................................................ 5
5.4 AME : VOTING REGIME FOR APPROVAL GROUPS ......................................................................................................................................................... 6
5.5 AME : APPROVAL RULES SUMMARY ................................................................................................................................................................................ 6
5.6 AME : PARALLEL APPROVAL PROCESS ............................................................................................................................................................................ 7
5.7 AME : PROCESS FLOW SUMMARY ..................................................................................................................................................................................... 8
6. SETUPS REQUIRED FOR APPROVALS ................................................................................................................................................................................. 9
7. DEMONSTRATION OF SOME EXAMPLE SCENARIOS USING AME IN EAM ..................................................................................................................10
7.1 EXAMPLE 1 : SINGLE LEVEL APPROVALS ......................................................................................................................................................................10
7.2 EXAMPLE 2 : MULTI/PARALLEL APPROVAL FIRST RESPONDER WINS ...............................................................................................................20
7.3 EXAMPLE 3: MULTI/PARALLEL APPROVAL - CONCENSUS ........................................................................................................................................25
7.4 EXAMPLE 4: HIERARCHICAL APPROVAL ORDER NUMBER ....................................................................................................................................27
7.5 EXAMPLE 5 : APPROVALS USING ESTIMATED COST CRITERIA FOR WORK ORDERS ...........................................................................................30
7.6 EXAMPLE 6 : APPROVALS USING HR HIERARCHY ......................................................................................................................................................35
8. OUTSIDE PROCESSING APPROVALS .................................................................................................................................................................................39

9. WORK PERMIT APPROVALS ...............................................................................................................................................................................................40

10. VACATION RULES ..............................................................................................................................................................................................................40
11. CUSTOMIZING WORKFLOWS ...........................................................................................................................................................................................40

1. OVERVIEW
The objectives of this white paper are to provide an overview of how
Approvals Management (AME)
rules are used in Enterprise Asset
Management (EAM) to generate approvals. It is not designed to be a
specialist AME paper. It will demonstrate approval functionality using
several different types of example . The paper will discuss the following :

Discuss where approvals are used in EAM.

Briefly explain how work requests are approved.
Briefly explain how work order completion approvals work.
Brief overview of AME
Explain the approval process using several different types of
example. These examples will form the main part of the paper and
include the scenarios below:
a.
b.
c.
d.
e.
f.

Single level type approval

Multi/parallel approvals using First Responder Wins
Multi/Parallel approvals using Consensus method
Hierarchy type approval using Order Number
Approval using Estimated Cost criteria for work orders
HR Hierarchy Approval using Supervisory level

Discuss outside processing approvals

Briefly explain work permit approvals.
Discuss vacation rules.
Discuss how workflows can be customized.

2. WHERE ARE AME APPROVALS USED IN EAM ?

Oracle Approvals Management (AME) is a product that allows users to define
rules for an appropriate process (transaction type) without the need to use
code. It means that non-technical people are able to define complex
approval rules using a simple tool.
Approval Rules provide the rules for generating approvals using a
combination of attributes, conditions, action types and actions - we will
discuss these later.
Approval Management is used in EAM in the following processes :

Work Order Release Approval

Work Order Completion
Work Permit Approval

Each of the above come with Seeded Workflows and transaction types
hence the only things a user needs to do is to define the approval rules.

In this white paper, I will concentrate on Work Order Release Approval the principles discussed will apply for the other EAM processes also - so we
can focus on just one business process.

3. WHAT ABOUT WORK REQUEST APPROVALS ?

Work Request Approval does not use AME. Hence, approval of work
requests will not be covered in this white paper as the focus of this white
paper is on the use of AME to handle approvals in EAM.
Work Request Approval requires the following :

Make sure the EAM Work Requests Parameter Auto-Approve is

unchecked.
Make sure Workflow is setup as there is a seeded workflow that is
used for Work Requests.
Setup the Department Approvers in EAM - these are the users who
will approve the work requests by department.

4. WHAT ABOUT WORK ORDER COMPLETION APPROVALS ?

There is an AME Transaction Type and a seeded workflow for EAM Work
Order Completion.
This is not dependent on the EAM Parameter : Enable Workflow for Work
Orders.
Work Completion Approval requires the use of the application Electronic
Records and Signatures.
The following setups are required :

Set the profile : EDR : E-Records and E-Signatures to Yes.

Setup the AME approval Rule for the transaction type : EAM Work
Order Completion.

The approval then works as follows :

During Work Order Completion, the approver has to E-sign the work order
completion process ONLINE.
The objective is to collect the work order details during the completion
process as an E-RECORD. This will be kept as an audit record.
2

The aim of the approval process is simply to get the E-Records created.
The WO Completion workflow was designed for the Pharma industry. No
standard completion workflow exists it has to be customized.

5. BRIEF OVERVIEW OF APPROVAL MANAGEMENT (AME)?

The main purpose of this white paper is to go through some examples of the
use of AME approvals in EAM business processes.
To achieve this aim, it is necessary to have a basic understanding of AME
terminology and how AME works. This section carries out this objective.
5.1 AME : TRANSACTION TYPES :
Each application that integrates with AME divides its transactions into
specific business process categories. Each category requires a separate set of
approval rules. Each set of approval rules and the components of the rules is
called a TRANSACTION TYPE.
There are three seeded Transaction Types used for EAM. They are :

EAM Work Order Release Approval

EAM Permit Release Approval
EAM Work Order Completion

Each transaction type has a header item class which has one item - the
transaction header).
You can add additional item classes to the transaction type these are
optional. (e.g line items, cost centres etc).
AME can generate separate approver lists for the transaction header and
a separate approver list for each item in the transaction.
5.2 AME : ATTRIBUTES, CONDITIONS, ACTIONS, ACTION TYPES :
Before approval rules can be defined, the building blocks for the rules have to
be in place. The building blocks required are :

Attributes
Conditions
Actions
3

Each transaction type comes with a seeded set of attributes, conditions and
actions. Any additional ones that are required for your approval rules can be
created.

ATTRIBUTES : These are business variables with a single value for a

transaction (e,g amount, department, salary). They are used by approval
rules to determine the outcome. Attributes use can be STATIC (fixed value
for the attribute) or DYNAMIC (calculated at runtime using SQL etc).
CONDITIONS : The if part of an approval rule. A condition is either true or
false for a transaction type. Conditions can be regular (e.g conditions on date,
number , string values etc) or List Modifier conditions (check for presence of
specific approvers etc).
ACTIONS : An instruction to AME to modify a transactions approval process
in the manner you specify. An action is an approval rules then part.
Actions can be of 2 types :
- Approval actions modify a transactions approval list.
- Production actions generate a production that assigns a value to a variable
name - such as the value digital certificate to the variable name eSignature.

An example action is :
Require Approval from the XX (where XX is name of an approval group).
This action generates an approval using the approval groups approver list.
ACTION TYPES : Every action belongs to an action type. An action type is a
collection of actions having similar functionality. For example, actions in the
absolute-job-level action type all require approvals upto a certain job level in
the HR supervisory hierarchy.
Action types have a name, rule type, allowed approver type and order
number all associated to them.
Voting Method : Action Types with the chain of authority rule type have a
voting method for the chains of authority generated by the actions. The
voting method affects the notification order of the approvals and how AME
treats their responses. (see later for types of voting).

Action types are grouped into the following :

-

Chain of authority action types

Production action types
Substitution action types
List modification action types.

Pre-seeded action types include : absolute-job-level action type, managerthen-final-approver action type, final-approver-only action type, approvergroup-chain-of-authority action type and supervisor level action type.
5.3 AME : GENERATION OF APPROVERS :
You can use the following in your action types to generate the approvers :
- APPROVER GROUP : Collection of approvers that you define (subject
matter experts)
- CHAIN OF AUTHORITY : This ascends a hierarchy of approvers that are
defined in applications outside of EAM (e,g HRMS). It usually contains
Managers. An approval group can also be treated as a chain of authority.
An Approver List is simply a list of approvers.
AME can generate an approver list for the transaction header and for each
item belonging to the transaction type.
The Approval list for a single transaction has a hierarchical, inverted tree
structure and can have 6 levels root downwards : Item Class, Item, Sub-List,
Action Type, Group or Chain, Group or Chain Member
An Approver has 2 properties :
- Approver Type = any workflow directory services orginating system that
defines entities and can receive notifications.
- Approver Category : Approvers can belong to ACTION categories or FYI
categories (no action required).
The approval process generates either both or one of the following :
- Approval actions. These modify the transactions approval list or generate
approval notifications.
- Productions. A production simply assigns a value to a variable name (e.g
AME may generate a production that assigns value of Digital certificate
to variable E-signature). Productions can be generated at transaction
level, approval level or item level.
5

5.4 AME : VOTING REGIME FOR APPROVAL GROUPS :

The following voting regime is used for approval groups:

Serial : Members are notified one after the other. All members must
approve for the transaction to be approved.
Consensus : ALL members are notified in parallel (at the same time). All
members must approve for the group to approve and for the transaction
to be approved.
First-Responder-Wins : All members are notified in parallel. As soon as
one member responds, the approval is complete. This becomes the group
decision.
Order Number Voting : Members are notified in order of their order
number. Members with the same order number are notified in parallel.
All members must respond for the approval to take place and they must
all approve.

5.5 AME : APPROVAL RULES SUMMARY :

The diagram below summarises the components of the approval rules :

The diagram shows the attributes, condition, action types and action for the
rule.

5.6 AME : PARALLEL APPROVAL PROCESS:

AME provides a parallel approval process the purpose of this is that it
shortens the approval time.
AME constructs an approver tree this will have different levels if required
and will show the approvers at each level.
AME calculates the order number at each level and the approvers at each leaf
of the approver tree.
The Approval process of nodes which are parallel to each other start at the
same time.
After that , the approval process of each node proceeds independently.
Key things to note in the diagram below are :
- There are Eight approvals : A, B, C , D, P, Q, R and S
- The progress of approvers A B C D independent of P Q R S
- A and P notified in parallel to start the process.
Also, please note that this is a complex example using header and line item
type approvals we do not need such complexity in EAM. In EAM, the
transaction types just require approval for the headers.

5.7 AME : PROCESS FLOW SUMMARY :

This is how an integrating application such as EAM works with AME :
1. Ask AME for the transactions entire approver list.
2. Display the approver list to the requestor they can optionally add or
suppress approvers.
3. Communicate any approver additions/suppresions to AME.
4. Ask AME is approval process complete? If not which approvers need
to be notified?
5. Stop if AME says no other approvals required.
6. Notify approvers identified in step 4.
7. Wait for approver to respond to notification.
8. Communicate the response to AME.
9. Go to Step 4.

The diagram below gives a high level business flow of the approval process.

6. SETUPS REQUIRED FOR APPROVALS ?

This section looks at the setups required for approvals APART from the AME
approval rules which will be looked at in the next section using specific
examples :

A. Setup Oracle Workflow :

The details for this are outside the scope of this webcast. Here are the basic
steps :
-

Setup default Oracle Workflow user preferences for your entire

enterprise using Workflow Configuration Page.

Setup directory service to provide details of individuals and roles who

will use Workflow and receive notifications.

Setup the background Workflow Engines to control the load and

throughput of the primary workflow on your system.

Setup Business Event to communicate business events between

systems using event subscription processing and workflow process
event activities.

Remember that EAM has seeded events and subscription. Enable these as
follows :

Go to Responsibility Workflow Administrator Web Applications >

Business Events

Query by Name : oracle.apps.eam.workorder.status.change.pending

Click GO and confirm status is enabled.

Click on Subscription icon and confirm that subscription to function

EAM_WORKORDER_WORKFLOW_PVT.Launch_Workflow exists and
has status of enabled.

B. Setup EAM Parameters :

The main requirement is to check the EAM parameter : Enable Workflow for
Work Orders.

7. DEMONSTRATION OF SOME EXAMPLE SCENARIOS USING AME IN EAM

This section will now look at some examples of how AME can use different
types of approval rules in EAM. We will look at the transaction type EAM
Work Order Release. The examples shown here could equally well be
applied to the other EAM transaction types.
7.1 EXAMPLE 1 : SINGLE LEVEL APPROVALS :
BUSINESS SCENARIO :
The business scenario for this example is as follows:

Just one approver is required for a work order hence, it is a single level
approval.
This means that one notification is sent and as soon as it is approved, the
work order is released.
The approval rules are simple. A specific approver is required each
department all work orders for that department require approval
before being released.
10

Work Orders belonging to Dept F-Maint need to be approved by Pat

Stock
Work Orders belonging to Dept W-Maint are approved by Phillip Taylor

SETUPS
The following setups are required :

There are 2 separate conditions (one condition for each Department).

Each condition will require separate approvers so 2 rules will be required.
Since each rule needs a separate approver , a separate approval group
will be used for each rule.
Each rule will have one condition and one action. Remember you can have
multiple conditions and actions for a rule.
The following screenshots now demonstrate this example :
Each screenshot is followed by an explanatory text for the PRECEEDING
screenshot :

SCREENSHOT 7.1.1 : The screenshot above shows the Business Analyst

Dashboard in the AME application. The transaction type that we are using
can be seen : EAM Work Order Release Approval.

11

SCREENSHOT 7.1.2 : The screenshot above shows the two separate rules that
are required for our example one rule for each department.

SCREENSHOT 7.1.3 : Before we look at the approval rule itself in detail, I will
show the building blocks for the rule. These can be seen from the Setup Tab.
The above screenshot shows the seeded attributes. The attribute that is
required for this example is DEPARTMENT which can be seen above.

12

SCREENSHOT 7.1.4 : The above screenshot shows the conditions that were
defined for this example. There is a condition for each department. The
conditions for both departments use the attribute DEPARTMENT. One
condition checks for DEPARTMENT = F-Maint and the other condition checks
for DEPARTMENT = W-Maint.

SCREENSHOT 7.1.5 : The screenshot above shows the action type and the
actions that will be used for this example. Each rule will use the same action
type (approval group chain of authority) but a separate action. This is
because each action will require approval from a separate approver group
one for each department.
Both the actions that to be used in the example are shown above.

13

SCREENSHOT 7.1.6 : The screenshot above shows the two approver groups
one approver group for each rule. Each approver group contains the
approvers for the specific department.

SCREENSHOT 7.1.7 : The screenshot above shows the setup for the approver
group for Department W-Maint.
The approver type of HR People simple means that the employee must as a
valid employee in HR.
The order number in the header level denotes the order in which any
approver groups in the same sub-list are ordered (in case a rule had multiple
approval groups).
The order number against the employee denotes the order in which
approvers are notified.
The voting method of serial means that the employees in the group are
notified one after the other (however, employees with same order number
are notified at the same time in parallel).
The usage type of static means that we manually need to enter the group
members. If dynamic was chosen as the usage type then a SQL query
would need to be entered to determine the approvers list.
14

SCREENSHOT 7.1.8 : The screenshot above shows the setup for the approver
group for Department F-Maint. The setup for both approval groups is the
same just the list of approvers is different.

SCREENSHOT 7.1.9 : The screenshot above shows the setup for the approval
rule for the F-Maint Department (click the create button on Rules tab to
create the rule). The rule shows the condition which checks for the valid
department and shows the action type and the related action.
The rule is simply as follows :
If DEPARTMENT = F-Maint , then require approval from the Approval group
EAM WO Release Dept 2 (which contains the approvers for F-Maint dept)

15

SCREENSHOT 7.1.10 : The screenshot above shows the setup for the second
approval rule - this time for the W-Maint Department.
The rule is simply as follows :
If DEPARTMENT = W-Maint , then require approval from the Approval group
EAM WO Release (which contains the approvers for W-Maint dept)

SCREENSHOT 7.1.11 : The next few slides will now demonstrate the rules in
action. The screenshot above shows that a work order for the W-Maint
Department. The status has been set to released and the user is about to hit
the save button.

16

SCREENSHOT 7.1.12 : The screenshot above shows that on saving the work
order, the status is set to RELEASED PENDING. This is because the work order
requires approval before it can be released.

SCREENSHOT 7.1.13 : The screenshot above shows the approval history for
the work order (on opening the work order and clicking the approval history
tab). It can be seen that Phillip Taylor has been sent a notification to approve
the work order hence the status is shown as NOTIFIED. This is the correct
approver see screenshot 7.1.7 above which shows that Phillip Taylor is the
approver for department W-Maint.

17

SCREENSHOT 7.1.14 : The screenshot above shows the notification from the
home page of the Maintenance Superuser Responsibility that was sent to
Phillip Taylor. This is where the notifications can be opened and approved or
rejected.

SCREENSHOT 7.1.15 : The screenshot above shows the notification itself

which is opened by selecting it from the home page. The approver can enter
a note and select the approve or reject button. In this case, the approve
button is selected.

18

SCREENSHOT 7.1.16 : The screenshot above shows that the work order is
now in a released status once the approval is complete.

SCREENSHOT 7.1.17 : Next, the second rule will be demonstrated. The above
screenshot shows a work order entered for the F-Maint Department.

SCREENSHOT 7.1.18 : The screenshot above shows that on clicking save, the
work order is in a Released Pending status since it requires approval.
19

SCREENSHOT 7.1.19 : The screenshot above shows the approval history tab
for the work order which confirms that the correct approver has been
notified Pat Stock (see screenshot 7.1.8 which confirms the approver for
department F-Maint).
There is no need to demonstrate the approval process itself since we have
already seen this for the first rule.

7.2 EXAMPLE 2 : MULTI/PARALLEL APPROVAL FIRST RESPONDER WINS :

BUSINESS SCENARIO
The business scenario for this 2nd example is as follows:

All Work Orders for the Department F-Maint will generate notifications
that go to MULTIPLE approvers.
The notifications will go to multiple approvers at the same time - this is
called PARALLEL APPROVAL.
This example uses the voting method of FIRST_RESPONDER_WINS. This
means that the first approver who approves the notification will make the
decision for the rest of the approvers and this results in the work order
being approved. If anyone else responds after this, their details will be
logged but ignored by AME.
Advantage of this method : It does not rely on one approver (who may be
absent or busy). It means that any available approver from the group can
approve. Typically, a company allows several managers to approve and
any of them can approve the work order. Hence, this is a commonly used
and recommended approach.

20

SCREENSHOT 7.2.1 : The screenshot above shows the business rule being
used for this example. Just one rule is required and its called First
Responder Wins for Dept F-Maint. It is likely that similar rules will be
created for each department in the company.

SCREENSHOT 7.2.2 : The screenshot above shows components of the

business rule we are using.
There is one condition being used using the attribute DEPARTMENT. The
condition simply checks for Department = F-Maint.
The action type is approval group chain of authority using an action that
requires approval from an approval group called First Responder Wins
Approval Group.

21

SCREENSHOT 7.2.3 : The screenshot above shows the setup for the action
type being used for the rule.
Note that the ordering mode is Parallel. This means that all approvers with
the same order number will be informed at the SAME time.
The voting method is First Responder Wins. As mentioned before, this
means that the first approver who responds will make the decision for the
whole approval group any further responses have no impact.

SCREENSHOT 7.2.4 : The screenshot above shows the setup of the approval
group used for the rule.
The voting method is First Responder Wins for reasons explained
previously.
Note that there are 2 approvers and both have order number 1. This means
that that they will both be notified at the same time (in parallel). In reality,
there are likely to be more then 2 approvers but the principle will be the
same.

22

SCREENSHOT 7.2.5 : The screenshot above shows a work order created for
the department F-Maint.
Note that the status of the work order is Released-Pending because it
requires approval before being released.
Note also that BOTH the approvers Pat Stock and Phillip Taylor have been
notified at the same time (in parallel). The approval status for both is
NOTIFIED.

SCREENSHOT 7.2.6 : The screenshot above shows the notification for the
approver, Phillip Taylor.

23

SCREENSHOT 7.2.7 : The screenshot above shows that Phillip Taylor is about
to approve the notification.

SCREENSHOT 7.2.8 : The screenshot above shows that the work order has
been released as a result of Phillip Taylors approval.

SCREENSHOT 7.2.9 : The screenshot above confirms that Phillip Taylors

response was enough to approve the work order. The second approver was
not required and the status of the remaining approvers who did not respond
is set to BEAT BY FIRST APPROVER.
24

7.3 EXAMPLE 3 : MULTI/PARALLEL APPROVAL - CONSENSUS :

BUSINESS SCENARIO :
Imagine a scenario where work orders for a key asset(s) for a department
need to be approved by all the key employees/managers. As a result, the
following are required:

All the key employees/managers need to get the notification in

parallel and at the same time.
They ALL have to approve the notification as they are key users of the
asset(s). If any one person rejects the notification, the work order is
rejected.

Typical Uses :
Key Maintenance projects where all members of the team need to be aware
of the maintenance work being done for key assets and all have to approve.

SCREENSHT 7.3.1 : The screenshot above shows the components of the

business rule being used.
In this example, I have used multiple conditions to demonstrate how various
criteria can be used to identify work orders using attributes. I have selected a
specific department and organization and specified a key asset that the rule
applies to (used attribute ASSET_NUMBER and condition ASSET_NUMBER in
FL1010). This type of business rule is commonly used for approval of
maintenance work for key, expensive assets and the conditions can be used
as specified to select the asset.
The Action type is an approval group chain of authority and will use an
approval group that requires a concensus type approval.

25

SCREENSHOT 7.3.2 : The screenshot above shows the key setup for the
action type.
Note that the ordering mode is parallel meaning all approvers with the
same order numbers will be notified in parallel.
The voting method is consensus meaning that everyone in the approval
group MUST approve for the work order to be approved. If anyone rejects
their notification, the whole work order will be rejected.

SCREENSHOT 7.3.3 : The screenshot above

consensus approval group.

shows the setup for the

Note that both approvers have the same order number and will be notified at
the same time (in parallel). In reality, there are likely to be more approvers
then the 2 shown here. Also, there may be different levels of approver with
different order numbers assigned to them this means that a hierarchical
build up of approvals can be setup. The first level could be shop floor
management (order number 1) followed by Senior Managers (order number
2) followed by Directors (order number 3). However, the principle is still the
same they all have to approve. Hence the 2 approvers shown in the
example is sufficient to show the process involved.

26

SCREENSHOT 7.3.4 : The screenshot above shows a work order created for
the relevant condition. It is in Released -Pending status because it is awaiting
approval. Note that BOTH the approvers have been notified.

SCREENSHOT 7.3.5 : The screenshot above shows that Phillip Taylor has
approved his notification. However, the work order is still in status of
Released-Pending because Pat Stock has NOT yet approved hence the
consensus principle has been demonstrated and the rule works correctly.
7.4 EXAMPLE 4 : HIERARCHICAL APPROVAL ORDER NUMBER :
BUSINESS CASE :

The work order needs to be approved by several key approvers.

However, the approval is done in a hierarchical order. For example - Shop
Floor Manager approves first. A notification is then sent to the General
Manager for the 2nd level of approval. The final approver is then someone
at Director level. When he/she approves the notification, the work order
is released. If anyone in the chain rejects the notification, the whole work
order is rejected and no further notifications are sent up the chain.
This is a multi level approval. It is serial. Each approver is notified in order
of the ORDER NUMBER. The approver with order number 1 gets the first
27

notification. When he/she approves, a notification is sent to the approver

with ORDER NUMBER 2 and so on.
If 2 approvers have the same order number, they are notified in parallel.
Typical Uses :
Some assets in a department may be of very high value and any
maintenance may need to have approval at several levels before the work
order is approved.

SCREENSHOT 7.4.1 : The screenshot above shows the components of the

rule.
The rule uses 2 conditions one to check for the department and the other
to check for a specific asset which is of such importance that this kind of
hierarchical approval is required at different levels.
The action used shows that approval will be required from a new approval
group Hierarchical Approval F-Maint Order Number.

SCREENSHOT 7.4.2 : The screenshot above shows the setup for the action
type used. Note that the ordering mode is now SERIAL (members will be
notified one after the other by order number). The voting method is also
28

serial (members notified one after the other by order number all members
with the same order number get notified at same time. All members must
approve or order will be rejected).

SCREENSHOT 7.4.3 : The screenshot above shows the setup of the approval
group. Note the voting method is Order Number meaning that members
will be notified by order number sequence.
Note that Phillip Taylor has order number 1 and will be notified first.
Pat Stock (lets say she is Phillips Manager in this example) has order number
2 and will only be notifed AFTER Phillip Taylor approves his notification.

SCREENSHOT 7.4.4 : The screenshot shows Phillip Taylor has been notified as
can be seen from the notified status. This is because he has order number of
1 in the approval group as shown earlier.
However, Pat Stock has not been notified yet she has order number 2 in the
approval group. She will only be notified only after Phillip Taylor approves.

29

SCREENSHOT 7.4.5 : The screenshot above shows that the rule has worked as
required.
Phillip Taylor has approved his notification as shown by the approve status.
This then triggers the notification to the next order number - which is for Pat
Stock (order number 2). The system shows a status of NOTIFIED for Pat Stock.
Note that although Phillip has approved his notification, the work order
status is still Released-Pending (as per the rules for serial approval).
Once Pat Stock approves, the whole work order is released since she is the
last approver.
If Phillip Taylor had rejected his notification, Pat Stock would receive no
notification and the work order would be rejected.

7.5 EXAMPLE 5 : APPROVAL USING ESTIMATED COST OF WORK ORDER

CRITERIA :
BUSINESS CASE :
This is a very commonly requested business scenario which I will now
demonstrate.
The requirement is based on a specific criteria estimated cost of the work
order.

If the estimated cost of the work order is less the 30, it will only require
approval by the Shop Floor Supervisor and not at Managerial level.
However, if the estimated cost of the work order is between 30 and
1000, it will require approval by the Works Manager.
Anything above 1000 will require approval from a Director but we will
just demonstrate the first 2 levels the principal is the same.
It is important to understand that work orders must be estimated before
they are released for this rule to work (however, a validation approval rule
could exist to validate any work orders with estimated costs of zero and
resubmit them after estimating the costs).
30

SETUPS NEEDED:
1. A new attribute called EST COST using a SQL to pick up the estimated cost
from a view as it is not held in a table.
2. The appropriate number of conditions to validate the estimate cost range
( 0 to 30, 30 to 1000, 1000 to 1000000 etc).
3. A new rule for each condition. Each rule will also specify the approvers for
that cost level.

SCREENSHOT 7.5.1 : The screenshot above shows the setup for the new
attribute that is required to pick up the estimated cost of the work order.
Notice that the usage type is dynamic because the value will be picked up at
run time. The sql used is :
Select wec.estimated_total_cost from wip_eam_cost_details_v wec,
eam_wo_workflows eww where wec.wip_entity_id = eww.wip_entity_id and
eww.wf_item_key = :transactionId

SCREENSHOT 7.5.2 : The screenshot above shows one of the conditions that
31

checks the EST COST attribute. The above condition will check for estimated
work order cost between 0 to 30.

SCREENSHOT 7.5.3 : The screenshot above shows the second condition that
checks the EST COST attribute. The above condition will check for estimated
work order cost between 30 to 1000.

SCREENSHOT 7.5.4 : The above screenshot shows the 2 rules required for this
business case. The next 2 slides will look at the components of each of these
rules.

32

SCREENSHOT 7.5.5 : The first rule uses the condition which checks for
estimated work order cost between 0 to 30 using the new attribute EST
COST.
It uses the approval group chain of authority.
It uses the action Require approval from EAM WO Release Dept 2 because
this approval group will only contain the approvers who can approve work
orders which are between 0 to 30.

SCREENSHOT 7.5.6 : The second rule uses the condition which checks for
estimated work order cost between 30 to 1000 using the new attribute
EST COST.
It uses the approval group chain of authority.
It uses the action Require approval from EAM WO Release because this
approval group will only contain the approvers who can approve work orders
which are between 30 to 1000.

33

SCREENSHOT 7.5.7 : The above work order has been raised to verify the first
of the approval rules. The work order has an estimated cost of 27.08. It is
about to be released by the user which will send the status to ReleasedPending because the work order requires approval.

SCREENSHOT 7.5.7 : The above screenshot confirms that the approval has
been sent to the correct approver.
The approver Pat Stock has been notified.
Screenshot 7.5.5 showed that work orders between 0 to 30 require
approval from EAM WO Release Dept 2.
Screenshot 7.1.8 confirms the setup of the approval group EAM WO Release
Dept 2 and shows that Pat Stock is the approver in this group.
Hence the rule has worked correctly.

SCREENSHOT 7.5.8 : The above work order has been raised to verify the
second of the approval rules. The work order has an estimated cost of
34

33.05. It is about to be released by the user which will send the status to
Released-Pending because the work order requires approval.

SCREENSHOT 7.5.9 : The above screenshot confirms that the approval has
been sent to the correct approver.
The approver Phillip Taylor has been notified.
Screenshot 7.5.6 showed that work orders between 30 to 1000 require
approval from EAM WO Release.
Screenshot 7.1.7 confirms the setup of the approval group EAM WO
Release and shows that Phillip Taylor is the approver in this group.
Hence the rule has worked correctly.
7.6 EXAMPLE 6 : HR HIERARCHY :
BUSINESS CASE :

A shop floor worker raises a work order for maintenance.

The AME system checks who his supervisor is and send them a
notification.
The supervisor approves the notification.
The work order is approved.

Note : As per Oracle documentation, the "approval-group chain of authority"

action type is the default and recommended for Work Order Release process.
However, the Supervisory Level action type can be setup also and this is
the action type that is required for this business rule.
35

SETUPS REQUIRED:

A business rule requiring action type of Supervisory level.

Select an action which indicates how many levels of approval are required
(for example you may want to go to the first superior only - the
supervisor of the person raising the work order. You can specify multiple
superior levels depending on business need).
Setup the required attributes for supervisory level. The one that has
been proven to work is TRANSACTION_REQUESTOR_PERSON_ID.

SCREENSHOT 7.6.1 : The screenshot above shows the setup required for one
of the required attributes - TRANSACTION_REQUESTOR_PERSON_ID - when
using the supervisory level action type. You need to modify the seeded
attribute by entering the above SQL to pick up the employee id for the
requestor.
As per Oracle documentation, the "approval-group chain of authority" action
type is the default and recommended for Work Order Release process.
If you are using an action type other than the default "approval-group chain
of authority" (such as supervisory level), then you need to setup the required
attributes.
For "Supervisory level", the three attributes required are:
TOP_SUPERVISOR_PERSON_ID
TRANSACTION_REQUESTOR_PERSON_ID
SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID
The attribute TRANSACTION_REQUESTOR_PERSON_ID has been proven to
work and needs to be setup as shown above. You cannot use the attribute in
36

its seeded form you need to modify it as shown above.

Setting up this attribute as in the example above is SUFFICIENT to make this
rule work. You do not need to touch the other 2 attributes shown above
unless there is a specific need.
The required SQL for the TRANSACTION_REQUESTOR_PERSON_ID attribute
is:
SELECT EMPLOYEE_ID
FROM FND_USER
WHERE USER_ID = (SELECT EWW.CREATED_BY
FROM EAM_WO_WORKFLOWS EWW, WIP_DISCRETE_JOBS WDJ
WHERE EWW.WF_ITEM_KEY = :transactionId AND EWW.WIP_ENTITY_ID =
WDJ.WIP_ENTITY_ID)

SCREENSHOT 7.6.2 : The screenshot above shows a basic rule for HR

Hierarchy type approvals.
The rule is using "Supervisory level" action type and the related action
requires approvals up to the first superior.
This means that if the hierarchy is :
A (person who created WO) > B > C > D
Then the WO will be approved once B approves and will not go onto C.

37

SCREENSHOT 7.6.3 : The screenshot above shows the HR record (Enter and
Maintain People Form in HR responsibility) for Pat Stock. It shows her
supervisor is Phillip Taylor in this example.

SCREENSHOT 7.6.4 : The screenshot above proves that the supervisory rule
worked.
It shows a notification was sent to Phillip Taylor for Work order WO719256
which was created by Pat Stock as can be verified by the request from field
in the notification.
Phillip Taylor is Pat Stocks Supervisor as shown in the previous screen.
Hence the rule worked.

38

8. OUTSIDE PROCESSING APPROVALS IN EAM

When the standard OSP process is run, a requisition is created that is in
APPROVED status.
This cannot be changed and is the standard functionality.
There are 2 different solutions for Outside processing :
a. Use the standard OSP Process that requires the setup of an OSP item, OSP
resource and assigning the resource to an OSP operation in the
appropriate department. This method uses the criteria defined in WIP
Parameters>Outside Processing regarding when the purchase requisition
is released.
The following points should be noted for this solution :
The work order can use the AME : Work Order Release approval
process already discussed.
The Purchase Requisition that is generated is always generated in
APPROVED status and this cannot be changed. For some
customers, this is an issue because their purchasing documents
all require approval. However, this is standard functionality.

b. The second solution for OSP is to use NON-STOCK DIRECT ITEMS for the
OSP work and enter these on the work order.
In fact, when direct items were introduced in EAM in 11.5.10, this was
the recommended solution for OSP.
The advantages of this method are:
Simpler setup is required just use non-stock direct items.
The Work Order can go through the AME : Work Order Release
approval process that we have already discussed.
However, the Purchase Requisition is also created based on the
privileges the user has (in the approval workflow on purchasing
side). Hence these requisitions undergo the required approval
process. This is a major advantage for some customers.

39

9. WORK PERMIT APPROVALS

This is recently introduced functionality for approval of Work Permits (Safety
Management).
It uses the EAM Parameter Enable Workflow For Work Orders.
This enables the EAM Work Permit Workflow to be used.
Then you need to set AME Rules similar to those shown for Work Order
Release.

10. VACATION RULES

Vacation Rules are created to delegate the ownership of a notification to
another user when the original owner is on vacation.
When new work orders are created, the notification will then flow to the
new user.
Only Workflow Administrators can create vacation rules using the navigation
below :
Navigation : Workflow Administration Responsibility> Administration >
Vacation Rules

11. CUSTOMIZING WORKFLOWS

Sometimes the standard workflows are not sufficient to meet a customers
needs. Their only option is to customize.
Disclaimer: Oracle does not recommend or support custom workflows.
How can workflows be customized?
The previous examples in this webcast have used seeded events and
subscription.
What is an event? An Event is simply a business activity
What is an event subscription? An Event subscription is the processing that is
carried out when the triggering event occurs.

40

Basic Steps

You would need to setup business events and event subscriptions

within Oracle Workflow. (define using workflow administrator
responsibility)
Specify which events will trigger the workflow.
You can write PL/SQL functions that can be specified for the
subscription event (the action type field for the subscription should
therefore be CUSTOM).
These PL/SQL functions allow you to enter your custom code and will
also launch your custom workflow
Your workflow is assigned to the event subscription
The workflow name and workflow process to be launched for the
event will be picked up from workflow_name and workflow_process
attributes for the event.

41

Component Pick Release

April 2011
Author: Zar Ahmed
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.
Copyright 2003 Oracle Corporation
All rights reserved.

42