Distributed Oracle EAM - A White paper

Distributed Oracle eAM An Oracle White Paper May 2009

Distributed Oracle eAM

CONTENTS

1. Introduction ................................................................................................................... 1

2. Deployment and Architecture ....................................................................................... 2

3. Reference data synchronization .................................................................................... 4

4. Business Flows .............................................................................................................. 7

4.1 Work Request to Work Completion ..................................................................... 7

4.2 Preventive Maintenance to Work Execution ........................................................ 8

4.3 Asset Acquisition to Maintenance ........................................................................ 9

4.4 Siebel Call Center to Maintenance Execution (for Public Sector / Federal) ...... 10

4.5 Manufacturing downtime integration for Capacity Planning ............................. 11

5. Implementation ........................................................................................................... 12

5.1 Work Order Creation and Release ...................................................................... 12

5.2 Work Order Transactions .................................................................................... 15

5.2.1 Resource Transactions ................................................................................ 15

5.2.2 Direct Item procurement /OSP flow ........................................................... 16

5.2.3 One-step material issue and material return ............................................... 19

5.2.4 Two-step material issue .............................................................................. 21

5.3 Work Order Completion ..................................................................................... 21

5.3.1 Work Order Completion Transactions ....................................................... 21

5.3.2 Work Order Close and Period Close .......................................................... 24

5.4 Asset Transactability Support ............................................................................. 25

5.5 Asset Genealogy ................................................................................................. 27

5.6 On Hand synchronization for MRO items .......................................................... 27

6. Integration artifacts from Oracle ................................................................................. 32

7. Supported Features ...................................................................................................... 33

8. Other Considerations / Limitations ............................................................................. 34

Appendix ............................................................................................................................. 35

A) Deploying de-centralized purchasing and inventory .......................................... 35

FIGURES

Figure 1 : Business Drivers for Distributed eAM Solution ....................................................... 1

Figure 2 : Deployment and Interactions .................................................................................... 3

Figure 3 : Work Request to Work Completion flow ................................................................. 8

Figure 4 : Preventive Maintenance to Work Execution flow .................................................... 9

Figure 5 : Asset Acquisition to Maintenance........................................................................... 10

Figure 6 : Siebel Call Center to Maintenance Execution ......................................................... 11

Figure 7 : Manufacturing Downtime Integration ..................................................................... 11

Figure 8 : Work Order Creation Flow ..................................................................................... 13

Figure 9 : Direct Item Procurement Flow ................................................................................ 17

Figure 10 : Work Order Completion sync-up recommendations ............................................ 23

Figure 11 : Recommendations for Asset transactability scenarios .......................................... 25

Figure 12 : Purchasing Flow for Stocked MRO Items ............................................................ 28

Figure 13 : De-centralized purchasing deployment ................................................................. 35

Standalone Oracle EAM Page 1


1. Introduction

Traditionally Oracle eAM has been sold and implemented along with other modules of

Oracle E-Business suite as a single instance. The advantage of this approach is that it

offers a seamlessly integrated solution with well defined setup procedures and prebuilt

integration touch points with other modules.

However, in recent times many customers and prospects are evaluating implementation

of eAM functions in a distributed mode, for the following reasons :

Figure 1 : Business Drivers for Distributed eAM Solution

1. Many customers using 11i Oracle EBS, especially in the asset intensive industry

segments, find their key maintenance business requirements addressed among the

features released in R12 and 12.1 releases. For such customers, implementing R12

eAM in a standalone mode and integrating it with their existing 11i backbone

ERP provides a quick way to uptake and start using the newly released features,

till the ERP system itself is ready to be upgraded to the latest release.

2. Prospects in industry verticals like Utilities, Mining, etc evaluate their business

software around the capabilities of a maintenance solution instead of an ERP

system. Also, some prospects in the asset intensive industry segments would like

to implement their maintenance business functions first and integrate with their

legacy financial systems, before evaluating the bigger backbone ERP system.

Compete in Maintenance Deals

• How to serve the needs of customers who are looking for a maintenance solution without any big requirement for an ERP?

Leverage Best-in-Class Features

• How can I use the features in the latest eAM release without upgrading the whole application suite?

Ensure High Availability

• In Asset Intensive industries, how to ensure that a mission critical application like EAM is available 24*7?

eAM instance decoupled from EBS

Easily integrate with host system

Streamlined processes & visibility

Distributed eAM

eAM for Non-EBS Host How can I use eAM

to manage my maintenance functions with a non-EBS ERP host system?

Distributed Oracle EAM Page 2

Oracle can compete effectively in such accounts through the standalone mode

implementation capability.

3. Customers operating in multiple remote locations (e.g. plants, ships, offshore

platforms, etc), can use their maintenance functions round the clock in a

standalone mode and synchronize the transactions in a distributed batch mode

with the central ERP system. This lets them operate their maintenance functions

independently and yet integrate in a batch mode with the ERP system for costing,

purchasing and inventory functions.

4. Some prospects/customers having a non-EBS Financial system such as SAP or

other legacy systems would like to implement Oracle eAM for handling their

maintenance needs. In the past, Oracle has not aggressively participated in such

deals due to the integrated nature of eAM flows. By providing an approach to de-

couple eAM from the EBS backbone using standalone eAM, we can participate in

such deals more effectively.

The objective of this whitepaper is to document and explain the suggested approach for a

implementing a distributed eAM system. Integration with non-EBS financial applications

may involve a modified approach from that stated in this document. This whitepaper

provides a high level view to implement a distributed eAM solution and is targeted at

implementation and sales consultants. Suggested setup methods and integration

approaches are provided, which can be implemented by the customer though a systems

integrator.

Please refer to whitepaper „Standalone Oracle WMS‟ for implementation

recommendations to purchase and receive MRO items in the distributed instance and

keep inventories synchronized between the two instances.

2. Deployment and Architecture

Distributed eAM Instance

The distributed eAM instances can be configured to operate the core maintenance

business functions. To execute the maintenance business flows related to materials,

necessary inventory on-hand balance information will have to be maintained.

The distributed eAM system will be the source of truth for eAM setup data and

Asset/Work history records. It will support execution of core eAM related business flows

such as Breakdown Maintenance, Preventive Maintenance, Work Definition, Work

Scheduling and Planning, Work Execution and reporting, Failure analysis, etc. All eAM

historical data and reports can be queried from this instance. The distributed eAM

instances can operate independent of the ERP instance. Since it is not the intention to cost

the transactions in the distributed instances, it is sufficient to do the minimal GL setups

required for Organization creation.


Figure 2 : Deployment and Interactions

Host ERP Instance

The Host ERP Instance will operate the broad business functions related to HCM, CRM,

FIN, SCM, etc. This instance will be responsible for carrying out centralized procurement

functions, AP Invoice matching, Inventory valuation and balances, HR functions, etc.

From an eAM standpoint, the ERP instance will be responsible for costing the eAM

transactions and posting the entries into General Ledger.

Prior to loading of transactional data into the ERP instance, an initial effort to replicate

eAM setup data needs to be done. This can be achieved manually, through SQL using

interface tables, Web ADI or ODI tool to populate the setup data in the ERP instance

similar to the eAM instance.

In order to update the inventory balances and perform costing of transactions, eAM work

orders and transactional data need to be synchronized from the eAM instance into the

ERP instance. This can be achieved using custom programs or a tool like Oracle Data

Integrator (ODI), which will call the work order API or insert a transaction record into

the interface table in the ERP instance. The ERP instance‟s transaction and cost manager

