Skip Headers

Oracle E-Records Implementation Guide
Release 12.1
Part Number E13700-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Implementing E-records

You must complete the following steps to enable the E-records functionality. These steps comprise the initial setup of Oracle E-Records and are required to ensure a complete and accurate system.

This chapter covers the following topics:

Enabling Profile Options

Oracle E-Records has several profile options that can be set to enable records and signatures, or modify the software in different ways.

EDR: E-records and E-signatures

You must set up the profile option EDR: E-records and E-signatures. This profile option lets you enable the functionality for your entire system. This profile option is sent out with the hierarchy type set to Site, which enables the system administrator to set the profile option based on the implementation. Valid values for this profile option are:

EDR: Server Time zone

Set the profile option EDR: Server Time zone to the time zone where the database is running. If you do not set this value, then you cannot raise any events and an error displays that all e-records have a null value for the time zone. Each window in Oracle E-records displays the time zone that the system is set up to use.

Note: If you had previously set the Server Time zone profile option, then you must set EDR: Server Time zone to the same value.

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.

Example 1

EDR: Workflow Notification Timeout (in Hours) = 5

EDR: Workflow Notification Timeout Interval = 3

The result is that five hours after the initial notification is sent, three more are sent at five hour intervals. If no acknowledgement is made, then the process is terminated and e-mails are sent to all approvers and the requestor that the process was terminated.

Example 2

EDR: Workflow Notification Timeout (in Hours) = NULL

EDR: Workflow Notification Timeout Interval = 3

The notification timeout in hours overrides the number of reminders sent. Therefore, in this example no reminders are sent and the process is terminated. This is not a valid combination. You must set a timeout interval in hours.

Example 3

EDR: Workflow Notification Timeout (in Hours) = 5

EDR: Workflow Notification Timeout Interval = NULL

The result is that no notifications are sent, and at the end of the five hours the process is terminated.

EDR: Security Level High

This profile option, when set to Y, restricts access to e-records before security rules are created for them. The default value is Y, and users must be granted access when the system is set up.

EDR: E-record Print Granted

This profile option lets you restrict access to printing e-records. 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.

EDR: Send Individual Approval Notification

This profile option is for receiving emails during a signing process. If this profile is set to Yes, then the requester gets a notification after every signer completes the signing process. If this is set to No, then there is no notification for each signature. All signers receive a notification for a rejection, regardless of the profile option setting.

EDR: Send Individual Approval Notification

This profile option is for receiving emails during a signing process. If this profile is set to Yes, then the requester gets a notification after every signer completes the signing process. If this is set to No, then there is no notification for each signature. All signers receive a notification for a rejection, regardless of the profile option setting.

EDR: Developer Mode

This profile options lets you debug a transaction by taking a snapshot of the raw XML and storing it in the EDR_RAW_XML_T table. This can now be used as the XML payload in the Validate Event window. Default value is No.

Setting Up Responsibilities

The following responsibilities are available with the Oracle E-Records applications. Give your users the appropriate responsibilities. The administration responsibilities must only go to the person responsible for setting up the system.

ERES Administrator

This person has the responsibility for overall administration of the Oracle E-Records application. Only a small number of people should be assigned this responsibility.

ERES User

This person can access the Oracle E-Records application for user tasks like querying the Evidence Store only. No administration related functions are exposed to this responsibility.

iSignatures Administrator

This person is the administrator for the iSignature process. This person can do all the functions of a user, in addition to updating and deleting other users files.

iSignatures User

This person can upload files and send them for approval. In addition, they can update or delete their own files only.

Enabling the Event

The Oracle Workflow Event Manager lets you register:

You can use the Event Manager web pages to define and maintain these events, systems, agents, and subscriptions.

A business event is an occurrence in an internet or intranet application or program that might be significant to other objects in a system or to external agents. For instance, the creation of a purchase order is an example of a business event in a purchasing application. You can define your significant events in the Event Manager.

Business Event Creation

Name

When you define an event in the Event Manager, you must assign it a unique internal name, which is case-sensitive. The format for these internal names is a compound structure of identifiers separated by periods (.) as follows:

