This chapter covers the following topics:
Seed data is generally defined as any data delivered with a standard installation of Oracle E-Business Suite. This includes menu definitions, concurrent manager definitions, list of values, and so on. In this chapter, the definition of seed data is limited to the data used for:
Definition of transaction record layouts.
Assignment of code categories to a transaction record layout.
Definition of process rules associated with a transaction.
Definition of column rules associated with a transaction.
Whenever a transaction-specific patch is applied, there may be changes or additions to the transaction record layout. Code category assignments, column rules, and process rules are closely linked to the transaction record layout so these definitions may also be impacted by a change to the transaction record layout.
This Seed Data Reconciliation process allows you to reapply the preexisting transaction record layout, if a patch updated the transaction record layout, or accept the new transaction record layout. Retaining the preexisting transaction record layout gives you a record layout that minimizes or eliminates transaction data map changes for any process that uses your transaction.
In addition to reconciling transaction record layouts, this process also performs reconciliation on the code conversion assignment, column rules, and process rules associated with the transaction record layout changes.
To understand the reconciliation, the transaction record layouts will be in three stages as defined in the following table.
| Transaction Record Layout | Description |
|---|---|
| Pre-existing (before patches applied) | Record layouts before new patches are applied. |
| Patch Applied (before reconciliation) | Record layouts as defined in the patch are stored but are not applied or visible to the user. |
| New (after reconciliation) | Record layouts after patch is applied and reconciliation is executed. |
The Seed Data Reconciliation process does the following when executed:
Runs a comparison of the preexisting the record layout attributes and the new record layout attributes for each column in the transaction.
Identify new columns.
Reapplies your customized preexisting record layout modifications (optional).
Reapplies process rules, column rules, and code conversion category assignments to the columns in the new transaction record layout (optional).
Produces a request log to report discrepancies between the preexisting and new transaction record layouts.
If you have e-Commerce Gateway extension tables for the outbound transaction, you must re-run the SQL script to populate the extension tables and update the interface data file definition. For each new column added to the extension table, you must again insert a record into ECE_INTERFACE_COLUMNS to position the data element in the interface data file.
The following table lists an example of seed data reconciliation. (Record layout attributes include record, position, length, record layout, and qualifier.)
| Data Element | Record Layout Attributes - Before Patch | Record Layout Attributes - In the Patch | Result |
|---|---|---|---|
| ABC | 1000, 100, 30, RF, REF | 1000, 100, 50, RF, REF | If Preserve Transaction Layout is Y, length remains at 30 after reconciliation. If N, length is updated to 50 after reconciliation. |
| ABC | 1000, 100, 50, PO, POI | 1050, 90, 50, RF, REF | Data element given all new record layout attributes in the patch. If Preserve Transaction Layout is Y before patch, attributes are retained after reconciliation. If Preserve Transaction Layout is N in the patch, the patch attributes are used. |
| ABC | does not exist | 1000, 10, 40, RF, REF | New data element is defined in the patch. If Preserve Transaction Layout is Y or N, new data element is added to the transaction record layout. |
| ABC XYZ |
1010, 90, 50, RF, REF does not exist |
1000, 30, 50, RF, RF1 1010, 90, 50, RF, REF |
Two different data elements reference the same record and position number. If Preserve Transaction Layout is Y or N, data elements cannot be automatically reconciled and manual intervention is required to resolve the discrepancy. |
See Also
Performing Seed Data Reconciliation
The following steps accomplish a full Seed Data Reconciliation review:
Run the Transaction Layout Definition Report. (Optional)
Apply the transaction-specific patch.
Submit the Seed Data Reconciliation request.
Run the Transaction Layout Definition Report again. (Optional)
Review the Seed Data Reconciliation request log.
Update the transaction record layout. (If Necessary)
Review and Modify Post Processes using changed transaction record. (If necessary)
Examine the README.TXT files for the patches to identify transactions that may have potential transaction record layout changes.
Select the Run Reports under Reports in the e-Commerce Gateway menu. Submit the Transaction Layout Definition Report to obtain the before images of the transaction record layouts for each transaction of interest to you.
This is an optional step, but it is highly recommended. This step is particularly important if you do not choose to preserve the transaction layout and would like before and after picture of the transaction record layout. See: Reports.
Apply the transaction-specific patch using Oracle's standard patching procedures. An Oracle E-Business Suite wide patchset or e-Commerce Gateway minipack patch may include more than one patch for any transaction and include patches for many transactions.
Select the Seed Data Reconciliation Request under Process in the e-Commerce Gateway menu.
Enter the Transaction Type from the List of Values.
After patches are applied, any transaction that needs seed data reconciliation will appear in the Transaction Type List of Values. Select one of your transactions from the List of Values.
If you do not have a transaction in that list implemented, you need not submit a request for that transaction at this time. You can do so in the future when you are read to implement that transaction.
Select Yes if you wish to Preserve the Transaction Layout. Select No if you do not wish to Preserve the Transaction Layout.
Selecting Yes means that the following record layout attributes will be retained regardless of the patch record layout definition.
Record number.
Position.
Data width.
Record layout code.
Record qualifier code.
Any new record layout definitions defined in the patch will be automatically merged into your preexisting record layout unless a discrepancy is found.
Selecting No means that the transaction record layout from the patch will become the new transaction record layout and any preexisting record layout modifications will be overlaid. Also previously defined Column rules, and Code Conversion Assignment for the transactions will not be reapplied to the new record layouts.
Select Yes or No to Preserve Process Rules for the entire transaction which were previously entered via the Interface File Definition form.
Select Yes or No to Preserve Column Rules which were previously entered via the Interface File Definition form. For a Yes response to be effective, there must also be a Yes response to the Preserve Transaction Layout parameter.
Select Yes or No to Preserve Code Category Assignment which were previously entered via the Assign Code Conversion form. For a Yes response to be effective, there must also be a Yes response to the Preserve Transaction Layout parameter.
When finished, choose OK in the parameter window.
Enter schedule options to schedule the request.
Enter Completion Options
Choose Submit and make a note of the Request ID returned.
Once the request for reconciliation for a particular transaction is completed, the transaction is removed from the Transaction Type's List of Values.
Repeat these steps for each of your implemented transactions that appear in the Transaction Type List of Values.
Select the Run Reports under Reports in the e-Commerce Gateway menu. Submit the Transaction Layout Definition Report to obtain the after images of the transaction record layouts for each transaction of interest to you.
This is an optional step, but it is highly recommended. This step is particularly important if you do not choose to preserve the transaction layout and would like a before and after image of the transaction record layout. See Reports.
If you select no for the Preserve the Transaction Layout parameter above, this log will provide summary information about the Seed Data Reconciliation process. Detailed reporting is not necessary since all of the record layout definitions in the patch will be automatically applied.
If you select yes for the Preserve the Transaction Layout parameter above, this log will provide detailed information about the reconciliation and analysis process used to apply record layout definitions from the patch.
Each data element in the transaction being reconciled will be analyzed for record layout differences. If you selected yes for the Preserve Code Category Assignments or Preserve Column Rules parameter, these definitions will be analyzed for differences as well.
For each data element, the Seed Data Reconciliation Request Log will record any updates automatically applied during the reconciliation process as well as data (e.g. record layout definitions, column rules) which was analyzed, but no update was required.
It is also possible to encounter a situation where automatic reconciliation is not possible and manual intervention is required. This will occur if the preexisting record layout and the record layout in the patch reference the same record/position number for two different data elements. If this occurs, the Seed Data Reconciliation Request Log will report the discrepancy but you must manually define the correct record/position number using the Interface File Definition form.
Following is sample output from the Seed Data Reconciliation Request Log:
***** Column: ”ASN_TYPE” * Checking to see if any Column Rules need to be reconciled... * Column Rule Sequence: 1, Rule Type: VALUE_REQUIRED, Action Code: SKIP_DOCUMENT found and reconciled for this column. * Checking to see if any Code Conversion Assignments need to be reconciled... * No Code Conversion Assignment found for this column. * Record Number and Position for Column: ”ASN_TYPE” at Output Level: 1 unchanged. * Width for Column: ”ASN_TYPE” at Output Level: 1 unchanged. * Conversion Sequence for Column: ”ASN_TYPE” at Output Level: 1 unchanged. * Record Layout Code for Column: ”ASN_TYPE” at Output Level: 1 unchanged. * Record Layout Qualifier for Column: ”ASN_TYPE” at Output Level: 1 unchanged.
Important: The Oracle e-Commerce Gateway does not prohibit the import or extract of a transaction between the time a patch is applied and Seed Data Reconciliation is executed.
If an import or extract is run during this period, the preexisting transaction record layout will be used. In addition, the import/extract will indicate a status of Warning on the View Requests form. A message will also be included in the request log indicating that the import/extract has been executed before Seed Data Reconciliation has been performed.
Oracle recommends that import/extract processes are not executed after a patch is applied and before Seed Data Reconciliation
Change Transaction Record Layout (if necessary).
If you selected No at the Preserve Transaction Layout prompt, you may need to reapply any customized record layout definitions, code category assignments, or column rules. Use the Interface File Definition form to reapply these assignments and definitions.
Notify trading partners if there are interface file changes that affect their process. If the new transaction record layouts impacts data maps in any subsequent or preceding processes, make appropriate changes to the data maps.