ORACLE EDI GATEWAY

Support Document Set Up Verification List

Creation Date: October 23,1999 Updated: January 13, 2000

Page 1 printed 01/15/00 12:23 AM

Document Purpose
The purpose of this document is to provide a simple check off list of the set ups and file reviews for a successful implementation of a transaction in the Oracle EDI Gateway. These items represent common set up oversights that are encountered. Action: Many implementation issues occurred because some of the following steps were bypassed. Please verify all of the following steps before entering a TAR with Oracle World Wide Services (Support ). Place a check mark in the Verified column after the condition when confirming a valid set up. Notes: Read the EDI Gateway User Guide and supplemental documents on the Oracle World Wide Services (Support )s Metalink website. Metalink contains useful information regarding various Oracle Products, Services, and Implementations. Metalink can be accessed at: http://support.oracle.com/metalink/ Document Subjects: 1. Trading Partner Set Ups 2. Code Conversion Set Ups 3. Interface File Record layout and synchronization with the layout in the EDI Translator. 4. Concurrent Manager 5. Multi-Organization Environment consideration 6. Base Oracle application required fields

Document Recommendations: Send document update suggestions to EDISIG@us.oracle.com.

Page 2 printed 01/15/00 12:23 AM

Section 1: TRADING PARTNER (TP) SET UP

Verified Direction Where Topic Note: The Organization of the signed-on user will limit the address sites in the LOV in the TP Assign form. Reference Metalink Document: Trading Partner Setups and their Relationship to Location Codes in the Transaction Interface File Control Record 0010: EDI LOCATION CODE is associated with an address site in the Oracle Payables, Oracle Receivables, or Banks as appropriate for the given transaction. (On the control record the location code is used to 1) Derive the Oracle supplier, or Oracle customer of the transaction, and 2) Checked if the transaction is enabled for the given transaction via the TP Detail form.) Control Record 0010: The EDI TRANSLATOR CODE in the file must be IDENTICAL to the EDI TRANSLATOR CODE defined for the TP via the TP Detail form. (The LOCATION CODE plus the TRANSLATOR CODE is used to derive the Oracle address site in the base application. Using both data fields allows multiple trading partners to use the same Location Code. Therefore, the combination of LOCATION CODE and TRANSLATOR CODE must uniquely identify a Trading Partner.) EDI LOCATION CODES within the transaction (found in the N104, or NAD segments) are found in the External location fields in the file for address records for the ship-to, bill-to, remit-to sites, etc. For most R10.7 outbound transactions, the EDI LOCATION CODES (External codes) are retrieved in the EDI Gateway by doing a Trading Partner lookup. Hence, the Trading Partners must be defined in the EDI Gateway. For a few transactions, location code conversion may be required. (These location code conversions are being reviewed for possible conversion to Trading Partner lookups.) For R11and higher, the EDI LOCATION CODES are retrieved from the base Oracle application where the EDI Location codes are defined for a given transaction. These codes are the external values for the interface files. Have you enabled EVERY transaction that you want enabled in the Trading Partner Detail window and set the Test/Production Flag correctly for that trading partner site? Do you have the correct Location code/Translator Code combination in each Trading Partner set up? R10.7, the location code is defined in the EDI Gateway in the trading partner header region of the form. In R11, if you assign a trading partner to an Oracle Site in Oracle Payables or Oracle Receivables, and it returns a blank LOCATION CODE, make sure the Location Codes are entered before any transaction processing for that trading partner. The EDI Gateway cannot find that address site until the location code is entered.

Inbound

File: Control Record 0010

Inbound

File: Control Record 0010

Inbound

File

Outbound

File

Both

TP Detail Window

Both

TP Detail Window TP Assign Window

Both

Page 3 printed 01/15/00 12:23 AM

Section 2: CODE CONVERSION (CC)

Verified Direction Where Topic Reference Metalink Document: Code Conversion Value Form: Search Key Illustration If code conversion is to be performed on data elements, the following must be done: The CC Category must be listed or newly defined in the Code Conversion Category form. You can create CC Categories as needed. The CC Category must be assigned to the data element in the transaction in the Code Conversion Assignment form. There may be multiple occurrences of a data element in a transaction, e.g., Unit of Measurement. (If CC Categories are not assigned, the code conversion value tables will not be accessed during code conversion for that data element.) If search keys will be used in the Code Conversion Value form, the maximum number of keys to be used must be checked in the Code Conversion Assignment form. (Entries may still be made in the CC Value form with no search keys entered, so the globally used CC records may be used as a default when no entries are found using the specific search key values.) The CC Values containing the Oracle defined internal codes , the 1-5 external codes recognized by the standards or trading partners, and any search keys to limit the ownership of the CC Value records are defined in the Code Conversion Value form. If more than one external code is retrieved from the code conversion value table, verify that the additional external code fields are activated in the interface file. (Usually only one external code is initially defined for the data element in the transaction interface file.) 13 Inbound Code Conversion If the Gateway is to perform Code Conversion, then the EDI Translator must move data only to the External codes for the data element. If codes are found in the Internal code position for the data element, the code conversion value table will not be accessed to find internal codes. It is assuming that the internal codes in the file are accurate so they are automatically copied to the application open interface tables.

