You are on page 1of 21

Introduction

Electronic Records and Electronic Signatures or commonly termed ERES has come into existence
because of the stringent regulation needs set by the Food and Drug Administration department of
USA. FDA attempts to protect the public health by regulating certain industries viz. Food &
Drug, Medical Devices, Biologics and Radiation Emitting Products like Cell phones or
Microwave Ovens. One of the requirements set by the FDA for the industries was to comply with
the FDAs 21 CFR Part 11 regulations.
FDA - 21 CFR Part 11 Regulations, originally introduced in 1997 describe the technical aspects
of computer or software systems that are used by the manufacturers, to assure that these
computerized records are safe, secure and as accurate as a paper based system. Administrative
controls like backup, security, password controls are carefully regulated. Organizations that are
required to or wish to maintain electronic documents must also have systems that support the
ability to electronically sign those documents to ensure that the appropriate personnel have
reviewed and approved them. Audit Trails are also demanded.
The two major requirements are:
Electronic Records 21CFR Part 11 describes the requirements for companies wanting to move
from paper based record keeping to electronic record keeping. The FDAs Quality Systems
Requirements describes where it is appropriate to keep electronic records and to capture
electronic signatures.
Electronic Signatures -- legally binding signatures equivalent to signatures on paper.
Organizations, which are required to or wish to maintain fully electronic documents, must also
have systems that support the ability to attach electronic versions of signatures to those
documents to ensure that the appropriate personnel have reviewed and approved them. Since
electronic signatures are a legal and binding equivalent to hand written signatures, users will want
to review the data theyre responsible for signing.

Existing systems
Oracle Process Manufacturing Applications can claim Part 11 compliance with 11.5.9, while
Oracle Discrete Manufacturing Applications cannot. With Release 11.5.10 now discrete
manufacturing is also capable of the compliance. The different modules, which are capable of
compliance with this release, are
Items/ Bill of Material (BOM) Engineering or Product Lifecycle Management (PLM)
Quality
WIP
Inventory
Purchasing & Receiving
Shipping

Scope of the document


In this document we will mainly focus on the Inventory side of ERES
We will touch upon the Framework components, the different setups across modules, which are
needed for the entire eRecord and eSignature process to get executed. We will explore the two
modes by which the eSignatures are captured (Online and Deferred Modes)
We will discuss the Setup and Usage of this by means of two examples
Miscellaneous Receipt for -- for Online capture and

Engineering Approval Process for Deferred Mode Capture.


We will not cover in this document, the setups necessary for functions viz. Purchasing/Receiving,
Shipping, WIP or Quality. (However the same concept can be extended for these functions also)

Understanding the Framework for ERES


The challenge that a provider of 21 CFR Part 11 compliant software built on a relational database
must address is How can I make the user of my system feel confident about entering their legally
binding electronic signature, when the information is not stored or displayed in a single, tidy
bundle?
The approach Oracle has taken in addressing this challenge is to assemble the relevant data from
the various screens and underlying database tables into an electronic record or eRecord, and
present it for the user in a unified, paper-like document format which can be scrolled through onscreen, or printed for review during the electronic signing process. The same representation that
the record reviewer/signer views on their screen are what are securely saved in the database in the
exact state it was viewed and signed. This What You See Is What You Get, or WYSISYG approach
ensures that the reviewer/signer(s) see exactly what they are going to sign, and sign what they
see, just as they currently do on paper.
Technical aspects of the framework

The process of reviewing an Electronic Record and signing the same, actually involves a
seamless integration of multiple modules or components. Each of these components is
responsible for specific function, which is described here.
Workflow Business Event System
Workflow Business Event system is used to define an eSignature event and associate
synchronous eSignature subscription to the event. These Business events are also termed
as Business Processes or Transaction Types. For instance doing a Miscellaneous
Transaction in the application can be termed as a Business Event.

