Professional Documents
Culture Documents
Distributed Oracle EAM Whitepaper
Distributed Oracle EAM Whitepaper
However, in recent times many customers and prospects are evaluating implementation
of eAM functions in a distributed mode, for the following reasons :
Distributed eAM
eAM for Non-EBS Host eAM instance
How can I use eAM decoupled from EBS Ensure High Availability
to manage my
maintenance
Easily integrate with
host system
• In Asset Intensive
industries, how to ensure
functions with a non-
that a mission critical
EBS ERP host Streamlined processes
& visibility application like EAM is
system?
available 24*7?
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.
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.
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.
Note: “ ” mark signifies that the setup step has to be done in that instance
Function- Master Entity Instance to setup data Data Sync. Data Entry/
al Area ERP Distri Both between Sync. options:
Only buted instances: 1 – Manual
eAM 1-Mandatory 2 – API
Only 2-Optional 3 – Interfaces
4 – WebADI
5 – Web services
Common
Accounting Key Flexfield
-Value Sets 2 1
-Accounting Key Flexfield 2 1
Structure
-Accounting Key Flexfield 2 1
Segments
-Chart of Account Segment 2 1
Values
Cross Validation Rules 1
Currencies 1 1
Accounting Calendars
-Accounting Period Types 1
-Periods to Accounting 1 1
Calendar
Accounting Structure
-Locations 1
-Legal Entity Profile 1
Options
-Legal Entity 1 1
-Primary Ledger 1 1
HRMS
Organization Type Lookup 1
Codes
HRMS Key Flexfield Value 1
Sets.
HR Key Flexfields (6)
-Grade Flexfield. 1
-Job Flexfield 1
-Position Flexfield 1
-Competence Flexfield 1
FND
Attachments 1
Descriptive Flex 1
Responsibilities 1
User 1
Assign Responsibilities to 1
User
Inventory
Inventory Key Flexfield 1 1
Value Sets
Inventory Key flexfields 1
-Item Flexfield 1 1
-Item Category Flexfield 2 1
-Item Catalog Group 1
Flexfield
-Stock Locators Flexfield 1 1
-Account Alias Key 1
Flexfield
Organization Receiving 1
Options
Unit of Measure
-UOM Classes 1 1
-UOMs 1 1
-UOM Conversions 1 1
Bills of
Material
Bills of Materials 1 1
Parameters
Workday Calendar 1 1
Resources 1 1
Department Classes 1
Departments 1 1
Standard Operations 2 1
Bill of Materials Profile 2 1
Options
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
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.
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
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.
* Update * Complete
* Work * Create * Release * Material * Material * Resource
Work order Work Order
Request/ Work order Work order Issues Returns transaction
(optional)
Service
Request
Synchronize Synchronize
transactions transactions
eAM Distributed # Direct Item * Receipts before Period after Work
Purchase Requisition Close within Order
Instance
ERP Completion
ERP
Instance
* Purchase
Order * Close
Work Order
# Cost
* User initiated (optional)
transactions
# Background step
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.
* PM Schedules
* Update * Complete
* PM * Create * Release * Material * Material * Resource
Work order Work Order
Forecast Work order Work order Issues Returns transaction
Engine (optional)
Synchronize Synchronize
transactions transactions
before Period after Work
eAM Distributed # Direct Item
Purchase * Receipts Close within Order
Instance ERP
Requisition Completion
ERP
Instance
# Update # Material # Material # Resource #Complete
# Create # Purchase
Work order Issues transaction Work Order
Released Requisition Returns
Work order
*
Purchase * Close
* User initiated Work Order
Order #Cost
# Background step transactions (optional)
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.
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.
ERP
Instance
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.
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.
Synchronize
Assets
# Create
Create Asset Number Work Order
# Background step
eAM
Distributed Create Asset Number Link to Production Create Capacity
Downtime
Instance + resource Work order changes for
Concurrent
resource
Production program
instance
Synchronize
Assets
ERP
Instance
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.
Create Work
Create Work Approve Work
Order in Draft
Request Request
Status
eAM
DistributedeAM
Create/Update Create/Update
Update Work
Work Order Work Order in
Order
Unreleased Released
Distributed
requirements
status status
PM Schedule/
Generate PM
Rules
Work Orders
definition
Integration
Integration
Synchronize Synchronize
Synchronize Synchronize
Work Order Work Order
Work Order Work Order
Material Resource
Header Operations
Requirements Requirements
ERP
HostERP
Please refer to the Enterprise Asset Management User Guide for more information.
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
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.
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
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.
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.
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
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 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
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.
Request
Direct Items
from Work
Order
Facilitated through Standalone WMS
eAM
DistributedeAM
Create Work
Distributed
System
Order with Create Receive
Release Work generated
Direct Item Purchase against Work
Order Purchase
material Order Order
Requisition
requirements
Run/ Schedule
Import
Standard
Purchase
Order program
Integration
Integration
Run
HostERP
Create Synchronized
Status Order item
Purchase procurement
Requisition
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.
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 purchase requisitions, which can be used to
transfer purchase requisitions from the distributed eAM instance to host ERP
instance.
Host System
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.
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.
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.
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.
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.
Please refer to the Enterprise Asset Management User Guide for more information on
how to perform the material transaction.
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.
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 material transactions, which can be used to
transfer material transactions from the distributed eAM instance to host ERP
instance.
Host System
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.
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.
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.
Failure Information
(Not required)
E-record snapshot
(Not required)
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
Host System
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.
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)
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.
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”.
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
Host System
No action.
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
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.
Create
Purchase
Order
Create Receive Item
Purchase to sub-
Distributed
Requisition inventory
Run/ Schedule (RCV_TRANS
Import ACTIONS)
Standard
Purchase
Order program
Pull records
using View
RCV_RECEIP
Integration
T_CONFIRMA
PO_REQUISITI Purchasing
TION_V
ONS_INTERFA Documents
CE table Open interface Update
Populate RECEIPT_CO Update
Receiving NFIRMATION_ RECEIPT_CO
Documents FLAG to ‘Sent NFIRMATION_
Open Interface Pending FLAG to ‘Sent
Confirmation’ Confirmed’
Run/ Schedule
Requisition
Import
ERP
HostERP
program
Host
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.
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.
Please refer to “Oracle Purchasing Open Interfaces and APIs manual” for detailed
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 “Oracle Warehouse Management Users Guide” for detailed information
on how to perform receiving transactions.
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
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.
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 ODI maps that Oracle provides to facilitate the integration between the distributed
eAM system and the host ERP system.
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
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, Asset Groups are not transactable prior
Maintenance family of organizations 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
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.
MRO Receipt to
Purchase Purchase Issue to Work
Inventory Order
Requisition Order
Sync-up
Sync-
Receipts using
ERP up PO
RCV_RECEIPT_
Instance using
CONFIRMATION
PDOI
_V
Release
Work order Purchase Receipts Invoice Matching and
Order Payments
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