Implementing E-Records & E-Signatures in Oracle Applications

Implementing E-Records and E-Signatures
(11.5.10)
in
Discrete Manufacturing Suite
An Oracle White Paper
October, 2005
Implementing E-Records and E-Signatures (11.5.10) in Discrete

Manufacturing Suite
Part 11 applies to electronic records required under a predicate rule, e.g., QSR, GLP, etc. It is not
intended to increase the number of records maintained by a regulated company. It is intended to place
some requirements on the retention of the records to ensure their usefulness and integrity. Many of the
informal interpretations that have been discussed over the past several years would increase significantly
the amount of data retained by regulated industries clearly contravening the intent of the rule. We believe
that our proposal would limit the amount of retained data to that which is truly needed to satisfy both
business and regulatory purposes.
William W. Bradley
Chairman, Steering Committee
Industry Coalition on 21 CFR Part 11
Docket 00D-1541 (June 14, 2002)
ABSTRACT
Oracle E-Records is a configurable framework for securely capturing, storing, inquiring and
printing electronic records and electronic signatures (ERES) in compliance with government
regulations viz., the United States Food and Drug Administrations 21 CFR Part 11. Oracle ERecords is part of the Oracle E-Business Suite. In compliance with the United States Food and
Drug Administration's (FDA) regulation on Electronic Records and Electronic Signatures 21
CFR Part 11, critical business events in Oracle Discrete Manufacturing were enabled for
Electronic Records and Electronic Signatures (ERES) in Release 11.5.10. Identification of the
business events to be enabled for ERES was based on the predicate GMP rule for Medical
Device Manufacturers 21 CFR Part 820. A total of 55 business events across the modules in
Discrete Manufacturing have been enabled for ERES. The Discrete Manufacturing Products, the
business events for which have been enabled for ERES include - Inventory, Bill of Materials,
Engineering, Work in Process, Quality, Purchasing and Shipping. In this paper we deal with stepby-step details of setting up ERES for business events selected from the above products.
Demonstrations have also been incorporated on the iSignatures feature introduced in Release
11.5.10. iSignatures is in compliance with FDAs 21 CFR Part 11 and enables users to upload
any type of file to the database and to rout it for approval using the ERES framework.
SCOPE
This paper is intended for an audience familiar with Oracle Discrete Manufacturing product cycles
and seeking an insight into how the Electronic Records and Electronic Signatures (ERES)
framework is built to cover important business events or transactions from each product cycle.
This paper is functional in nature keeping in sight Oracles existing literature that has adequate
details on the technical aspect of the ERES Framework and also the fact that the technical
framework for ERES remains the same for Oracles Process as well as Discrete Manufacturing
Suites. This paper adheres to the content and borrows from the structure outlined in the
Reference texts listed under the References section at the end of this paper. This document is
intended to be supplementary in nature and does not in any way, purport to be a substitute for
any official literature being drafted or currently published.
Due to the paucity of time
business events from Purchasing and Shipping have not been covered in this paper
only select business events from each of the Discrete Manufacturing Products (excluding
Purchasing and Shipping) have been included for our demonstrations.
To prevent this document from becoming needlessly bulky with content already available (and not
specific to Discrete Manufacturing but applicable to Process Manufacturing as well), we have
chosen not to elaborate on features introduced in Release 11.5.10 such as:
Delegate Signing Responsibility
Signer List Modification
Enhanced Print Control
Integration with XML Publisher
ABOUT THE FDAS 21 CFR PART 11
On August 20, 1997, the United States Food and Drug Administration (FDA) enacted Part 11 of
Title 21 of the Code of Federal Regulations (21 CFR Part 11). 21 CFR Part 11 represents the
combined effort of divisions within the FDA, along with members of the pharmaceutical industry,
to establish a uniform, enforceable, baseline standard by which the FDA will consider electronic
records equivalent to paper records and electronic signatures equivalent to traditional handwritten
records and signatures. The regulation provides a uniform, enforceable, baseline standard for
accepting electronic records and their associated signatures and provides a level of confidence
that electronic records maintained in accordance with the rule will be of high integrity.
Where Part 11 describes the technical, administrative and procedural requirements for electronic
recordkeeping, one must look to the areas of the FDA code of federal regulations to determine
where the requirements in Part 11 must be applied. These other areas are generally called the
GxPs, which is a catch-all for good practices including Good Manufacturing Practices (GMP),
Good Laboratory Practices (GLP), Good Clinical Practices (GCP), etc. The GxPs are also broken
down by regulated industry. For example, Parts 210 and 211 contain the GMPs for
pharmaceuticals and Part 820 for medical devices. Oracle looks to these regulations as the basis
for designing the compliance solutions it offers its customers.
In 2003, the FDA announced that it was re-examining 21 CFR Part 11 and would be taking a
more narrow interpretation of the scope of part 11; focusing its efforts on assuring compliance for
high-risk records. High-risk records are those whose integrity, or lack thereof, pose the greatest
potential risks to product quality and consequently, public health and safety. During the reexamination period, the agency would be exercising enforcement discretion to certain part 11
requirements, however the technical requirements outlined in the regulation remain in effect. So,
the importance of record security, audit trails, operational system checks and electronic
signatures remain undiminished, however, the FDA will be looking for these requirements to be
in-place in a more focused set of (high-risk) records. The FDA reaffirmed that 21 CFR Part 11 is
here to stay and it wants to encourage industry to embrace electronic recordkeeping because of
its significant potential benefits to the agency, industry and the public.
The Oracle E-Business Suite 11i provides a complete set of tools for managing electronic
records, in accordance with the technical requirements in 21 CFR Part 11, including strong
security, audit trails, archiving, operational system checks built into GxP-critical business flows
and electronic signatures.
E-RECORDS AND E-SIGNATURES ON ORACLE TECHNOLOGY
The approach Oracle has taken in delivering a flexible and usable solution is to take a framework
approach built on proven Oracle technology comprising:
Oracle Approval Management to configure approval rules

Oracle Workflow to electronically route electronic signature requests
Oracle XML Gateway to define the data content of e-records
Oracle Database to manage both the source transactional data, as well as the electronic records
Evidence Store.
Oracle E-Records provides a generic toolset into which any application component of the Oracle
E-Business Suite can tie with minimal changes to existing code or end-user experience. This
build it once / apply it anywhere approach localizes the majority of new code to the Oracle ERecords product, thereby minimizing changes to existing code, increasing ongoing quality,
reducing re-validation costs, and enabling rapid rollout of electronic record-keeping and electronic
signatures across the Oracle E-Business Suite.
E-RECORDS AND E-SIGNATURES IN DISCRETE MANUFACTURING
In order to comply with the FDA regulation on Electronic Records and Electronic Signatures 21
CFR Part 11, critical business events in Oracle Discrete Manufacturing have been enabled for
ERES. Identification of the business events to be enabled for ERES was based on the predicate
GMP rule for Medical Device Manufacturers 21 CFR Part 820. A total of 55 business events
across the modules in Discrete Manufacturing have been enabled for ERES. It is important to
note that in 11.5.10, ERES support exists only for Forms based business events. There is no
ERES support for HTML or Mobile Applications.
Support for 21 CFR Part 11 Compliance was a gap in Oracle Discrete Manufacturing. With the
introduction of this support in Release 11.5.10, Oracle is in a superior position than the
competition in the Medical Devices Industry space for the following reasons:
Leveraging the Power of the Database

The driving force behind enterprise application suppliers push to provide tools to address the
requirements of 21 CFR Part 11 is to make their products more marketable by addressing the
critical business needs of its current and future customers. There are other significant benefits,
beyond the cost avoidance of a warning or shutdown order from a regulatory agency such as the
FDA, to be gained by implementing a compliant electronic record management solution.
It is a requirement in the pharmaceutical industry to retain records that pertain to the manufacture
and quality assurance of regulated products for a period equal to the life of the product plus
seven years. In the case of medical device industry, the record retention period should be for a
period of time that is equivalent to the design and expected life of the device. Given this
approach, it is easy to see how maintenance of the production records alone, for even a relatively
short-lived product can become quite cumbersome. When the size of each individual production
record may be 100 pages or more, a primary benefit of electronic storage, reduction in physical
space requirements to store paper records, quickly becomes obvious.
Physical storage space is expensive, while computer disk space is relatively cheap and easily
expandable. Headcount reduction or reallocation may also be realized, as the filing process in an
integrated system becomes a seamless process, eliminating the need for manual filing and for
data entry clerks. The data entry is done once, online, and the system takes care of the filing
automatically. Computer databases are built specifically to file, organize, sort and retrieve huge
amounts of data quickly and efficiently.
Reduced Cost of Compliance
An integrated approach comprising a common technology and a common set of procedures for ERecords and E-Signatures across all applications simplifies the validation process and reduces
the associated costs.
Faster Turnaround with Electronic Routing
In a global enterprise where geographical distances between teams and individuals make routing
of paper records cumbersome and expensive, electronic routing of signature requests ensures
that approvals are obtained almost instantaneously. This translates into quicker and cheaper
product development, manufacturing and quality assurance turnaround.
Better Collaboration
The physicality of paper records imposes the restriction that they can be accessed at any given
time only at the location where they are stored. As opposed to this, in an integrated global
environment, individuals with the requisite access privileges can view the electronic records and
sign them without geographical location being a cause of concern. This facilitates faster decisionmaking.
Enforced Best Practices
Rigorous manual scrutiny is probably the only means to ensure that valid data in entered on
paper documents. Beyond the ability to manage vast amounts of data, computer systems,
however, are adept at reducing data errors by providing users with lists of appropriate values to
choose from and validating data format prior to accepting or saving the data into files or tables.
Oracle E-Records enables you to enter critical manufacturing, inventory and product quality
information directly into the system, because the controls that require signatures at critical points
in your processes are built into the system and are configurable. This enables you to enforce
compliance with GxP and avoid reentry of data, which introduces data error risk.
Advanced Search and Analysis
Information on paper is static and standalone. Analysis to find trends across a multitude of paper
records is tedious, time consuming and complex. Analysis across a large set of records may be
impossible. Enterprise systems that run on advanced relational database management systems
excel at searching data records for the purpose of finding trends and patterns across large
numbers of records. Oracle E-Records offers a powerful E-Record query tool, to search you
entire E-Record repository quickly and accurately, based on a wide variety of standard and
configurable query criteria.
THE RESPONSIBILITIES REQUIRED FOR IMPLEMENTING E-RECORDS AND ESIGNATURES IN DISCRETE MANUFACTURING
The Responsibilities we would need for implementing ERES in Discrete Manufacturing are:
1. Workflow Administrator Web Applications for enabling business events and their
subscriptions. To enable (or disable) business events and subscriptions, this
responsibility needs to be accessed using the sysadmin login.
2. Approvals Management Administrator for defining Approval Groups, Conditions and
Rules.
3. Workflow or Workflow User Web Applications for accessing Notifications and
responding to them.
4. ERES Administrator for defining the Input Configuration Variables
5. ERES User for accessing the E-Records from the Evidence Store.
6. A Manufacturing Function Responsibility such as Manufacturing and Distribution
Manager, for accessing all the relevant Discrete Manufacturing Menu options.
7. System Administrator for setting the required EDR profile options at the Site level.
Note: The E-Records upon creation are stored in a repository called the Evidence Store. The
Evidence Store can be accessed either from the transaction windows or by using the ERES User
Responsibility.
SETTING UP E-RECORDS AND E-SIGNATURES: A CASE FROM ORACLE PROCESS