will process the transactions, cost it and post the accounting entries into GL.


3. Reference data synchronization

As almost all the maintenance business functions will be performed in the eAM instance,

it is recommended to do the complete setups for eAM flows in this instance. Since work

orders will be replicated to ERP instance for costing purpose, it is necessary to replicate

some mandatory eAM reference data to the ERP instance as well. These reference data

need to be kept in a synchronized state on an ongoing basis.

The following table summarizes the recommendations for reference data synchronization

between the Distributed eAM instance and the ERP instance.

Note: “ ” mark signifies that the setup step has to be done in that instance

Function-

al Area

Master Entity Instance to setup data Data Sync.

between

instances:

1-Mandatory

2-Optional

Data Entry/

Sync. options:

1 – Manual

2 – API

3 – Interfaces

4 – WebADI

5 – Web services

ERP

Only

Distri

buted

eAM

Only

Both

Common

Accounting Key Flexfield

-Value Sets 2 1 -Accounting Key Flexfield

Structure

2 1

-Accounting Key Flexfield

Segments

2 1

-Chart of Account Segment

Values

2 1

Cross Validation Rules 1 Currencies 1 1 Accounting Calendars -Accounting Period Types 1 -Periods to Accounting

Calendar

1 1

Accounting Structure -Locations 1 -Legal Entity Profile

Options

1

-Legal Entity 1 1 -Primary Ledger 1 1

HRMS

Organization Type Lookup

Codes

1

HRMS Key Flexfield Value

Sets.

1

HR Key Flexfields (6) -Grade Flexfield. 1 -Job Flexfield 1 -Position Flexfield 1 -Competence Flexfield 1


Function-

al Area


between

instances:

1-Mandatory

2-Optional

Data Entry/

Sync. options:

1 – Manual

2 – API

3 – Interfaces

4 – WebADI

5 – Web services

ERP

Only

Distri

buted

eAM

Only

Both

-Cost Allocation Flexfield 1 -People Group Flexfield 1 Employee 1 1,2 Locations 1 HR Business Group

Organization

1

Organization Calendar 1 Organizations- GRE LE,

Operating Units, Inventory

Organizations

1 1

Setup Default Operating

Unit for your Site

1

Multi-Org Administrative

Processes

1

-Concurrent Managers-

Define, Administer

1

-Submit Workflow

processes

1

-Gather Schema Statistics 1 -Replicate Seed data for

operating unit

1

FND

Attachments 1 Descriptive Flex 1 Responsibilities 1 User 1 Assign Responsibilities to

User

1

Inventory

Inventory Key Flexfield

Value Sets

1 1

Inventory Key flexfields 1 -Item Flexfield 1 1 -Item Category Flexfield 2 1 -Item Catalog Group

Flexfield

1

-Stock Locators Flexfield 1 1 -Account Alias Key

Flexfield

1

Organization Receiving

Options

1

Unit of Measure -UOM Classes 1 1 -UOMs 1 1 -UOM Conversions 1 1


Function-

al Area


between

instances:

1-Mandatory

2-Optional

Data Entry/

Sync. options:

1 – Manual

2 – API

3 – Interfaces

4 – WebADI

5 – Web services

ERP

Only

Distri

buted

eAM

Only

Both

Subinventories 1 1, 4 Stock Locators 1 1 Item Attribute Control 1 Item Categories 2 1,2,3

Item Category Set 2 1,2,3

Item Default Category Set 1,2,3

Item Statuses 1

Item Types 1

Items - MRO Stocked

Items, Non-Stock Direct

Items, OSP Items

1 1,3,4

Shipping Network 1 1

Account Aliases 1

Transaction Source Types 1

Transaction types 1

Transaction Reasons 1

Purchasing Options 1

Accounting Periods 1 1

Inventory Profile Options 1 1

Item Relationships 1

Bills of

Material

Bills of Materials

Parameters

1 1

Workday Calendar 1 1

Resources 1 1

Department Classes 1

Departments 1 1

Standard Operations 2 1

Bill of Materials Profile

Options

2 1

Work in

Process

Work in Process Parameters 1 1

WIP Accounting Classes 1 1

Quality

Collection Elements 2 1

Collection Plans 2 1,2,3

Specifications 2 1

Collection Element Types 2 1

User Groups and Privileges 2 1

EAM


Function-

al Area


between

instances:

1-Mandatory

2-Optional

Data Entry/

Sync. options:

1 – Manual

2 – API

3 – Interfaces

4 – WebADI

5 – Web services

ERP

Only

Distri

buted

eAM

Only

Both

EAM Parameters 1 1

IB Parameters 1 1

Define EAM Look-up codes 2 1

Areas 2 1

Activity Items 1 1,3,4

Maintenance BOM 2 1,3,5

Maintenance Routing 2 1,3,5

Asset Groups and Rebuild

Items

1 1,3,4,5

Attribute Assignments 2 1

Asset Numbers, Rebuild

Numbers, Asset Routes

1 1,3, 5

Activity Association 1 1,5

Meter Definition 2 1,3

Meter Association 2 1,3

Set Name 2 1

Suppression 2 1

Last Service Info 2 1

Schedule Definition 2 1

Work Order Statuses 1 1

Department Approvers 2 1

Category Associations 1 1

Define Forecast 2 1

Failure Codes 2 1

Failure Set 2 1

4. Business Flows

This section outlines some of the broad business flows in eAM and highlights the

interactions between the different instances to accomplish the end to end flows.

4.1 Work Request to Work Completion

Work request to work completion flow, also known as Breakdown Maintenance, starts

with a user reporting a problem that has been noticed on an asset by raising a Work

request. The Work Request is then routed through approval notifications. After approval,

the Maintenance planner converts the work request or groups multiple similar work

requests into a work order to enable resolution of the issue at hand. The Maintenance


planner identifies the nature of work required to be carried out and then defines the

operations (tasks), references the material and resources required to perform the work.

The Maintenance supervisor mobilizes the crew and materials required to perform the

work and initiates release of work order to begin the execution of work. The various

operations are then completed with material, resources and direct item procurement

transactions performed to complete the tasks.

Figure 3 : Work Request to Work Completion flow

After completion of work, the maintenance technician or supervisor completes the work

order.

As can be seen Figure-3 above, the entire end to end maintenance flow can be performed

in the eAM instance. Optionally, work orders can be closed in the ERP instance.

4.2 Preventive Maintenance to Work Execution

Preventive Maintenance of Assets entails maintaining assets on a pro-active basis by

defining complex runtime rules and scheduling rules to generate periodic PM work orders

which maintain the health of assets on an ongoing basis. Run time rules allow adoption of

both day interval rules and meter usage based rules. Scheduling rules in conjunction with

PM last service information determines the anchor dates and scheduling options for PM

work orders. In addition, cyclicality of PM schedules and suppression rules can be

defined to cater to different business needs.

* Work Request/ Service

Request

* Create Work order

* Release Work order

# Direct Item Purchase Requisition

# Purchase Requisition

* Purchase Order

# Create Released Work order

* Receipts

* Update Work order

(optional) * Material

Issues * Material Returns * Resource

transaction * Complete Work Order

# Material Issues # Material

Returns # Resource transaction

* Close Work Order

(optional)

# Complete Work Order

eAM Distributed

Instance

ERP

Instance

Synchronize transactions before Period Close within

ERP

Synchronize transactions after Work

Order

Completion

# Cost transactions * User initiated

# Background step

# Update Work order


The PM Engine will generate PM work orders which will be released by the Maintenance

supervisor for execution. Operation completion, material and resources can then be

