JDE Enterprise One Equip Asset Managments Approvals

8/18/2019 JDE Enterprise One Equip Asset Managments Approvals

1/45

Oracle Enterprise Asset

Management

– Approval Management in

eAM

An Oracle White Paper

May 2013


2/45

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


3/45

2

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

10. VACATION RULES ..............................................................................................................................................................................................................40

11. CUSTOMIZING WORKFLOWS ...........................................................................................................................................................................................40


4/45

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.

Single level type approval

b.

Multi/parallel approvals – using First Responder Winsc.

Multi/Parallel approvals using Consensus method

d.

Hierarchy type approval using Order Number

e.

Approval using Estimated Cost criteria for work orders

f.

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.


5/45

2

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.


6/45

3

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 ofapproval 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 - thetransaction 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 tobe in place. The building blocks required are :

Attributes

Conditions

Actions


7/45

4

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 atransaction (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 transaction’s 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 transaction’s 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 AMEtreats their responses. (see later for types of voting).


8/45

5

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, manager-

then-final-approver action type, final-approver-only action type, approver-

group-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 generateapproval 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.


9/45

6

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.


10/45

7

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 requiredand 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.


11/45

8

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 orsuppress 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.


12/45

9

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 asfollows :

• 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.


13/45

10

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 differenttypes 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 levelapproval.

• 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.


14/45

11

• 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.


15/45

12

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.


16/45

13

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 checksfor 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.


17/45

14

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.


18/45

15

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)


19/45

16

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.


20/45

17

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.


21/45

18

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.


22/45

19

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.


23/45

20

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 andany of them can approve the work order. Hence, this is a commonly used

and recommended approach.


24/45

21

SCREENSHOT 7.2.1 : The screenshot above shows the business rule being

used for this example. Just one rule is required and it’s 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”.


25/45

22

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 meansthat 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.


26/45

23

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.


27/45

24

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 Taylor’s approval.

SCREENSHOT 7.2.9 : The screenshot above confirms that Phillip Taylor’s

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”.


28/45

25

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, thefollowing 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.


29/45

26

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 floormanagement (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.


30/45


31/45

28

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


32/45

29

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 memberswill 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 Phillip’s 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.


33/45

30

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).


34/45

31

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


35/45

32

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.


36/45

33

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 thisapproval group will only contain the approvers who can approve work orders

which are between £30 to £1000.


37/45

34

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.

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


38/45

35

£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.


39/45

36

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 multiplesuperior 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 therequestor.

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


40/45

37

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.


41/45

38

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 Stock’s Supervisor as shown in the previous screen.

Hence the rule worked.


42/45

39

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 approvalprocess 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 wasthe 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.


43/45

40

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 thenew 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 customer’sneeds. 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.


44/45

41

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.


45/45

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.
http://www.oracle.com/http://www.oracle.com/http://www.oracle.com/

Documents

JDE Enterprise One Equip Asset Managments Approvals