MANUFACTURING (OPM)
Before we review the components that constitute the ERES framework in Oracle Applications, it
would be worthwhile to study the setting up and implementation of ERES in a typical OPM
business event. This preliminary exercise would serve to introduce us to a live example that
would subsequently ease the task of understanding the role that each stack of technology plays
in operating the ERES framework.
Demo 00-A: The case of implementing E-Records and E-Signatures for OPM inventory
items that have an Inventory Type of TEA or RAW
Case Summary
We define items in OPM Item Master such that an Inventory Type classifies each item. We have
a pre-defined list of Inventory Types that have been defined in OPM Inventory Setup. Two of
these types are TEA and RAW. Our objective is to ensure that the moment we create and try to
save an item in OPM Item Master with either of these two inventory types, the ERES framework
would trigger an E-Signature process, which would invite signatures from a pre-defined group of
five approvers. These approvers are defined as employees in Oracle HRMS, and approval by all
five of them would be necessary before the item data entered in the Item Master form gets
committed to the database.
Demo 00-A Step 1: Defining our Approval Group
Fig 1. Approval Group to be used in all our ERES Business Events Setup in this paper
Approvals Management Administrator > Approvals
Click on the Groups tab.

Click on the button Add Group.
Refer the Demo Defining the PRB Approval Group in Note 336709.1, for a step-by-step
review
The five individuals constituting the group are defined as employees in Oracle HRMS.
The Voting Regime for this Approval Group has been defined a Serial, which implies that the
order, in which the members were added to the group (which in turn constitutes their serial
number) is the same as the order in which the E-Record would be presented for signing when an
approval is sought on the transaction.
Note: In all the business events covered in this paper, to preserve some uniformity, the initial
requester would always be Member 1 i.e., Saumit Mandal. It intuitively follows that Members 2, 3,
stand in an ascending order as per the position held by each in the organizations hierarchy.
Thus, Ray Satyajit is the most senior member in the group and would be presented with the task
of signing the E-Record only after the same has been signed and approved by all the other
members.
Demo 00-A Step 2: Enabling our Business Event
Use the sysadmin login.
Workflow Administrator Web Applications > Find Events/Event Group
The business event we are concerned with is termed oracle.apps.gmi.item.create.
The Display Name is GMI ERES Item Creation.
Fig 2. Enabling ERES for Item Creation in Oracle Process Manufacturing

Note: Business events for ERES, can only be enabled using the sysadmin login.
The Self Service Application opens a search page for Events.
Search for the event with the Display Name GMI ERES Item Creation.
Click on the Update icon to set the status of the business event to Enabled in the Update
Events page.
Return to the main events page and then click on the Subscription icon to set the status of the
Subscription to Enabled in the Update Event Subscriptions page.
Note: An event's Subscription is the integration point with ERES and the calling application.
When the application raises an event, Subscriptions are invoked by workflow. ERES Subscription
(when invoked) takes the snapshot of the transaction (E-Record) and proceeds for taking signers
responses based on the setup.
We have enabled our business event.
Now, log out of sysadmin.
Refer the Demo 00-A GMI ERES Item Creation in Note 336709.1 for a step-by-step
review
Demo 00-A Step 3: Defining our Attribute
I now log in as the user SAUMIT.
Using the Responsibility Approvals Management Administrator navigate to Approvals.
Set the Transaction Type as GMI ERES Item Creation.
Now, click on the Attributes tab.
In the list of seeded Attributes available for Item Creation in OPM Inventory, we do not find an
Attribute that distinguishes items based on their Inventory Type. We have to define one.
We define an Attribute with the name INVENTORY_TYPE. This Attribute will have values of type
string.
This Attribute is expected to pick up the Inventory Type of an item when it is being defined in
OPM Inventory. This Inventory Type value would then be matched to a Condition embedded in a
Rule that we would subsequently define for GMI ERES Item Creation. To meet this requirement,
we define our Attribute Usage as dynamic, and define a Usage containing the SQL query that
would pick the inventory type every time we define an item in OPM (Fig 3).
Fig 3. Defining an Attribute to trigger ERES for OPM items based on their Inventory Type
Demo 00-A Step 4: Defining our Condition using the Attribute defined in Step 3
Click on the Conditions tab. Click on the button Add a Condition. The Condition Type is set as
ordinary. Now, select the Attribute INVENTORY_TYPE from the drop down list. One-by-one,
enter two string values for INVENTORY_TYPE viz., RAW and TEA (Fig 4).
Fig 4. Defining values for the Attribute in creating our Condition

Demo 00-A Step 5: Defining our Rule using the Condition defined in Step 4
Click on the Rules tab. Click on the Add Rule and Usage button. The system generates a Rule
Key. Select Action Type as chain of authority includes an approval group. Select the PRB
Approval Group as the group that would be presented with the E-Signature process.
Fig 5. Defining our Rule for OPM Items having Inventory Type as RAW or TEA
Select the Condition we had defined in Step 4. The Rule has been defined (Fig 5).
Demo 00-A Step 6: Defining Input Configuration Variables for our newly created Rule
Oracle continues to add support for electronic record keeping throughout the Oracle E-Business
Suite. In addition to providing control at the transaction level, the same controls have been added
at the setup of the system. The user can now enable electronic record keeping on the Oracle ERecords Input Configuration Variables. This is a key control point in enabling or disabling
electronic record keeping on individual transactions. It is the setting of these variables, which
determine if electronic record keeping and electronic signature control is enabled at the
transaction level and optionally at the transaction rules level. Additional settings control which
stylesheet files and versions are used to format each electronic record.
Responsibility: ERES Administrator.

Administration Tasks > Setup.
Select Transaction Name as GMI ERES Item Creation. There is only one Rule defined under
this business event, the one we have defined in Step 5. Select the same. Click on the button Go.
Fig 6. Message indicating that Configuration Variables need to be defined for the Rule
We get the message as shown in Fig 6. We need to define the Configuration Variables for the
Rule Approval for Items in Tea Production. There are four seeded variables (Fig. 7).
Fig 7. Seeded Variables that determine the configuration of the E-record transaction
EREC_REQUIRED implies whether E-Records need to be maintained for the transaction.
ESIG_REQUIRED implies whether E-Signatures are required with the E-Record.
gmiitmxs.xsl is the seeded XML Stylesheet designed to capture into an E-Record, the data
generated by the creation of an item in OPM Inventory. All business events that are seeded and
supported for electronic record keeping have pre-defined, seeded XML stylesheets against the
variable EREC_STYLE_SHEET. The seeded stylesheets can be replaced by custom defined
stylesheets should there be a requirement to capture additional information. Oracle XML
Publisher Users Guide Release 11i, details how to design stylesheets. Finally,
EREC_STYLE_SHEET_VER specifies the version of the stylesheet in use. The default values of
each of these variables are user-updateable.
As Fig 7 shows, we specify E-Record required and E-Signature required as Y (or Yes) for Item
Creation in OPM.
The setup required for triggering the creation of E-Records and E-Signatures in OPM Item
Creation, is complete. Now, select Responsibility OPM Inventory and navigate to
OPM Inventory Control > Setup > Item Master.
Fig 8. Approving the OPM Item after defining it with an Inventory Type as TEA
Create an item with Inventory Type as TEA. Save the item. Now select the option for approving
the item (Fig 8). This launches the List Of Signers web page (Fig 9).
Fig 9. The list of approvers who need to endorse this item with their E-Signatures
Assuming all the approvers are present at the same place at the same time, they can complete
the approval and the signing process using the screen in Fig 9.
Note: ERES allows for signers to sign an E-Record in two modes Online and Deferred. In
the Online mode, all the signers have to be present at the same place at the same time to
complete the signing process within that session. If a signer fails to participate in this process,
then the transaction data does not get committed to the database or the entity (a new item
created in OPM, for example) fails to get activated or approved. In the Deferred mode, the first
approver can sign the E-Record and click the Submit button. Upon doing so, the second
approver will receive a notification in his Notifications Summary or Worklist. When the second
approver approves the transaction and signs the E-Record by responding to the notification, a
notification is sent to the third approver...and so on. The Submit button appears only when
Deferred Signature is permitted for that event. In ERES, Deferred Signature is seeded and
10
supported for those events where the signers are likely to be separated geographically and/or the
signers require time to review the information captured in the E-Record before taking a decision.
The List Of Signers page (Fig 9) always indicates whether Deferred Signature is allowed for the
given transaction or event.
GMI ERES Item Creation is a business event, which is seeded to accommodate Deferred
Signature as well. This implies that if all the signers are not present at the same location, the
requester Saumit Mandal may choose to approve the item and then submit the rest of the signing
process for the other signers to pick up. In that case, the next approver Andre Wajda would
receive a workflow notification indicating that an item approval is pending. Andre Wajda would
then approve the item and endorse his approval with his E-Signature, by entering his applications
login and password. A workflow notification would then go to the third approver Jean Renoir, and
the process continues till the last approver Ray Satyajit validates the transaction with his ESignature. In the demo 00-A GMI ERES Item Creation, we use Deferred Signature for obtaining
the E-Signature of each approver after receiving the approval and signature of the initial
requester Saumit Mandal.
Once all the approvers have approved the new item and endorsed the same with their electronic
signatures, the E-Record assumes the form as shown in Fig 10.
11
Fig 10. The Completed E-Record for item creation in Oracle Process Manufacturing
Refer the Demo 00-A GMI ERES Item Creation in Note 336709.1 for a step-by-step
review
12
Demo 00-B: The case of implementing E-Records and E-Signatures for OPM inventory
items that have a specific suffix in the item name
Case Summary
Continuing the example taken in Demo 00-A, we now have items with item names spanning 22
characters. The last 5 characters from an item name determine whether the item is a processed
as a Leaf, Dust or Fiber. These examples are taken from the Tea Processing industry that was
dealt with in the white paper in Note 296558.1 (published on the Metalink).
Demo 00-B Step 1: We would be using the same Approval Group PRB Approval Group as was
defined in Demo 00-A Step 1.
Demo 00-B Step 2: The business event GMI ERES Item Creation has already been enabled in
Demo 00-A Step 2.
Demo 00-B Step 3: Defining our Attribute
This time we define our Attribute as dynamic, with a SQL query that picks up the item name
th
nd
between the 18 and the 22 characters i.e. the last five characters (Fig 11).
Fig 11. Defining our dynamic Attribute that picks up the last 5 characters in the item name
The Attribute we have defined is called COMPONENT_TYPE. The last 5 characters in the name
would specify whether the item is a Leaf, Dust or Granule. We therefore need to create a
Condition to meet this requirement.
Demo 00-B Step 4: Defining our Condition using the Attribute defined in Step 3
We define the Test Values TDUST, GRANL and FIBER as the Attribute Values that must exist
in the item name for the Condition to be satisfied (Fig 12).
13
Fig 12. Defining values for the Attribute in creating our Condition
Demo 00-B Step 5: Defining our Rule using the Condition defined in Step 4
The Rule we define (Fig 13) requires the approval process to be routed through the PRB
Approval Group and incorporates the Condition that the COMPONENT_TYPE Attribute would
have any of the three values defined in Fig 12.
Fig 13. Defining our Rule for OPM Items having a suffix of FIBER, GRANL or TDUST in the
item name
Note: We now have two Rules for the event GMI ERES Item Creation (Fig 14).
Fig 14. The two Rules defined so far for GMI ERES Item Creation
Demo 00-B Step 6: Defining Input Configuration Variables for our newly created Rule
Select Responsibility ERES Administrator.
14
Navigate to Administration Tasks > Setup.