reported by the technicians performing the preventive maintenance work. When the work

order is completed, a feed back loop is provided back to the PM Last service information

to keep the PM anchor dates updated.

Figure 4 : Preventive Maintenance to Work Execution flow

As can be seen Figure-4 above, the entire end to end maintenance flow including the

setups required for preventive maintenance can be entirely performed in the eAM

instance. As the ERP instance is responsible to merely cost the transactions, PM

definitions, meter readings and last service information need not be synchronized with

the ERP instance.

Work order close can be optionally performed in the ERP instance.

4.3 Asset Acquisition to Maintenance

Assets can be acquired by creating a purchase order in the ERP instance. The purchase

order can be created by entering the description and quantity of assets to be procured.

* PM Forecast Engine

* Create Work order

* Release Work order

# Direct Item Purchase

Requisition

# Purchase Requisition

* Purchase

Order

# Create Released

Work order

* Receipts

* Update Work order (optional)

* Material Issues

* Material Returns * Resource

transaction * Complete Work Order

# Material Issues # Material

Returns # Resource transaction

* Close Work Order (optional)

#Complete Work Order

eAM Distributed Instance

ERP Instance

Synchronize transactions before Period Close within

ERP

Synchronize transactions after Work

Order Completion

#Cost transactions

* PM Schedules Last service information update

# Update Work order

* User initiated # Background step


These assets can then be invoice matched in the Accounts payable module of ERP system

and the appropriate costs can be posted to Fixed Assets to create new mass addition lines.

Figure 5 : Asset Acquisition to Maintenance

eAM Assets can be defined in the eAM instance and synchronized to the ERP system.

The assets can then be associated with the corresponding Fixed Assets created through

AP-FA postings.

As can be seen in Figure-5 above, the only integration required for this flow is eAM

Asset Number synchronization. Post sync-up, eAM Assets in ERP instance can be

updated with their corresponding FA numbers.

If the ERP instance is R12 or above, this Fixed Asset integration flows can be modeled

through OAT Depreciable Items flow.

4.4 Siebel Call Center to Maintenance Execution (for Public Sector / Federal)

This flow entails integration of Siebel assets with Oracle eAM asset numbers in the

distributed eAM instance to enable Request to Resolution flow using these products.

Service Requests can be created using Siebel call center application which will be

transformed by the Integration layer into a Work request in EAM. The Maintenance

planner can then create a work order to resolve the issue reported.

Create Work Request

ERP Instance

eAM Distributed Instance

Synchronize Assets; Use

Asset Number interface to

load data into eAM system

Purchase Order to Procure Asset

Receive Asset Create Maintainable Asset

Link to Fixed Asset Create Maintainable Asset


Figure 6 : Siebel Call Center to Maintenance Execution

4.5 Manufacturing downtime integration for Capacity Planning

eAM integrates with manufacturing by linking equipment resources deployed for

production jobs with the Asset Numbers in eAM. Maintenance work orders created on

such assets which require shutdown to perform the work have to be communicated back

to Manufacturing planning system such as ASCP to reduce the available capacity of these

resources. eAM downtime flow verifies the work day pattern of the resources and

appropriately blocks the available capacity for the duration for which the work order has

been scheduled.

Figure 7 : Manufacturing Downtime Integration

ERP Instance

eAM Distributed Instance + Production

instance

Synchronize Assets

Create Asset Number

Create Asset Number

Link to Production

resource

Create Work order

ASCP

Downtime Concurrent

program

Capacity changes for

resource

ERP Instance

eAM Distributed

Instance

Synchronize Assets

Create Asset Number

Create Asset Number

Create

Work order

Synchronize Assets

Siebel Call Center

Create Asset Create Service Request

# Create Work Request

# Create

Work Order

Work Execution (refer Figure3)

# Work Execution Sync.

(refer Figure3)

# Background step


As can be seen for the Figure-7 above, manufacturing downtime integration flow can be

executed between eAM organization and production organizations of eAM Distributed

instance. The details captured in the capacity changes form for a resource will be read by

ASCP.

5. Implementation

5.1 Work Order Creation and Release

Work Order creation is recommended to be initiated in the distributed eAM instance.

The typical sequence of steps for Work Order Creation and Release are as below:

1. The work orders are created either from a Work request by the maintenance

planner or auto-created by the system through the preventive maintenance engine

either in Draft or Unreleased status. Draft status indicates the ongoing work

definition phase. Once work order is defined and but not yet ready to be executed,

user can change the status to „Unreleased‟.

2. Work Orders are then updated to Released status when the work order execution

is ready to begin. If Workflow approvals are setup, work order status changes to

„Released‟ after final approval by the users defined in the AME approval groups.

3. Work Order Release triggers the following actions along with :

a. Purchase Requisitions are created for Direct Items and OSP Items

b. Material Allocations are created through background move order creation.

4. Work Orders can be updated to other statuses or modifications can be made in the

work definitions.


Work Order Creation – Breakdown and Preventive Maintenance Flows

Inte

gra

tio

nIn

teg

rati

on

Ho

st

ER

PH

os

t E

RP

Dis

trib

ute

d e

AM

Dis

trib

ute

d e

AM

Create Work

Request

Approve Work

Request

Create Work

Order in Draft

Status

Create/Update

Work Order

Unreleased

status

PM Schedule/

Rules

definition

Generate PM

Work Orders

Create/Update

Work Order in

Released

status

Update Work

Order

requirements

Synchronize

Work Order

Header

Synchronize

Work Order

Operations

Synchronize

Work Order

Resource

Requirements

Synchronize

Work Order

Material

Requirements

Create/Update

Work Order

Operation

requirements

Create/Update

Work Order

Material

requirements

Create/Update

Work Order

Resource

requirements

Create Work

Order in

Released

Status

Figure 8 : Work Order Creation Flow

Distributed eAM System

Create Work Orders

The distributed eAM system creates and approves the work orders. Work orders can be

created either from Forms or from Self-service or loaded into the system using the WO

Business APIs.

Please refer to the Enterprise Asset Management User Guide for more information.

Transmit Work Orders

When a work order is either created in a Released status or updated to a Released status,

the distributed system transmits work order information to the host system.

Systems Integrator

Work orders may be transmitted to the host system, by invoking the WO Business

process APIs. This will ensure that data integrity is not compromised and all the

functional and technical validations are performed before the work orders are imported

into the host system. During implementation, systems integrator will need to write the

transformation to ensure that newly released work orders can be imported using the

Public WO Business Object API into the host system. The integration layer should also


perform any code conversions as well as mapping required to populate data into the host

system.

Systems Integrators will also be responsible to keep the information updated in the host

system as the work orders can be updated or cancelled in the distributed eAM system.

What Does Oracle Provide

Oracle provides pre-seeded Oracle Data Integrator (ODI) maps, which can be used to

transfer data between the distributed eAM instance and the host ERP instance. Following

are the artifacts that Oracle provides to facilitate the integration between the distributed

eAM system and the host ERP system.

a) Oracle will provide an ODI map for work orders, which can be used to transfer

work order and work order requirements (operations, materials, resources,

assigned employees and equipments) from the distributed eAM instance to host

ERP instance.

b) Web Service for work order and work order requirements. The web service can be

used for incremental sync up of work order between the two systems

c) Interface tables to support Oracle Business Object API for Work Orders

d) Business Object API for Work Order and work order requirements (operations,

materials, resources, assigned employees and equipments)

Host System

Import Work Orders

Work orders created in the distributed eAM system will be synchronized with the host

