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:
Oracle E-Records has several profile options that can be set to enable records and signatures, or modify the software in different ways.
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:
Yes - Enable e-record and e-signature
No - Do not enable e-record and e-signature (default value)
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.
Ensure that the database time zone is the same as the server time zone profile option value since the system does not verify the database value.
Once Oracle E-Records is enabled, do not reset this value.
This value does not reflect the current user time zone value. It is always the server time zone.
Note: If you had previously set the Server Time zone profile option, then you must set EDR: Server Time zone to the same value.
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.
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: 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.
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.
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.
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.
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.
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.
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.
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.
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.
The Oracle Workflow Event Manager lets you register:
business events that occur in your applications,
the systems among which events are communicated,
named communication agents within those systems, and
subscriptions indicating that an event is significant to a particular system.
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.
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
The Display Name displays in the Edit Event list.
A brief description of the e-signature event.
All seed data is sent set to enabled.
Generate functions is NULL for all e-signature events.
The Owner Name must be your product name.
The Owner Tag must be your three letter product code.
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.
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.
Subscription processing can include the following types of processing:
Run a function on the event message.
Send the event message to a workflow process.
Send the event message to an agent.
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.
This is the local system, on which the subscription code is to run.
Set the triggering condition to local.
Select the event that this subscription is for.
Leave blank.
Set the phase to 0.
All seed data is sent set to disabled.
Key: the subscription requires only the event key.
Set the action type to Custom
Stop and roll back. Do not set to any other value.
Leave this blank.
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.
Workflow item Type = EDRPSIGF
Workflow Process Name = PSIG_ESIGN_PAGE_FLOW
Leave blank.
Leave blank.
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>
The Owner Name must be your product name.
The Owner Tag must be your three letter product code.
Any information you want to document about the subscription.
The customization level will be set to "Limit"
Refer to the Oracle Workflow Guide for details on enabling subscriptions.
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.
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.
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'}
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.
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.
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.
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.
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.
Navigate to the Configuration Variables window.
Select a Transaction Name from the list of values. Required.
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:
Variable Name displays the name of either a seeded or custom variable.
Description displays the description of the variable.
Data Type displays the type of data for the variable.
Default Value displays the default value for the variable.
Navigate to the Configuration Variables window.
Select a Transaction Name from the list of values.
Select a Rule Name from the list of values. Only rules associated with the selected transaction type are displayed.
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:
Variable Name displays the name of either a seeded or custom variable.
Description displays the description of the variable.
Data Type displays the type of data for the variable.
Default Value displays the value for the variable that overrides the value found in the transaction.
Click Create from the Configuration Variables window. The Create Transaction Variable window displays. The Transaction Name is a display only field.
Select a transaction variable from the menu. If the variable has already been set, it does not appear in this list. Required.
Enter a description for the variable.
Select a data type for the variable. Valid values are:
Boolean
Character
Date
Number
Time
String
Enter the default global value for the variable.
Click Apply to save the variable.
Click Create from the Configuration Variables window. The Rule Variable Definition window displays. The Transaction Name and Rule Name are display only fields.
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.
Enter the value for the variable that overrides the global default value.
Click Apply the save the variable.
Once the transaction variables display, click Update. The Update Rule Variable window displays. The following fields are display only:
Transaction Name
Variable Name
Data Type
Modify the Description and Default Value as necessary. The default value must be Y or N. No other values are accepted.
Click Apply to save your changes.
Once the rule variables display, click Update. The Update Rule Variable window displays. The following fields are display only:
Transaction Name
Rule Name
Input Variable
Data Type
Modify the Variable Value as necessary.
Click Apply to save your changes.
Once the transaction variables display, click Delete. The Delete Transaction Variable window displays. You must not delete the four seed data variables, including:
E-record required
E-record style sheet
E-record Style Sheet version
E-signature required - you must set this to Y to enable e-signature.
The following fields are display only:
Transaction Name
Input Var Name
Description
Default Value
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.
Once the rule variables display, click Delete. The Delete Rule Variable window displays. You cannot delete the four seed data variables, including:
E-record required
E-record style sheet
E-record style sheet version
E-signature required
The following fields are display only:
Transaction Name
Rule Name
Input Variable
Data Type
Variable Value
Click Apply to delete the variable.
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:
Event Name
Subscription
Profile Options
Transaction Type
AME Conditions and Rules
Approval Groups
Approvers
Transaction Type Configuration Variables
Generated XML
Navigate to the Submit Request window.
Enter E-record Event Setup Verification in the Name field. The Parameters dialog box displays.
Enter any of the following fields to narrow the scope of the report:
Business Event is the workflow business event name.
Event Key is the business event key number.
Click OK. The Submit Request window displays.
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.
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.
Navigate to the Submit Request window.
Enter E-record Indexed XML Element Maintenance in the Name field.
Click Submit.
View or print the report.
It is possible that your system is set up to run Oracle Internet Directory (OID). If so, then you must do the following:
Make sure you have Oracle Applications usernames and passwords for all users.
Set the Applications SSO Login Types profile option to Both.
You must set up security rules on your system. Refer to “Setting Up Security Rules” for details.
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.
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:
If you have more than one e-record event subscription enabled for the parent event, then an error displays when you try to perform the transaction.
If you have more than one e-record event subscription for the parent event, and they are all disabled, then an error displays when you try to perform the transaction.
If you do not have any e-record subscriptions for the parent event, then an error displays when you try to perform the transaction.
The following are valid setups:
Only one e-record subscription either in enabled or disabled status.
Only one e-record subscription enabled where you have more than one e-record subscription defined for the event.
Navigate to the Business Events window in the Workflow Web Administrator responsibility.
Locate the event that is designated as the parent event.
Click Subscription, then Update.
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:
EVALUATE_NORMAL - you want to consider the child as a regular e-record event and proceed without any special processing.
IGNORE_SIGNATURE - you want to consider the child as a regular ERES event, but does not want to capture e-signatures.
ERECORD_ONLY - you want to only capture the e-record for the child transaction without evaluating or AME rules.
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.
Navigate to the Configuration Variables window by selecting ERES Administrator Setup.
Search for the event you want to put ad hoc signers on, and click Go.
Click Create to add a new variable.
Enter the variable name Adhoc Signer Capability.
Enter a description.
Change the data type to String.
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.
Click Apply.
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.
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.
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.
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.
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.
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.