XML Gateway
When a specific eRecord gets generated in the form of a Web page, we find several
attributes of the Transaction being captured in the eRecord. For instance, while doing the
Misc Receipt of an item, it captures the Item number, Description, Serial Numbers, the
transaction date etc in the eRecord. XML Gateway is used for Mapping these definition
and generation of XML for an eRecord. Individual product teams define XML maps and
DTD for eSignature / eRecord Events (ERES) supported by them. These Maps and DTD
are loaded into Database and source controlled under respective Product Tops. The
eRecord Style sheet is also defined as part of XML gateway.

Oracle Approval Management Engine (AME)


This component is used to define Conditions, rules and approval hierarchy. This module
gives us the maximum flexibility in terms of usage of the entire functionality. These rules
are evaluated at runtime based on Transaction Id (This is primary key for the transaction,
TRANSACTION_ID in case of a Miscellaneous receipt or it could be CHANGE_ID in
case of ECO approval process).

Oracle Applications
ERES can be used only from the Forms based applications, It cannot be used from the
Web based applications or Mobile applications. Oracle uses (FNDWFSIG.pll) a generic
call, to raise an event from the forms

Workflow Notification Subsystem


Notification subsystem is used to generate the signature UI and control the flow of the UI
and return status back to application module.

ERecords Evidence store


Finally Digital signatures evident store is used for storing Electronics signatures.
Whenever any specific eRecord needs to be pulled up (old Transactions etc), the data is
queried from the Evidence Store
The framework component and the integration is depicted in the following diagram

The setups related to each of the components will be discussed more in details in the setup
section.

Online Versus Deferred Mode Capture


When windows require an e-signature, there are two methods of capturing this data. The signature
can be captured in process (online) or asynchronously (deferred) through workflow notifications.
Transaction windows (e.g., Batches, Inventory Quantities, Quality Results) require us to enter all
signatures online only. If the signatures cannot be fulfilled in that session, then the new or

updated transaction data is not committed to the database. Online signatures are beneficial for
those real-time processes that cannot proceed without immediate authorization. For example,
Miscellaneous Receipt Transactions.
Deferred mode signatures are useful when the signature does not need to occur immediately, the
signers are not typically in the same physical location or are otherwise not immediately available
at the time of the signature request, or if there are several items that the signers must verify prior
to signing, thus creating a time lag between receipt of the e-signature request and the response. A
typical example could be the Engineering Change notifications, which can be a deferred flow.

Case Study:
Company Vision Corporation manufactures an Item "MediVision Laparoscope" - production
requires FDA compliance. The Item is manufactured only at one of the organizations - Denver
Manufacturing Unit (M5)
As per the FDA Requirement Company has decided to follow the compliance with ERES for the
following Business Processes
Item Creation /Updation
Miscellaneous Receipt / Issue Transactions
BOM Creation/Updation
ECO Creation/Approval/Transfer or Copy to Manufacturing
For our demonstration purpose we shall deal with only two of these Transactions viz.
Miscellaneous Receipt and
ECO Creation/Approval
The Item MV1000 "MediVision Laparoscope" which is created with Finished Goods Template
and assigned to Organization M5 Denver Manufacturing
For the Misc. Receipt/issue transactions it requires the Approval of the Warehouse Manager
For any Engineering Changes, it requires the approval of the Design Group
We have created the following users
WHMGR - Warehouse Manager
DESIGN1 - Design group member#1
DESIGN2 - Design group member#2

Setup Steps
The following diagram illustrates the various components that need to set up.

EDR:
Server
Time zone

Profile
Options

EDR: Erecords and


E-Signatures

ERES

Review and Update


Transaction Variables

Workflow
Administra
tion

Enable Business Event


& Subscription

AME

Review/Create
Attributes

Create
Conditions

EDR: WF
Notification
Time out
Interval

Create
Actions

EDR: WF
Notificatio
n Time out

Create
Groups

EDR: Send
individual
Approval
Notification

Create
Rules

Enabling profile options