system by running the WO Business Object API. If no errors are found in the submission

process, the complete definition of the work orders including their requirements are

loaded into the base tables (WIP_ENTITIES, WIP_DISCRETE_JOBS,

WIP_OPERATION_RESOURCES, WIP_OPERATION_RESOURCE_USAGES,

WIP_OPERATION_RESOURCE_INSTANCES,

WIP_REQUIREMENT_OPERATIONS, and WIP_EAM_DIRECT_ITEMS). The work

orders in the host system will have the same name as those in the distributed eAM

system. If the WO API returns errors on the interface records, the errors are written out to

the EAM_WO_ERRORS. The error records in the interface tables must be updated

before the re-run of the ODI import program.

When syncing the records for material requirements of stocked inventory items and direct

items, the auto request flag should be turned off in the Host ERP. This will prevent

duplication of purchase requisition and material allocations in the Host ERP system.

When syncing up PM work orders to the Host ERP system, it is not required to sync-up

the PM schedule id and other related PM fields on the work order, as the Preventive

Maintenance function would be an executed only from the distributed eAM system.


Assumption for importing work orders into the host system is that all corresponding setup

(asset, departments, resources, materials) is previously synched between the host ERP

and the distributed eAM system.

5.2 Work Order Transactions

5.2.1 Resource Transactions

Resource transactions (also known as Charge Time) is recommended to be initiated in the

distributed eAM instance.

The typical steps/options for resource transaction are as follows:

1. A Work Order is first created with operations which in turn may have resource

requirements specified against it. The Work Order is then updated to Released

status.

2. User then enters Charge Time transactions against a resource with or without an

employee reference using the Mass Time entry page.

3. User can also enter an OTL timecard by specifying hours worked on each work

order for a given period. Time card is then approved and imported into eAM as

resource transactions.

If it is not the intention to cost the transactions in distributed eAM instance, the cost

manager may be turned off in this instance.


Charge Time

Users report time against Released work orders in the distributed eAM system. These

labor transactions need to be synched up to the host system in order to ensure that costs

are correctly generated against these transactions and maintenance expense is reported

correctly.

Please refer to the Enterprise Asset Management User Guide for more information on

how to perform the labor transaction.

Transmit Resource Transactions

Resource transactions created in the distributed eAM system should be transmitted to the

host system. It is recommended to sync up the labor transactions to the host system

periodically – daily or weekly for instance. Care should be taken to ensure that all labor

transactions reported against work orders are synched up to the host system before the

Accounting period in the host system is closed.

Systems Integrator

The integration layer will be responsible for loading resource transactions into the WIP

transactions interface table. During implementation, systems integrator will need to write


the transformation in the Integration layer, which will fetch the resource transaction from

the distributed eAM instance and populate the WIP transaction interface tables in the host

system. The integration layer should also perform any code conversions as well as

mapping required to populate data into the host system.






a) Oracle will provide an ODI map for resource transaction, which can be used to

transfer resource transaction from the distributed eAM instance to host ERP

instance.

b) Web Service for resource transaction. The web service can be used for

incremental sync up of resource transactions.

Host System

Import Resource Transactions

Once the WIP transaction interface table is loaded in the host system, transactions can be

imported by running the “Inventory Move Transactions Manager”. The Inventory Move

Transactions manager receives the data, derives and defaults any missing data, and

validates the data. If no errors are found in the submission process, the data in the WIP

transactions Interface tables is loaded into the WIP transactions base tables and

corresponding Work Order resource tables are updated.

If the Inventory Move Transactions manager finds errors in the interface tables, the

record identification number and the details of the error are written to the

WIP_COST_TRANSACTION_ERRORS table. These errors can be viewed in the

Pending Resource Transactions form along with the failure reason(s) for each row. The

error records in the interface tables must be updated before the re-run of the import

program.

Assumption for importing resource transactions into the host system is that the

corresponding work order is already imported into the host system in released status.

5.2.2 Direct Item procurement /OSP flow

Direct Item and OSP purchase requisitions will be initiated in the distributed eAM

instance.

The typical sequence of steps for Direct Item flow is as follows:

1. Work Order is created with material requirements for Non-Stock Direct Item

and/or Descriptive direct items.


2. Work Order is then updated to Released status. This triggers automatic creation of

Purchase Requisition for each direct item on the work order material requirements

for which the Auto Request flag is checked.

3. If Auto Request flag is not for a direct item material requirement record, then user

can invoke the „Request All‟ function to trigger the Purchase Requisition creation.

4. User can also update or request for additional quantity of the direct items than

what was originally specified.

5. Another possibility is to invoke i-procurement responsibility from the work order

and manually create a non-catalog request for descriptive direct item

requirements.

Direct Item Procurement flow

Dis

trib

ute

d e

AM

Dis

trib

ute

d e

AM

Facilitated through Standalone WMS

Inte

gra

tio

nIn

teg

rati

on

Ho

st

ER

PH

os

t E

RP

Create Work

Order with

Direct Item

material

requirements

Release Work

Order

Synchronize

Work Order

and Direct Item

requirements

Create Work

Order in

Released

Status

System

generated

Purchase

Requisition

Request

Direct Items

from Work

Order

Populate

Requisition

Interface table

of Host ERP

Run

Requisition

Import to

Create

Purchase

Requisition

Create

Purchase

Order

Receive

against Work

Order

Create

Purchase

Order

Run/ Schedule

Import

Standard

Purchase

Order program

Populate

Purchasing

Documents

Open interface

Populate

Receiving

Documents

Open Interface

Receipt

Synchronized

Work Order

reflects cost

due to direct

item

procurement

Figure 9 : Direct Item Procurement Flow


Generate Requisitions for Direct Item/ OSP Item

Direct Item requirements (Non-Stock direct items and Description based direct items) are

added to a work order manually by updating the requirements of the work order. Non-

Stock direct item requirements may also be included in the Asset BOM/ Maintenance

BOM. Purchasing Requisitions for these items are generated when the work order is

released in the distributed eAM system.


It is recommended to setup workflow approval for direct item and OSP purchase

requisitions in the distributed eAM instance and then sync up only the approved purchase

requisitions.

Transmit Purchasing Requisitions

Direct Item requisitions created in the distributed system should be transmitted to the host

system. It is recommended to sync up the purchase requisitions after the released work

order is synched with the host system.

Systems Integrator

The integration layer will be responsible for loading requisitions for direct items into the

Purchasing Requisitions interface table. During implementation, systems integrator will

need to write the transformation in the Integration layer to populate the requisitions

interface tables in the host system. To trace back the Purchase requisition number in the

eAM instance should a need arise, it is recommended to store the purchase requisition

number in the buyer notes field while populating the interface table in the host system.

The integration layer should also perform any code conversions as well as mapping

required to populate data into the host system.






a) Oracle will provide an ODI map for purchase requisitions, which can be used to

transfer purchase requisitions from the distributed eAM instance to host ERP

instance.

Host System

Import Purchasing Requisitions

Once the Purchasing Requisitions interface table is loaded in the host system, these can

be imported by running the “Import Requisitions” program. The Requisitions import

process receives the data, derives and defaults any missing data, and validates the data. If

no errors are found in the submission process, the data from the requisition Interface

tables is loaded into the Purchasing Requisitions base tables.

If the process finds errors in the interface tables, the record identification number and the

details of the error are retained in the Requisitions interface tables. These errors can be

viewed by running the “Requisition Import Exceptions Report”. The error records in the

interface tables must be updated before the re-run of the interface program.


