Professional Documents
Culture Documents
EAM - Approvals AME PDF
EAM - Approvals AME PDF
Management
Approval Management in
eAM
1. OVERVIEW .............................................................................................................................................................................................................................. 1
7.5 EXAMPLE 5 : APPROVALS USING ESTIMATED COST CRITERIA FOR WORK ORDERS ...........................................................................................30
2
1. OVERVIEW
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.
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 :
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.
Setup the AME approval Rule for the transaction type : EAM Work
Order Completion.
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 main purpose of this white paper is to go through some examples of the
use of AME approvals in EAM business processes.
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 :
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.
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.
An example action is :
This action generates an approval using the approval groups approver list.
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).
4
Action types are grouped into the following :
You can use the following in your action types to generate the 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
5
5.4 AME : VOTING REGIME 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.
The diagram shows the attributes, condition, action types and action for the
rule.
6
5.6 AME : PARALLEL APPROVAL PROCESS:
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.
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.
7
5.7 AME : PROCESS FLOW SUMMARY :
The diagram below gives a high level business flow of the approval process.
8
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 :
The details for this are outside the scope of this webcast. Here are the basic
steps :
Remember that EAM has seeded events and subscription. Enable these as
follows :
9
B. Setup EAM Parameters :
The main requirement is to check the EAM parameter : Enable Workflow for
Work Orders.
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.
BUSINESS SCENARIO :
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
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.
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.
BUSINESS SCENARIO
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.
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.
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:
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.
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 shows the setup for the
consensus approval group.
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.
BUSINESS CASE :
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 :
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.
BUSINESS CASE :
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 :
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 Released-
Pending because the work order requires approval.
SCREENSHOT 7.5.7 : The above screenshot confirms that the approval has
been sent to the correct approver.
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.
BUSINESS CASE :
35
SETUPS REQUIRED:
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.
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.
TOP_SUPERVISOR_PERSON_ID
TRANSACTION_REQUESTOR_PERSON_ID
SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID
36
its seeded form you need to modify it as shown above.
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)
The rule is using "Supervisory level" action type and the related action
requires approvals up to the first superior.
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.
38
8. OUTSIDE PROCESSING APPROVALS IN EAM
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 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.
39
9. WORK PERMIT APPROVALS
Then you need to set AME Rules similar to those shown for Work Order
Release.
The previous examples in this webcast have used seeded events and
subscription.
40
Basic Steps
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
42