oracle.apps.<product>.<component>.<object>.<event>

This format lets you organize the events you define into a classification hierarchy.

Example: oracle.apps.gme.Process.Batch.close, Process Batch Close Event

Display Name

The Display Name displays in the Edit Event list.

Description

A brief description of the e-signature event.

Status

All seed data is sent set to enabled.

Generate Function

Generate functions is NULL for all e-signature events.

Owner Name (mandatory)

The Owner Name must be your product name.

Owner Tag (mandatory)

The Owner Tag must be your three letter product code.

Customization Level

The Customization Level determines how much of the event information can be changed. All seed events are set to Limit, where only the Status can be changed. Custom events are set to User, and all fields can be changed.

Identify Event Key

Each instance of an event must be unique and is identified by an event key. The key helps to tag the transaction data with e-signature and e-record data. The key must be a unique identifier for an event and not hold multiple values. In most cases, it is the primary key of a table on which the event is taking place. In some cases, the primary key can be a multi part key, which is concatenated and treated as a single event key. This key is used as a business event key and is passed as a parameter to the event raise API.

Example of a single key:

Event: GME_BATCH_RELEASE

Event Key: GME_BATCH_HEADER.BATCH_ID

Example of a multi part key: (If the Batch Header table does not have BATCH_ID)

Event: GME_BATCH_RELEASE

Event Key: GME_BATCH_HEADER.PLANT_CODE

GME_BATCH_HEADER.BATCH_NO

Event key representation during API calls:

GME_BATCH_HEADER.PLANT_CODE|| GME_BATCH_HEADER.BATCH_NO

Refer to the Oracle Workflow Guide for details on enabling events.

Enabling the Subscription

Subscription processing can include the following types of processing:

Add Synchronous E-signature Subscription

A synchronous subscription is added to the defined business event, which is a local subscription. The phase of the subscription determines if the subscription is synchronous or not. The phase of the subscription must be set to 0 to make sure that e-signature subscription is the first subscription run when an event occurs. A rule function is associated to the subscription that determines if an e-signature is required and generates a snapshot of the data to be signed. The snapshot is generated as an XML document in the rule function. This is the generic rule function, which is used by all product teams while defining a subscription.

Subscriber: System

This is the local system, on which the subscription code is to run.

Triggering Condition: Source Type

Set the triggering condition to local.

Triggering Condition: Event Filter

Select the event that this subscription is for.

Triggering Condition: Source Agent

Leave blank.

Execution Control: Phase (mandatory)

Set the phase to 0.

Execution Control: Status

All seed data is sent set to disabled.

Execution Control: Rule Data

Key: the subscription requires only the event key.

Action: Action Type

Set the action type to Custom

Action:On Error

Stop and roll back. Do not set to any other value.

Action:Java Rule Function

Leave this blank.

Action: Pl / SQLRule Function (required)

Enter EDR_PSIG_RULE.PSIG_RULE. This is the rule function, which determines if e-signature is required for the event instance and generate XML document if required.

Action: Workflow Item Type and Workflow Process Name

Workflow item Type = EDRPSIGF

Workflow Process Name = PSIG_ESIGN_PAGE_FLOW

Action: Out Agent and To Agent

Leave blank.

Action: Priority

Leave blank.

Action: Parameters

The parameter column can be used to add space delimited name=value pairs, which can be accessed by rule function. The rule function looks for the following parameter and if the parameters are not, then set it.

EDR_XML_MAP_CODE=<Your XML Map Code>

EDR_AME_TRANSACTION_TYPE=<AME transaction Type>

Documentation: Owner Name (mandatory)

The Owner Name must be your product name.

Documentation: Owner Tag (mandatory)

The Owner Tag must be your three letter product code.

Documentation: Description

Any information you want to document about the subscription.

Customization Level

The customization level will be set to "Limit"

Refer to the Oracle Workflow Guide for details on enabling subscriptions.

Setting Up Oracle Approval Management

Oracle Approvals Management (AME) is a self–service 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.