Assumption for importing purchasing requisitions for direct items into the host system is

that the corresponding work order is already imported into the host system in a released

status.

Create Purchase Order

Once the Direct item purchase requisition is successfully imported into the Host system,

this will be converted into a Purchase Order by the Purchasing personnel, following

standard business procedures.

Transmit/Import Purchase Order to the Distributed eAM system

Once the Direct item Purchase order is approved, it will be transmitted and imported into

the distributed eAM system. Refer the approach documented in section 5.6 for further

details.

Once purchase orders are created in the distributed eAM instance, the work order details

page may show the original purchase requisition line and a new line for the purchase

order just created. The additional purchase requisition line can be ignored or manually

closed out.


Receipt of Direct items

The direct items are received in the distributed eAM system against the imported

Purchase Order number. The direct items are received into the shop floor, for the work

order against which they were requisitioned.

After the Direct Items are received into Shop Floor

Once the direct items are received into Shop Floor, these receipts are transmitted back to

the host system, so the receipt transaction can be accounted for in the host system. Refer

the approach documented in section 5.6 for further details.

5.2.3 One-step material issue and material return

Material transactions are recommended to be initiated in the distributed eAM instance.

The typical sequence of steps for material transactions – one step material issue and

material returns in the distributed eAM instance is as follows:

1. Work Order is created with stocked inventory material requirements referencing

operation sequence numbers. Work Order is then updated to Released status.

2. User then goes to the stores page and performs a one-step material issue of items

by specifying the quantity to be issued and the sub inventory details.


3. User can also issue items which are not on the work order material requirements.

4. Items that are unused in the maintenance work can be returned back to sub

inventory using the Material returns transaction by specifying the quantity and

sub inventory details.


Issue Material

Users issue or return material against Released work orders in the distributed eAM

system. These material transactions need to be synched up to the host system in order to

ensure that costs are correctly generated against these transactions and maintenance

expense is reported correctly.


how to perform the material transaction.

Transmit Material Transactions

Material transactions created in the distributed eAM system should be transmitted to the

host system. It is recommended to sync up the transactions to the host system periodically

– daily or weekly for instance. Care should be taken to ensure that all material

transactions reported against work orders are synched up to the host system before the

Accounting period in the host system is closed.

Systems Integrator

The integration layer will be responsible for loading material transactions into the

Inventory transactions interface table. During implementation, systems integrator will

need to write the transformation in the Integration layer, which will fetch the material

transaction from the distributed eAM instance and populate the Inventory transaction

interface tables in the host system. The integration layer should also perform any code

conversions as well as mapping required to populate data into the host system.






a) Oracle will provide an ODI map for material transactions, which can be used to

transfer material transactions from the distributed eAM instance to host ERP

instance.

Host System

Import Material Transactions


Once the Inventory transaction interface table is loaded in the host system, transactions

can be imported by running the “Inventory Move Transactions Manager”. The Inventory

Move Transactions manager receives the data, derives and defaults any missing data, and

validates the data. If no errors are found in the submission process, the data from the

Inventory transactions Interface tables is loaded into the Inventory transactions base

tables and corresponding Work Order material requirements tables are updated.

If the Inventory Move Transactions manager finds errors in the interface tables, the

record identification number and the details of the error are retained in the

MTL_TRANSACTION_INTERFACE table. These errors can be viewed in the Pending

Material Transactions form along with the failure reason(s) for each row. The error

records in the interface tables must be updated before the re-run of the import program.

Assumption for importing material transactions into the host system is that the

corresponding work order is already imported into the host system in released status.

5.2.4 Two-step material issue

Material transactions are recommended to be initiated in the distributed eAM instance.

The typical sequence of steps for two step material issue transaction in the distributed

eAM instance is as follows:

1. Work Order is created with stocked inventory material requirements referencing

operation sequence numbers. The „Enable Material Issue‟ flag in the work order

header is checked. The „Auto Request‟ flag can be optionally checked for each of

the material requirement lines.

2. Work Order is then updated to Released status. If „Auto Request‟ flag is checked,

this automatically triggers material allocations for the items which are available in

stock.

3. If „Auto Request‟ flag is unchecked, users can use „Request All‟ from the work

order details page to trigger manual allocations from a sub inventory.

4. User then goes to the stores page and performs a material issue of the allocated

items by specifying the quantity to be issued.

Material Allocations against work orders in the distributed eAM instance need not be

synchronized to the ERP instance, as there are no costing impacts. Once material gets

issued then this transaction should be synchronized to the ERP instance.

Please refer to section 5.2.3 for details on synchronizing material transactions.

5.3 Work Order Completion

5.3.1 Work Order Completion Transactions

Work order completion transaction is recommended to be initiated in the distributed eAM

instance.


The typical sequence of steps for work order completion in the distributed eAM instance

is as follows:

1. User queries a released work order and initiates the work order completion

transaction. The work order status can be changed to either complete or complete-

no charges.

2. User can also query a completed work order and update the status to complete –

no charges.

3. User can query an already completed work order and un-complete the same to

modify or add reporting details.

The recommended implementation to synchronize these steps is depicted in the table

below:

Sl.No. Action in Distributed eAM

Instance

Follow-up Action in Host ERP

Instance

1. Work Order Completion 1. Check if Released Work Order

exists; else synchronize all the

work order details.

2. If work order already exists,

verify if all the work order details/

lines have been synchronized,

else synchronize all the work

order details.

2. Verify if all transactions

performed in the distributed eAM

instance has been synchronized

into the host ERP instance, else

synchronize the transactions.

3. Complete the work order into

the appropriate completion status.

2. Work Order status update to

„Complete No Charges‟

1. Verify if Complete status work

order exists. If it does not,

perform above steps.

2. Update the status of work order

to Complete – No Charges

3. Work Order Un-Complete and

change status to Released.

1. Verify if Complete status work

order exists. If it does not,

perform steps as per 2 above.

2. Update status of work order to

Released.


Complete Work Order


When a work order is completed, the maintenance technicians will report completion

which will change the status of the work order to “Complete” or “Complete – No

charges” in the distributed instance.


how to complete work orders.

Transmit Work Order Completion Transactions

Work Order completion transactions should be transmitted from the distributed instance

to the host system. It is recommended to sync up the transactions to the host system

periodically – daily or weekly for instance.

Systems Integrator

Work orders completion transactions may be transmitted to the host system, by invoking

the WO Business process API. This will ensure that data integrity is not compromised

and all the functional and technical validations are performed before the work orders

completions are imported into the host system. During implementation, systems

integrator will need to write the transformation to ensure that newly completed work

orders can be imported using the Public WO Business Object API into the host system.

The integration layer should also perform any code conversions as well as mapping

required to populate data into the host system.

Figure 10 : Work Order Completion sync-up recommendations




Distributed eAM system

E-record snapshot (Not required)

Integration Layer

Failure Information (Not required)

Last service Information update to PM (Not required)

Replace Rebuild details (Not required)

Collection result entries (Not required)

Meter readings entries (Not required)

Completion Sub-inventory details (Conditionally mandatory)

WO shutdown dates (Conditionally mandatory)

WO actual completion dates (Mandatory)

Work Order Completion

Work Order Completion

E-Signature and E-record

(optional)

Last Service Info update to

PM

Host ERP system

Work Order Close

(optional)




a) Oracle will provide an ODI map for work order completion transactions, which

can be used to transfer completed work orders from the distributed eAM instance

to host ERP instance.

b) Web Service for work order completion transactions. The web service can be used

for incremental sync up of completed work orders between the two systems