The following profile options needs to be set
EDR: E-records and E-Signatures this is the profile, which either enables or disables
the functionality of ERES. This can be set only at the site level.
EDR: Server Time zone in the even of a global implementation it is the time where the
database is running. This is used again only at the site level. If this is not set then all the
all e-records have a null value for the time zone.
EDR: Workflow Notification Timeout Interval
And
EDR: Workflow Notification Timeout (in Hours)
This two profile options work in tandem, The first determines , no of times the email
notification will be sent to the user, and the second profile determines what should be
the interval between the two notifications in hours. Both of them work only at the site
level
EDR: Commit Size
The value set in this profile option is used to issue a commit during a mass update
of e-records if a new indexed element is turned on for query and security.
This is set at the Site level only.
EDR:Security Level High This profile restricts the viewing of the eRecords depending
on the security rules setup
EDR: E-record Print Granted This profile allows the control of Printing the eRecords.
Typically this should be set to NO at the site level, and yes only at the specific user
level.

EDR: Send Individual Approval Notification


This profile option is for receiving emails during a signing process. If this profile is
Set to yes, then the requester gets approval notification after every signer. If this is
Set to No, then there is no notification for each signature. All signers receive a
Notification for a rejection, regardless of the profile option setting.
Business Events and Subscription
Business events are the business processes or the transactions against which the ERES is
enabled. In 11.5.10 there are total 55 Business Events across modules, which has been enabled.
** Imp: The ERES business events work only from the FORMS based components and do not
work from HTML or mobile applications. These business events are seeded values.
For our case study we will be discussing the Inventory Miscellaneous Receipt as an example.
(Other business events will also require similar types of setup)
Navigation: ERES Administrator responsibility >> setup.
The following screen capture show the components of it

The variable EREC_REQUIRED = Y determines that for the business event the eRecord will
enabled, similarly, ESIG_REQUIRED = Y means that , along with the eRecord the eSignature is
also enabled for the Business events.
(Who will be the signers will be discussed later) In the eRecord what data will be captured is
determined by the invtrxxs.xls the style sheet type.
If any specific business event variable needs to be changed it can be done by updating the
record (Hit the Update icon)
Enabling the Business Event and Subscriptions:
A synchronous subscription is added to the defined business event, which is a local
Subscription.
Navigation: Workflow Administrator >> Event manager
Search for the respective event name can retrieve Business Events The Business event

as shown in the following screen captures

Hit the Subscription Button

Function EDR_PSIG_RULE.PSIG_RULE. This is the rule function, which determines if


e-signature is required for the event instance and generate XML document if required.
The workflow shows the following
Workflow item Type = EDRPSIGF
Workflow Process Name = PSIG_ESIGN_PAGE_FLOW
The Enabled Status determines if the Business event is enabled or not
Note: If the Business Event and subscription are not enabled, the system will not show the ERES
record during transaction processing To Enable the Business Event and the corresponding
Subscription (in case it is disabled) you need to login with username SYSADMIN Only then the
Update Icon will appear
(This Icon does not appear without the username as SYSDMIN, refer Note.290603.1)
Now we will look at the AME (Approval Management Engine) to create so that the Business
Events are which are initiated by some transactions actually pass through the right group of
approvers. This is done via Oracle Approval management module

Setting Up Oracle Approvals Management for ERES

Oracle Approval management (also called AME) is a web based application that enables users to
define business rules governing the process for approving transactions in other Oracle
Applications. It enables business users to specify the approval rules for an application without
having to write code or customize the application. AME has the following main components
Transaction Types: These are the basic Business flows for which AME is enabled.
We need to choose the Transaction Types from the list and for each of the Transaction Types we
need to define/select the following
Attributes
Conditions
Actions
Groups
Rules

Attributes: These are named Business variables such as ORGANIZATION_CODE


