Standalone Oracle

eAM
An Oracle White Paper
May 2009

Standalone Oracle
eAM
CONTENTS

1.
2.
3.
4.

Introduction..............................................................................................................1
Deployment and Architecture..................................................................................2
Reference data synchronization...............................................................................3
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
4.6
Maintenance Integration with third party GIS systems.................................12
5. Implementation......................................................................................................12
5.1
Work Order Creation and Release.................................................................12
5.2
Work Order Transactions...............................................................................14
5.2.1
Resource Transactions...........................................................................14
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.........................................................................20
5.3
Work Order Completion................................................................................20
5.3.1
Work Order Completion Transactions...................................................20
5.3.2
Work Order Close and Period Close......................................................22
5.4
Asset Transactability Support........................................................................23
5.5
Asset Genealogy............................................................................................24
5.6
On Hand synchronization for MRO items.....................................................24
6. Supported Features................................................................................................29
7. Other Considerations / Limitations........................................................................31
FIGURES

Figure 1 : Business Drivers for Standalone 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 : eAM Integration with Third party GIS solution................................................12
Figure 9 : Work Order Creation Flow................................................................................13
Figure 10 : Direct Item Procurement Flow........................................................................17
Figure 11 : Purchasing Flow for Stocked MRO Items......................................................26

Standalone Oracle
eAM
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 standalone mode, for the following reasons :

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?

eAM for Non-EBS Host

How can I use eAM

to manage my
maintenance
functions with a nonEBS ERP host
system?

eAM instance
Standalone
eAM
decoupled from EBS
Easily integrate with
host system
Streamlined processes
& visibility

Ensure High Availability

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

Leverage Best-in-Class Features

How can I use the features in the latest eAM
release without upgrading the whole
application suite?
Figure 1 : Business Drivers for Standalone 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
Standalone Oracle EAM

Page 1

to implement their maintenance business functions first and integrate with their
legacy financial systems, before evaluating the bigger backbone ERP system.
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 on a 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 decouple 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
standalone eAM system in the current R12 release with an 11i EBS ERP 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
standalone 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 Setup Optimization document for detailed setups steps required to
implement core Oracle EBS setups for a Standalone EAM system.
Please refer to whitepaper Standalone Oracle WMS (January-2009) for implementation
recommendations to receive MRO items into standalone instance and keep inventories
synchronized in the two instances.

2. Deployment and Architecture

Standalone eAM Instance
The Standalone eAM instance will 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 standalone 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 standalone eAM system
will operate independent of the ERP instance. Since it is not the intention to cost the

Standalone Oracle EAM

Page

transactions in this standalone instance, it is sufficient to do the minimal GL setups

required for Organization creation.
Enterprise Analytics

Corporate ERP

FIN
(CST, FA & GL)

HR

CRM

Projects

ERP (EBS/ PSFT/ JDE/ SAP/ Legacy)

Siebel
Siebel CRM
CRM
(iSupport,
(iSupport,
Tele
Tele
Service)
Service)
Sync. assets, and SRs

Push Completion
Notifications

Push transactions to post

into GL

Meter Readings, Asset

Events

Maintenance
Organization

MDM
MDM
Assets
Assets
Suppliers
Suppliers

Requisition to PO and
Invoice Integration

Push Work Order

Transactions

Maintenance Operations
Op.
Op. System
System

Master Data
Synchronization

Items
Items

Standalone
Standalone
Logistics
Logistics
(Optional)
(Optional)

Asset
Asset Definition,
Definition, Tracking,
Tracking, Performance,
Performance, History
History
Work
Work
Request
Request
Requisition
Requisition

Work
Work
Scheduling
Scheduling
Labor
Labor

Work
Work
Execution
Execution
Inventory
Inventory for
for
MRO
MRO Parts
Parts

Asset
Asset
Availability
Availability
Quality,
Quality,
Meters
Meters

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 instances transaction and cost manager will
process the transactions, cost it and post the accounting entries into GL.

Standalone Oracle EAM

Page

3. Reference data synchronization

As most of the maintenance business functions will be performed in the standalone eAM
instance, it is recommended to do all the 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 in 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 Standalone eAM instance and the ERP instance.
Note: mark signifies that the setup step has to be done in that
instance
Functional Area