Host System

Import Work Order Completion Transactions

Work orders completed in the distributed eAM system will be synchronized with the host

system by running the WO Business Object API.

The following details pertaining to the work order completion transaction need not be

synchronized into the host ERP system: Meter readings, Collection results entered, Last

service information update, replace rebuild details and e-record capture. This is shown in

the schematic above.

If no errors are found in the submission process, the status of the work will be updated in

the host system. If the WO API returns errors on the interface records, the errors are

written out to the EAM_WO_ERRORS table. The error records in the interface tables

must be updated before the re-run of the import program.

5.3.2 Work Order Close and Period Close

In the distributed eAM instance, the terminal status of a work order will be a completed

work order which can be modeled as a user defined status such as „Frozen‟. Since the

transactions in the distributed eAM instance are not costed, work order close and period

close need not be initiated here.

In the host ERP instance, user can optionally perform Work Order close transaction for

all the completed work orders. This can be done for each completed work order or in bulk

using the Mass close feature from the Maintenance Workbench.

Period close should be initiated in the host ERP instance. The following additional checks

should be enforced manually, prior to period close:

1. Verify that work orders in Released status in the distributed eAM system are

synchronized into the host ERP instance in Released status.

2. Verify that for open work orders, all the transactions posted in the distributed

eAM instance are synchronized into the host ERP instance and costed.

3. Verify that all completed work orders in host ERP instance are closed.(optional)


5.4 Asset Transactability Support

Prior to R12, Asset Groups were not transactable and were required to be defined in the

EAM enabled organization to execute the maintenance business functions.

However using an R12 eAM instance in distributed mode it would be possible to use

Asset transactability features, as R12 Asset Groups are allowed to be setup as

“Transactable”. Thus Assets can move between the organizations defined in this instance

in distributed eAM instance.

Figure 11 : Recommendations for Asset transactability scenarios

In R12, eAM also introduced the concept of a “family of maintenance organizations”.

With this concept, one maintenance organization could service multiple production

organizations (EM1 services M1 and M3, and EM2 services M2 and M4). The assets can

physically exist in any location, across any production organization, but for maintenance

purposes they are always visible to the eAM organization associated with its location and

work orders can be defined against these assets in the eAM organization. This is very

different from the behavior in 11i when an asset had to be defined in the maintenance

organization itself and linked to the production equipment of the production organization,

in order to execute the maintenance business processes for this asset.

EM1

M1

EM2

M2

Rebuild Numbers: Update the Material Transaction interface (MTL_TRANSACTIONS_ INTERFACE)

Asset Numbers: If R12 host ERP, then update the Material Transaction interface (MTL_TRANSACTIONS_ INTERFACE)

Asset Numbers: If 11i host ERP, then update the CURRENT_ORGANIZATION_ID of MSN table to destination eAM org

Scenario-1: Inter-org transfer

across family of maintenance orgs

EM1

Scenario-2: Sub inventory transfer

Main Store Sub Store

Rebuild Numbers: Update the Material Transaction interface (MTL_TRANSACTIONS_ INTERFACE)

Asset Numbers: If R12 host ERP, then update the Material Transaction interface (MTL_TRANSACTIONS_ INTERFACE)

Asset Numbers: If 11i host ERP, then no update required

EM1

M1

EM2

M2

Asset Numbers and Rebuild Numbers: If R12 host ERP, then update the Material Transaction interface (MTL_TRANSACTIONS_ INTERFACE)

Asset Numbers and Rebuild Numbers: If 11i host ERP, then no update required

Scenario-3: Inter-org transfer

within family of maintenance orgs

Integration Layer Distributed Instance


On the other hand, rebuildable items were always transactable in eAM and could move

from one organization to another just like any other stocked inventory item.

Using a distributed R12 eAM system, users will be able to take advantage of the “family

of maintenance organizations” concept and also transfer assets from one sub-inventory/

organization to another. The following section outlines the steps to be taken to keep an

asset that is “transactable” in the distributed eAM instance in sync with its counterpart

that is “non-transactable” in the host system.

Setup

The following setups need to synchronized between the distributed instance and host ERP

instance to enable transactability feature:

1. Asset Numbers with genealogy

2. Asset Groups: Should be transactable in all R12 instances.

3. Shipping Networks

4. Sub Inventories

5. Organization parameters

Move Assets

Assets and rebuilds can be moved in and out of organizations in the distributed system as

long as they are defined as “Transactable”.

Sync Transactable Assets

If the asset moves within a family of maintenance organizations, there is no need to sync

between the distributed and the host system.

If the asset moves out of the current maintenance organization into another, then the

location needs to be synched to the host system.

Systems Integrator

The integration layer will be responsible for syncing the location of the asset to host

system when the asset moves out of a maintenance organization boundary in the

distributed system. Since, assets cannot be defined as transactable in the host system; it is

not possible to interface any transactions on the asset between the host and the distributed

system. Therefore, during implementation, systems integrator will need to write the

transformation, to ensure that the asset group is assigned to the new maintenance

organization in the host system (there is a row against the new organization for the asset

group in the MTL_SYSTEM_ITEMS_B table) and that the

CURRENT_ORGANIZATION_ID of the asset in the table MTL_SERIAL_NUMBERS

is updated to the new organization.

For rebuildables with on hand balance, any location change should be synched back to

the host system through the corresponding background inventory transaction using the


materials transaction interface. Location changes can be on account of movement into

and out of sub inventory, sub inventory transfers and inter-org transfers.

Host System

No action.

5.5 Asset Genealogy

Asset Genealogy represents the hierarchy of assets. eAM Hierarchy is maintained

manually by users, however, material transactions against work orders, do update the

Asset Genealogy. The genealogy will initially be in sync between the host and the

distributed system; however, incremental manual and transactional changes may make

the genealogy in the host system out-dated. As the asset genealogy information may be

used to rollup costs and to perform other analysis based on hierarchy, users may want to

keep the genealogy information synchronized between the host and distributed system.

This may be done on an on-need basis or at regular intervals, by simply syncing up data

between the genealogy table – MTL_OBJECT_GENEALOGY – between the distributed

and the host systems.

5.6 On Hand synchronization for MRO items

In order to perform material transactions against work orders in distributed instance and

synchronize the same to host ERP instance, it is vital to maintain accurate on-hand

balances for MRO items in both the distributed eAM and host ERP instances. Purchasing

of MRO and Direct Items would be initiated in the ERP instance. In order to receive the

same in the distributed eAM instance, it is recommended to configure this instance as a

standalone WMS instance as well. (Please refer the whitepaper on Standalone Oracle

WMS solution on how to setup and configure the instance). These items are then issued

against eAM work orders. Other transactions such as material returns, miscellaneous

issue/ receipt transactions, adjustment transactions, etc can also be performed in the

distributed eAM Instance. All these transactions cumulatively determine the on hand

balance for MRO items in the distributed Instance.

A new view MTL_ONHAND_SYNC_UP_V will be provided that will show the details

about the on hand quantity of items like total on hand quantity, available quantity, lot and

serial details, snapshot date etc. Systems Integrators should create a custom program in

the integration layer to utilize the information from this view and push the on hand

balances to the host ERP system periodically. This custom program should create an

output in the form of a flat file or EDI or XML file depending on the best method that the

host system can make use of. The standalone solution will also provide a web service,

which the host system can call anytime to get a current snapshot of on hand quantities.

Host System

Create PO

The host system creates and approves the purchase orders. If the host system is an

Oracle ERP system, purchase orders can be created using forms or purchasing open