Select Transaction Name as GMI ERES Item Creation. There is only one Rule defined under
this business event, the one we have defined in Step 5. Select the same. Click on the button Go.
Fig 15. Message indicating that Configuration Variables need to be defined for the Rule
We define the same values for the Rule Variables as shown in Fig 7. We specify that both ERecords and E-Signatures are required for this Transaction and Rule combination.
Responsibility: OPM Inventory
OPM Inventory Control > Setup > Item Master
We now define an item GRADE-1 TEA LEAF_GRANL in the Item Master form in OPM Inventory.
Of the 22 characters in the item name the last 5 characters have the string value GRANL, which
satisfies the Rule Approval for Tea Leaf Components (Fig 13). Upon saving the item and
selecting the Approve New Item option from the Actions menu, we are presented with the list of
approvers as shown in Fig 9.
This time we do not use the Deferred Signature process. Assuming all signers are present at the
same place at the same time, we use the online approval mode.
Refer the Demo 00-B GMI ERES Item Creation in Note 336709.1 for a step-by-step
review
USING THE 00-A, 00-B DEMO SET TO UNDERSTAND AME FUNDAMENTALS APPLICABLE
TO ERES
Oracle Approvals Management (AME) is a selfservice web application that enables users to
define business rules governing the process for approving transactions in other Oracle
Applications. Rules are constructed from conditions and approvals.
Transaction Attributes
In AME, an attribute is a named business variable such as TRANSACTION_AMOUNT, whose
value AME fetches at run time. AME includes the attributes commonly required for the transaction
types of each application that can use AME. However, there may be occasions when an attribute
would need to be defined to suit a specific requirement. The attributes INVENTORY_TYPE and
COMPONENT_TYPE that we defined in Demo 00-A and Demo 00-B respectively are examples
15
of user-defined attributes. Only a user with the Approval Management Administrator responsibility
can create or alter attributes (using the Attributes tab), because doing so generally requires
entering or changing an SQL query.
For setting up ERES in Discrete Manufacturing modules as detailed in the demonstrations that
follow, we shall use the seeded attributes available in AME under the given business events or
Transaction Types.
Static and Dynamic Attribute Usages
A static usage specifies a fixed value for the attribute, for all items and transactions. A static
usage always stores an attribute value as a string, regardless of the attribute's data type. The
string form of the attribute value should not exceed 100 bytes. Static usages should not use either
single or double quote marks to demarcate strings.
It is common practice to give static usages to most or all of the mandatory attributes. One reason
is that static usages require less runtime overhead than dynamic usages. Another is that static
usages express uniform business policies for all transactions in a given transaction type. Fig 16 is
an example of an attribute with static usage that we have defined for demonstrating the
iSignatures feature.
Fig 16. Example of an Attribute with Static Usage

A Dynamic Usage specifies an SQL query that AME executes at run time to fetch the Attribute's
value for each item in the Attribute's item class, for a given transaction. Dynamic usages can be
up to 4000 bytes long. They should not end with a semicolon. A dynamic usage can reference a
transaction's ID by using the bind variable ':transactionId'. The transaction-ID placeholder is a
true dynamic PL/SQL bind variable. That is, at run time, AME binds a transaction-ID value to this
variable before dynamically executing the query. A condition of a where clause referencing this
bind variable must have the form:
transaction ID = :transactionId
where transaction ID is a column that contains the transaction ID passed to AME at run time by
the application whose transaction type uses the query.
The query we used for attribute INVENTORY_TYPE in Demo 00-A

select inv_type
from ic_item_mst_b
where item_id = :transactionId
16
was based on the same principles. So too with the query for Attribute COMPONENT_TYPE
defined in Demo 00-B.
Conditions
In AME, a Condition specifies a list or range of Attribute values required to make a Rule apply to
a transaction. For example:
COMPONENT_TYPE in {FIBER,GRANL,TDUST}
There are three types of Conditions:
Ordinary
Exception
List-modification
In this paper we shall be using Ordinary Conditions to activate ERES for all our business events.
A Note on Ordinary Conditions
An Ordinary Condition associates an Attribute with a set of allowed values or range. Such a
Condition is true when the Attribute has one of the allowed values. We then say that the
Attribute's value satisfies the Condition. Ordinary Conditions have one of three forms.
Conditions on Date, Number, and Currency Attributes
These Conditions are associated with an approver type and have the form
attribute_name = approver_name
That is, the Condition is true when the Attribute's value is the ID of a specified approver of the
type associated with the Attribute.
Conditions on date and currency attributes, and number Attributes not associated with an
approver type, have the form,
lower_limit <{=} attribute_name <{=} upper_limit
Conditions on Boolean Attributes
Conditions on boolean attributes have the form,
attribute_name is {true, false}
Conditions on String Attributes
Conditions on string Attributes have the form,
attribute_name in {value_1, value_2, . . . }
The allowed values are case-sensitive.
Approval Rules
In AME, an approval Rule associates one or more Conditions with an approval action. The Rule
applies to a transaction if and only if all of the Rule's conditions are true for the transaction.
Each application that can use AME defines one or more transaction types. Each transaction type
has its own set of approval Rules. Several transaction types can share Attribute names, while
defining separate usages for those Attribute names. This makes it possible for several transaction
types to share Conditions and Rules.
17
Implementing E-Records and E-Signatures for Discrete Manufacturing

Now, that we have a working knowledge of AME fundamentals, we set our sights on setting up
ERES in individual applications in Discrete Manufacturing.
The steps to implementing ERES are:
1. Enable EDR Profile Options
2. Enable Workflow Business Event and Event Subscription
3. Approvals Management (AME) Setup
- Approval Group
- Attribute
- Condition
- Rules
4. ERES Configuration Variables
- Setting E-Record and E-Signature flags
- Specifying stylesheet name and version
Enabling EDR Profile Options

EDR: E-Records and E-Signatures. To enable the ERES functionality for the entire system, this
profile option must be set to Yes at the Site level.
Note: Some applications have additional profile settings to facilitate ERES for business events
associated with those applications. Demo 00-A and 00-B were executed in OPM Inventory or
GMI. To activate ERES in GMI, the profile option GMI: E-Signature Active must also be set to
Yes at the Site level, over and above the profile EDR: E-Records and E-Signatures. If the
profile GMI: E-Signature Active is not set to Yes, the Approve New Items option would not
appear in the Actions menu (Fig 8). However, the Discrete Manufacturing applications of
Inventory, Bill of Materials, Engineering, Work In Process and Quality do not have any
application-specific profile options for enabling ERES.
EDR: Server Time zone. Set this profile option to the time zone where the database is running.
EDR: Workflow Notification Timeout Interval. This profile option determines the number of
times you receive an e-mail notification reminder. It works in conjunction with the EDR: Workflow
Notification Timeout (in Hours) profile option. This is set at the Site level only.
EDR: Workflow Notification Timeout (in Hours). This profile option determines the length of
time between reminder notifications. It works in conjunction with the EDR: Workflow Notification
Timeout Interval profile option. This is set at the Site level only.
EDR: E-record Print Granted. This profile lets the administrator restrict access to printing ERecords. The default value, No, set at the Application level restricts everyone in that application
from printing E-Records. The system administrator can set the profile option to Yes for specific
users to grant printing capabilities.
Enabling Workflow Business Event and Event Subscription
This shall be done when we deal with individual business events in each application.
18
Approvals Management (AME) Setup

This shall be done when we deal with individual business events in each application.
ERES Configuration Variables
This shall be done when we deal with individual business events in each application
E-RECORDS AND E-SIGNATURES IN ORACLE INVENTORY
There are five business events concerning Inventory Items that are seeded and supported for
ERES.
Fig 17. Business Events in Oracle Inventory Items that are seeded and supported for ERES
Of these, we shall deal with the following three:
INV ERES Item Creation
INV ERES Item Update
INV ERES Item Revision Entry
There are six business events concerning Inventory Transactions that are seeded and supported
for ERES.
and
Fig 18. Business Events in Oracle Inventory Transactions that are seeded and supported
for ERES
Of these (Fig 18), we shall deal with INV ERES Miscellaneous Receipt, as setting up ERES for
the other Inventory Transaction business events would involve the same steps.
But before we proceed, we need to ensure that the business events are enabled and so are their
subscriptions.
19
Refer the Demo 011 INV ERES Item Creation in Note 336709.1 for a step-by-step
review
INV ERES Item Creation
Select the Transaction Type INV ERES Item Creation.
Click on the Attributes tab.
Select the seeded Attribute ORGANIZATION_CODE.
This is an Attribute with a Dynamic Usage defined by the SQL:
select organization_code
from mtl_parameters
where organization_id = to_number(substrb(:transactionId,1,
instrb(:transactionId,'-') -1))
Under the Conditions tab, we had defined the following Condition
ORGANIZATION_CODE in {M1,M2,M3}
when setting up ERES for the event Bill of Materials Creation (to be discussed in the next
section). We shall use this Condition for our business events in Oracle Inventory with the
modification that the Condition will include the organization V1 as well. So the Condition now
becomes:
ORGANIZATION_CODE in {M1,M2,M3,V1}.
Under the Rules tab, we define a Rule: INV Item Creation in V1, M1, M2 and M3
Note: When defining a Rule in AME, we shall be using the Action Type chain of authority
includes an approval group throughout this paper. This will enable us to use the PRB
Approval Group that we had defined in Demo 00-A Step 1 (Fig 1).
We thus come up with the Rule in Fig 19.
Fig 19. The Rule for Creating Items in Oracle Inventory in the ERES Framework
To define the Input Configuration Variables for this Transaction Type, use
ERES Administrator > Setup
For Transaction Type = INV ERES Item Creation
20
and Rule = INV Item Creation in V1, M1, M2 and M3, we set EREC_REQUIRED = Y and
ESIG_REQUIRED = N.
Thus Item Creation will generate an E-Record but will not call for E-Signatures.
Responsibility: Manufacturing and Distribution Manager
Inventory > Items > Master Items
We now define an item (STJ180/15) in Item Master organization V1 and save it.
Upon navigating to Tools > eRecord Details, we are led to the Evidence Store where the following
E-Record is available:
Fig 20. The E-Record for item STJ180/15 created in organization V1

Click on the link under Event Name to open the E-Record. The E-Record header provides details
of the user who created the record (Requester), the Event Name and the time stamp (Fig 21).
21
22
23
Fig 21. The E-Record for Item Creation in Oracle Inventory
Refer the Demo 011 INV ERES Item Creation in Note 336709.1 for a step-by-step
review
INV ERES Item Update
Here, we use the same Attribute and Condition as was used in Item Creation. The structure of the
Rule too remains the same (composed of the same Attribute and Condition). Only this time, the
Rule has a different name: INV Item Update in V1, M1, M2 and M3.
The Rule Variables are again set as EREC_REQUIRED = Y and ESIG_REQUIRED = N.
The item we created in V1 (STJ180/15) has been assigned to M1, M2 and M3.
We now navigate to Organization Items and select the organization M2.
Inventory > Items > Organization Items
We query for the item STJ180/15. When the item is retrieved, we change the items Serial
Generation from At Receipt to At Sales Order Issue. We save our work.
We navigate to Tools > eRecord Details to locate the resulting E-Record in the Evidence Store
(Fig 22).
Fig 22. The E-Record for item STJ180/15 updated in organization M2