Oracle E-Records enables you to enhance your system using the functionality available in AME, including Serial and Parallel Approvers, First Responder Wins, Consensus Voting, and Line Item Class Approvers. The information in this section offers an overview of how to maintain information in AME. For details on setting up AME, refer to the Oracle Approvals Management documentation.

Two notable features in the AME setup are the First Responder Wins and Parallel Approver Support. First Responder Wins supports voting regime. You need to set voting regime to ‘First Responder Wins’ and order to parallel in AME. The First Responder Wins feature sends out signature notifications to either single or multiple signing groups (as the case maybe) involved in a particular transaction. The transaction is approved even if one of the designated signers, from the group or groups, signs the transaction.

The parallel approver support allows signers to sign the transaction according to the signing order created for the transaction and multiple approvers can be on the same order. This feature accommodates more than one signer for a transaction and allows the user to set the order or sequence of the signature process.

Creating Transaction Attributes

In OAM, an attribute is a named business variable such as TRANSACTION_AMOUNT, whose value OAM fetches at run time, when it constructs transactions' approver lists. OAM includes the attributes commonly required for the transaction types of each application that can use OAM.

Creating Conditions

In OAM, a condition specifies a list or range of attribute values required to make a rule apply to a transaction. For example:

INVENTORY_TYPE IN {'A'}

Creating Approval Groups

An OAM approval group is an ordered list of persons or user IDs. You can create OAM rules to include one or more approval groups in a transaction approver list. You must create an approval group before using it in an approval-group rule.

Defining 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 OAM 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.

Defining Action Types

An action is used to instruct the AME to modify a transaction’s approval process. There are two types of action, approval and production actions. Actions associated with a transaction’s approver list are approval actions or approvals. Production actions are actions that generate a production such as a variable name or value pair.

The AME contains action types and actions that an implementation requires. These actions and action types can be used to either create or modify an existing action.

Setting Up the Configuration Variables

The Configuration Variables lets you add, delete, and update new variables to transactions and rules. You can also add a variable to a rule that overrides the default global value for the variable in the transaction.

Associate the e-record output XSL or RTF to the rule. This ensures multiple style sheets can be associated to a single event based on the control parameters.

AME Transactions as ERES-enabled Events

When you create, update, or delete an input configuration variable for transaction type at the transaction or rule level, it raises the appropriate event that goes through the approval process. If the approval process fails, then the transaction rolls back. If it is approved, then it is committed to the database. Refer to the Events appendix for details.

To view variables associated with a transaction:

  1. Navigate to the Configuration Variables window.

  2. Select a Transaction Name from the list of values. Required.

  3. Click Go. The available variables are listed under the Result for Transaction section. All seeded variables can be updated but not deleted. The following transaction fields are display only:

To view variables associated with a transaction and rule:

  1. Navigate to the Configuration Variables window.

  2. Select a Transaction Name from the list of values.

  3. Select a Rule Name from the list of values. Only rules associated with the selected transaction type are displayed.

  4. Click Go. The available variables are listed under the Result for Transaction and Result for Rule regions. All seeded variables can be updated but not deleted. The following rule fields are display only:

To add a transaction variable:

  1. Click Create from the Configuration Variables window. The Create Transaction Variable window displays. The Transaction Name is a display only field.

  2. Select a transaction variable from the menu. If the variable has already been set, it does not appear in this list. Required.

  3. Enter a description for the variable.

  4. Select a data type for the variable. Valid values are:

  5. Enter the default global value for the variable.

  6. Click Apply to save the variable.

To add a rule variable:

  1. Click Create from the Configuration Variables window. The Rule Variable Definition window displays. The Transaction Name and Rule Name are display only fields.

  2. Select the input variable you want to add from the menu. If you do not see the variable, then ensure that it is already created as a global variable under transactions. The Data Type field is display only. Required.

  3. Enter the value for the variable that overrides the global default value.

  4. Click Apply the save the variable.

To update a variable for a transaction:

  1. Once the transaction variables display, click Update. The Update Rule Variable window displays. The following fields are display only:

  2. Modify the Description and Default Value as necessary. The default value must be Y or N. No other values are accepted.

  3. Click Apply to save your changes.