The most useful attributes for the present Example (Miscellaneous Receipt) would be
ORGANIZATION_CODE, SUBINVENTORY, ITEMS, and ITEM REVISIONS etc.
If more such attributes are required, selecting the Attribute Tab and going to Add
Attribute Button can always add it up.
Conditions: This is the list or range of Attribute value which the system uses to make
the Rule apply on a Transaction
Navigate to Conditions Tab , and go to Add Conditions Button .
Select Condition Type as ORDINARY, Attribute as ORGANIZATION CODE,
Enter the Attribute Value <SAME AS THE ORG_CODE> , this is case sensitive> and
continue

Similarly you can create other Conditions , like , Item numbers for which you would
like to enable the ERES functionality.

Actions: Every approval may or may not require a predefined set of actions.( This is
not very relevant in the INV ERES context of discussion)
Groups: is an ordered list of persons and/or user IDs. These are the persons who is
responsible for accepting or Rejecting a Transaction
Approval groups are an ordered set of one or more approvers (persons and/or user
accounts).
Choose the Groups tab >> Choose the Add Group button >> On the Create an Approval
Group page, enter a name and description that uniquely identify the new approval group
You can have more than one person as group member and the order number in which
they are listed will determine who will be the first approver and than the next person
with the higher order number

Rules: Associates one or more conditions with an approval action. The rule
applies to a transaction if and only if all of the rules conditions are true for the
transaction.
Rules will use the Conditions Created earlier in conjunction with the Approval Groups
There are 6 types of Rules , For INV ERES purpose we can use the List-creation rules
which is used to generate the default chain of authority for a given transaction. It uses the
ordinary conditions . There are 6 steps to Create the Rules
From the Rules Tab click on Add Rule and Usage >>Provide a description, rule type and
rule affectivity date and click Continue >> Select the Action Type as Chain of
Authority includes an Approval Group and click Continue >> Select the previously
created Approval Group from the List and click Continue >> Choose the subordinate
item class as none and click on Continue >> Select the Header Level Attributes ( for
selecting more than one conditions use Cntrl key + click on the attributes , in our case it
will be the ORGANIZATION_CODE and ITEMS ) and click continue >> in the last
step select the conditions that we have defined earlier and click continue , and the
Rule creation will be completed.

This concludes the Setups that are necessary for Enabling/performing ERES related
Transactions. This Setup will ensure that when anyone performs a Miscellaneous Receipt in
M5 Organization for Item MV1000, system will launch a Webpage , showing all the details of
the Transactions and the Approver will require to provide his userid and password and only then
the Transaction will be processed. If any of the events fail (Signature authentication / Rejection
by the user ) the Transaction will not be processed

Miscellaneous Receipt - Online Mode Capture


The below screen dump shows the receipt of Serial number SR2000 to SR2049 of Lot LP06

Similarly the other Lot LP07 having Serial Number SR2050 to SR2099 is also received.
Now when we hit the SAVE button , we are presented with the ERES Webpage

Notice that the Signer is WHMGR, Click on the Sign icon,


The Notification page appears detailing the actual Electronic Record

The signer has to review the document and at the bottom of the page has to provide his
response and Approve

Now the eSignature verification page comes up, where the signer has to provide his
USERID/PASSWORD and hit the Sign button.. This will give the confirmation page

Once you apply, and OK the Transaction, the ERES page will go away and the original
Application page (Misc. Receipt) will appear where you need to press the OK button. Once this
is done the Transaction gets processed

eRecords Evidence Store


Once the Transaction is committed to the database, from the following screens we would be able
to retrieve the eRecords details (Tools > eRecords)
1) Material Transactions >> INV > Transactions > Material Transactions
2) Transaction Summaries >> INV > Transactions > Transaction Summaries > Transaction
Details
3) Lots Screen >> INV > On hand Availability > Lots > View Genealogy and View
Transactions screen
4) Serials Screen >> INV > On hand Availability > Serials > View Genealogy and View
Transactions screen
5) ERES Administrator >> Evidence Store > Based on the Search Criteria you can retrieve
the ERES records