In/Out

Code Conversion

In/Out

Code Conversion

10

In/Out

Code Conversion

11

In/Out

Code Conversion

12

Outbound

Code Conversion and File

Page 4 printed 01/15/00 12:23 AM

Section 3: INTERFACE FILES:

Verified Direction Where Topic Reference Metalink Documents: R10.7 Report Scripts For Transaction Interface Record Layouts, and Code Categories Assignments or R11 Report Scripts For Transaction Interface Record Layouts, and Code Categories Assignments UTL_FILE Package and Directory Names For Transaction Interface Files (ECE_UTILITIES package) See the Required Data Fields documents for the base application applicable to the transaction. For example, the Order Entry Inbound Transactions: Transaction Detail and Required Data Elements for the Interface File. 14 In/Out Files The Record layout defined in the EDI Gateway tables and in the EDI Translator must be identical, since our software product is creating the file that the other software product will read. Run the Report Scripts for the record layout in the EDI Gateway. Compare it to the record layout in the EDI Translator. (EDI Translators should provide a similar report against their tables.) The record layout comparison is especially needed if data exception errors are encountered: 1) during the import processes for inbound transactions, or 2) the EDI Translators are having data mapping problems for outbound transactions. Some out of sync record layouts cause error message ORA-1400. Careful, some patches may add new data to the transaction which should be reviewed. IMPORTANT NOTE: Some patches may add new data to the transaction. Carefully review the README.TXT file for the Patch before implementation. 15 In/Out Files Run the ECE_UTILITIES.verify_flatfile PL/SQL procedure to have a transaction file print its data against the record layout to confirm that the correct data is in the correct fields on the file. This is the Interface File Data Report. In R11i, this report is in the standard product in a list of reports. 16 Inbound Files All required field are on the file or derived by the Oracle EDI Gateway. (See documentation on Metalink or the base Applications manual on the specific Open Interface for the inbound transaction for what is required per transaction.) 17 Outbound Files If you think you are missing data from the outbound file, search through the transaction in the R10.7 Output File Definition form or R11 Interface File Definition form (at the data level that you expect to find the data) to see if the data element is at the end of the list of data elements. The data element may be there if it does not have a record number, position, and width assigned it. It needs this data to activate the data field to be written to the interface file.

Page 5 printed 01/15/00 12:23 AM

Section 3: INTERFACE FILES: (continued)

Verified 18 Direction Both Where Files Topic If a patch was recently installed, it may change your transaction record layout. Review the record layout changes in the README.TXT and the Transaction record layout report which should have been executed before and after the patch install. Make desired record layout changes via the Transaction File Definition form. Run the Interface File Data Report script to review a data file against its record layout. (see document on Metalink) 19 Inbound Files For inbound transactions, look for misaligned data in the file. This will happen if the record layout in your translator is not the same as the record layout in the EDI Gateway.

Page 6 printed 01/15/00 12:23 AM

Section 4: CONCURRENT MANAGER

Verified 20 Direction Both Where Request Topic Usually only the transaction interface file name is required. The request will ask for more data if it is required. All transactions, which are eligible to be extracted since the last request was executed, are extracted by the transactions request. If you do not want all the transactions extracted., enter other parameters to limit what is selected.

21

Outbound

Request

Section 5: ORGANIZATIONS in a Multi-Org Environment and Responsibilities

Verified 22 Direction Outbound Where Concurrent Manager Request Topic Outbound Concurrent Manager Requests are associated with the Organization (as defined by the responsibility) of the user submitting the request. Consequently, the outbound request will extract only transactions for Trading Partners assigned to that Organization. Note: The term Organization in this case refers to a single organization (a Multi-Org environment) and should not be confused with Inventory Organization. 23 Inbound In R10.7 and R11, the transactions must be separated by Organization when loaded into the Oracle EDI Gateway. Otherwise, the Trading Partner sites, which are associated with a given organization, will not be found in the EDI Gateway.

Section 6: BASE APPLICATION

Verified 24 Direction Outbound Where Base Application Topic ALL conditions that make a transaction eligible for extraction are satisfied. (otherwise, the transaction cannot be extracted.) Most transactions can be extracted only once, because flags are set that mark them as having been extracted. You will have to null the flags and other fields (such as dates) to extract the transaction again. The extract flag may be the same as the print flag. You may not be able to do both EDI extract and print the document. (Check for detailed documents on this subject in Metalink. They will be placed in Metalink as they are written.)

Section 7: FILE SET UP

Verified 25 26 Direction Both Both Where Topic DBA set up: utl_file_dir are set up properly. Confirm that the file directories are created.

Page 7 printed 01/15/00 12:23 AM

Oracle EDI Gateway October 1999 Author: Bonnie Shebat Williams Copyright Oracle Corporation 1999 All Rights Reserved Printed in the U.S.A. This document is provided for informational purposes only and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document. Oracle is a registered trademark and Enabling the Information Age, Oracle, Oracle EDI Gateway are trademarks of Oracle Corporation.

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: 650.506.7000 Fax 650.506.7200 Copyright Oracle Corporation 1999 All Rights Reserved

Page 8 printed 01/15/00 12:23 AM