Master Entity

Source of Truth
ERP
Stand
Only
alone
eAM
Only

Actual Data
Synch.
between
instances:
1-Mandatory
2-Optional

Initial Data
load options:
1 Manual
2 API
3 Interfaces
4 WebADI

2
2

1
1

1
1

1
1

Both

Common
Accounting Key Flexfield
-Value Sets
-Accounting Key Flexfield
Structure
-Accounting Key Flexfield
Segments
-Chart of Account Segment
Values
Cross Validation Rules
Currencies
Accounting Calendars
-Accounting Period Types
-Periods to Accounting
Calendar
Accounting Structure
-Locations
-Legal Entity Profile
Options
-Legal Entity
-Primary Ledger

1
1
1
1

1
1

HRMS
Organization Type Lookup
Codes
HRMS Key Flexfield Value
Sets.
HR Key Flexfields (6)
-Grade Flexfield.
-Job Flexfield
-Position Flexfield

Standalone Oracle EAM

1
1
1

Page

Functional Area

Master Entity

Source of Truth
ERP
Stand
Only
alone
eAM
Only

Both

-Competence Flexfield
-Cost Allocation Flexfield
-People Group Flexfield
Employee
Locations
HR Business Group
Organization
Organization Calendar
Organizations- GRE LE,
Operating Units, Inventory
Organizations
Setup Default Operating
Unit for your Site
Multi-Org Administrative
Processes
-Concurrent ManagersDefine, Administer
-Submit Workflow
processes
-Gather Schema Statistics
-Replicate Seed data for
operating unit

Actual Data
Synch.
between
instances:
1-Mandatory
2-Optional

Initial Data
load options:
1 Manual
2 API
3 Interfaces
14 WebADI

1
1
1,2
1
1

1
1

1
1

Attachments
Descriptive Flex
Responsibilities
User
Assign Responsibilities to
User

1
1
1
1
1

Inventory Key Flexfield

Value Sets
Inventory Key flexfields
-Item Flexfield
-Item Category Flexfield
-Item Catalog Group
Flexfield
-Stock Locators Flexfield
-Account Alias Key
Flexfield
Organization Receiving
Options
Unit of Measure
-UOM Classes
-UOMs

FND

Inventory

1
2

1
1
1
1

Standalone Oracle EAM

1
1
1

1
1

1
1

Page

Functional Area

Master Entity

-UOM Conversions
Subinventories
Stock Locators
Item Attribute Control
Item Categories
Item Category Set
Item Default Category Set
Item Statuses
Item Types
Items - MRO Stocked
Items, Non-Stock Direct
Items, OSP Items
Shipping Network
Account Aliases
Transaction Source Types
Transaction types
Transaction Reasons
Purchasing Options
Accounting Periods
Inventory Profile Options
Item Relationships

Source of Truth
ERP
Stand
Only
alone
eAM
Only

Both

Actual Data
Synch.
between
instances:
1-Mandatory
2-Optional
1

Initial Data
load options:
1 Manual
2 API
3 Interfaces
14 WebADI

1
1

1, 4
1
1
1,2,3
1,2,3
1,2,3
1
1
1,3,4

2
2

Bills of Materials
Parameters
Workday Calendar
Resources
Department Classes
Departments
Standard Operations
Bill of Materials Profile
Options

1
1
1
2
2

1
1
1
1
1
1

Work in Process Parameters

WIP Accounting Classes

1
1

1
1

2
2
2
2
2

1
1,2,3
1
1
1

1
1

1
1
1
1
1
1
1
1
1

Bills of
Material

Work in
Process

Quality
Collection Elements
Collection Plans
Specifications
Collection Element Types
User Groups and Privileges

Standalone Oracle EAM

Page

Functional Area

Master Entity

Source of Truth
ERP
Stand
Only
alone
eAM
Only

Actual Data
Synch.
between
instances:
1-Mandatory
2-Optional

Initial Data
load options:
1 Manual
2 API
3 Interfaces
4 WebADI

1
1
2
2
1
1
1
1

1
1
1
1
1,3,4
1,3
1,3
1,3,4

2
1

1
1,3

1
2
2
2
2
2
2
1
2
1
2
2
2