Engineering Approval :Deferred Mode Capture:


Business Example
Any Engineering Change order for the existing Item MV1000 (Medivision Laparoscope)
requires the Approval of all the members of the design team and eRecord is created at the time
of ECO creation and the eSignature of all the members in the Approval group
The Business Process and the corresponding event names which are involved are
ECO Creation --- oracle.apps.eng.ecoCreate
ECO Approval --- oracle.apps.eng.ecoApproval
For ECO Creation the Transaction variable ESIG_REQUIRED default value can be set N
This will ensure that during the ECO creation no signature process is involved
and the eRecord for the ECO is created in the background
Please note that, there is no transaction type as 'ECO Approval'. It has only the business event.
All the AME setups are done with respect to the transaction Type which in this case will be

the ECO Creation. ECO Approval will be child process of the ECO Creation when approval
mechanism is used
Ensure that The Business Events (mentioned above) are enabled and their subscriptions are also
Enabled. (Oracle Workflow Administrator Workflow Responsibility)
Approval group in AME is created in the Similar way as that of Miscellaneous Receipt
Transaction , with 2 members in the Group Design1 and Design2
Similarly Conditions/Rule are built in AME such that
if the ECO Type is ERES , then It will require the Approval of the Design group

In Engineering Application we create a Priority named as ERES and also create a Change
Type called as ERES and attach the Workflow ERES Approval Process
Create a Approval List as ERES1 having Design1 and Design2 as the Approver

Now we create a an ECO for Item MV1000 with ECO Type as ERES , Priority ERES and
Approval List ERES1 . The ECO is created to add a reference designator to one of the
components. Once the ECO is saved , submit the ECO for approval.
At the instance when the ECO is created the eRecord related to ECO creation gets triggered
and the eRecord gets created in the background. The eRecord will contain all the details of the
ECO .He same can be viewed by Navigating to Actions>eRecord details
Once the ECO is submitted for approval, the ERES Approval workflow (seeded workflow) takes
over and does all the necessary validation , gathers data for the eRecord creation and sends
notifications to the users based on the Approval List .

The user Design1 and Design2 logs into the Application and reviews their individual
Notification and would find the ECO Approval notification

Once the user clicks on the Hyperlink, the original Create ECO eRecord will show up

The user can review the ECO changes requested for , scroll down and Approve/Reject the ECO

Once the user hits the Approve/Reject Button the eSignature web page comes up and the user
has to provide his username/password for verification and click on Sign button.
Once both the users have Approved the ECO Notification the ECO status will changed to
Approved. The navigation/View eRecords Details will now show , two links
ECO Approval and ECO Creation

Conclusion:
Complying with the technical requirements of FDA 21 CFR Part 11 is critical for software
applications that manage GMP critical data. Oracle Applications offers an unmatched set of tools
to help enterprises in regulated industries address these requirements and maintain electronic
records

Appendix:
Total 55 Business events are enabled with this release
Summary of Business Events enabled in the discrete manufacturing area with release 11.5.10
Summary of Business Events enabled in the discrete manufacturing area with release 11.5.10

Transaction

Business Event

eRec
ord

eSign
ature

Comments

oracle.apps.inv.acctAlia
sIssue

Yes

YesOnline

Based on the Transaction Type this business


event is called from the form INVTTMTX. The
eSignature is invoked online

oracle.apps.inv.acctAlia
sReceipt

Yes

YesOnline

-do-

INV
INV ERES
Account Alias
Issue
INV ERES
Account Alias
Receipt
INV ERES
Account Issue
INV ERES
Account Receipt
INV ERES
Miscellaneous
Issue
INV ERES
Miscellaneous
Receipt

oracle.apps.inv.acctIssu
e
oracle.apps.inv.acctRec
eipt

Yes
Yes

YesOnline
YesOnline

-do-do-

oracle.apps.inv.miscIssu
e

Yes