Click on the link under Event Name to open the E-Record. The E-Record for Item Update would
have the same structure as that for Item Creation since in both events, the seeded stylesheet
used (inviditm.xsl) is the same.
Refer the Demo 012 INV ERES Item Update in Note 336709.1 for a step-by-step review
INV ERES Item Revision Entry
24
Here, we use the same Attribute and Condition as was used in Item Creation and Item Update.
The structure of the Rule too remains the same (composed of the same Attribute and Condition).
However, the Rule has a different name: INV Item Revision Entry in V1, M1, M2 and M3.
This time the Rule Variables have been set as EREC_REQUIRED = Y and ESIG_REQUIRED =
Y. We would need E-Signatures to complete the transaction.
We now navigate to the Master Items form in Oracle Inventory and query for the item STJ180/15
in Item Master organization V1.
Inventory > Items > Master Items
Click on the Revisions tab at the top left corner.
Fig 23. Creating a New Revision for item STJ180/5

As soon as we save the new revision entry (Fig 23), the List Of Signers page is launched (Fig
24).
Fig 24. The approvers whose E-Signatures would be required to commit the new revision
entry
25
As Fig 24 shows, Deferred Signature is not available for this business event. The approvers have
to validate the transaction with their E-Signatures in Online mode, which implies that the signers
must sign the E-Record then and there.
Fig 25. The E-Record for Item Revision Entry

Fig 25 shows the signature details as evidenced on the E-Record, after all the signers have
approved the transaction.
26
Refer the Demo 013 INV ERES Item Revision Entry in Note 336709.1 for a step-by-step
review
INV ERES Miscellaneous Receipt
Approvals Management > Approvals
Select the Transaction Type INV ERES Miscellaneous Receipt.
from mtl_eres_transactions_gtmp
where original_transaction_temp_id =to_number(:transactionid)
The table mtl_eres_transactions_gtmp is a new global session table introduced into Oracle
Inventory through 11i.SCM_PF.J. This table holds Inventory Transactions (Misc UI header
information) for electronic record capture purposes. The current session is able see data that it
placed in the table but other sessions cannot. Data in the table is temporary. It has a data
duration of SYS$TRANSACTION. Data is removed at the end of this period.
Note: The DURATION column in dba_tables or user_tables or all_tables can have a
value of SYS$SESSION or SYS$TRANSACTION. These values indicate the duration of a
temporary table. SYS$SESSION implies the rows are preserved for the duration of the session
while SYS$TRANSACTION indicates that the rows are deleted after COMMIT.
The Condition that we had defined under INV ERES Item Creation viz., ORGANIZATION_CODE
in {M1,M2,M3,V1} is available under the Conditions tab and we use the same in defining our
Rule INV Misc Receipt in M1, M2 and M3 (Fig 26).
Fig 26. The Rule for performing a Miscellaneous Receipt in the ERES Framework
The Rule Variables have been set up as EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
We are calling for E-Signatures from our five approvers to ratify a Miscellaneous Receipt
Transaction.
27
Inventory > Transactions > Miscellaneous Transactions

Select organization M3.
Perform a Miscellaneous Receipt of 50 units of the item SRCJ200/20 into the Stores
subinventory. Item SRCJ200/20 would be introduced in the section where we implement ERES in
Oracle Quality. Upon saving the transaction, the List Of Signers web page opens up.
Once each approver has approved the transaction and validated the same with electronic
signatures, navigate to the Evidence Store using the ERES User responsibility.
ERES User > Evidence Store
Fig 27. The E-Record for Miscellaneous Receipt in the Evidence Store
The E-Record for Miscellaneous Receipt is available in the Evidence Store (Fig 27).
The E-Record opens up as shown in Fig 28.
28
Fig 28. The E-Record for Miscellaneous Receipt
Refer the Demo 014 INV ERES Miscellaneous Receipt in Note 336709.1 for a step-bystep review
E-RECORDS AND E-SIGNATURES IN ORACLE BILL OF MATERIALS
There are four business events that are seeded and supported for ERES.
Fig 29. Business Events in Oracle Bill of Materials that are seeded and supported for ERES
We shall demonstrate implementation of ERES with each of these four business events.
BOM Bill of Materials Create
Using sysadmin login, ensure that the business event and its subscription are enabled.
Select the Transaction Type BOM ERES Bill of Materials Creation.
FROM mtl_parameters
where organization_id = (select organization_id
from BOM_BILL_OF_MATERIALS
WHERE bill_sequence_id = TO_NUMBER(:transactionId))
Under the Conditions tab, we define a new Condition:
ORGANIZATION_CODE in {M1,M2,M3}
For the business events in Inventory, we had modified this to include V1 as well.
29
Under the Rules tab, we define the Rule shown in Fig 30.
Fig 30. The Rule for the BOM Creation Event

For Transaction Name = BOM ERES Bill of Materials Creation
and Rule = BOM Creation in M1, M2 and M3, we set EREC_REQUIRED = Y and
ESIG_REQUIRED = N.
Thus BOM Creation will generate an E-Record but will not call for E-Signatures.
We now navigate to the Bill of Materials creation form, select M1 as our organization and define a
BOM for the item Humidifier.
Responsibility; Manufacturing and Distribution Manager
Bills Of Materials > Bills > Bills
Having defined the BOM and upon saving our work, we navigate to Bills > eRecord Details to
review the E-Record created (Fig 31).
We are now led to the Evidence Store where the E-Record for BOM Creation is available (Fig
32). Clicking on the link below the Event Name, will open the E-Record.
The complete E-Record is shown in Fig 33.
30
Fig 31. Accessing the E-Record for the Bill of Material created
Fig 32. The newly created E-Record in the Evidence Store
31
32
Fig 33. The E-Record for Bill of Material Creation

We now change our organization to M3. Since the item Humidifier is assigned to M3 as well, we
copy the BOM of the Humidifier from M1 to M3, using Tools > Copy Bill from. We now add an
attachment to this BOM using the paper clip Attachments icon on the menu bar. We save the
BOM.
Navigate to Bill > eRecord Details as shown in Fig 31. Open the E-Record from the evidence
Store.
33
Fig 34. E-Record Header for a Bill of Material with an Attachment

The E-Record opens with the Attachment we had uploaded onto the BOM, when creating the
same in M3 (Fig 34).
Note: The Attachment utility in Oracle E-Records is used to attach business entities,
documents, spreadsheets, images or videos to an E-Record. It is configurable by document
category and it is set up in the XML map. Essentially, this allows the developers of Oracle ERecord events to include attachments of specified document categories as part of the E-Record
approval process and to be saved with the E-Record once all the approvals have been obtained.
Attachments have not been enabled for all of the seeded, supported E-Record events in Oracle
Applications at this point. However, all the four business events in Fig 29, support Attachments
for their E-Records.
Refer the Demo 021 BOM ERES Bill of Materials Create in Note 336709.1 for a step-bystep review
BOM Bill of Materials Update
Here, we use the same Attribute and Condition as was used in BOM Creation. The structure of
the Rule too remains the same (composed of the same Attribute and Condition). Only this time,
the Rule has a different name: Bill Updation in M1, M2 and M3.
The Rule Variables are again set as EREC_REQUIRED = Y and ESIG_REQUIRED = N.
We now navigate to the Bill of Materials Creation form in organization M1, and query for the BOM
of Humidifier. We change the Quantity of Heating Coils from 4 to 5. We save our work ant then
navigate to Bills > eRecord Details.
Fig 35. The E-Record in the Evidence Store

The E-Record for Bill of Materials Update is available in the Evidence Store (Fig 35).
34
35
36
Fig 36. E-Record for Bill of Materials Update

The E-Record body captures the new component quantity (Fig 36).
Refer the Demo 022 BOM ERES Bill of Materials Update in Note 336709.1 for a step-bystep review
BOM Routing Create
Select the Transaction Type BOM ERES Operational Routing Creation.
Click on the Rules tab.
In a departure from our previous setup, we are simply going to reference the Rule we had created
for BOM ERES Bill of Materials Creation. This implies that we will create a copy of the Rule for
our current Transaction Type.
Under the Rules tab, click on the Add Usage button. In all our previous cases we had used the
Add Rule and Usage button. Next, select the option add usage for rule used by another
transaction type. When prompted to select the Transaction Type, select BOM ERES Bill of
Materials Creation from the drop down list. The Rule BOM Creation in M1, M2 and M3 defaults
since it is the only rule defined for BOM Creation. The Rule is copied for the current Transaction
Type.
The Rule Variables are set as EREC_REQUIRED = Y and ESIG_REQUIRED = Y. We want
routing creation to be approved through E-Signatures.
Bills Of Materials > Routings > Routings
We navigate to the Routing Creation form and select organization M3. We define a single
operation routing for the item SCJ180/20. Upon saving our work, we are presented with the List
Of Signers page. This business event does not permit deferred signature. The signatures have
to be made in online mode. Once the signatures and the approval from the individual signers has
37
been received, we navigate to Actions > eRecord Details. We find the E-Record in the Evidence
Store (Fig 37).
Fig 37. The E-Record for Routing Creation

Open the E-Record (Fig 38).
38
Fig 38. E-Record for Routing Creation
Fig 39. The E-Record Signature Details
Refer the Demo 023 BOM ERES Operational Routing Creation in Note 336709.1 for a
step-by-step review
BOM Routing Update
Select the Transaction Type BOM ERES Operational Routing Update.
As in the case of BOM Routing Creation, we are simply going to reference the Rule we had
created for BOM ERES Bill of Materials Creation. The steps to be followed are the same as
described in BOM Routing Creation.
The Rule Variables have been set as EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
39
Bills Of Materials > Routings > Routings

We navigate to the Routing Creation form in organization M3 and requery the routing for
STJ180/15. Here, we change the Usage of the Resource LATHE from 0.25 to 0.5. Upon saving
our work, we are presented with the List Of Signers page. This business event does not permit
deferred signature. The signatures have to be made in online mode. Once the signatures and the
approval from the individual signers has been received, we navigate to Actions > eRecord
Details. We find the E-Record in the Evidence Store (Fig 40).
Fig 40. The E-Record for Routing Updation

When we open the E-Record, we find the new Usage quantity captured in the E-Record (Fig 41).
40
Fig 41. The E-Record for Routing Updation