1
1,3
1,3
1
1
1
1
1
1
1
1
1
1

Both

EAM
EAM Parameters
IB Parameters
Define EAM Look-up codes
Areas
Activity Items
Maintenance BOM
Maintenance Routing
Asset Groups and Rebuild
Items
Attribute Assignments
Asset Numbers, Rebuild
Numbers, Asset Routes
Activity Association
Meter Definition
Meter Association
Set Name
Suppression
Last Service Info
Schedule Definition
Work Order Statuses
Department Approvers
Category Associations
Define Forecast
Failure Codes
Failure Set

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

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

Standalone Oracle EAM

Page

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.

Work
Request/
Service
Request

Create
Work order

eAM Standalone
Instance

Release
Work order

Update
Work order

#Direct Item Purchase

Requisition
Receipts

Material
Issues

Material
Returns

Synchronize
transactions
before Period
Close within
ERP

Resource
transaction

Complete
Work Order

Synchronize
transactions
after Work
Order
Completion

#Material
Issues

#Create Released #Purchase

Requisition
Work order

ERP
Instance
# background step

Purchase
Order

#Material
Returns

#Cost
transactions

#Resource
transaction

#Complete
Work Order

Close
Work Order
(optional)

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 Standalone 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.
Standalone Oracle EAM

Page

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.

Last service information update

PM
Schedules

PM
Forecast
Engine

Create
Work order

EAM
Standalone
Instance

Release
Work order

Material
Issues

Update
Work order

#Direct Item Purchase

Requisition
Receipt
s

Synchronize
transactions
before Period
Close within
ERP

Material
Returns

Resource
transaction

Complete
Work Order

Synchronize
transactions
after Work
Order
Completion

#Material
Issues

#Create Released #Purchase

Requisition
Work order

ERP
Instance
# background step

Purchase
Order

#Cost
transactions

#Material
Returns

#Resource
transaction

#Complete
Work Order

Close
Work Order
(optional)

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 performed in the Standalone 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.

Standalone Oracle EAM

Page

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.

EAM
Standalone
Instance

Receive Asset

Create Maintainable Asset

Synchronize
Assets; Use
Asset Number
interface to
load data into
eAM system

Create Work Request

ERP
Instance

Purchase Order to
Procure Asset

Create Maintainable Asset

Link to Fixed Asset

Figure 5 : Asset Acquisition to Maintenance

eAM Assets can be defined in the Standalone 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 synch-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
standalone 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.

Standalone Oracle EAM

Page

Create Asset

Siebel Call
Center

Create Service
Request

Synchronize
Assets

eAM
Standalone
Instance

Work Execution (refer

Figure3)

Create Asset Number

#Create Work
Request

Create
Work order

Synchronize
Assets

ERP
Instance

#Work Execution Synch.

(refer Figure3)
#Create
Work Order

Create Asset Number

# background step

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.

Standalone Oracle EAM

Page

eAM
Standalone
Link to Production
Instance + Create Asset Number
resource
Production
instance

Create
Work order

Downtime
Concurrent
program

Capacity
changes for
resource

Synchronize
Assets

ERP
Instance

ASCP
Create Asset Number

Figure 7 : Manufacturing Downtime Integration

As can be seen for the Figure-7 above, manufacturing downtime integration flow can be
executed between eAM organization and production organizations of eAM Standalone
instance. The details captured in the capacity changes form for a resource will be read by
ASCP.

4.6

Maintenance Integration with third party GIS systems

Customers using an existing third party GIS system require a standalone maintenance
execution system such as Oracle eAM to perform downstream work execution business
functions. The suggested integration method is shown below.

Standalone Oracle EAM

Page

Geo-coder

Third party
GIS solution

Asset/
Equipment

Asset Geo-code
Information

GIS Analytics
rd

3 party Map
Viewer

Synchronize
Assets

eAM
Standalone
Instance

#Create Work
Request

(optional)

Create Asset Number

Asset Geo-code
Information

Custom Map
viewer
within eAM
(optional)

#Create
Work order

Work Execution

# background step

Figure 8 : eAM Integration with Third party GIS solution

5. Implementation
5.1

Work Order Creation and Release