YesOnline

-do-

oracle.apps.inv.miscRec
eipt

Yes

YesOnline

-do-

INV ERES Item


Creation

oracle.apps.inv.itemCre
ate

Yes

YesOnline

INV ERES Item


Cross Reference
Entry

oracle.apps.inv.itemCro
ssRefEntry

Yes

No

INV ERES Item


Organization
Assignment

oracle.apps.inv.itemOrg
Assignment

Yes

No

INV ERES Item


Revision Entry

oracle.apps.inv.itemRev
isionEntry

Yes

YesOnline

INV ERES Item


Update

oracle.apps.inv.itemUpd
ate

Yes

YesOnline

Yes

YesDeferr
ed

At the time of Item creation in the Item master


org, eSig is required on line
At Org assignment eSig is not required
This event is called from the Master Items
form, Item Cross Reference menu entry from
menu bar
This event will trigger Item Creation event in the
background. Only eRecord is needed for item
creation event as eSignature is already collected
for Item Organization Assignment event
When the event is invoked from the Master
Item form , the eSignature will be required.
However, If event is raised after ECO
implementation, no eSignature will be needed
since ECO approval already collects the
eSignaure.
Any kind of Item updation will trigger this
event with both eRecord and eSig

ECO
ECO Approval

oracle.apps.eng.ecoApp
roval

ENG ERES ECO


Cancellation

oracle.apps.eng.ecoCan
cellation

Yes

No

ENG ERES ECO


Creation

oracle.apps.eng.ecoCrea
te

Yes

No

This is invoked by the ECO approval workflow


, and at the time of actual approval the
eSignature is recorded
This even is invoked from Engineering -> ECOs
-> Cancellation action from menu bar.
The eRecord content will show only the
cancelled item/component/operations
The ECO details are recorded at the time of
ECO creation from Engineering -> ECOs form

Transaction

Business Event

eRec
ord

eSign
ature

Comments
This is invoked by the ECO implementation
concurrent program. The eRecord content
will
show
only
the
implemented
item/component/operations.
The event will trigger other events based on the
ECO contents, e.g. Bill Update
Invoked from Engineering -> ECOs -> Schedule
action from menu bar. Date and comments will
be captured together with ECO contents

ENG ERES ECO


Implementation

oracle.apps.eng.ecoImpl
ement

Yes

No

ENG ERES ECO


Reschedule

oracle.apps.eng.ecoResc
hedule

Yes

No

ENG ERES ECO


Schedule
ENG ERES ECO
Update

oracle.apps.eng.ecoSche
dule
oracle.apps.eng.ecoUpd
ate

Yes

No

Yes

No

ENG ERES Copy


to Manufacturing

oracle.apps.eng.copyTo
Manufacturing

Yes

YesOnline

ENG ERES
Transfer to
Manufacturing

oracle.apps.eng.transfer
ToManufacturing

Yes

YesOnline

-do-

ENG ERES Mass


Change Bills

oracle.apps.eng.massCh
angeBill

Yes

YesOnline

The event is invoked from either Engineering ->


ECOs -> Mass Changes form or Bill of Materials
> Bills > Mass Changes form

-doAfter ECO creation any subsequent changes to


the ECO this event will capture the details.
When the process is invoked from the forms, i.e.
Transfer/Copy To Manufacturing form and
Engineering -> Items form -> tools menu -> , the
eSignature is recorded online. However, if the
When event is raised through ECO
implementation. eSignature will be collected
through ECO approval.

BOM
BOM ERES Bill
of Materials
Creation

oracle.apps.bom.billCre
ate

Yes

YesOnline

BOM ERES Bill


of Materials
Update

oracle.apps.bom.billUpd
ate

Yes

YesOnline

BOM ERES
Operational
Routing Creation

oracle.apps.bom.routing
Create

Yes

YesOnline

BOM ERES
Operational
Routing Update

oracle.apps.bom.routing
Update

Yes