The E-Signature details captured at the bottom of the E-Record are shown in Fig 42.
Fig 42. The E-Signature details captured in the E-Record for Routing Updation
Refer the Demo 024 BOM ERES Operational Routing Update in Note 336709.1 for a
step-by-step review
E-RECORDS AND E-SIGNATURES IN ORACLE ENGINEERING
When FDA was working with Industry to propose the current Quality System Regulation the question of at
what point in the development process the Design Control requirements take effect loomed large in the
discussions. Industry expressed its legitimate concerns that documenting a process before it is ready (e.g.,
before it has taken on a recognizable shape) can be harmful to the development process. Much of the very
early creative design work is done very informally, and the personalities of the people doing that work
incline them to resist recording it before it they believe it is truly ready to be recorded. The agency believed
41
that a good design control program that documents the decisions made in the process would make it
difficult for a design error to propagate through the entire process.
Industry agreed with FDAs fundamental concept, but was concerned that if documentation were required
too early in the process, the free flow of creative ideas could be diminished, thus stifling innovation. There
are clear benefits to the use of Design Control in an R&D setting that leads directly to manufacturing.
Nevertheless, one must keep focused on the ultimate goal, which is the development and production of a
commercially viable, safe product. The initial creativity of the designers and engineers is critical to the
success of such endeavors.
Ultimately, FDA settled on a compromise position that satisfied regulatory needs and also satisfied
industrys needs. Each company must define within its quality system the point at which Design Control
becomes effective. This enabled the industry to set the entry point late enough that the design is beyond the
point of daily change, yet FDA was comfortable that the information needed to determine how the company
approached its design and the justification for major design decisions would be recorded.
Industry Coalition on 21 CFR Part 11
Docket 00D-1541, June 2002
There are ten business events that are seeded and supported for ERES in Engineering.
Fig 43. Business Events in Oracle Engineering that are seeded and supported for ERES
We shall demonstrate implementation of ERES with the following five business events:
Copy To Manufacturing
Transfer to Manufacturing
ECO Creation
ECO Schedule
ECO Implementation
Transfer To Manufacturing
Select the Transaction Type ENG ERES Transfer To Manufacturing.
42
from eng_revised_items_temp
where temp_id = :transactionId
The table eng_revised_items_temp is a global temporary table. The current session is able
see data that it placed in the table but other sessions cannot. Data in the table is temporary. It
has a data duration of SYS$SESSION. Data is removed at the end of this period.
The Condition we had defined earlier under BOM and Inventory, exists under the Conditions tab,
viz., ORGANIZATION_CODE in {M1,M2,M3,V1}.
Under the Rules tab, we define the Rule shown in Fig 44.
Fig 44. The Rule for the Engineering Transfer to Manufacturing Event
For Transaction Name = ENG ERES Transfer to Manufacturing
and Rule = ENG Transfer to Mfg for Prototypes in V1, M1, M2 and M3, we set the Rule Variables
as EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
Using the Manufacturing and Distribution Manager Responsibility, we now navigate to
Engineering > Prototypes > Master Items
In Item Master org V1, we define an item Universal Humidifier Pad.
We assign this item to M1, M2 and M3.
Engineering > Prototypes > Transfer to Manufacturing
Enter the item Universal Humidifier Pad and click on the Transfer button.
This opens the web page with the List Of Signers.
Deferred signature is not allowed in this event, all signatures have to be executed online.
Once the E-Signature process is complete and the Transfer to Manufacturing has been approved
by all the signers, switch to the ERES User responsibility. This will open the Evidence Store.
Search for E-Records with the Event Name Transfer To Manufacturing. Our E-Record is
available in the Evidence Store (Fig 45).
43
Fig 45. The E-Record available in the Evidence Store

Open the E-Record seen in Fig 45.
Fig 46. The E-Record for Transfer To Manufacturing
Refer the Demo 032 ENG ERES Transfer to Manufacturing in Note 336709.1 for a stepby-step review
44
Copy To Manufacturing
Select the Transaction Type ENG ERES Copy to Manufacturing.
Once again, we are simply going to reference the Rule we had created for ENG ERES Transfer
to Manufacturing. This implies that we will create a copy of the Rule for our current Transaction
Type.
Under the Rules tab, click on the Add Usage button (instead of the Add Rule and Usage
button). Next, select the option add usage for rule used by another transaction type. When
prompted to select the Transaction Type, select ENG ERES Transfer to Manufacturing from the
drop down list. The Rule ENG Transfer to Mfg for Prototypes in V1, M1, M2 and M3 defaults
since it is the only rule defined for Engineering Transfer to Manufacturing. The Rule is copied for
the current Transaction Type.
The Rule Variables are set as EREC_REQUIRED = Y and ESIG_REQUIRED = Y. We want Copy
to Manufacturing to be approved through E-Signatures.
Engineering > Prototypes > Items > Master Items
Using the Engineering Master Items form in organization V1, we create a new item, Water Tray.
We assign this item to organizations M1, M2 and M3.
Engineering > Prototypes > Copy to Manufacturing
Select the organization as M3.
Fig 47. Copying item Water Tray to Manufacturing

Copy the item to Manufacturing as shown in Fig 47.
The moment we click on the Copy button, the List Of Signers page is launched (Fig 48).
45
After the signing process completes, and all the approvers approve the transaction, navigate to
the Evidence Store using the ERES User responsibility. There are three E-Records created as a
result of the Copy to Manufacturing transaction (Fig 49).
Fig 48. List of Signers configured to approve the Copy to Manufacturing Transaction
Fig 49. Three E-Records created as a result of the Copy to Manufacturing transaction
The first E-Record was created when we defined the item Water Tray in the Engineering
Prototypes Master Items form. This E-Record has the E-Record ID 28068 (Fig 49). This E-Record
was created because we have the event INV ERES Item Creation enabled.
The second E-Record was created as a result of the actual Copy to Manufacturing transaction.
This E-Record has the E-Record ID 28069 (Fig 49).
The third E-Record was created when the item Water Tray was copied into Manufacturing in M3
organization under the name Standard Water Tray. This E-Record creation too was triggered
because the event INV ERES Item Creation is enabled.
When we open the E-Record for Copy To Manufacturing (Fig 50), we find the necessary
information encapsulated in the field Identifier Value. The field displays Water Tray-M3Standard Water Tray, which implies that, the Engineering item Water Tray was copied into
organization M3 under the name Standard Water Tray. Also, E-Record ID 28070 appears as the
Child Record of the current E-Record.
46
Fig 50. The E-Record for Copy to Manufacturing
Refer the Demo 031 ENG ERES Copy to Manufacturing in Note 336709.1 for a step-bystep review
47
ECO Creation, Approval and Implementation

We shall now embark upon a journey through three business events in the Engineering cycle:
ECO Creation, ECO Approval and ECO Implementation. Enabling these three events and their
subscriptions, defining their Rules in Approvals Management and defining the Rule Variables for
these events, has all been covered in a single demo 030 ENG ERES ECO Setup.
Note: Unlike ECO Creation (or any other ECO business event), ECO Approval does not exist
as a separate event or Transaction Type in AME. ECO Approval is triggered as a result of ECO
Creation but ECO Approval does not make use of AME. To implement ERES in ECO Approval,
the (seeded) ERES Approval Process must be associated with the concerned ECO through
Engineering Setup. The list of approvers must also be defined in Engineering. These setup steps
are contained in 030 ENG ERES ECO Setup. Nonetheless, we shall cover the essentials here.
Engineering > Setup > Priorities
Define a Priority 21CFR11 (Fig 51).
Fig 51. Defining a New Priority

Engineering > Setup > Change Types
Define a new Change Type (Fig 52).
Fig 52. Defining a New Change Type
48
Engineering > Setup > Change Types > (B) Processes

Click on the Processes button.
In the Change Type Processes window that opens up, select from the LOV, the Priority
21CFR11 that we had defined in the previous step. From the LOV, select the Process ERES
Approval Process (Fig 53).
Fig 53. Associating the seeded Workflow ERES Approval Process to the Priority and the
Change Type
Engineering > Setup > Approval Lists
Since the business event ECO Approval does not use AME, we will not be able to use the
Approval Group that we had defined in AME in Demo 00-A Step 1 (Fig 1). We would therefore
recreate the same Approval Group as an Approval List in Engineering (Fig 54).
Fig 54. List of Approvers for ECO Approval
Refer the Demo 030 ENG ERES ECO Setup in Note 336709.1 for a step-by-step review
ECO Creation
Select the Transaction Type ENG ERES ECO Creation.
Under the Attributes tab we select the following three seeded Attributes:
(i) PRIORITY. This is an Attribute with a Dynamic Usage defined by the SQL:
select priority_code
from eng_engineering_changes
where change_id = to_number(:transactionId)
49
If we query the instance for priority codes (Fig 55), we find our Priority 21CFR11 available.
Fig 55. Querying the Priority Code we had defined previously

We shall use the PRIORITY Attribute to create a Condition in AME for ECO Creation.
(ii) ORGANIZATION_CODE. This is an Attribute with a Dynamic Usage defined by the SQL:
from mtl_parameters
where organization_id = (select organization_id
from eng_engineering_changes
where change_id = to_number(:transactionId))
The Condition we had defined earlier under BOM and Inventory (using this Attribute), exists under
the Conditions tab: ORGANIZATION_CODE in {M1,M2,M3,V1}.
(iii) ECO TYPE. This is an Attribute with a Dynamic Usage defined by the SQL:
select ecotvl.type_name
from eng_engineering_changes eec, eng_change_order_types_vl ecotvl
where eec.change_id = to_number(:transactionId)
and eec.change_order_type_id = ecotvl.change_order_type_id
If we modify this query slightly and use it to query the instance (Fig 56), we find the Change Type
that we had defined previously (Fig 52), as available.
We shall use the ECO TYPE Attribute to create a Condition in AME for ECO Creation.
50
Fig 56. Querying the ECO Change Types available in our instance
Under the Conditions tab we create the conditions involving Attributes ECO TYPE and
PRIORITY (Fig 57). The asterisk (*) associated with the Condition using ORGANIZATION_CODE
denotes that this Condition has been used by other Transaction Types in AME.
Fig 57. The Conditions to be used for our ECO related business events
Under the Rules tab, we define the Rule as shown in Fig 58.
Fig 58. The Rule for ECO Creation
51

For Transaction Name = ENG ERES ECO Creation and Rule = ENG ECO Creation in V1, M1,
M2 and M3, we set the Rule Variables as EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
Engineering > ECOs > ECOs
We define ECO = SMECO30
Select from the LOV, Type = 21 CFR Part 11
Select from the LOV, Priority = 21CFR11
Upon doing so, The Approval List field becomes mandatory, the Approval Process defaults as
ERES Approval Process (seeded) and the Approval Status field defaults as Not submitted for
approval. This occurs because of the setup steps demonstrated in Fig 51, Fig 52 and Fig 53.
Select from the LOV, Approval List = PRB.
We enter the Description detailing what we wish to achieve through the ECO (Fig 59).
Fig 59. The Description explaining the purpose of creating this ECO
Now, click on the Revised Items button.
This opens the Revised Items form.
We enter Item = Humidifier and tab out.
Now click on the Components button.
This opens the Revised Components screen.
In the Action field, we select Add from the LOV.
We are going to add a component to our Bill for the Humidifier in organization M3.
We add a component Standard Water Tray in Item Sequence 40 in the Bill for the Humidifier.
Close the Revised Components window and the Revised Items window.
We are back to the main ECO screen.
We are going to attach some files to this ECO.
In the toolbar menu, click on the paper clip icon meant for Attachments.
We upload two files as attachments. One contains the diagram of the Humidifier and the other
contains a photograph of the Water Tray.
Once the attachments have been successfully uploaded, we click on the Submit button.
The List Of Signers web page is launched with the Event Name as ECO Creation.
Deferred signature is not allowed in this event.
The approvers read the document and validate it with their E-Signatures one-by-one in online
mode. The attachments are available on the E-Record being approved and signers can open and
view the attachments before endorsing the document with their E-Signature.
When approvals for all the five approvers have been obtained, the Approval Status field in the
ECO changes from Not submitted for approval to Approval requested.
Navigate to Actions > eRecord Details from the toolbar menu. This leads us to the Evidence
Store.
52
The E-Record for ECO Creation is visible in the Evidence Store (Fig 60).
Fig 60. The E-Record for ECO Creation in the Evidence Store
Fig 61 shows the complete E-Record.
53
54
Fig 61. The E-Record for ECO Creation