Work Order creation should be initiated in the eAM Standalone system.

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.

Standalone Oracle EAM

Page

Figure 9 : Work Order Creation Flow

Standalone System
Create Work Orders
The standalone 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 host 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 never 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

Standalone Oracle EAM

Page

perform any code conversions as well as mapping required to populate data into the
standalone 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 standalone system.
Host System
Import Work Orders
Work orders created in the standalone 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, WIP_EAM_DIRECT_ITEMS). The work
orders in the host system will have the same name as those in the standalone system.
If the WO API finds errors in the interface tables, the errors are written out to the WO log
file. The error records in the interface tables must be updated before the re-run of the
import program.
Assumption for importing work orders into the host system is that all corresponding setup
(asset, departments, resources, materials) is previously synched between the host and the
standalone system.

5.2

Work Order Transactions

5.2.1 Resource Transactions

The typical steps/options for resource transaction (a.k.a. Charge Time) flow in the
Standalone eAM instance is 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.
Since it is not the intention to cost the transaction in Standalone eAM instance, the cost
manager can be turned off in this instance.
Standalone System

Standalone Oracle EAM

Page

Charge Time
Users report time against Released work orders in the standalone 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 standalone system should be transmitted to the host
system. It is recommended to synch 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, for the resource transaction from the standalone system, in the
Integration layer that will be responsible for populating 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 standalone system.
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.

Standalone Oracle EAM

Page

5.2.2 Direct Item procurement /OSP flow

The typical sequence of steps for Direct Item flow in the Standalone eAM instance 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.

Figure 10 : Direct Item Procurement Flow

Standalone System
Generate Requisitions for Direct Item/ OSP Item

Standalone Oracle EAM

Page

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. NonStock 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 standalone system.
Transmit Purchasing Requisitions
Direct Item requisitions created in the standalone system should be transmitted to the host
system. It is recommended to synch up the 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, for the requisition from the standalone system in the
Integration layer that will be responsible for populating the Requisitions 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 standalone system.
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.

Standalone Oracle EAM

Page

Transmit Purchase Order to the Standalone system, Import Purchase Order into the
Standalone system
Once the Direct item Purchase order is approved, it will be transmitted and imported into
the Standalone system. Refer the approach documented in section 4.2 for further details.
Standalone System
Receipt of Direct items
The direct items are received in the Standalone 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 4.2 for further details.

5.2.3 One-step material issue and material return

The typical sequence of steps for material transactions one step material issue and
material returns in the Standalone 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.
Standalone System
Issue Material
Users issue or return material against Released work orders in the standalone 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.
Please refer to the Enterprise Asset Management User Guide for more information on
how to perform the material transaction.
Transmit Material Transactions

Standalone Oracle EAM

Page

Material transactions created in the standalone system should be transmitted to the host
system. It is recommended to synch 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, for the material transaction from the standalone system,
in the Integration layer that will be responsible for populating 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 standalone system.
Host System
Import Resource 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

The typical sequence of steps for material transactions two step material issue transaction
in the Standalone 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.

Standalone Oracle EAM

Page

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 Standalone 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 4.6 for details on synchronizing material transactions.

5.3

Work Order Completion

5.3.1 Work Order Completion Transactions

The typical sequence of steps for work order completion in the Standalone 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 completeno 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 Standalone Instance

1.

Work Order Completion

2.

Work Order status update to

Complete No Charges

Standalone Oracle EAM

Follow-up Action in Host ERP

Instance
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 standalone EAM
instance has been synchronized
into the Host ERP instance, else
synchronize the transactions.
3. Complete the work order into
the appropriate completion status.
1. Verify if Complete status work
order exists. If it does not,
perform above steps.

Page

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.

Standalone System
Complete Work Order
When a work order is completed, the maintenance technicians will change the status of
the work order to Complete in the standalone instance.
Please refer to the Enterprise Asset Management User Guide for more information on
how to complete work orders.
Transmit Work Order Completion Transactions
Work Order completion transactions should be transmitted from the standalone instance
to the host system. It is recommended to synch 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 never 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 standalone system.
Host System
Import Work Order Completion Transactions
Work orders completed in the standalone 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 status of the work will be updated in the host system.
If the WO API finds errors in the interface tables, the errors are written out to the WO log
file. The error records in the interface tables must be updated before the re-run of the
import program.