interface.

Please refer to “Oracle Purchasing Implementation Guide” for detailed information on

how to create new purchase orders.

Transmit PO

The host system transmits purchase order information to the distributed system. If the

host system is an Oracle ERP system, purchase orders can be transmitted using ASC X12

850/EDIFACT ORDERS or its XML equivalent. Any changes to purchase orders can be

transmitted using ASC X12 860 or its EDI or XML equivalent.

Purchasing flow for Stocked MRO Items

Inte

gra

tio

nIn

teg

rati

on

Ho

st

ER

PH

os

t E

RP

Dis

trib

ute

d in

sta

nc

eD

istr

ibu

ted

in

sta

nc

e

Create

Purchase

Requisition

Create

Purchase

Requisition

Populate the

PO_REQUISITI

ONS_INTERFA

CE table

Run/ Schedule

Requisition

Import

program

Create

Purchase

Order from PR

Run/ Schedule

Import

Standard

Purchase

Order program

Populate

Purchasing

Documents

Open interface

Create

Purchase

Order

Receive Item

to sub-

inventory

(RCV_TRANS

ACTIONS)

Pull records

using View

RCV_RECEIP

T_CONFIRMA

TION_V

Update

RECEIPT_CO

NFIRMATION_

FLAG to ‘Sent

Pending

Confirmation’

Populate

Receiving

Documents

Open Interface

Run/Schedule

Receiving

Transaction

Processor

Update

RECEIPT_CO

NFIRMATION_

FLAG to ‘Sent

Confirmed’

Receipts are

created and

ready for

Invoice

matching

Figure 12 : Purchasing Flow for Stocked MRO Items

Systems Integrator

The integration layer will be responsible for loading standard purchase orders into the

purchasing interface tables. During implementation, systems integrator will need to write

the transformation, for the transmitted PO from the host system, in the Integration layer

that will be responsible for populating the PO interface tables in the distributed system

using the Purchasing Document Open Interfaces. The integration layer should also

perform any code conversions as well as mapping required to populate the interface

tables in the distributed system.


Systems Integrators will also be responsible to keep the information updated in the

distributed system as the purchase orders are updated or cancelled in the host system.

They will have to call appropriate purchasing public APIs to orchestrate these changes.


Import PO

The Purchasing Documents Open Interface uses Application Program Interfaces (APIs)

to process the data in the Oracle Applications interface tables to ensure that it is valid

before importing it into Oracle Purchasing. New Purchase orders can be imported into

distributed warehouse (operating on standalone WMS solution) by processing

information in the purchasing documents open interface. They cannot be imported

through EDI or XML gateway.

Once the interface tables have been loaded, the “Import Standard Purchase Order

program” must be run in the distributed system to import the data from the interface

tables into Oracle Purchasing. The Purchasing Documents Open Interface program

receives the data, derive and default any missing data, and validate the data. If no errors

are found in the submission process, the data in the Purchasing Documents Open

Interface tables is loaded into the purchasing base tables to create the standard purchase

order. The purchase order will be created in approved status and should have the same

document number as in the host system.

If the Purchasing Documents Open Interface program finds errors in the interface tables,

the record identification number and the details of the error are written to the

PO_INTERFACE_ERRORS table. You can launch the Purchasing Interface Errors

Report in Purchasing to view the rows that were not imported by the Purchasing

Documents Open Interface along with the failure reason(s) for each row. The

“Purchasing Documents Open Interface” saves or errors out on a line-by-line basis. This

means that if an error is found in a document line, only that line is rolled back (not

submitted to Purchasing), and you can find the error in the PO_INTERFACE_ERRORS

table. The error records in the interface tables must be updated before the re-run of the

import program. Because the Purchasing Documents Open Interface saves or errors out

line by line, it can accept partial documents. Assumption for importing purchase orders

into the distributed system is that the required reference data such as item and supplier (or

vendor) must already be set up in the distributed system.

Please refer to “Oracle Purchasing Open Interfaces and APIs manual” for detailed

information on what fields to populate for importing new purchase orders.

Purchase Order Changes and Cancellations

If the host system has modified or cancelled the purchase order after it has been

downloaded in the distributed system, such changes can be transmitted to the distributed

system using the public APIs. All the PO change management supported currently in the

E-Business suite will be supported for the distributed system as well. The purchase order

change API allows you to update quantity, price or promise date on standard purchase


orders or cancel an existing purchase order. These APIs perform all the necessary

validation before updating the changes. The integration layer will be responsible for

transmitting and populating the change data or calling the appropriate APIs.


information on how to invoke purchase order change and cancellation APIs.

Import ASNs

Supplier will send the ASNs to the host system from where they can be imported into the

distributed system by a variety of methods – I-Supplier portal, EDI, or XML. One can

import ASNs into distributed system by passing the data in the form of ASC X12 856

EDI or its equivalent XML transaction. For the EDI/XML import to successfully go

through suppliers and supplier sites should be defined as trading partners and Oracle

ecommerce gateway should be appropriately set up. Once all the setups are complete, one

can run the Oracle e-commerce gateway import program to process the transactions.

If the required data is not provided in the transaction, the Oracle e-Commerce Gateway

import process fails the transaction. Then an exception message is displayed in the View

Staged Documents window. If the trading partner is valid and the transaction is enabled,

the import process proceeds to validate the transaction using the user-defined column

rules. If no process or column rule exceptions are detected, the Oracle e-Commerce

Gateway import program will write the transaction to the “Receiving Open Interface”

tables to be processed by the Receiving Open Interface API. The host system can also

write the ASN information in the “Receiving Open Interface” tables directly using the

public APIs. To successfully import ASNs into Oracle Purchasing, one must run the

“receiving transaction manager”.

Please refer to “E-commerce PO Implementation guide” for detail information on how to

import new ASNs.

Receipt of Material in the Warehouse

When material is physically received in the warehouse, it is received against the purchase

order (or the ASN) in the distributed warehouse.

Please refer to “Oracle Warehouse Management Users Guide” for detailed information

on how to perform receiving transactions.

After the Material is received in the Warehouse


Send Receipt Confirmation

Once material is received in the warehouse, distributed system will provide a mechanism

such that the host system can update its inventory system with the receipts, procurement

system for the purchase order (or ASN) against which receipt is made, and the accounts


payable for the value of the material received. The host system may also use receipt and

inspection information to monitor supplier compliance.

Historical information about the receipts made and results of quality inspection etc. are

stored in RCV_TRANSACTIONS table in Oracle Purchasing. Standalone solution will

provide a view „RCV_RECEIPT_CONFIRMATION_V‟ which will contain all the

detailed information about the receipt transactions. The view will contain information