To update a variable for a rule:

  1. Once the rule variables display, click Update. The Update Rule Variable window displays. The following fields are display only:

  2. Modify the Variable Value as necessary.

  3. Click Apply to save your changes.

To delete a transaction variable:

  1. Once the transaction variables display, click Delete. The Delete Transaction Variable window displays. You must not delete the four seed data variables, including:

    The following fields are display only:

  2. Click Apply to delete the variable. An error displays if the variable is associated with a rule. You must delete the variable from the rule first, then delete it from the transaction.

To delete a rule variable:

  1. Once the rule variables display, click Delete. The Delete Rule Variable window displays. You cannot delete the four seed data variables, including:

    The following fields are display only:

  2. Click Apply to delete the variable.

Running the E-record Event Setup Verification Report

This program logs all set up seed data for an Oracle E-Records selected event into the concurrent log file. It displays the current setup for the following information:

To submit the E-record Setup Verification report:

  1. Navigate to the Submit Request window.

  2. Enter E-record Event Setup Verification in the Name field. The Parameters dialog box displays.

  3. Enter any of the following fields to narrow the scope of the report:

  4. Click OK. The Submit Request window displays.

  5. Complete the fields on the Submit Request window and click Submit. View or print the report.

    Refer to "Validate E-record Events" for more information.

Setting Up Indexed XML Elements

The initial implementation of Oracle E-Records contains seed data for indexed XML elements. You must run a concurrent program to index these elements.

The job of the concurrent program is to index all the non-indexed elements. The indexing consists of changing the status field in the table EDR_IDX_XML_ELEMENT_B and creating a section in the interMedia text index for the indexed XML element.

After creating or updating an indexed XML element, you must run this program again in order to index the element.

Refer to Maintaining Indexed XML Elements details on querying, updating, and deleting indexed XML elements.

Refer to "Adding a New Indexed XML Element" for details on adding new XML elements.

To submit the E-record Indexed XML Element Maintenance program:

  1. Navigate to the Submit Request window.

  2. Enter E-record Indexed XML Element Maintenance in the Name field.

  3. Click Submit.

  4. View or print the report.

Security Rules

It is possible that your system is set up to run Oracle Internet Directory (OID). If so, then you must do the following:

You must set up security rules on your system. Refer to “Setting Up Security Rules” for details.

Related Events

Related event mode lets you relate major events to multiple other events, in a parent-child relationship. Some of the scenarios where related events can be implemented are:

Mass Lot Creation

Many lots are created on one window and only one signature is required, but individual e-records must be captured.

Mass Specifications

When a master specification is assigned to various organizations, the master specification is signed, but creation of referenced organization specifications require e-records and must be linked to the Master Specification.

Batch Release

Batch Release requires an e-signature, but lots created during this process only need an e-record and must be linked to the Batch Release Event.

Setting Up Related Events

To ensure that the related event completes correctly, it must be set up as part of the configuration variable for the parent event. Therefore, when the parent event and related events are triggered, the processing can complete successfully.

The following scenarios depict invalid setup:

The following are valid setups:

To set up a related event:

  1. Navigate to the Business Events window in the Workflow Web Administrator responsibility.

  2. Locate the event that is designated as the parent event.

  3. Click Subscription, then Update.

  4. Enter a line with the name of the child event and the type of action to be taken in the Action region, in the Parameter field.

    The line looks like oracle.apps.event.name=VALUE

    An example of this is oracle.apps.edr.InterEvt.Event2=ERECORD_ONLY

    The valid values are:

Setting Up Ad Hoc Signers

You can set up your system so that signers can be dynamically changed during the signing process for a single document. Based on the setup, you can either not change signers, add new signers, or add new signers and remove existing signers. This can be set up at both the transaction and rule level, with the more stringent one taking precedent. Therefore, if you have the transaction level set to add and remove signers, but the rule level is set to add only, then you can only add users.

If this variable is not set up, then the functionality defaults to NONE.