Now, in the ECO creation form, navigate to Tools > View Approvals
The Approval History window opens up showing
Approval Process = ERES Approval Process
Submit Date = 13-SEP-2005 00:13:19
Now, click on the Status button.
This launches the web page showing the Workflow Activities History (Fig 62).
55
Fig 62. A snapshot of the Workflow Activities History concerning our ECO
Engineering > ECOs > Notification
Fig 63. The ECO Approval Notification awaiting my approval

As the Requester for the ECO Approval process, I find the ERES Approval Notification in my
Worklist (Fig 63).
Fig 64. The ERES Approval Notification (header portion) awaiting approval of the First
Approver Saumit Mandal
When the first approver (Saumit Mandal) approves the ECO and validates his decision with his ESignature, a notification is sent to the second approver Andre Wajda (Fig 65).
56
Fig 65. The ERES Approval Notification waiting upon the Second Approver Andre Wajda
When the second approver (Andre Wajda) approves the ECO and validates his decision with his
E-Signature, a notification is sent to the third approver Jean Renoir (Fig 66).
Fig 66. The ERES Approval Notification waiting upon the Third Approver Jean Renoir
This process continues till the fifth and the final approver, Ray Satyajit approves and signs the
record. Thereupon, along with the E-Record for ECO Creation, the E-Record for ECO Approval
also gets archived in the Evidence Store (Fig 67).
Fig 67. E-Records for ECO Creation and ECO Approval in the Evidence Store
Fig 68 shows the complete E-Record for ECO Approval
57
58
Fig 68. The E-Record for ECO Approval
Refer the Demo 033 ENG ERES ECO Creation Approval in Note 336709.1 for a stepby-step review
59
ECO Implementation
The event and its subscription have been enabled.
Select the Transaction Type ENG ERES ECO Implementation.
The Attributes and the Conditions would remain the same as what we had employed in ECO
Creation. Therefore, we shall not create a new Rule but will simply create a new Usage out of the
Rule we had defined for ECO Creation. Under the Rules tab, click on the Add Usage button.
Next, select the option add usage for rule used by another transaction type. When prompted
to select the Transaction Type, select ENG ERES ECO Creation from the drop down list. The
Rule ENG ECO Creation in V1, M1, M2 and M3 defaults since it is the only rule defined for ECO
Creation. The Rule is copied for the current Transaction Type.
The Rule Variables are set as EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
Responsibility: Manufacturing and Distribution Manager Responsibility
Engineering > ECOs > ECOs
Query the ECO SMECO30.
Select Tools > Implement
We get the following message at the bottom of the screen:
Submitted request 2790579 for ENCACN ECO/Revised Item Cannot be Updated While it is
being Implemented.
Navigate to the View > Requests screen
Ensure that the request for ECO Implementation completes in Normal status.
Now return to the ECO creation screen.
We find that the ECO is now in Scheduled status.
Now, navigate to Actions > eRecord Details
This leads us to the Evidence Store where we find three E-Records associated with this ECO (Fig
69).
Fig 69. The ECO Implementation E-Record in Pending Status

If we open the ECO Implementation E-Record, we find that signatures are pending from the listed
approvers (Fig 70).
60
Fig 70. The E-Record for ECO Implementation is yet to be reviewed and signed
Engineering > ECOs > Notification
The following Notification is available (Fig 71)
Fig 71. Notification received by approver for validating the E-Record on ECO
Implementation
The moment the first approver approves the E-Record and validates it with his E-Signature, a
notification is sent to the second approver, and so on.
Fig 72. The ECO Implementation E-Record after it is approved by all approvers
The E-Record displays a status as Complete, after it has been approved and signed by all the
approvers. Fig 73, displays the complete E-Record for ECO Implementation.
61
62
63
Fig 73. The complete E-Record for ECO Implementation

The ECO will now display the status of Implemented.
Note: Implementing the ECO adds the component Standard Water Tray in Item Sequence 40
in the BOM for the Humidifier. This updation of the Bill triggers an E-Record (E-record ID =
33083) as seen in Fig 73, since the event BOM Bill of Materials Update is in Enabled status. The
E-Record for the Bill Updation appears as a Child E-Record for the ECO Implementation ERecord.
Refer the Demo 034 ENG ERES ECO Implementation in Note 336709.1 for a step-bystep review
E-RECORDS AND E-SIGNATURES IN WORK IN PROCESS
There are three business events that are seeded and supported for ERES.
Fig 74. Business Events in Work in Process that are seeded and supported for ERES
We shall demonstrate implementation of ERES with the following two business events:
WIP Job Assembly Move
WIP Job Assembly Completion
WIP Job Assembly Move
Select the Transaction Type WIP ERES Job Assembly Move.
Under the Attributes tab, we select the seeded Attribute WIP_MOVE_TRANSACTION_TYPE.
select wip_move_validator.move_txn_type(wmt.transaction_id)
from wip_move_transactions wmt
where wmt.transaction_id = :transactionId
64
Fig 75. The Text Values to use, if the Attribute WIP_MOVE_TRANSACTION_TYPE is used
in creating a Condition in AME
Fig 75, explains the logic for defining Conditions based on our chosen Attribute
WIP_MOVE_TRANSACTION_TYPE. Since we would be using a simple move transaction for
demonstrating ERES for the business event WIP Job Assembly Move, we shall use the value
Move transaction for creating our condition.
Approvals Management Administrator > Approvals > (T) Conditions
Click on the Add a Condition button.
We create the Condition shown in Fig 76.
Fig 76. Our Condition for triggering ERES for the WIP Assembly Move business event
Approvals Management Administrator > Approvals > (T) Rules
Using the Condition defined in Fig 76, we define our Rule (Fig 77).
65
Fig 77. Our Rule for the WIP Assembly Move business event
For Transaction Name = WIP ERES Job Assembly Move and Rule Name = WIP Job Move
Rule, we specify EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
WIP > Move Transactions > Move Transactions
Select the organization M3.
We pick an existing Released Job and move 2 units from Operation 10 Queue to Operation 10 To
move. When we click on the button Save, we get the following pop-up (Fig 78).
Fig 78. Pop-up indicating association of a mandatory Collection Plan defined in Oracle
Quality
This pop-up comes because a collection plan defined in Oracle Quality (discussed under the
section E-RECORDS AND E-SIGNATURES IN ORACLE QUALITY) has been made mandatory
for data collection during WIP Move transactions. We enter the quality results and once again
click on the Save button. This launches the List Of Signers page. This business event does not
allow deferred signature. The signers approve and sign the record online.
Fig 79. The E-Record for WIP Job Assembly Move in the Evidence Store
Fig 80, shows the complete E-Record for this business event.
66
67
Fig 80. The E-Record for WIP Job Assembly Move