like source document number (PO#), line number, shipment number, item, quantity

received, unit of measure etc. and will contain information about the following

transaction types – PO Receipt, Return to Vendor, Corrections, RMA Receipt, RMA

Return, Internal Requisition In transit Receipt, Inventory In transit Receipt.

Systems Integrators can write code in the integration layer to query this view directly or

create a web service to fetch all the new receipts for which confirmation has not been sent

to the host system. They can then convert this information into appropriate format to

populate the receiving interface tables of the host system. A new flag

„RECEIPT_CONFIRMATION_EXTRACTED‟ in the RCV_TRANSACTIONS table

will indicate the status if the receipt confirmation has been sent to the host system or not.

Once the confirmation is successfully sent to the host system, a new public API will

allow the users to update „RECEIPT_CONFIRMATION_EXTRACTED‟ flag in the RT

table. The RECEIPT_CONFIRMATION_EXTRACTED‟ flag can have the following

values-

NULL – Receipt confirmation not sent to the host system Sent Pending Confirmation –

Receipt confirmation sent to the host system but awaiting confirmation if host received it

successfully or not.

Sent Confirmed - Receipt confirmation successfully received by the host system.

Alternately the host system can also pull the information from the distributed system by

calling a web service. Based on the parameters passed, this web service will provide the

receipts for which confirmation has not been sent and update the

„RECEIPT_CONFIRMATION_EXTRACTED‟ flag to „Pending Confirmation‟. Once

the receipt confirmation is successfully received by the host system, it can call another

web service that will update the RECEIPT_CONFIRMATION_EXTRACTED‟ flag to

Confirmation Sent status.

Host System

Import Receipt Information

The host system should process the receipt information obtained from the distributed

system and update its inventory records, procurement system for the purchase order (or

ASN) against which receipt is made, and the accounts payable for the value of the

material received.

If the host system is an Oracle E-Business Suite, then the information can directly be

written into the “Receiving Documents Open Interface” of the host system. This means

that integration or B2B layer should load the receipt information in the receiving

interface tables. Once the receipts have been imported into “Receiving Documents Open


Interface”, one can run the “Receiving Transaction Processor” to process these

transactions and create receipts in the host system.


information on how to make use of “Receiving Documents Open Interface” to update

receipt information in the host system.

6. Integration artifacts from Oracle



are the ODI maps that Oracle provides to facilitate the integration between the distributed


a) ODI map for work order and work order requirements, which can be used to sync

up work order and work order requirements.

b) ODI map for work order completion. The ODI map will sync up completed work

order between the distributed eAM and host ERP instance.

c) ODI map for resource transactions. The ODI map will push resource transactions

from distributed eAM instance to the host ERP instance for Costing.

d) ODI map for material transactions. The ODI map will push material transactions

from distributed eAM instance to the host ERP instance for Costing.

e) ODI map for purchase requisitions. The ODI map will push purchase requisitions

from distributed eAM instance to host ERP instance so that the corporate

Purchasing can act upon the requisition and create Purchase Orders to procure the

parts.

Besides Oracle will provide a host of web services to facilitate the communication

between the distributed eAM instance and the host ERP instance.

a) Web service to create and update asset numbers and rebuildables. The web

service will help to sync up assets and asset updates between the distributed eAM

and host ERP instance

b) Web service to create and update asset groups and activities. The web service will

help to sync up asset groups and activities between the distributed eAM and host

ERP instance

c) Web service to create and update Maintenance BOM and Maintenance Routings.

The web service will help to sync up Maintenance BOM and Routings between

the distributed eAM and host ERP instance

d) Web service to sync up asset activity association. The web service will help to

sync up asset activity associations between the distributed eAM and host ERP

instance so that the asset activity associations can be used by an eAM work order

e) Web service to sync up work order and work order requirements. The web service

will help in incremental sync up of work order and work order requirements


f) Web service to sync up work order completions. The web service will help in

incremental sync up of completed work orders between the distributed eAM and

host ERP instance

g) Web service for resource transactions. The web service will help in incremental

sync up of resource transactions between the distributed eAM and host ERP

instance

7. Supported Features

The below table summarizes some of the key maintenance business flows/features and

their support in the distributed implementation mode.

Flow / Feature Supported Comments/ Prerequisites

Request to Resolution

- Work Request

- Work Order definition

- Material & resource

transactions

- Direct Item and OSP

Procurement

- Work Order Completion

Plan to Maintain

- Preventive Maintenance

setups

- PM Simulate and Run

- Work Order definition

- Material & resource

transactions

- Direct Item and OSP

Procurement

- Work Order Completion

Asset Transactability,

Maintenance family of organizations

Asset Groups are not transactable prior

to R12.

Failure Analysis

Maintenance Budgeting

Recommended to be done in host ERP

instance. Limited budgeting features

can be performed in the eAM instance

if Host ERP is in 11i10 or earlier.

Work Order Workflow

Wireless Maintenance User

Workbench

Multiple Activity PM

Crew Scheduling

Asset Operational status and Check-

in/out of assets


Support for 21CFR Part11

Capitalization of maintenance WO

costs Recommended to be done in host ERP

instance. Not supported if Host ERP is

in 11i10 or earlier.

Meter Hierarchy

Asset Secured Enterprise Search

Oracle reports in XML Publisher

Assets on Maps-Google Maps

Construction Estimating

Supply Source sub inventory

Single page Debrief and Express

Work Order

PM Enhancements – Generate Next

PM WO

Item Cross reference search

Graphical Display of Asset Network

Relationship

Work Order Billing

Recommended to be done in the Host

ERP instance

8. Other Considerations / Limitations

1. For organizations using costing method other than standard costing, it is desired

that the synchronization of receipts and issues of items from the distributed eAM

instance to the host ERP instance are done as frequently as possible to ensure the

correct sequencing of transactions. This is important in order to have the item

costs reflect the reality as closely as possible. Also, work order cost reports (for

both estimates and actuals) should be taken out from the host ERP instance, as the

item costs would be more accurate here.

2. Long standing maintenance work typically spans multiple months of duration.

When inventory periods are desired to be closed in the intervening duration, it is

recommended to synchronize all the transactions done till the period end into the

Host ERP instance. This will ensure the timely flow of accounting entries into

General Ledger and accounted in the corrected periods.

3. Most eAM functions are expected to be performed by the users using the UIs of

the distributed eAM system. Hence eAM responsibility definitions and their

access in the host ERP system should be appropriately setup during

implementation to prevent end users from accidentally using the wrong instance

for transactions.


Appendix

A) Deploying de-centralized purchasing and inventory

Customers can also optionally deploy purchasing and inventory along with eAM

in the distributed instance if their business processes allow for the same. This

deployment mode allows users to create direct item purchase requisitions from the

work order and use the same PR to convert into a PO and receive against the

same. This eliminates the scenario where the Purchasing and Maintenance

departments would have to work with different PR and PO numbering as would

have been the case when purchasing is driven by the ERP instance. In the case of

MRO items, this mode of deployment would make available the on-hand

availability of stocked items immediately on purchase receipt without having to

synchronize the receipts from the ERP instance.

Figure 13 : De-centralized purchasing deployment

It is recommended to synchronize the purchase order and purchase receipts (refer

schematic above) to the ERP instance, so that supplier invoice matching can be

done in the ERP instance. For MRO items, the purchase receipt sync-up is

required to establish the on-hand balance in the ERP instance for subsequent

background material issues to work order.

To implement de-centralized purchasing, users need to deploy appropriately the

Receipt & On-hand sync views, table changes as necessitated in the Standalone

WMS implementation, to sync-up purchase orders, receipts and on-hand balance.

Please refer to sections 5.2.2 and 5.6 for details of the same.

MRO Purchase

Requisition

Direct Item Purchase Requisition

Purchase Order

Release Work order

Receipt to Work Order

Receipt to Inventory

Purchase Order

Receipts Release

Work order Invoice Matching and Payments

Purchase Order

Issue to Work Order

Work Order costs are updated

EAM Distributed

Instance

ERP Instance

Sync-up PO using PDOI

Sync-up Receipts using RCV_RECEIPT_

CONFIRMATION_V


May 2009

Authors: Alexander Vaidhyan, Anju Gupta,

Contributing Authors: Amit Mondal, Ajay Kalavala

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 Corporation provides the software

that powers the Internet.

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 © 2002 Oracle Corporation

All rights reserved.