YesOnline

oracle.apps.wip.job.asse
mbly.complete

Yes

YesOnline

When the Bill is created from the Bills form


eSignature is captured online. However, if the
Bill is created from ECO Implementation then
the signature is collected from the ECO
Approval workflow event.
The process is same as in Bills creation . In
addition if the Bill updation is happening via
Mass change process, then the eSignature is not
collected, as this would be collected by the Mass
Change event
If the Routing is created from the Routing form
, the eSig will be captured online.
But if the Routing is created from ECO
implementation or Copy/Transfer from
engineering , then the eSignature will not be
captured online
Same as above, except for the fact that
Copy/Transfer function does not apply to
Routing updation

WIP
WIP ERES Job
Assembly
Completion
WIP ERES Job
Assembly Move

oracle.apps.wip.job.asse
mbly.move

Yes

YesOnline

WIP ERES Job


Material
Transaction

oracle.apps.wip.job.mat
erial.transact

Yes

YesOnline

Event is invoked from WIPTXCMP (online


transaction processing mode)
Event is invoked from WIPTXSFM (online
transaction processing mode) This event
supports the following transaction types:
assembly move, assembly move and completion
and assembly return and move.
Event is invoked from WIPTXMAT (online
transaction processing mode) This event
supports the following transaction types:
material issue/return, material negative
issue/return

Transaction

Business Event

eRec
ord

eSign
ature

Comments

oracle.apps.po.asl.create

Yes

No

Event is invoked from POXSCASL . The


eRecord will capture all the details of the ASL

oracle.apps.po.asl.updat
e

Yes

No

oracle.apps.po.rcv.deliv
er

Yes

No

oracle.apps.po.rcv.transf
er

Yes

No

oracle.apps.po.rcv.inspe
ct

Yes

YesOnline

PO
PO ERES ASL
Creation
PO ERES ASL
Update
PO ERES
Receiving
Delivery
PO ERES
Receiving
Transfer
PO ERES
Receiving
Inspection
WSH

WSH ERES
Delivery Shipment

-doThe event is invoked from the Delivery


Transactions form (online, immediate, batch
mode)
-doThis event is invoked when Quality data is
involved and the eSignature is called online
This can be invoked from Quality > Other >
Requests > Run > Generate Shipping Electronic
Record concurrent program
The concurrent program looks at the
wsh_new_deliveries table for all the deliveries
that are in Closed or In-Transit status and having
an initial pickup date within a range provided as
parameter to the concurrent program. For all
deliveries meeting this criteria, the eRecord will
be generated (if satisfying the AME criteria).

oracle.apps.wsh.eres.del
ivery.shipment

Yes

No

oracle.apps.qa.element.c
reate

Yes

No

oracle.apps.qa.element.u
pdate

Yes

No

-doThis event is Invoked from Quality > Setup >


Collection Plans
Conditions under which you collect quality data,
and enable transactional collection.

QUALITY
QA ERES
Collection
Element Creation
QA ERES
Collection
Element Update
QA ERES
Collection Plan
Creation
QA ERES
Collection Plan
Update
QA ERES
Corrective Action
Creation

oracle.apps.qa.plan.creat
e

Yes

Yes

oracle.apps.qa.plan.upda
te

Yes

YesOnline

oracle.apps.qa.car.create

Yes

No

QA ERES
Corrective Action
Update

oracle.apps.qa.car.updat
e

Yes

No

QA ERES
Corrective Action
Approval

oracle.apps.qa.car.appro
ve

Yes

YesDeferr
ed

QA ERES
Corrective Action
Implementation
Approval

oracle.apps.qa.car.impl.
approve

Yes

YesDeferr
ed

This event is Invoked from Quality > Setup >


Collection Elements

-doThis event is Invoked from Quality > Corrective