Note: We had entered Quality Results for the two units of item SCJ180/20, that were moved
from Queue of Operation 10 to To move of Operation 10. These Quality Results are clearly
captured in the E-Record in Fig 80.
Refer the Demo 041 WIP ERES Job Assembly Move in Note 336709.1 for a step-bystep review
WIP Job Assembly Completion
Select the Transaction Type WIP ERES Job Assembly Completion.
Under the Attributes tab, we select the seeded Attribute WIP_SUBINVENTORY.
select mmt.subinventory_code
from mtl_material_transactions mmt
where transaction_id in (select transaction_id
68
from mtl_material_transactions
where transaction_set_id =
substr(:transactionId, 1, (instr(:transactionId,
'-')-1))
and transaction_source_id =
substr(:transactionId, (instr(:transactionId, '')+1), (instr(:transactionId, '-', 1, 2)(instr(:transactionId, '-')+1)))
and transaction_type_id in (44,17)
Note: The Condition we had defined for the event WIP Assembly Move viz.,
WIP_MOVE_TRANSACTION_TYPE in {Move transaction} is not available for the the event
WIP Job Assembly Completion as the move transaction type attribute does not apply to WIP
Completion. Thus under the Attributes tab, the Attribute WIP_MOVE_TRANSACTION_TYPE is
not available for the event WIP Job Assembly Completion. Instead a new (seeded) Attribute
WIP_COMPLETION_TRANSACTION_TYPE appears. We would however, not be using this
attribute.
Click on the Add a Condition button.
We create the Condition shown in Fig 81.
Fig 81. Our Condition for triggering ERES for the WIP Job Assembly Completion business
event
Using the Condition defined in Fig 81, we define our Rule (Fig 82).
69
Fig 82. Our Rule for the WIP Job Assembly Move business event
The Rule in Fig 82, implies that ERES would be triggered if an assembly is completed into the
FGI or the Stores subinventory.
For Transaction Name = WIP ERES Job Assembly Completion and Rule Name = WIP
Assembly Completion in Stores & FGI subinventories, we specify EREC_REQUIRED = Y and
ESIG_REQUIRED = Y.
WIP > Material Transactions > Completion Transactions
We select a pre-defined job that has one unit of item SCJ180/20 as Available to Complete.
Click on the Continue button. This opens the WIP Assy Completion screen.
Enter Subinventory = Stores, UOM defaults as Ea, enter Quantity = 1.
Since this item SCJ180/20 is a serial controlled item, click on the Lot/Serial button. This opens
the Serial Entry screen. Enter the Start Serial Number and the End Serial Number as 123.
Click on the Done button. We are back to the WIP Assy Completion screen. Click on the Done
button here. We are brought back to the main Completion Transactions screen and a message
is displayed at the bottom of the screen (Fig 83).
Fig 83. Message at the bottom indicating that the ERES setup is being validated for the
Assembly Completion transaction
After a moments wait, the List Of Signers page is launched. Deferred signature is not available
for this event. The signers put their electronic approval in online mode.
Once the approvals and electronic signatures are complete, navigate to
Fig 84. The E-Record is available in the Evidence Store
70
The complete E-Record is detailed in Fig 85.
Fig 85. The E-Record for WIP Job Assembly Completion
71
Refer the Demo 042 WIP ERES Job Assembly Completion in Note 336709.1 for a stepby-step review
E-RECORDS AND E-SIGNATURES IN ORACLE QUALITY
There are twenty-two business events that are seeded and supported for ERES.
Fig 86. Business Events in Oracle Quality that are seeded and supported for ERES
We shall demonstrate implementation of ERES with the following four business events:
QA ERES Collection Element Creation
QA ERES Specification Creation
QA ERES Collection Plan Creation
QA ERES Result Creation
72
Case Summary
A specific business case has been employed to setup the required business events in Oracle
Quality for the purpose of demonstrating the requisite ERES setup. This business case has been
adopted verbatim from the business case detailed in the white paper A Guide to Oracle Quality
published on the Metalink under Note 248331.1. Therefore, to save on space for the current
discussion, we have chosen not to elaborate on the same business scenario in this paper. Like in
all our previous sections and to retain consistency in the style of presentation we shall directly
launch ourselves into a transaction-by-transaction analysis of ERES implementation.
9
QA ERES Collection Element Creation

Using sysadmin login ensure that the business event and its subscription are enabled.
Select the Transaction Type QA ERES Collection Element Creation.
Select the seeded Attribute QA_ELEMENT_TYPE.
select char_type_meaning
from qa_chars_v
where char_id = :transactionId
If I query my instance using the above SQL, for collection element types I find some values (Fig
87).
Fig 87. Querying my instance for Collection Element Types

However, we are aware that Oracle Quality provides us with three predefined collection element
types, Attribute, Variable and Reference Information. Each of these has been explained in
detail in Note 248331.1. We shall define our Condition and Rule such that whenever a collection
element of type Variable or Reference Information is created, ERES would be triggered.

Click on the Add a Condition button. Using the QA_ELEMENT_TYPE Attribute, we define a
Condition as seen in Fig 88.
73
Fig 88. The Condition for launching ERES for Quality Collection Element Creation
Here, we create the Rule depicted in Fig 89.
Fig 89. The Rule for triggering ERES for Quality Collection Element Creation
For Transaction Name = QA ERES Collection Element Creation and Rule Name = QA
Collection Element Creation we set EREC_REQUIRED = Y and ESIG_REQUIRED = N.
Quality > Setup > Collection Elements
We are now in the Collection Elements page. Here, we enter the values as follows:
Collection Element = SHAFT LENGTH
Select from the LOV, Element Type = Variable
Data Type = Number
Reporting Length = 5
Decimal Precision = 2
UOM = MM
When we place the cursor on the Default Value field, Specification Limits window opens up.
Here, we enter the values:
74
Target Value = 180

Specification Range = 179 182
Reasonable Range = 178.5 183.5
We save our work.
Now, navigate to Tools > eRecord Details.
The E-Record is available in the Evidence Store (Fig 90).
Fig 90. The E-Record for Collection Element Creation

The complete E-Record for the Collection Element Creation is displayed in Fig 91.
Fig 91. The E-Record for Quality Collection Element Creation
75
In the demo 051 QA ERES Collection Element Creation, we have gone further and defined a
collection element of Type Reference Information, to demonstrate the creation of E-Record for
that collection element as well, in accordance with our Rule (Fig 89).
Refer the Demo 051 QA ERES Collection Element Creation in Note 336709.1 for a stepby-step review
QA ERES Specification Creation
Select the Transaction Type QA ERES Specification Creation.
Select the seeded Attribute QA_ORGANIZATION_CODE.
from qa_eres_specs_v
where spec_id = :transactionId
Click on the Add a Condition button. Using the QA_ORGANIZATION_CODE Attribute, we
define a Condition as seen in Fig 92.
Fig 92. The Condition for Creation of a Specification in Quality

Approvals Management > Approvals > (T) Rules
Using the Condition created above, we define our Rule (Fig 93).
76
Fig 93. The Rule for Creation of a Specification in Oracle Quality

For Transaction Name = QA ERES Specification Creation and Rule Name = QA Specification
Creation in M1, M2 and M3, we set EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
Quality > Setup > Specifications
Select M3 as the organization.
In the Specifications screen, we define a Specification as follows.
Specification Name = SPEC_SCJ180/20
Item = SCJ180/20
We now click on the Spec Elements button. In the Specification Elements window that opens
up we enter the details as displayed in Fig 94.
Fig 94. Associating a Specification Element and a Range of with our Specification
We save our work.
The Specification is saved in Status = Draft.
Navigate to Tools > Request e-signature approval
This launches the List Of Signers page.
Deferred Signature is allowed for this event. We use this utility.
When the first signer Saumit Mandal approves and signs the E-record and then clicks on the
Submit button, a notification is sent to the next signer Andre Wajda (Fig 95).
77
Fig 95. Notification received by the second signer Andre Wajda

Each signer responds to the notification by approving it and the notification gets forwarded to the
next approver and so ontill the last approver Ray Satyajit approves and signs it. Now, if the first
signer or the Initial Requester opens his notification, he finds the following (Fig 96).
Fig 96. Notification indicating that the Specification SPEC_SCJ180/20 has been approved
Fig 97. The Complete Approval Notification

If we query the Specification SPEC_SCJ180/20, we find the Specification now has a Status =
Approved for Use.
Tools > eRecord Details
The E-Record is available in the Evidence Store (Fig 98).
Fig 98. The E-Record for Specification Creation
78
Fig 99. The E-Record for Specification Creation

Now, in the Specifications creation form, we click on the Org Assignments button.
This opens the Organization Assignments form for Specifications.
Note: Since the item SCJ180/20 was created in V1 and assigned to M1, M2 and M3 only, we
find M1, M2 and V1 in the Specification Organization Assignments form (we are already in M3).
79
We proceed to assign the specification we created in M3 to M1 and M2. The system adds the
organization code as a suffix to the specification name to create the name of the specification in
that organization. For example, the Specification gets the name SPEC_SCJ180/20 M1 in the M1
organization.
Select M1 as the organization.
Query for the Specification SPEC_SCJ180/20 M1.
Tools > eRecord Details
Fig 100. An E-Record created for the Specification SPEC_SCJ180/20 M1

The Specification assignment created new Specifications in the organizations to which the
assignments were done. This in turn creates E-Records for those specifications (Fig 100).
Refer the Demo 052 QA ERES Specification Creation in Note 336709.1 for a step-bystep review
QA ERES Collection Plan Creation
Select the Transaction Type QA ERES Collection Plan Creation.
Select the seeded Attribute QA_PLAN_TYPE.
select plan_type_meaning
from qa_eres_plans_v
where plan_id = :transactionId
If I query my instance using the above SQL, for collection element types I find some values (Fig
101).
80
Fig 101. The values that can be associated with the Attribute QA_PLAN_TYPE
Approvals Management > Approvals > (T) Conditions
Using the Attribute QA_PLAN_TYPE, we define a new Condition as shown in Fig 102.
Fig 102. A new Condition using the Attribute QA_PLAN_TYPE

Approvals Management > Approvals > (T) Rules
We would be using two Conditions for defining our Rule for this business event (Fig 103).
81
Fig 103. The Rule for Quality Collection Plan Creation

For Transaction Name = QA ERES Collection Plan Creation and Rule Name = QA Collection
Plan Creation for WIP & Receiving, we set EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
Quality > Setup > Collection Plans
We create a Collection Plan as seen in Fig 104.
Fig 104. Defining a Collection Plan of Type WIP Inspection
82
The moment we save our work, the List of Signers page is launched. Deferred signature is not
available for this event. After all the signers approve and validate the collection plan with their
electronic signatures, the rest of the information can be entered in the Collection Plan. This would
include
selecting the Values for the Attribute type collection element FAILURE CODE
entering the Actions for the Reference Information type collection element MY ITEM
entering the Actions for the Variable type collection element SHAFT LENGTH
entering the relevant information in the Quality Collections Transactions form (Fig
105).
Fig 105. Entering the transaction details that would trigger the call for data collection for
this Collection Plan
Now, navigate to Tools > eRecord Details.
The E-Record for this Collection Plan is available in the Evidence Store (Fig 106).
Fig 106. The E-Record for the Collection Plan available in the Evidence Store
Fig 107 displays the complete E-Record for the Collection Plan 01 SCJ COLLECTION PLAN.
83
84
Fig 107. The complete E-Record for the Collection Element
Refer the Demo 053 QA ERES Collection Plan Creation in Note 336709.1 for a step-bystep review
QA ERES Result Creation
Select the Transaction Type QA ERES Result Creation.
85
For this business event, we shall use the same condition that we had defined in Fig 92, for the
event Quality Specification Creation i.e., QA_ORGANIZATION_CODE in {M1,M2,M3}. Using this
condition, we define the Rule shown in Fig 108.
Fig 108. The Rule for triggering ERES during Result Creation in Oracle Quality
For Transaction Name = QA ERES Result Creation and Rule Name = QA Result Creation in
M1, M2 and M3, we set EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
Quality > Setup > Collection Plans
Select organization M3 and query for the Collection Plan we have just created: 01 SCJ
COLLECTION PLAN. Here we reset the field Record Option from the (default) value of Per Row
to Per Collection (Fig 109). We save our work.
Fig 109. Choosing to have E-Records created for Results entered against each Collection
Plan as against each row of entry in the Quality Results
Setting the Record Option to Per Row implies that E-Records would be created for each row of
Result entered for the Collection Plan. So as many rows entered and committed in the Result, so
many E-Records created. Setting the Record Option to Per Collection would simplify the task for
the approvers to the extent that only one E-Record would be created for (as many rows of) Result
entered against the Collection Plan.
Quality > Results > Entry > Enter Quality Results
86
In the Enter Quality Results form that opens up, click on the Find Plan button. In the list of
Collection Plans that pops up, select the Collection Plan we had defined in the previous event, 01
SCJ COLLECTION PLAN.
Having done so, we are presented with the Find Specifications form. Select the Item radio
button and enter Item = SCJ180/20. Tab out and click on the Find button. We now have the
Enter Quality Results form with the Collection Plan displayed as 01 SCJ COLLECTION PLAN
and the Spec Name displayed as SPEC_SCJ180/20. We had a job in which ten serialized units
of rough-cut steel shafts were to undergo a cutting operation that would trim the length of each
unit to 180 millimeters producing the final product SCJ 180/20. We now enter the Item Number,
its Serial Number, and the Shaft Length in the Enter Quality Results form for the ten units and
save our work (Fig 110).
Fig 110. Entering Quality Results against a Collection Plan and a Specification
Upon saving our work, the List Of Signers page is launched. Deferred Signature is not allowed
for this event. Thus, the signers approve and sign the results in online mode and ratify the
transaction.
The E-Record is created and archived in the Evidence Store (Fig 111).
Fig 111. The E-Record for Quality Results Creation in the Evidence Store
Fig 112 displays the complete E-Record.
87
88
Fig 112. The complete E-Record for Quality Results Creation

The E-Record (Fig 112) displays the results entered for each row i.e., for each of the ten
serialized units of item SCJ180/20 that were completed through job 90103. For the first four units,
Serial Number 101 to 104, the Defect Code has also been captured in the E-Record.
Note: This case is detailed in Note 248331.1 (A Guide to Oracle Quality), published on the
Metalink.
Refer the Demo 054 QA ERES Result Creation in Note 336709.1 for a step-by-step
89
review
iSIGNATURES
What is iSignatures?
iSignatures, previously called iSign, is a 21 CFR Part 11 compliant file approval process which
enables users to upload any type of file to the database and rout it for approval to a configurable
list of reviewers or approvers.
The key features of iSignatures are:
Ability to capture electronic signatures, enforce file version control
Track an audit trail of the version history of the file
Secure the file based on its status and associate any number of file attributes with the file
An additional process is provided for files, which are categorized as Oracle E-Record
stylesheets. Once approved, these files will be automatically uploaded to the stylesheet
repository. This replaces a manual upload process in Oracle E-Records in patch
releases.
Why iSignatures?
Customers have asked for support for 21 CFR Part 11-compliant electronic signatures on
standalone files, such as documents, spreadsheets and E-Record stylesheets. Using the ERES
framework, this is supported from Release 11.5.10. Users can upload any file to the database
through a standard upload feature, and submit the file for approval. Once submitted for
approval, the approval process is the same as any other ERES approval process supported by
deferred Workflow processes. The approved files are securely stored, along with their meta
data and electronic signatures in the Evidence Store.
Benefits of iSignatures
iSignatures offers the following benefits:
A standard best practices approval process for critical files enforced by technology
The accountability for approvals is tracked in the evidence store in the form of electronic
signature details of the signer along with the E-Record content
Electronic approval of files routed via Workflow is significantly faster and cheaper than
sending paper records around your global enterprise to capture handwritten signatures
Powerful query capabilities to search for various records if needed
Finally, in addition to being available for use for any of the enterprise's documents, the
iSignatures capabilities are being used to support approval processes for specific type of
files used by the Oracle E-Business Suite such as E-Record, Stylesheets and Material
Safety Data Sheets (MSDS)
How to use iSignatures
There are five steps through which iSignatures is executed:
Upload the File
Assign Categories to the File
Send File for approval
Sign the E-Record created for Files Approval
Query the File from the Evidence Store
Working with iSignatures
Login as sysadmin.
Workflow Administrator Web Applications > Find Events/Event Groups
90
Ensure that the event ERES File Approval Event and its Subscription are enabled
Fig 113. Enabling the File Approval Event and its Subscription
I now logout and then login again using my personal login.
Approvals Managament Administrator > Approvals > (T) Attributes
Select the Transaction Type EDR ERES File Approval
Here, we create a new Attribute of Type Boolean and Usage Static.
Attribute Name = DOCUMENT_AS_PER_SPECS
This Attribute has a Usage value as true (Fig 114).
Fig 114. The Attribute created for iSignatures File Approval

Approvals Managament Administrator > Approvals > (T) Conditions
Using the Attribute we created above, we define a new Condition (Fig 115).
Fig 115. The Condition to be used for iSignatures File Approval

Approvals Managament Administrator > Approvals > (T) Rules
Using the Condition created above, we create the Rule (Fig 116).
91
Fig 116. The Rule for iSignatures File Approval

For Transaction Name = EDR ERES File Approval and Rule Name = Rule for PRB Files, we set
EREC_REQUIRED = Y and ESIG_REQUIRED = Y.
Now, select the Responsibility iSignatures User.
iSignatures User > Files Approval
This opens the Files Approval page.
Click on the Upload File button. This opens the File Upload page. Select an appropriate
Category (we have selected the generic Category File), and use the Browse button to upload
the desired file from your machine (Fig 117).
Fig 117. Uploading a file for the iSignatures File Approval process
We choose to version the existing file and set the Version Label as 1.0. Having selected out file
and entered the relevant information, we click on the Apply button (not shown in Fig 117) on the
page. This starts the file upload process. When the file has been successfully uploaded we are
brought back to the initial page with the Upload button, and we get the conformation as seen in
Fig 118.
92
Fig 118. Confirmation indicating successful upload of the file and its version number
If we perform a search for this file we can confirm its existence and its version number (Fig 119).
Fig 119. The Uploaded file as visible in the Repository

If we click on the Details icon (Fig 119), we get the details of the approvers who are configured to
review and approve this file (Fig 120).
Fig 120. The File Properties and the configured List of Approvers
We now select the file and click on the button Send for Approval (Fig 121).
Fig 121. Submitting the file for Electronic Routing to the Approvers
93
This launches the List Of Signers page, like for any other business event seeded and supported
for ERES. Here, the Event Name is ERES File Approval Event and Deferred Signature is allowed
for this event.
When each approver reviews the E-Record, the file is available as an attachment for the approver
to review before deciding on approval or rejection. Once all the approvers have approved and
endorsed the file with their electronic signatures, the E-Record is completed and archived in the
Evidence Store (Fig 122).
Fig 122. The E-Record available in the Evidence Store

The complete E-Record created by this File Approval is displayed in Fig 123.
Fig 123. The E-Record for the File Approval through iSignatures
If we now query the file in the File Approvals page we find that the file appears with Status
Approved and the Update icon is disabled (Fig 124).
94
Fig 124. The file appearing in Approved status

Note: A file once uploaded and sent for approval using iSignatures, cannot be modified. This
is because iSignatures is a File approval system and is not designed to work as a collaborative
document editing system. Therefore, if an uploaded file calls for changes, a new and modified
version of the file would have to be uploaded. The case that follows demonstrates this point.
The case of Rejecting a file in iSignatures
In the previous demonstration, we had uploaded a file GMP 210 211 820_v_1.0.doc to the
database and the same was approved using iSignatures. It has now been observed that a few
additional clauses need to be incorporated into this file and a new version needs to be created,
uploaded and approved using iSignatures.
Fig 125. Successfully uploading version 1.1 of file GMP 210 211 820.doc using iSignatures
Fig 125 shows a new version file GMP 210 211 820_v_1.1.doc having been uploaded onto the
database. This file is awaiting approval from the approvers as listed in Fig 125. The previous
version of the same file GMP 210 211 820_v_1.0.doc appears in Approved status in the
Version History.
The first three approvers approve the file. However, upon closer scrutiny, the fourth approver
Akira Kurosawa finds some vital information missing in the file and he underlines his objection to
the new version of the document by rejecting the same and putting his comments along with his
95
electronic signature on the E-Record. Fig 126 shows the Notification received by the first
approver (or the initial requester) upon rejection of the file from the fourth approver.
Fig 126. The Rejection Notification from the Fourth Approver to the First
Now, if the first approver tries to query the file and delete it from the database (Fig 127).
Fig 127. Attempting to Delete the Uploaded and subsequently Rejected file from the
database
He receives the following message (Fig 128)
Fig 128. The File can no longer be deleted

To incorporate the modifications suggested by the fourth approver, a new version of the file
needs to be uploaded and submitted for approval.
Refer the Demo 060 Working with iSignatures in Note 336709.1 for a step-by-step review
96
Our overall implementation of Part 11 will be shaped not only by industry input, but also:
Our field experience with the rule (problems we continue to find that impact product quality and
safety and data integrity);
Emerging products and services;
Technology trends; and,
The influences of electronic government and electronic commerce.
John Marzilli,
Deputy Associate Commissioner for Regulatory Affairs,
U.S. Food and Drug Administration
ACKNOWLEDGEMENTS
I wish to record my heartfelt thanks to Ravindra Akella, Sagar Thakker, Swaminathan
Subramanian, Sujatha Karimisetty and Bhupendra Chopra from the ERES Development team
for their valuable inputs, which have helped this project tide over the many hurdles that came in
the way.
I am deeply grateful to Michele Fields, Srikanth Karimisetty and Srinivasulu Puri for taking
time out from their busy schedules to share with me their expert comments and feedback. In
doing so, they have helped sustain this seemingly daunting project.
My sincere gratitude goes to Michele Fields who as the Product Manager, and former Doc Writer
of ERES since its inception, has been instrumental in reviewing this paper and in publishing it on
the Metalink.
Without the expertise, which these colleagues from the ERES Development community have so
willingly shared with me, this paper would not have been possible.
About the Author
Saumit Mandal CPIM, is a Principal Support Engineer at Oracles India Support Center,
Bangalore. As a member of the Global Applications BDE team, he works on the Core
Manufacturing domain and can be reached at saumit.mandal@oracle.com or
saumitmandal@yahoo.com.
References:
1. Oracle E-Records Data Sheet, May 2004.
2. Oracle E-Records Implementation Guide, Release 11i, Part No. B10633-03, August
2004.
3. Risk-Based Approach to 21 CFR Part 11, ISPE, Tampa, FL.
4. Oracle XML Publisher Users Guide, Release 11i, Part No. X00000-01, June 2004.
5. Guidance for Industry Part 11, Electronic Records; Electronic Signatures Scope and
Application, FDA, August 2003.
6. Oracle E-Records Functional Overview, presented by John Danese, content published by
Oracle University.
7. Note 264933.1: About Oracle E-Records in Patchset C.
8. Implementing Oracle Approvals Management, Release 11i10/AME.A, January 2005
9. Note 248331.1: A Guide to Oracle Quality, An Oracle White Paper, August 2003
10. Industry Coalition on 21 CFR Part 11, Docket 00D-1541, June 2002.
11. Note 296558.1: Making Tea with GMD: A Case Study in OPM Product Development
11i10, An Oracle White Paper, January 2005
97
White Paper: Implementing E-Records and E-Signatures (11.5.10) in Discrete Manufacturing Suite
October, 2005
Author: Saumit Mandal CPIM
Contributing Authors: N/A
Oracle Corporation
World Headquarters
520 Oracle Parkway
Redwood Shores, CA 94265
U.S.A.
Worldwide Inquiries:
Phone: +1.652.526.7000
Fax: +1.652.526.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 2005 Oracle Corporation
All rights reserved.
98

Implementing E-Records &amp; E-Signatures in Oracle Applications

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing E-Records &amp; E-Signatures in Oracle Applications

Uploaded by

Copyright:

Available Formats

Implementing E-Records and E-Signatures

Implementing E-Records and E-Signatures (11.5.10) in Discrete

Oracle Approval Management to configure approval rules

Leveraging the Power of the Database

SETTING UP E-RECORDS AND E-SIGNATURES: A CASE FROM ORACLE PROCESS

Click on the Groups tab.

Fig 2. Enabling ERES for Item Creation in Oracle Process Manufacturing

Fig 4. Defining values for the Attribute in creating our Condition

Responsibility: ERES Administrator.

Navigate to Administration Tasks > Setup.

Fig 16. Example of an Attribute with Static Usage

The query we used for attribute INVENTORY_TYPE in Demo 00-A

Implementing E-Records and E-Signatures for Discrete Manufacturing

Enabling EDR Profile Options

Approvals Management (AME) Setup

Fig 20. The E-Record for item STJ180/15 created in organization V1

Fig 21. The E-Record for Item Creation in Oracle Inventory

Fig 22. The E-Record for item STJ180/15 updated in organization M2

Fig 23. Creating a New Revision for item STJ180/5

Fig 25. The E-Record for Item Revision Entry

Inventory > Transactions > Miscellaneous Transactions

Fig 28. The E-Record for Miscellaneous Receipt

Fig 30. The Rule for the BOM Creation Event

Fig 32. The newly created E-Record in the Evidence Store

Fig 33. The E-Record for Bill of Material Creation

Fig 34. E-Record Header for a Bill of Material with an Attachment

Fig 35. The E-Record in the Evidence Store

Fig 36. E-Record for Bill of Materials Update

Fig 37. The E-Record for Routing Creation

Fig 38. E-Record for Routing Creation

Fig 39. The E-Record Signature Details

Bills Of Materials > Routings > Routings

Fig 40. The E-Record for Routing Updation

Fig 41. The E-Record for Routing Updation

Fig 45. The E-Record available in the Evidence Store

Fig 46. The E-Record for Transfer To Manufacturing

Fig 47. Copying item Water Tray to Manufacturing

Fig 50. The E-Record for Copy to Manufacturing

ECO Creation, Approval and Implementation

Fig 51. Defining a New Priority

Fig 52. Defining a New Change Type

Engineering > Setup > Change Types > (B) Processes

Fig 54. List of Approvers for ECO Approval

Fig 55. Querying the Priority Code we had defined previously

Fig 58. The Rule for ECO Creation

ERES Administrator > Setup

Fig 61. The E-Record for ECO Creation

Fig 63. The ECO Approval Notification awaiting my approval

Fig 68. The E-Record for ECO Approval

Fig 69. The ECO Implementation E-Record in Pending Status

Fig 73. The complete E-Record for ECO Implementation

Fig 80. The E-Record for WIP Job Assembly Move

Fig 84. The E-Record is available in the Evidence Store

The complete E-Record is detailed in Fig 85.

Fig 85. The E-Record for WIP Job Assembly Completion

QA ERES Collection Element Creation

Fig 87. Querying my instance for Collection Element Types

Approvals Management Administrator > Approvals > (T) Conditions

Target Value = 180

Fig 90. The E-Record for Collection Element Creation

Fig 91. The E-Record for Quality Collection Element Creation

Fig 92. The Condition for Creation of a Specification in Quality

Fig 93. The Rule for Creation of a Specification in Oracle Quality

Fig 95. Notification received by the second signer Andre Wajda

Implementing E-Records & E-Signatures in Oracle Applications

Implementing E-Records & E-Signatures in Oracle Applications