To setup ad hoc signers:

  1. Navigate to the Configuration Variables window by selecting ERES Administrator Setup.

  2. Search for the event you want to put ad hoc signers on, and click Go.

  3. Click Create to add a new variable.

  4. Enter the variable name Adhoc Signer Capability.

  5. Enter a description.

  6. Change the data type to String.

  7. Set the default value to NONE for no dynamic changes, ADHOC for adding new signers, and ALL for adding new signers and deleting existing signers.

  8. Click Apply.

Manually Enabling E-Records Only

The e-record framework lets you set an event capture with e-signature or e-record only. But, when initiating an API where there is only an e-record needed, it is necessary to also set the configuration variables correctly. You can set a flag programmatically when running the API to set the program to capture an e-record only. This flag would override anything in the configuration variables. For more details on enabling this flag, refer to the Oracle E-Records Developer's Guide.

Enabling One-Step E-signatures

One-step e-signatures is a method of signature capture where all signatures are done on a single window. In regular e-signatures, there are three windows that the signer sees. The initial List of Signers page, the e-record itself, and the Signers page. In the simplified version of the e-signatures, all signatures are done on one page, condensing the signing process.

Like the regular signing process, the signer selects an approval or rejection, a reason, and enters a username and password as unique identifiers.

Setting Up the One Step E-signatures Page

In order to set up the simplified e-signatures process, you must set the configuration variable to E-Signature Mode. The values for this variable are SHORT or FULL. The value FULL is the regular way of signing documents. You must set this variable to SHORT to use the one-step e-signatures feature.

The rest of the set up for one-step e-signatures is the same as regular signing. You must ensure that the AME setup is complete and the business events you want to use are enabled.

There are a few limitations associated with one step signatures;. you cannot use Ad Hoc signers, digital signatures, and dynamic responses.

Setting Up Redlining

There are a number of transaction e-records that can change based on the transaction. For example, you can change the status of a formula several times, each time creating a new transactional e-record. The redlining functionality lets you set up change tracking for both text and RTF e-records.

For an RTF e-record, the change tracking highlights removed items. You have the option of setting the redlining feature to reflect changed information however you want.

For a text e-record, the body of the record has the text PREV before the old information and CURR before the new information.

To set up the redlining functionality, you must add the configuration variable REDLINE REQUIRED. If you want to use this functionality, you must set it to Yes.

Refer to the Oracle E-Records Developer's Cookbook Guide for details on creating redlining templates.

Enabling E-Records in Mobile Supply Chain Applications

The demand for accurate, real-time information and the need to increase inventory velocity throughout the supply chain drives rapid adoption of mobile computing for inventory, logistics, and manufacturing. Mobile computers connected using Radio Frequency (RF) to the network, combined with the use of automatic identification techniques such as bar coding, permits activity execution, such as picking or receiving an item, to be unified with the recording of that activity in the information system. This approach virtually eliminates sources of error. It also reduces latency, increases work efficiency, and reduces the complexity of the overall business process.

The addition of e-records and e-signatures to mobile devices gives you the same level of compliance and security that the associated window offers.

The basic functionality remains the same when signing on the mobile device. Upon completion of a transaction, the signature window displays, and can be signed online, or deferred if the transaction allows. The deferred signing process continues in the windows-based Workflow.

At the end of the signature process on the mobile device, the e-record is not automatically displayed, due to space limitations. You can review the complete e-record in the normal ERES Evidence Store. In addition, any attachments associated to the transaction are viewable in the ERES Evidence Store in the text versions. The PDF version is not supported for mobile supply chain applications.

Another limitation of the mobile signing is the inability to add Ad Hoc signers. All signers must be set up in AME prior to initiating the transaction.

As with the windows-based e-records, the mobile counterpart offers the same inter-event verification process, giving you the opportunity to test flows prior to using them.

Refer to the Oracle E-Records Developer's Guide for details on setting up of e-records and e-signatures for Mobile Supply Chain Applications.

Force E-Record Generation

The ERES Framework can also capture E-records at the minimum, irrespective of the setup. When the new event subscription parameter, FORCE_ERECORD is set to Y (yes), then an e-record is captured irrespective of the configuration variables, status of the profile options, with or without signatures, etc. If the option is set to N (No), then ERES process continues normally.