Action > Enter Corrective Action Request
This event is Invoked from Quality > Corrective
Action > Update Corrective Action Request.
This is used to Use to track root cause, closing
CAR etc.
This event is Invoked from Quality >
Corrective Action > Enter /Update Corrective
Action Request. This is used to obtain approval
of the submitted corrective action request.
-do-

Transaction

Business Event

eRec
ord

QA ERES
Corrective Action
Review Approval

oracle.apps.qa.car.revie
w.approve

Yes

QA ERES
Disposition
Creation

oracle.apps.qa.disp.creat
e

QA ERES
Disposition
Update

oracle.apps.qa.disp.upda
te

QA ERES
Disposition Detail
Approval

Yes

eSign
ature
YesDeferr
ed
No

Yes

No

oracle.apps.qa.disp.detai
l.approve

Yes

YesDeferr
ed

QA ERES
Disposition
Header Approval

oracle.apps.qa.disp.head
er.approve

Yes

YesDeferr
ed

QA ERES
Nonconformance
Creation

oracle.apps.qa.ncm.creat
e

Yes

No

QA ERES
Nonconformance
Update

oracle.apps.qa.ncm.upda
te

Yes

No

QA ERES
Nonconformance
Master Approval

oracle.apps.qa.ncm.mast
er.approve

Yes

YesDeferr
ed

QA ERES
Nonconforman
ce Detail Approval

oracle.apps.qa.ncm.det
ail.approve

QA ERES Result
Creation
QA ERES Result
Update
QA ERES
Specification
Creation
QA ERES
Specification
Update
QA ERES
Specification Org
Assignment

Comments
-doThis event is invoked from Quality >
Dispositions > Enter Dispositions
This enables to initiate a disposition resulting
from a nonconformance.
This is invoked from Quality > Dispositions >
Update Dispositions
This should be used when it is required to track
disposition status, e.g. Completion of Rework.
This event is invoked from Quality >
Dispositions > Update Dispositions
This helps to track disposition status, e.g.
Completion of Rework.
This event is invoked from Quality >
Dispositions > Enter/Update Dispositions. This
should be used when if a formal signature needs
to be obtained for the execution of a disposition,
e.g. rework, scrap, etc.
This event is invoked from Quality >
Nonconformances > Enter Nonconformances .
This used to report a nonconformance found
during inspection or other quality activities
This event is invoked from Quality >
Nonconformances > Update Nonconformances .
This is used to track nonconformance status e.g.
Closing.
This event is invoked from Quality >
Nonconformances >Enter/Update
Nonconformances. This event can be used
when a formal signature needs to be obtained for
a nonconformance prior to deciding on the
disposition.

Yes

YesDeferr
ed

-do-

oracle.apps.qa.result.cr
eate

Yes

YesOnline

This event is invoked from Quality > Results >


Enter Quality Results . Multiple applications
possible with this, for e.g. inspection results, test
results etc.

oracle.apps.qa.result.up
date

Yes

oracle.apps.qa.spec.cre
ate

Yes

oracle.apps.qa.spec.upd
ate

Yes

YesOnline

Yes

YesOnline

oracle.apps.qa.spec.org
.assign

Exclusions
ERES is not supported in the following areas

YesOnline
YesDeferr
ed

-doThis event is invoked from Quality > Setup >


Specifications
-doThis event is invoked from Quality > Setup >
Specifications . This is used for Item and Test
Specifications.

Not supported on mobile WMS and MSCA

Not supported for Service transaction integration

Not supported on iSupplier Portal

Not supported for collection import interface or public APIs

Not supported for OSFM lot-based job move transaction

Not supported for Flow Work order less completion transaction

Not supported for Flow workstation line operation completion transaction

Not supported for any Advanced Service Online (ASO) transactions

Not supported for EAM transactions

Not supported on OA Framework based pages (selfservice quality applications)

White Paper: A Guide to set up ERES


January, 2005
Author: Ritwik Chakraborty
Principal Support Engineer
Contributing Authors: N/A
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright 2003 Oracle Corporation
All rights reserved.

You might also like