Standalone Oracle EAM

Page

5.3.2 Work Order Close and Period Close

In the Standalone 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 Standalone instance are not costed, work order close and period close
need not be initiated here.
In the 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 standalone system are
synchronized into the Host ERP instance in Released status.
2. Verify that for open work orders, all the transactions posted in the standalone
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 standalone 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 standalone eAM instance.

EAM1
M1

EAM2
M2

M3

M4

Asset A could move to M2 or

M3 from M1

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

With this concept, one maintenance organization could service multiple production
organizations (EAM1 services M1 and M2, and EAM2 services M3 and M4). The assets
can physically exist in any location, across any production organization, but for

Standalone Oracle EAM

Page

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 R11i when an asset had to be defined in the
maintenance organization for it to be visible to that organization (it had to be physically
located in the maintenance organization or be linked to the production asset via
equipments).
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 standalone R12 eAM system, users will be able to take advantage of this family
of maintenance organizations concept and also have the assets be transactable. The
following section outlines the steps to take to keep an asset that is transactable in the
standalone instance in synch with its counterpart that is non-transactable in the host
system.
Move Assets
Assets and rebuilds can be moved in and out of organizations in the standalone system as
long as they are defined as Transactable.
Synch Transactable Assets
If the asset moves within a family of maintenance organizations, there is no need to synch
between the standalone 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 synching the location of the asset to host
system when the asset moves out of a maintenance organization boundary in the
standalone system. Since, the asset 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
standalone 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.
Host System

Standalone Oracle EAM

Page

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 synch between the host and the
standalone 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 standalone system.
This may be done on an on-need basis or at regular intervals, by simply synching up data
between the genealogy table MTL_OBJECT_GENEALOGY between the standalone
and the host systems.

5.6

On Hand synchronization for MRO items

In order to perform material transactions against work orders in standalone instance and
synchronize the same to Host ERP instance, it is vital to maintain accurate on-hand
balances for MRO items in both the standalone and host instances. Purchasing of MRO
and Direct Items would be initiated in the ERP instance. In order to receive the same in
the standalone 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
standalone eAM Instance. All these transactions cumulatively determine the on hand
balance for MRO items in the Standalone 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 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.

Standalone Oracle EAM

Page

Transmit PO
The host system transmits purchase order information to the standalone 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.

Figure 11 : 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 standalone 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 standalone system.
Systems Integrators will also be responsible to keep the information updated in the
standalone 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.
Standalone System

Standalone Oracle EAM

Page

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 Standalone 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
standalone system is that the required reference data such as item and supplier (or
vendor) must already be set up in the standalone 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 standalone system, such changes can be transmitted to the standalone
system using the public APIs. All the PO change management supported currently in the
E-Business suite will be supported for the standalone 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.
Please refer to Oracle Purchasing Open Interfaces and APIs manual for detailed
information on how to invoke purchase order change and cancellation APIs.

Standalone Oracle EAM

Page

Import ASNs
Supplier will send the ASNs to the host system from where they can be imported into the
Standalone System by a variety of methods I-Supplier portal, EDI, or XML. One can
import ASNs into Oracle Standalone 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
Standalone System
Send Receipt Confirmation
Once material is received in the warehouse, standalone 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

Standalone Oracle EAM

Page

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
valuesNULL 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 standalone 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 standalone
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.
Please refer to Oracle Purchasing Open Interfaces and APIs manual for detailed
information on how to make use of Receiving Documents Open Interface to update
receipt information in the host system.

Standalone Oracle EAM

Page

6.

Supported Features

The below tables summarizes some of the key maintenance business flows/features and
their support in standalone 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 Groups are not transactable prior

Asset Transactability,
to R12.
Maintenance family of organizations

Failure Analysis

Maintenance Budgeting

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

Recommended to be done in host ERP
Capitalization of maintenance WO
instance. Not supported if Host ERP is

costs
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

Standalone Oracle EAM

Page

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

7.

Recommended to be done in the Host

ERP instance

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

Standalone Oracle EAM

Page

Standalone eAM
March 2009
Authors: Alexander Vaidhyan, Anju Gupta

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.