Oracle E-Commerce Gateway Implementation Manual, Volume 1

Oracle e-Commerce Gateway Implementation Manual
Oracle e-Commerce Gateway Implementation Manual, Volume 1
Release 11i
March 31, 2000 Part No. A75164-01
Oracle e-Commerce Gateway Implementation Manual, Release 11i Part No. A75164-01 Copyright 2000, Oracle Corporation. All rights reserved. Primary Author: Bonnie Shebat Williams, Fred Graham, Debbie Quezadaz, Janet Lee Steve Moriarty, Dan McCoy, Geoffrey Scott-Baker, Steve Nelson, David
Contributing Authors: Wrightson Contributors:
David Reitan
The Programs (which include both the software and documentation) contain proprietary information of Oracle Corporation; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs is prohibited. The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Oracle Corporation. If the Programs are delivered to the U.S. Government or anyone licensing or using the programs on behalf of the U.S. Government, the following notice is applicable: Restricted Rights Notice Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication, and disclosure of the Programs, including documentation, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication, and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-19, Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065. The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and Oracle Corporation disclaims liability for any damages caused by such use of the Programs. Oracle is a registered trademark, and is trademark or registered trademark of Oracle Corporation. All other company or product names mentioned are used for identification purposes only and may be trademarks of their respective owners.
Contents
Send Us Your Comments ................................................................................................................... ix Preface............................................................................................................................................................ xi 1 Introduction
Purpose of the Implementation Guide........................................................................................... Documentation.................................................................................................................................... Oracle e-Commerce Gateway Overview ....................................................................................... Processing Traditional EDI Transactions ................................................................................ EDI Translators ........................................................................................................................... 1-2 1-3 1-4 1-12 1-17
Implementation Positioning
Implementation Positioning............................................................................................................. Other Application Implementations.......................................................................................... Determine Communications Methods For The Transactions ................................................ Implementation Planning.......................................................................................................... 2-2 2-5 2-9 2-11
Oracle e-Commerce Gateway Implementation Checklist

Implementation Steps........................................................................................................................ Implementation Checklist for Software Upgrade........................................................................ Implementation Checklist for Fresh Install .................................................................................. Implementation Checklist for Maintenance Patch ...................................................................... 3-2 3-3 3-7 3-8
Implementation Details
Report Scripts ...................................................................................................................................... Define Responsibilities..................................................................................................................... Define UTL_FILE_DIR Parameter in INIT.ORA File.................................................................. Review Release 11i Upgrade Guideline......................................................................................... Set Up Profiles................................................................................................................................... 4-2 4-4 4-5 4-7 4-10
iii
System Profile Window ............................................................................................................. Transaction Specific Options .................................................................................................... Outbound Purchase Order Transaction Profile ..................................................................... Determine Process and Column Rules and Actions .................................................................. Enable Additional Transaction Data............................................................................................. Modify Transaction Interface File ................................................................................................. Synchronize New Transaction Layout Definitions with Translator ....................................... Common Transaction Interface File Definition Errors.............................................................. Set Up Trading Partners................................................................................................................... Common Set Up Errors.............................................................................................................. Set Up Code Conversion ................................................................................................................. Interface with Translators ............................................................................................................... .................................................................................................... Transaction Data File Report Communications......................................................................................................................... Archive/Backup.................................................................................................................................
4-11 4-15 4-16 4-18 4-25 4-29 4-35 4-36 4-37 4-40 4-41 4-45 4-46 4-48 4-49
Transaction Interface File Architecture

File Structure Overview..................................................................................................................... Interface Data File Structure............................................................................................................. Special Records ............................................................................................................................. Optional Outbound Trading Partner Flexfield Records (0020-0070) ...................................... Common Record Key (1-100) .................................................................................................... Common Records (Based on Record Layout Code) .............................................................. Code Conversion Internal and External Codes on the File ...................................................... 5-2 5-5 5-7 5-12 5-13 5-17 5-25
Application Transaction Detail

Oracle Inventory ................................................................................................................................. 6-2 Oracle Order Management ............................................................................................................... 6-5 Oracle Payables ................................................................................................................................... 6-6 Inbound Invoice (INI/810/INVOIC) ........................................................................................ 6-8 Inbound Shipment and Billing Notice (SBNI/857/No EDIFACT) ..................................... 6-15 Outbound Application Advice (ADVO/824/APERAK)...................................................... 6-16 Outbound Payment Order/Remittance Advice (PYO/820/PAYORD-PAYEXT-REMADV) ... 6-18 Oracle Process Manufacturing ....................................................................................................... 6-24
iv
Oracle Purchasing............................................................................................................................. Inbound Price/Sales Catalog (CATI/832/PRICAT) Inbound Response to Request for Quotation (RRQI/843/QUOTES 6-27 Inbound Ship Notice/Manifest (ASNI/856/DESADV) Inbound Shipment and Billing Notice (SBNI/857/No EDIFACT) 6-36 Outbound Application Advice (ADVO/824/APERAK)...................................................... Outbound Purchase Order (POO/850/ORDERS)................................................................. Outbound Purchase Order Change (POCO/860/ORDCHG) ............................................. Oracle Receivables............................................................................................................................ Outbound Invoice (INO/810/INVOIC) ................................................................................. Outbound Credit Memo/Debit Memo (CDMO/812/CREADV-DEBADV)..................... Oracle Release Management .......................................................................................................... Oracle Shipping Execution ............................................................................................................. Oracle Supplier Scheduling ........................................................................................................... Outbound Planning Schedule (SPSO/830/DELFOR) .......................................................... Outbound Shipping Schedule (SSSO/862/DELJIT) .............................................................
6-25
6-48 6-49 6-52 6-55 6-56 6-59 6-62 6-63 6-64 6-65 6-69
Test Transactions
Testing Inbound Transactions .......................................................................................................... 7-2 Testing Outbound Transactions ....................................................................................................... 7-6 Printing and Extract of Documents ................................................................................................. 7-8
Troubleshooting
Troubleshooting ............................................................................................................................... ... Error Messages .................................................................................................................................... Inbound Transactions ...................................................................................................................... Transaction Exception Summaries........................................................................................... Reports ............................................................................................................................... ................. 8-2 8-4 8-11 8-13 8-16
Trading Partner
Trading Partner.................................................................................................................................... Trading Partner Group....................................................................................................................... EDI Location Codes............................................................................................................................ Translator Codes............................................................................................................................... ... 9-2 9-3 9-4 9-6
Translator Code and EDI Location Code Across Applications .................................................. Linking Trading Partner Data to the Oracle Application Source ........................................ EDI Location Codes in the Transaction Interface Files ............................................................. Multi Organizations......................................................................................................................... Organizations in Oracle Application Open Interface Tables ............................................... Trading Partner Windows.........................................................................................................
9-9 9-11 9-13 9-20 9-24 9-25
10
Code Conversion
Code Conversion............................................................................................................................... 10-2 Concatenated Search Key for Inbound Transactions .......................................................... 10-32 Concatenated Search Key for Outbound Transactions............................................................ 10-38
11
Extensible Architecture
Customizing EDI Transactions....................................................................................................... 11-2 Descriptive Flexfields ...................................................................................................................... 11-4 Steps for Extensible Architecture .................................................................................................. 11-8
A Transaction Summary Layouts

Oracle Inventory Transaction Summaries...................................................................................... Current Information..................................................................................................................... Oracle Order Management Transaction Summaries.................................................................... Current Information..................................................................................................................... Oracle Payables Transaction Summaries ....................................................................................... Current Information..................................................................................................................... Inbound Invoice.......................................................................................................................... Oracle Process Manufacturing Transaction Summaries ........................................................... Current Information................................................................................................................... Oracle Purchasing Transaction Summaries ................................................................................. Current Information................................................................................................................... Oracle Receivables Transaction Summaries................................................................................ Current Information................................................................................................................... Oracle Release Management Transaction Summaries............................................................... Oracle Shipping Execution Transaction Summaries ................................................................. Current Information................................................................................................................... A-2 A-2 A-7 A-7 A-8 A-8 A-11 A-28 A-28 A-29 A-29 A-72 A-72 A-90 A-91 A-91
vi
Oracle Supplier Scheduling Transaction Summaries................................................................ A-92 Current Information................................................................................................................... A-92
vii
viii
Send Us Your Comments

Oracle e-Commerce Gateway Implementation Manual, Release 11i
Part No. A75164-01
Oracle Corporation welcomes your comments and suggestions on the quality and usefulness of this publication. Your input is an important part of the information used for revision.
s s s s s
Did you find any errors? Is the information clearly presented? Do you need more information? If so, where? Are the examples correct? Do you need more examples? What features did you like most about this manual?
If you find any errors or have any other suggestions for improvement, please indicate the chapter, section, and page number (if available). You can send comments to us in the following ways:
s s s
E-mail - edisup@us.oracle.com FAX - 650.506.7812 Attn: Oracle e-Commerce Gateway Postal service: 3op9 Oracle Corporation Oracle Oracle e-Commerce Gateway Documentation 500 Oracle Parkway, 3op6 Redwood Shores, CA 94065 USA
If you would like a reply, please give your name, address, and telephone number below.
If you have problems with the software, please contact your local Oracle Support Services.
ix
Preface
The Oracle e-Commerce Gateway Implementation Manual is used to implement application integrations for electronic commerce.
Intended Audience
This manual is intended for anyone who is interested in implementing Oracle e-Commerce Gateway.
Structure
This manual contains eleven chapters and one appendix:
Chap
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8
Introduces Oracle e-Commerce Gateway implementation. Explains Oracle e-Commerce Gateway implementation additional requirements. Contains the Oracle e-Commerce Gateway implementation checklist. Provides Oracle e-Commerce Gateway implementation details. Contains the details of the Transaction Interface File Architecture. Explains the transaction details by Oracle application. Explains how to test an inbound or outbound transaction . Contains information regarding troubleshooting Oracle e-Commerce Gateway errors.
xi
Chapter 9 Chapter 10 Chapter 11 Appendix A
Explains in detail about Oracle e-Commerce Gateway Trading Partners. Explains how to define and use Code Conversions used by Oracle e-Commerce Gateway. Describes Extensible Architecture and how it relates to outbound transactions. Includes the transaction summary layouts by product.
Related Documents
For more information, see the following manuals in the Release 11i Oracle Applications Open Interface Guides:
s
Oracle e-Commerce Gateway Users Guide Oracle Purchasing Users Guide Oracle Supplier Scheduling Users Guide Oracle Payables Users Guide Oracle Receivables Users Guide Oracle Order Management Users Guide Oracle Shipping Execution Users Guide Oracle Release Management Users Guide Oracle Manufacturing, Distribution, Sales and Service Open Interface Manual Oracle Payables Users Guide, Payables Open Interface Oracle e-Commerce Gateway Technical Reference Manual Oracle Purchasing Technical Reference Manual Oracle Supplier Scheduling Technical Reference Manual Oracle Payables Technical Reference Manual Oracle Receivables Technical Reference Manual Oracle Order Management Technical Reference Manual Oracle Shipping Execution Technical Reference Manual Oracle Release Management Technical Reference Manual
xii
Conventions
In examples, an implied carriage return occurs at the end of each line, unless otherwise noted. You must press the Return key at the end of a line of input. The following conventions are also used in this manual:
Convention Meaning Angle brackets enclose user-supplied names. What follows is the actual SQL statement.
<> >
xiii
xiv
1
Introduction
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Purpose of the Implementation Guide on page 1-2 Documentation on page 1-3 Oracle e-Commerce Gateway Overview on page 1-4
Introduction 1-1
Purpose of the Implementation Guide
Purpose of the Implementation Guide

The Oracle e-Commerce Gateway Implementation Guide provides details to facilitate implementation of the product, and highlights additional actions to ensure a successful implementation. While Oracle e-Commerce Gateway is in itself, a comprehensive product that will suit most customers e-business integration requirements, most of the effort expended during an implementation cycle concerns defining, mapping, and balancing customer requirements against trading partner expectations. This guide includes implementation details, and contains an overview of the main points that should be taken into consideration during the course of an Oracle e-Commerce Gateway project. The Oracle e-Commerce Gateway Implementation Guide provides the following:
s
Required knowledge profile for an implementer Implementation checklist Profiles and validation rules setup details Trading Partner setup details and recommendations Code conversion setup details and recommendations Oracle Application setups for the transactions Transaction interface file architecture Transaction interface file modification guidelines Testing recommendations Details about the supported transactions Trouble Shooting tools and recommendations Recommendations on how to extend the supported transactions Note: Details for adding transactions not supported by Oracle e-Commerce Gateway are not included in this document.
1-2
Documentation
Documentation
The following documentation for Oracle e-Commerce Gateway is available:
s
Oracle e-Commerce Gateway Users Guide Oracle e-Commerce Gateway Technical Reference Manual (TRM) Someone in your organization may need this manual if any customizations such as extension tables are implemented.
Oracle Manufacturing, Distribution, Sales and Service Open Interface Manual Oracle Payables Users Guide Note: Get the latest Oracle e-Commerce Gateway supplemental documents from Oracle Support Services Metalink web site. See the preface for more details about this web site.
Introduction 1-3
Oracle e-Commerce Gateway Overview

e-Business Integration
Oracle e-Commerce Gateway is a standards-based integration product for Oracle Applications. This integration product allows you to integrate Oracle Applications with applications residing inside or outside of your enterprise, communicating via the Intranet, Extranet, or the Internet. Oracle e-Commerce Gateway evolved from the Oracle EDI Gateway product, focusing on Electronic Data Interchange (EDI) into a product focused on e-business integration. All the features and functions of Oracle EDI Gateway are retained and enhanced to create the Oracle e-Commerce Gateway product.
Oracle e-Commerce Gateway supports seamless integration, streamlined implementation, and rule-based transaction processing to automate your business operations. The major features include:
s
Open and Extensible Architecture
1-4
Streamlined Transaction Implementation Configurable Integration Environment Rule-Based Process Management Reports
Oracle e-Commerce Gateway is designed with an open and extensible architecture for easy integration with any third party application. The product is architected with self-contained yet integrated modules focused on ease of implementation; you simply define the business rules and configuration parameters, then you can implement any of the pre-built transactions. Extensibility hooks are provided to integrate custom transactions and extend the Oracle e-Commerce Gateway supported transactions by incorporating data from non-Oracle Applications data sources.
Configurable Integration Environment

Oracle e-Commerce Gateway supports configurations at the system, transaction, trading partner, and process levels giving you utmost control of your data, interface files, and business processes. You can configure how data elements are validated and mapped, the structure and layout of an interface file, when a business process is initiated, and how it should proceed. Furthermore, you can control the behavior of a process if an exception is detected. All rules are stored in a repository to support dynamic run-time message creation, automated process monitoring, and exception analysis. Using a single window, you can change a rule by changing the information stored in the Oracle e-Commerce Gateway repository. The updated rule takes effect at run-time without any code modifications. System level configurations apply to all transactions, and include the following:
s
Define inbound/outbound file directory Enable/disable transactions Define text wrapping rules
Transaction level configurations apply to a specific transaction, and include the following:
s
Validation Rules
Introduction 1-5
Code Conversions Transaction Layout
By defining the validation rules, you indicate how a transaction is to be validated, what constitutes an exception, and what action to take if an exception is detected. This ensures that only valid transactions are passed to Oracle e-Commerce Gateway for processing. Oracle e-Commerce Gateway supports the following validation and exception processing rules: The transaction exception rules include invalid trading partner, invalid Address, nd Test/Production mode discrepancy. The data validation rules include:
Data Rule Data Type Checking Default if Null Null Dependency Predefined List Description Compare the data types of the data in the file to the data type defined in Gateway transaction table. Move a default value to the staging table column, if the field is NULL (blank) in the interface file. Checks if the incoming data for a given column has a null dependency. Checks if the incoming data for a given column is equal to or not equal to a value in a predefined list in the Oracle e-Commerce Gateway. Checks if the incoming data for a given column is a valid value equal to the one found in the user-defined table and column that will be used in a SQL Select Statement. Checks if the incoming data for a given column is a valid value in a standard Oracle Valueset. Checks if the incoming data for a given column has a non-null value, i.e. it cannot be blank.
Simple Lookup
Valueset Lookup Value is Required
Each rule is associated with an action taken when an exception is detected. The exception processing options are skip current document, log the violation and continue processing, or abort the entire run. Another form of transaction configuration is performed on the transaction data, based on user-defined code conversion rules. The Oracle e-Commerce Gateway Code Conversion module supports the following:
s
One Oracle code to one external code
1-6
One Oracle code to many external codes Criteria-based code conversion Intelligent search for Oracle or external code(s)
An example of a one-to-one relationship is the conversion of a single Oracle code for unit of measure to a unit of measure code based on the ISO 9000 code list, the ASC X12 code list, or your private code list. An example of a one to many relationship is the conversion of a single Oracle code for payment terms to its ASC X12 components for discount percent, discount days, and net days. You can define a code conversion rule that applies to all transactions for all trading partners or one that is specific to a trading partner and transaction combination. For maximum flexibility, you can define up to five specific criteria per rule. Intelligent search is used to identify the Oracle internal or external codes by performing the search using the maximum number of user-defined criteria then reducing the number of criteria by one until a match is found. If a match is not found, a default is used. The final transaction configuration is related to the transaction layout. Oracle e-Commerce Gateway delivers seeded transaction layout definitions representing relevant business data from or to Oracle Applications. The transaction layout definitions may be used as is, or customized to match the data you transmit to your trading partner. The transaction layout configuration options include change file structure, change record layout, change record attributes, and delete records. In addition to the system and transaction level configurations, you may configure the trading partner attributes. The trading partner is the entity you are doing business with and is the key link between Oracle e-Commerce Gateway and Oracles suite of e-business products and between Oracle e-Commerce Gateway or any third party application. The third party application may be an EDI translator for EDI transactions or any other application internal or external to your enterprise. In addition to establishing these links, you can configure the trading partner attributes to indicate that a transaction is enabled or disabled for processing, and indicate the transaction status to be test or production for processing. Once all the necessary system, transaction and trading partner level configurations are defined, and you are ready to initiate a transaction, Oracle e-Commerce Gateway supports three processing options: Event-driven processing for time critical business transactions such as electronic payments or ship notices.
Introduction 1-7
Schedule-based processing for less critical but routinely used business transactions such as purchase orders. User-defined processing. The processing option you select depends on the nature of your business and transaction criticality. Once the transaction process is initiated, the run-time execution engine takes over and proceeds according to the system, transaction, and trading partner configurations you defined. If necessary, a user-activated run-time execution log is available to assist with trouble shooting. This diagnostic tool supports multiple levels of trace details for both technical and non-technical analysts.
View Transaction Exceptions

The status of a transaction process and any reported exceptions may be viewed using a single workbench style window known as the View Staged Documents window. Summary or detailed inquires are supported using tree style navigation. Dynamic windows and drill-downs are provided to help analyze the cause of an exception. Once the cause of the exception is identified and resolved, you have the option to submit the transaction for reprocessing or treat the exception as a warning by ignoring or deleting the exception. The status inquiry, trouble-shooting and re-processing of transactions are all done in one single window, the View Staged Documents window. Several reports facilitate the implementation process. Use the reports to view trading partner and code conversion data or review the seeded transaction layout definitions, and the contents of a data file.
Transaction List
Oracle e-Commerce Gateway is independent of all EDI standards and can be integrated with any upstream or downstream process via an ASCII file. It is this independence that enables you to select any EDI translator or third party application that best suits your business requirements. Included in the Oracle e-Commerce Gateway product are many pre-built business critical transactions, and integration configuration tools designed to streamline your implementation to easily transform your business to e-business.
1-8
X12 Tran. 850 855 856
EDIFACT Message ORDERS ORDRSP DESADV Direction inbound outbound outbound Description Purchase Order into Oracle Process Manufacturing Purchase Order Acknowledgment from Oracle Process Manufacturing Ship Notice/Manifest from Oracle Process Manufacturing
X12 Tran. 850 860 832 843 856 857
EDIFACT Message ORDERS ORDCHG PRICAT QUOTES DESADV no equivalent Direction Description outbound Purchase Orders outbound Purchase Order Change Request inbound inbound inbound inbound Price/Sales Catalog Response to Request for Quotation Ship Notice/Manifest Shipment and Billing Notice Base Oracle Application from Oracle Purchasing from Oracle Purchasing into Oracle Purchasing into Oracle Purchasing into Oracle Purchasing into Oracle Purchasing and Payables from Oracle Purchasing and Payables
824
APERAK
outbound Application Advice, diagnostic message used in response to the inbound ship notice, shipment/billing notice, and invoice transactions
830 862
DELFOR DELJIT
outbound Planning Schedule outbound Shipping Schedule
from Oracle Supplier Scheduling from Oracle Supplier Scheduling
Introduction 1-9
810
INVOIC
inbound
Invoice, includes data for the ASC X12 110, 210, 410, 880 transactions
into Oracle Payables
820
PAYORD/ REMADV
outbound Payment Orders / Remittance Advice inbound Purchase Orders
from Oracle Payables
850 855 860 865
ORDERS ORDRSP ORDCHG ORDRSP
into Oracle Order Management from Oracle Order Management from Oracle Order Management from Oracle Order Management from Oracle Shipping Execution into Oracle Release Management into Oracle Release Management into Oracle Release Management from Oracle Receivables
outbound Purchase Order Acknowledgments inbound Purchase Order Changes
outbound Purchase Order Change Acknowledgments
856 830 862 866
DESADV DELFOR DELJIT no equivalent
outbound Ship Notice/Manifest inbound inbound inbound Planning Schedule Shipping Schedule Production Sequence
810
INVOIC
outbound Invoice, includes data for the ASC X12 110, 210, 410, 880 transactions
812 N/A
CREADV/ DEBADV CUSDEC
outbound Credit Memo, Debit Memo outbound Movement Statistics (INTRASTAT)
from Oracle Receivables from Oracle Inventory
The following transactions are available with Oracle Process Manufacturing. The Inbound Purchase Order and Outbound Ship Notice/Manifest transactions are based on the Oracle Process Manufacturing data model and should be treated as different transactions even though they share the same name as their respective transactions in Oracle Order Management.
1-10
X12 Tran. 850 855 856
EDIFACT Message ORDERS ORDRSP DESADV Direction Description inbound Purchase Order Base Oracle Application into Oracle Process Manufacturing from Oracle Process Manufacturing from Oracle Process Manufacturing
outbound Purchase Order Acknowledgment outbound Ship Notice/Manifest
Introduction 1-11
Processing Traditional EDI Transactions

Although Oracle e-Commerce Gateway has evolved into an e-business integrator, it continues to be the hub for processing high volume traditional EDI transactions. The following section describes how traditional EDI transactions are processed through Oracle e-Commerce Gateway.
Interface Files between Oracle e-Commerce Gateway and Any Translator

ASCII files are passed between Oracle e-Commerce Gateway and any Translator for traditional EDI transaction processing. For inbound transactions, the Translator copies the data from its position in the standard EDI transaction to its required position in the Oracle transaction interface file. The reverse data mapping is done for outbound transactions. Oracle e-Commerce Gateway creates a transaction interface file of the data from the base Oracle Application. The Translator copies the data to its position in the chosen standard. The following graphic is an example Oracle e-Commerce Gateway outbound purchase order (POO) interface file on the left, and the ASC X12 purchase order (850) transaction on the right.
1-12
0010 => ISA, GS 1000 => BEG
2000 => PO1
3000 => SCH
Oracle e-Commerce Gateway extracts outbound transaction data from application tables and loads inbound transactions into the base Oracle Application Open Interface tables.
Introduction 1-13
The components and transaction flows are shown below.
Oracle Application Oracle e-Commerce Gateway
85 35
0B
T1
Translator
ISA ~ G~ 00 N1 ~S T~ Outbound BE
Interface File
78 89 SG 41 82 55 20
Message
Outbound Flow of a Transaction with Oracle e-Commerce Gateway
Oracle Application
Oracle Application Open Interface
Oracle e-Commerce Gateway
85 0B T1 2 35 78 9S G 41 82 55 20
ISA ~ BE G~ 00 N1 ~S T~
Interface File
Translator
Inbound Message
Inbound Flow of a Transaction with Oracle e-Commerce Gateway
Oracle e-Commerce Gateway resides between Oracle Applications and a translator and processes data using ASCII interface files. The EDI Translator accommodates the EDI standards such as ASC X12 and EDIFACT, and monitors transmitting standard formatted data between Trading Partners. The format and content of this file can be adjusted using the Interface File Definition window within Oracle e-Commerce Gateway, though any changes must be implemented within the EDI Translators data map and set-up. An EDI Translator data map may be defined to produce a transaction according to the recommendations of any industry guideline such as UCS, EIDX, or AIAG. A data map may accommodate the data requirements of a single trading partner or many trading partners.
1-14
Oracle e-Commerce Gateway processes data via the transaction interface file that is received from or sent to the Translator. Oracle e-Commerce Gateway is independent of all standard formats since only the business data is found in the Oracle e-Commerce Gateway transaction interface files. Oracle e-Commerce Gateway does not have communication software to transmit the standard formatted data between trading partners. Oracle e-Commerce Gateway relies on the Translator being connected to third party communication service providers to transmit data to, or receive data from, trading partners after the data is mapped to the desired standard format.
Outbound Process Flow

Oracle e-Commerce Gateway outbound transaction process creates interface data files to support any EDI Standard that is available from the Translator. Oracle e-Commerce Gateway collects all of the business data needed to map to a standard EDI transaction which the receiving Trading Partner can interpret properly into their receiving application using their equivalent of Oracle e-Commerce Gateway/Translator set up. Oracle e-Commerce Gateway extracts the data from the base application tables, and optionally extracts data from other files/tables via extension tables. The use of extension tables requires the customization of standard code packages provided with Oracle e-Commerce Gateway. Oracle e-Commerce Gateway does the following:
s
Reviews the System and Transaction profiles. Gets Trading Partner processing parameters, e.g. location codes, allowable/enabled EDI transactions, etc. Extracts data from Oracle base applications tables relevant to the transaction being processed. Optionally, retrieves data from customer defined extension tables (requires some customization). Applies code conversions (when set up and activated). Populates Oracle e-Commerce Gateway tables with all the data gathered. Sets the data extract flags in the base Oracle Application table to prevent subsequent re-extraction. Produces an interface data file for use by the EDI Translator.
Introduction 1-15
Inbound Process Flow

The inbound transaction flow is similar to the outbound transaction flow. Oracle e-Commerce Gateway performs the following functions during an inbound transaction process after it receives an interface file from the EDI Translator or other process:
s
Reviews the System and Transaction profiles. Gets Trading Partner validation processing parameters. Validates data based on user-defined process rules for the transaction. Applies code conversions (if set up and activated). Validates data based on user-defined column rules for the data elements. Captures transaction data exceptions. These exceptions can be reviewed on-line from the staging tables to examine the exception condition. The correction action is performed in a trading partner set up or other application set up, then the transaction can be revalidated. Optionally transactions may be deleted from the view staging tables. Loads valid transactions into the appropriate Oracle Application Open Interface tables for the transaction.
All the valid transactions are loaded into the Application Open Interface tables where it is validated by Oracle Open Interfaces Application Program Interfaces (APIs). Valid data is loaded into Oracle Application base tables. Exception data is detected both in Oracle e-Commerce Gateway and Oracle Applications depending on the type of exception encountered. For example, Oracle e-Commerce Gateway would detect that the trading partner was not set up for a given transaction, whereas the base Oracle Application API would detect a duplicate invoice. The applications standard error handling functions are used to identify, report, and resolve errors. Errors detected by the Translator are resolved by the error handling in that process. Reoccurring data errors that originate from the sender should be discussed with the trading partner for permanent corrections.
1-16
EDI Translators
The following section describes function performed by an EDI Translator in the processing of traditional EDI transactions. The various standards for message formatting are both precise and potentially changing, in addition, there are many issues regarding the various addressing methods and communication protocols that may be used for the actual exchange of transactions. A formatting and communications interface is therefore required between Oracle e-Commerce Gateway and the external communications service. This interface software is called the EDI Translator. There are a number of specialist companies who operate in this area offering packages to address these requirements. EDI Translators generally provide tools to map any interface data file format to any format including standard EDI transactions and messages, so data mapping to a standard like SPEC2000 should not be an issue with most Translator providers. They may not provide predefined data maps for all standards, but their software should provide a means to handle any-to-any data mapping. Another key feature provided by the Translator is communication error and format checking to ensure that invalid messages are rejected and returned. Translator software normally provides built in support for one or more of the EDI standards and communication methods. It may also offer support for pre-packaged extension products that include proprietary file formats. EDI Translators perform the following main functions:
1.
Integrated Audit Trail. Provides an audit trail of transaction activity and profile updates.
2.
Trading Partner Identification. Trading partner identifications are maintained to define which transactions are enabled for test or production, which EDI standard and its version/release to map the data, define data for the electronic envelope, define the communications method to be used, etc.
3.
Standards Translation. Maintains ASC X12 and EDIFACT transaction tables for all versions/releases, XML, and other standards as needed .
4.
Data Mapping. Provide data mapping facilities between proprietary formats and the standards.
Introduction 1-17
5.
Communications. Provides scripts to access popular VANs and VASPs, They also have the capability to send data over the Internet.
6.
Short-term Transaction Archival. Requeues transactions to transmit again as needed.
7.
Automatic Transaction Status Feedback to the Application Feedback is provided to Oracle Applications that transactions have confirmed receipts from trading partners or some other transmission status, e.g. buyers may wish to see a confirmation that a supplier received (or not) a specific order.
8.
Audit Transaction Archival. Maintains historical archival of data for audit purposes.
1-18
2
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Implementation Positioning on page 2-2
Implementation Positioning 2-1
To successfully implement the Oracle e-Commerce Gateway and enable specific transactions within the product, the implementers needs to have certain knowledge and experience beyond the Oracle e-Commerce Gateway. This section describes those additional requirements.
Understand Standards
If traditional EDI transactions are being implemented, the following must be understood: Understand Standard Components Implementers must be familiar with all EDI standards components, i.e., segments, elements, and code values that make up EDI transactions for which the E-Commerce Gateway interface is being implemented. Implementors must know which elements in an EDI transaction correspond with fields in an Oracle E-Commerce Gateway interface file to be able to assist with Translator software mapping. Implementors must be familiar with codes (qualifiers) that are used to identify data elements in an EDI transaction. Understand Characteristics of the EDI Transaction Implementors must be familiar with the characteristics of an EDI transaction. For example, the ASC X12 standard Purchase Order 850 transaction has a three level structure: Header, Item, and Shipments. The Oracle Order Management OrderImport open interface has a two level structure: header and the combined Item/Shipments. Each combination of the Item and Shipment in the transaction must be combined to create an item record in the transaction interface file. Understand the Data Mapping Requirements Implementors should review the clients data mapping requirements to identify elements for which there is no corresponding field in the Oracle E-Commerce Gateway transaction interface file. For example, the Trading Partner may send data at the detail line level in a purchase order transaction that identifies their warehouse bin/bulk location. The Trading Partner requires the supplier to print this data on a label and apply the label to each carton associated with the detail line item. This carton label facilitates the Trading Partners receiving process. If necessary, it is recommended that the EDI implementation team include an application specialist in the relevant transaction area.
2-2
Understanding the Oracle e-Commerce Gateway Functions

Attend an Oracle E-Commerce Gateway Course Implementors should attend an Oracle E-Commerce Gateway course. They must understand all the features including profile set ups, process rules, column rules, trading partner definitions, and code conversion for setting up the product. Understand Trading Partner Set Ups It is essential that the relationship between Translator and EDI Location Codes be completely understood. Also a policy should be put in place with the customer so an administrator can easily maintain the trading partner set up screens given only basic data about the Trading Partner, Location, and permissible transactions. Understand General Code Conversion Set Ups The Code Conversion capabilities of the Oracle e-Commerce Gateway can provide a comprehensive set of criteria to convert internal Oracle codes, site codes, payment codes etc. to/from the terms used by the Trading Partners. These conversions can be undertaken globally or based upon specific criteria using up to five keys - see the Oracle e-Commerce User Manual for more details. Conversion requirements should be carefully planned and kept as simple as possible to avoid over complex situations requiring burdensome maintenance. Understand Extension tables (for Outbound Transactions) Implementors should understand or have access to a developer who understands PL/SQL and how data is stored in the database. They can determine feasibility of changes, how to make those changes without disturbing the existing routines, and how to make them in such a way that the changes can be easily adapted when patches are installed. This also applies to inbound transactions when additional routines are needed to make the data put into the interface tables by the Oracle e-Commerce Gateway compatible with the import process and/or the customers needs. A basic knowledge of the table structure of the relevant Oracle Applications and Oracle e-Commerce Gateway is a big advantage if any custom work is contemplated.
Understand Oracle Applications and Application Open Interfaces

Know the Transient Data in the Oracle Application The Oracle Applications produce data as needed by the application. They may not retain data in the tables that is calculated because the numbers used to produce the calculation (number of units and discount percentage in the example below) may change each time the application is run. The data is printed on a permanent paper document. Because EDI is a substitute for the paper document, this data must be computed and stored in the outgoing file. The implementer must allow for this by defining a field in the EDI extension table and the code to populate it. Know the Functionality of the Oracle Application Verify that the Oracle Application performs the function expected by the transaction. Know the Required Fields and Default Data Know the required fields in the transaction interface file and the application open interface and know the defaults defined in the Oracle e-Commerce Gateway for the transaction The open interface tables require certain fields to be populated to properly process the incoming data. Because it is not known whether the data is available on the source system, a default value can be used so that processing can continue. Required fields and default values are dependent on how the application is configured to handle keyboard entry in setup. It is also very important that the base application is set up with the data that it is expecting.
2-4
Other Application Implementations

For standard transactions, an e-Commerce environment must be installed. Generally the following must be done in the Translator specifically and the e-Commerce environment generally. This document does not discuss the detail of installing Translators or the operation of Translators.
Translators
Each company must install a Translator to processes traditional standard transactions such as ASC X12 transactions and EDIFACT messages. They must review its system requirements, and its integration requirements with the Oracle e-Commerce Gateway. The ability to configure the Translator to suit different formats is also a consideration to facilitate any changes that may be required from updates to the Oracle e-Commerce Gateway. These changes may be in the form of new or additional transactions, changes in the customers business requirements, and changes occasioned by new or existing trading partners. If the Translator is difficult to update or configure, this may impact the successful, timely outcome of an EDI implementation. Another consideration is whether or not the Translator is running on the same server as the Oracle e-Commerce Gateway. In some cases, the Translator has been installed on a separate machine, for example a mainframe. When this is the case, it is necessary to allow for file transfer requirements and scheduling to/from the Translator. In some instances a file transfer to/from a mainframe may require that the file be of fixed length. In this case. the variable nature of the files used by the Oracle e-Commerce Gateway may pose problems of padding (for outbound transactions) and interface file definition (for inbound transactions). Trading Partner Definitions Translators have criteria for defining trading partners, that is different from the trading partner definitions used in the Oracle e-Commerce Gateway. The Translator set up requires identifying the following:
s
Sender and receiver identification codes for the electronic envelopes. The EDI standard and its version/release or data dictionary for traditional EDI transactions.
The transactions data map used to map data between the source data file and the standard transaction. Which code conversion sets are to be used for the transaction for the trading partner. Communication method. Communication service provider.
The Oracle e-Commerce Gateway requires the Translators identification code for its trading partner definition in the transaction interface file on the Control Record 0010. It is defined at the Translator Code in the trading partner set up in the Trading Partner Detain tab in the Trading Partner set up. Code Conversion Like the Oracle e-Commerce Gateway, Translators provide for code conversion between the value defined in the base Oracle Application and the values required by the EDI standard or the trading partner. Code conversion is performed on specific data elements. You can use the Oracle e-Commerce Gateway for some data elements and the Translator on other data elements. You should decide where it is most efficient for your implementations, bearing in mind how easy it will be in the future to add, edit, or delete conversions in the Oracle e-Commerce Gateway or the Translator. Data Mapping Review the Oracle e-Commerce Gateway transaction interface files and the EDI standard transaction to determine where the data is positioned in the EDI standard transaction. If transaction data maps already exist, they provides a good starting point since the standard transaction portion of the data map can be copied from the existing data map. You will need to substitute its mapped position defined in the Oracle e-Commerce Gateway transaction interface file. Some Translators provide a base data map for the Oracle e-Commerce Gateway transaction interface file. These base data maps are currently based on the initial release 11. They are not likely to be plug and play data maps. Note that the Translator providers may charge additional license or service fees for these pre-configured data maps. The base data maps most likely need customization for the following reasons:
s
Whether the internal or external code(s) are available in the interface file (if you used code conversion)
2-6
System or business requirements Trading partners requirements
The base data maps may also need changes if software patches add or change data element positions in the transaction interface file and you accept new records after the seed data reconciliation review. The following reports may facilitate your data map reviews. Run the reports as needed:
s
Transaction Record Layout report to see the transaction interface file Transaction Data File report to see data from a file against its transaction interface file layout
The following process should be followed after a patch is applied. This process attempts to restore the record layout to the layout as defined before the latest patches were applied. Review the log from this process to see the impact of the patch and the reconstructed transaction record layout:
s
Seed Data Reconciliation process
For outbound transactions, if data cannot be found in the transaction interface file as defined by the Oracle e-Commerce Gateway, supplemental data may be found in user defined flexfields or the user defined transaction extension tables. Data may also be mapped to transaction flexfields for inbound transactions. Custom code is required to populate the transaction extension tables if that option is used for outbound transactions. If there are still gaps in the data, determine the best way to address data or functional gaps. Two alternatives may be followed for inbound transactions:
s
Custom modifications may be necessary in the base application This applies to outbound transactions: there may be the case where the transaction passed all the validation in the Oracle e-Commerce Gateway, but the application open interface may still require additional data. Write custom code to add data to the transactions in the application open interface tables. This custom code is executed after the Oracle e-Commerce Gateway wrote the transactions to the application open interface table but before the application open interface executes. For inbound transactions, modifications should be made similarly to those made to populate the extension tables.
Transaction Processing The Oracle e-Commerce Gateway creates transactions by the following methods:
s
A transaction is initiated by an event in the base Oracle Application. The base application initiates a request within Concurrent manager with key data from the transaction to write the transaction to a transaction interface file. Created by a scheduled request within Concurrent Manager.
Usually the request extracts all eligible transactions that are ready to be extracted. You can limit the transactions selected by entering selection parameters in the request. Set up appropriate transaction interface file detection in the file directory. The file directory is defined in the initial application set up for all transactions in the System Profile Options in the Oracle e-Commerce Gateway. The Translator needs to be able to access the interface file. Follow your file backup and archive procedures and practices that may also need to consider local fiscal requirements. Determine the frequency that the Oracle e-Commerce Gateway files are processed through the Translator. Ideally, you should put completed transaction files either in another directory or under other file names so that the Translator cannot access the file until the Oracle e-Commerce Gateway is finished with it.
2-8
Determine Communications Methods For The Transactions

Ensure that the order in which the processes are performed - e.g. for outbound transactions, Oracle e-Commerce Gateway processing, file transfer, archive, or Translator - fits in with the local environment and other processes being performed around the Oracle e-Commerce Gateway. Transaction Testing Create test acceptance criteria to test the transactions. Bear in mind that each trading partner may have its own requirements and therefore one size may not fit all. Customization may extend to a lower level than just the transaction type. This may increase the time required for both development and testing. Trading partner and customer are not synonymous! For example, if a chain of ten retail stores allows each store to require some sort of different data on a transaction, then there are ten trading partner data maps, not one data map. Another example is a trading partner in California where the state may require additional hazardous material data for shipping. First test internally to validate initial mapping, conversions, settings and interaction between the Oracle e-Commerce Gateway and Translator, e.g.
s
Interface file testing into/out of the Oracle e-Commerce Gateway Interaction testing to/from the Translator Interaction testing along the path between the applications and the Translator output/input Verify and compare the data passed to/from the applications with the EDI transaction file into/out of the Translator.
Nominate test Trading Partners for the initial transaction outbound/inbound and obtain their agreement to be test sites. Where the number of trading partners is large, it may be necessary to take a phase testing approach, that is:
s
An initial small set of test trading partners to validate correct mapping, and identify any initial issues caused by new mapping specifications and/or software. A second, larger set of trading partners to verify the fixes implemented as a result of the initial trading partner testing.
Final testing with the total trading partner community, or move directly to production status.
It is important that acceptance of correct operation at each stage be documented before proceeding to the next stage of testing.
2-10
Implementation Planning
The process of sending and receiving an e-commerce transaction is relatively simple. As with all simple concepts however, there is usually a lot of work to do in mapping customer, trading partner, and Translator requirements to ensure that each stage has the required data in the correct fields. Most of the implementation time is taken in these tasks. The checklist for the issues involved in a standard Oracle e-Commerce Gateway implementation can be summarized as:
s
Data mapping requirements Trading Partner set ups General Code Conversion set ups Extension tables (for outbound transactions) Standards to be used for transactions Relevant functionality in the Oracle Application Required fields and defaults on transaction interface file and Application Open Interface Customer's setup and procedures for using the Applications Changes in procedures or business rules within the Application relating to e-Commerce Specific implementation rules negotiated with the Trading Partners Capabilities of the Translator in creating and using the transaction interface file Method for file transfer between the Translator and Oracle e-Commerce Gateway
The planning process includes the following:

s
Develop project plans Investigate and understand the business impact of each transaction Identify customization requirements Co-ordinate the Translator interface Collate all set-up data
Write transaction or message specifications Produce Test Plans Develop transaction archiving policies Co-ordinate testing with Trading Partners
The scope of a project depends on the knowledge of the implementers, number of Trading partner sites to define, number of Transactions implemented, and the number of data maps needed in the Translator. A simple project is one that involves one supported transaction, few trading partners, and minimal code conversion. Set-up includes the hardware set-up and software installation of the pre-built products. It does not address the changes that may be needed for code conversion and customization which are part of the Modification phase. Also, Modification may either come before Testing (since the need for changes are identified in the Definition phase), or there may be another Testing phase after Modification. A good minimum guideline for this second phase would be one day of testing for each day of modification. An outline timeline proposal for a simple project could show elapsed time to be as follows if both a customer EDI implementer and a person who is experienced with the Oracle e-Commerce Gateway and the base Oracle application:
Experienced Oracle e-Commerce Gateway Implementer
Phase
Time (Days)
Customer EDI Implementer
Training Project Definition Set-ups Testing Modification Moving to Production Status Production Status/ Ongoing Support
2 10 2 10 TBD 5 15
X X X X X X X
X X X X X
2-12
3
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Implementation Steps on page 3-2 Implementation Checklist for Software Upgrade on page 3-3 Implementation Checklist for Fresh Install on page 3-7 Implementation Checklist for Maintenance Patch on page 3-8
3-1
Implementation Steps
Implementation Steps
The following is a list of the implementation steps to implement a transaction in Release 11i. Since the total solution requires other Oracle Application modules as well as a Translator, references to these products are included. There are three possible starting points when implementing a transaction, they are as follows:
s
Upgrading from Release 10.7/ Release 11 to Release 11i Fresh install of Release 11i Applying a maintenance patch for Release 11i
The purpose of the implementation checklist is to guide you through the implementation process. The details for each step are described in the implementation section referenced or the corresponding Oracle reference manual.
3-2
Implementation Checklist for Software Upgrade

Required/ Step 1 Optional Required Description Run the following server side scripts for each transaction implemented in Release 10.7/Release 11. These scripts will report the transaction layout definitions and code conversion assignments prior to the upgrade: Release 10.7: ECEUGR.sql - for layout definitions ECEUGR2.sql - for code conversion assignments Release 11: ECELAYDR.sql - for layout definitions ECEXREFR.sql - for code conversion assignments 2 3 Required Required Install Release 11i Oracle e-Commerce Gateway. Run the following reports for each transaction implemented in Release 10.7/Release 11 to view the Release 11i transaction layout definitions and code conversion assignments after the upgrade. Transaction Layout Definition Report Code Conversion Values Report 4 As Needed Compare the before and after upgrade reports for differences in transaction layout definitions and code conversion assignments. Make the necessary changes: Adjust transaction layout definitions Reassign code categories Since this is an upgrade, there will not be any validation rule differences to reconcile. 5 Required Set up system profiles, pay special attention to the profiles for inbound and outbound directory path: Inbound file directory Outbound file directory IG: Set Up Profiles IG: Modify Transaction Interface File IG: Set Up Code Conversion Users Guide: Setting Profile Options Users Guide: Changing the Interface Data File Record Layout Assigning Categories Oracle AutoInstall Manual Users Guide: Reports Reference (IG: Implementation Guide) Upgrade Documentation IG: Report Scripts IG: Review Release 11i Upgrade
3-3
Required
Ensure that inbound and outbound directory paths defined in the system profile match UTL_FILE_DIR settings in INIT.ORA file. Restart the database if you made changes to the INIT.ORA file. Set up general transaction profiles Enable/disable transaction (for all transactions) Address precedence (for inbound transactions)
IG: Define UTL_FILE_DIR parameter in INIT.ORA file
As Needed
Users Guide: Setting Profile Options IG: Set Up Profiles Users Guide: Setting Profile Options IG: Set Up Profiles IG: Determine Process and Column Rules and Actions IG: Determine Process and Column Rules and Actions Application Set Up
As Needed
Set up transaction specific profiles for outbound transactions, such as the Purchase Order or Purchase Order Change transactions Review seeded Process Rule Actions and update rule action if default behavior is not desired Review seeded Column Rule Actions for required fields and update rule action if default behavior is not desired
Required, for inbound transaction Required, for inbound transaction
10
11
Required, for inbound transaction Optional, for inbound transactions As Needed
Review seeded Column Rule Actions for date and numeric fields and update rule action if default behavior is not desired Determine if other columns in the transaction require Column Rules Enable additional data fields as necessary using reference fields, descriptive flexfields or the Oracle e-Commerce Gateway Extensible Architecture
IG: Determine Process and Column Rules and Actions IG: Determine Process and Column Rules and Actions IG: Enable Additional Transaction Data
12
13
14
Optional
Review interface file definitions (record layouts) for the transaction and make any necessary adjustments
Users Guide: Changing the Interface Data File Record Layout IG: Modify Transaction Interface File
15 16
Required Required
Run Transaction Layout Definition Report to get the current definitions. Synchronize the data maps in the Translator with the transaction interface file definitions
Users Guide: Reports IG: Interface with Translators
3-4
17
Required
Ensure that Location Code is defined for the trading partner entity (customer site, supplier site, bank branch, internal location) defined in Oracle Applications Define trading partner: Assign trading partner to address site in Oracle Applications using Define Trading Partner, Assignment tab. Define translator code using Define Trading Partner, Details tab. This is the link to the Translator definition for the trading partner Enable transaction(s) for trading partner(s)
IG: Application Set Up
18
Required
IG: Set Up Trading Partner Trading Partner Details
19
As Needed
Set up code conversions Review/define Code Conversion Categories Enable Code Conversion Define Code Conversion Values
IG: Set Up Code Conversion Code Conversion Details
20 21
Required Required
Review Oracle Applications set ups for each transaction and update as necessary Prepare data to test transaction Add data in Oracle Applications to test outbound transaction Create inbound file to test inbound transaction
IG: Application Set Up IG: Test Transactions
22
Required
Test the transaction being implemented at several levels until results match expectations Internally (Oracle e-Commerce Gateway and Oracle Applications) With Translator With Trading Partner
IG: Test Transactions
23 24
Required As Needed
Release fully tested transaction to production Archive transaction interface files as needed IG: Archive/Backup
In summary, the following has been installed or set up:

s
The upgrade version is installed All custom development re-integrated after upgrade is completed (when appropriate)
3-5
System and Transaction Profile set ups are entered Process rules and Column rules are set up Code Conversion is set up Trading Partners are set up Base Oracle Application set ups are complete Transaction interface file definitions modifications are completed (when appropriated)
It is suggested that a simple outbound and/or inbound transaction be passed through the Oracle e-Commerce Gateway to validate the installation before any site-specific configuration is undertaken.
3-6
Implementation Checklist for Fresh Install
Implementation Checklist for Fresh Install

To help ensure a successful implementation, do the following:
s
Read the Introduction, and become familiar with the pre-requisites Implement related Oracle Applications modules before implementing Oracle e-Commerce Gateway Become familiar with the Oracle e-Commerce Gateway set ups
If you are implementing Oracle e-Commerce Gateway for the first time, steps 1, 3, and 4 described in the Implementation Checklist for Software Upgrade section are not required since there is no existing seed data to compare and reconcile. Insert steps 2.1 and 2.2 below. All other implementation steps are still required in addition to defining an Oracle e-Commerce Gateway responsibility to start the implementation process.
Required/ Step 1 2.1 2.2 3 4 Optional Omit Required Required Omit Omit
s
Reference Description Run Scripts. Define Access Responsibilities. Define the utl_file_dir parameters. Done by DBA. Run reports for each transaction Compare reports IG: Define Responsibilities IG: Define UTL_FILE_DIR Parameter in INIT.ORA File (IG: Implementation Guide)
In summary, the following has been set up in addition to the summary items in the software upgrade: System options for the inbound and outbound directory paths are defined in the system profile and match the UTL_FILE_DIR settings in INIT.ORA file System and Transaction profile set ups are entered (as needed) Transaction specific options have been implemented (as needed)
3-7
Implementation Checklist for Maintenance Patch

If you are installing a maintenance patch to a Release 11i environment, additional implementation steps are necessary to retain any customizations made to the original seed data. There are four types of seed data that may be impacted by applying a maintenance patch, they are as follows:
s
Transaction layout definitions Code conversion assignments Process rules and corresponding actions Column rules and corresponding actions
Use the Seed Data Reconciliation process in Oracle e-Commerce Gateway to compare the seed data values before and after the install. Depending on your response to the program parameters, the program either preserves or overwrites your seed data customizations. In addition, the program reports anything that it could not automatically reconcile. These exceptions must be reviewed and re-implemented as necessary. The following implementation steps are necessary to re-implement any seed data customizations to the original seed data values and to synchronize the transaction layout definitions with the Translator. Your ability to quickly install and implement a maintenance patch is essential to minimizing any business disruptions.
3-8
Required/ Step 1 Optional Required Description Review README text delivered with the maintenance patch to identify transactions containing layout definition changes. Run seed data reports for each transaction identified to get the before values. Transaction Layout Definition Report Code Conversion Values Report 2 3 Required As Needed Apply maintenance patch Run Seed Data Reconciliation process for each transaction in the list of values to resolve the seed data differences. The list of values will be adjusted to reflect the transactions processed. A report of seed data differences that could not be automatically reconciled will be provided. Manually resolve seed data differences that could not be automatically reconciled: Adjust transaction layout definitions Reassign code categories Redefine process rule actions Redefine column rules and actions Repeat this step for each transaction impacted. 5 As Needed For new data elements added as a result of installing a maintenance patch, assign record attributes to the data element to activate them. Refer to the README text delivered with the maintenance patch for a description of the change(s). For new data elements added as a result of installing a maintenance patch, define column rules as necessary.
Reference (IG: Implementation Guide) Users Guide: Reports
Oracle AutoInstall Manual Users Guide: Seed Data Reconciliation
As Needed
Users Guide: Interface File Definition Assign Code Conversion Categories Assign Process Rules Assign Column Rules
Users Guide: Interface File Definition
As Needed
Users Guide: Assigning Column Rules IG: Determine Process and Column Rules and Actions
As Needed
Synchronize the data maps in the Translator with the transaction interface file definitions.
IG: Interface with Translators
In summary, the following has been installed or set up:
3-9
Most current patches applied (when appropriate) All custom development re-integrated after patches applied (when appropriate) The Seed Data Reconciliation process preserved or overlaid the seed data Transaction interface file definitions modifications are completed (when appropriated)
It is suggested that a simple outbound and/or inbound transaction be passed through the Oracle e-Commerce Gateway to validate the installation before any site-specific configuration is undertaken.
3-10
4
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Report Scripts on page 4-2 Define Responsibilities on page 4-4 Define UTL_FILE_DIR Parameter in INIT.ORA File on page 4-5 Review Release 11i Upgrade Guideline on page 4-7 Set Up Profiles on page 4-10 Determine Process and Column Rules and Actions on page 4-18 Enable Additional Transaction Data on page 4-25 Modify Transaction Interface File on page 4-29 Synchronize New Transaction Layout Definitions with Translator on page 4-35 Common Transaction Interface File Definition Errors on page 4-36 Set Up Trading Partners on page 4-37 Set Up Code Conversion on page 4-41 Interface with Translators on page 4-45 Archive/Backup on page 4-49
4-1
Report Scripts
Report Scripts
There are two sets of server side SQL scripts to report the transaction layout definitions and code conversion assignments. The report script names are as follows:
ECEUGR.sql - for transaction layout definitions Release 10.7 ECEUGR2.sql - for code conversion assignments ECELAYDR.sql - for transaction layout definitions Release 11 ECEXREFR.sql - for code conversion assignments
Contact your DBA to determine where these files are stored on the server. These report scripts provide you with a before and after image of your transaction interface file definitions and code conversion assignments. You can use this information to re-implement any customizations from your original environment to your newly upgraded environment If you are applying a maintenance patch to an existing Release 11i environment, this does not apply. Refer to the section on Seed Data Reconciliation for details on managing customized seed data in a Release 11i environment. These reports can be run in SQLPLUS. The report scripts have two parameters as follows:
1. 2.
Output file name Transaction ID
Table 41 The following is a list of the valid Transaction IDs for Release 10.7:
Transaction ID ASNO INO POO Transaction Description Outbound Ship Notice/Manifest Outbound Invoice Outbound Purchase Order ASC X12 856 810 850 EDIFACT DESADV INVOIC ORDERS
POI
Inbound Purchase Order
850
ORDERS
4-2
Report Scripts
Table 42 The following is a list of the valid Transaction IDs for Release 11:
Transaction ID ADVO DSNO INO POCO POO PYO SPSO SSSO Transaction Description Outbound Application Advice Outbound Ship Notice/Manifest Outbound Invoice Outbound Purchase Order Change Outbound Purchase Order Outbound Payment Order/Remittance Advice Outbound Planning Schedule Outbound Shipping Schedule ASC X12 824 856 810 860 850 820 830 862 EDIFACT APERAK DESADV INVOIC ORDCHG ORDERS PAYORD-RE MADV DELFOR DELJIT
ASNI CATI INI POI RRQI SBNI
Inbound Ship Notice/Manifest Inbound Price/Sales Catalog Inbound Invoice Inbound Purchase Order Inbound Response to RFQ Inbound Shipment & Billing Notice
856 832 810 850 843 857
DESDAV PRICAT INVOIC ORDERS QUOTES n/a
4-3
Define Responsibilities
Define Responsibilities
This step assigns the Oracle e-Commerce Gateway responsibility to the user to access the Oracle e-Commerce Gateway database and windows.
Responsibility System Administrator Action Assign Oracle e-Commerce Gateway responsibility to user
4-4
Define UTL_FILE_DIR Parameter in INIT.ORA File

A Database Administrator (DBA) does this step. To use Oracle e-Commerce Gateway, you must first create directories where data files, for both inbound and outbound transactions are stored. Oracle e-Commerce Gateway uses the UTL_FILE package to read and write the ASCII transaction interface flat files on the server. UTL_FILE can only write to accessible directories. The directories are defined by the utl_file_dir parameter in the init<SID>.ora file. This file is usually found in the $ORACLE_HOME/dbs directory. Within this file, each accessible directory is indicated by a line similar to: utl_file_dir = directory_name The specification of directory_name will vary, depending on the operating system. If the operating system is case-sensitive, then directory_name is case sensitive. The value for directory_name must be a physical directory as opposed to a variable, logical or an alias. In addition, the value for directory_name must match the value defined in the Oracle e-Commerce Gateway profile for ECE: Inbound File Path and ECE: Output File Path. Refer to section entitled Set Up Profiles for the details. For example, the following entries are legal for a UNIX system, assuming the directories specified exist: utl_file_dir = /tmp utl_file_dir = /home/oracle/output_files In addition to this form of database security, operating system security must also be considered. The file I/O operations performed with UTL_FILE will be done by the Oracle user (the Oracle user is the owner of the files that are used to run the database, and also the owner of the processes that make up a database instance). Consequently, the Oracle user must have operating system privileges to read from and write to all of the accessible directories. If the Oracle user does not have privileges for an accessible directory, then any operations in that directory will be prohibited by the operating system. To ensure that operating system security allows the Oracle user to create, delete, rename, read and write files in the specified directories, the DBA must grant directory and file access privileges by issuing the CHMOD 777 command at the operating system level. This is a UNIX example only, so use operating system appropriate commands for your environment.
4-5
The Oracle instance must be brought down and back up for the changes in the init<SID>.ora file to be effective.
4-6
Review Release 11i Upgrade Guideline

Release 11i Upgrade
This chapter provides general information about topics to consider while planning the upgrade to Release 11i. To facilitate a successful upgrade to Release 11i, make sure that the information contained in the Upgrading Oracle Applications, Release 11i manual is understood by everyone involved with the upgrade process. Note the following regarding the upgrade process:
s
Plan the upgrade by reading all the steps that apply to your products before beginning. This allows the user to determine the most efficient way to prepare for and finish the process given the unique combination of products. Failure to complete the upgrade preparation and upgrade finishing steps correctly can adversely affect the upgrade process. You must be at either Release 10.7 (NCA, SmartClient or character-mode) or Release 11of the Oracle Applications to upgrade to Release 11i. You cannot upgrade to Release 11i directly from releases prior to Release 10.7. Pay close attention to all warnings that indicate where and when you run upgrade steps. Carefully coordinating your upgrade preparation work across different products will avoid errors. For a complete list of changes and enhancements to the Oracle Applications in Release 11i, review the Oracle Applications Product Update Notes.
If you are an Automotive customer, review the Release 11i Automotive Upgrade documentation to insure that all pre upgrade and post upgrade steps are performed. For existing Oracle Order Entry users, it is important to note that Oracle Order Entry is not included in the initial Release 11i and, thereby, the inbound Purchase Orders (850/ORDERS) and the outbound Departure-based Shipping Notice/Manifest (856/DESADV) transactions will not be available for use until the new Oracle Order Management product is released. It is important that customers stay current on the latest patch sets provided by Oracle e-Commerce Gateway. This insures that they have the most recent bug fixes and added functionality. Information on the latest patch sets available can be obtained from Oracle Support Services or their web site Metalink.
4-7
Prior to running the Release 11i upgrade process, it is important to remember to run the two report scripts that are provided. These report scripts help identify customizations that may have been made to the existing transaction record layouts, any table updates to accommodate extension tables, and identifies new code conversion categories that may have been added. If you have made any customizations to the seeded data including extension tables or program routines, execute the report scripts both before and after you apply the upgrade. The before report identifies the current definitions, the after report identifies the new definitions after the upgrade has been applied. The differences between the two reports identify the customizations that must be evaluated. If necessary, re-implemented your customizations after you apply the upgrade. In addition, make certain you have complete documentation of software modifications before applying the patch. This allows you to easily re-apply your changes, and make additional changes if the seed data reconciliation could not restore that transaction layout or set up. Detailed information on running these report scripts can be found the Release 11i Upgrade manual.
Seed Data Reconciliation

Seed data is generally defined as any data delivered with a standard installation of Oracle Applications. This includes menu definitions, concurrent manager definitions, list of values, etc. In this chapter, the definition of seed data is limited to the data used for:
s
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. The Release 11i 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 such as the Translator.
4-8
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. For detailed information on how the Seed Data Reconciliation process works, refer to the Oracle e-Commerce Gateway Users Guide.
4-9
Set Up Profiles
Set Up Profiles
Recognizing that no two businesses operate in the exact same manner, Oracle e-Commerce Gateway provides users with profile options to configure their implementation. This allows the user to set up an ERP environment that matches their business environment. Oracle e-Commerce Gateway supports two types of profile options; system level profile options which are used by all transactions and transaction level profile options used by a specific transaction. System level profiles are usually done as an initial set up whereas transaction level profile options are done as you implement a transaction.
System Profiles (Initial Setup)

The following table lists the three profile option. There is an indicator as to whether the profile option is required or optional and what the default value is:
Default Value No Default
System Profile Option ECE:OUT_FILE_PATH
Description Indicates the directory where outbound data files write to. This value must match the actual directory on disk and is designated in the INIT.ORA file Yes indicates words in attachments are split when the segment size is reached. No indicates that words do not split; when segment size is reach, the split occurs at the nearest place or punctuation mark. Indicates the directory where inbound data files write from. This value must match the actual directory on the disk and that is designated in the INIT.ORA file
Required Yes
ECE: ATT_SPLIT_WORD_ ALLOWED
Yes
No Default
ECE: IN_FILE_PATH
Yes
No Default
Table 43 Table 1. System Profiles
4-10
Set Up Profiles
System Profile Window
ECE_OUT_FILE_PATH This is a required field. It is the outbound file path that Oracle e-Commerce Gateway uses to determine where to write the outbound datafile to. If this is not set up, the outbound transactions will not work. This value must match the actual directory defined in the INIT.ORA file. ECE_ATT_SPLIT_WORD_ALLOWED This profile option is used for attachments in Purchase Order. Specifically it is used for Purchase Order Outbound and Purchase Order Change Outbound. The purpose of this profile option is to help split long text into several records to facilitate data mapping in the translation process. Setting the flag to Yes means you do want to split the word; No means it will be split at the nearest space or word.
Implementation Details 4-11
Set Up Profiles
ECE_IN_FILE_PATH This is a required field. It is the inbound file path that Oracle e-Commerce Gateway uses to determine where to read the inbound data file. If this is not set up, the inbound transactions will not work. This value must match the actual directory defined in the INIT.ORA file. Note: For system profile options related to directory paths, refer to section entitled Define UTL_FILE_DIR Parameter in INIT.ORA File for the details.
Transaction Profiles (Ongoing as transactions are implemented)

Transaction profiles are categorized as follows:
s
Address precedence for each inbound transaction Enable/disable flag for each transaction Transaction specific options
There are two transaction profiles for each transaction: an address precedence profile and a transaction enabled profile. There is an indicator as to whether the profile option is required or optional and what the default value is:
Default Value Yes
Transaction Profile Option ECE_XXX_ADDRESS_ PRECEDENCE ECE_XXI_ENABLED ECE_XXO_ENABLED
Description Enables Address Precedence for transaction where xxx represents a specific inbound transaction Enables inbound transaction where xxx represents a specific inbound transaction Enables outbound transactions where xxx represents a specific outbound transaction
Required Yes
Yes Yes
No No
Table 44 Table 2 General Transaction Profiles
4-12
Set Up Profiles
Transaction Profile Window
Enable/Disable flag for Each Transaction

For each transaction supported by Oracle e-Commerce Gateway, there is a transaction enabled flag, (i.e.: ECE_XXX_ENABLED, where XXX represents a specific transaction). This flag indicates if a transaction will be enabled or disabled at the system level. The setting determines Oracle e-Commerce Gateways ability to process a given transaction. If the flag is disabled, the transaction will not be processed by Oracle e-Commerce Gateway. You still need to enable the flag in the Detail tab of the Define Trading Partner window to enable the transaction at the trading partner level.
Set Up Profiles
Address Precedence for Each Inbound Transaction

All inbound transactions have an address derivation precedence profile option. The address derivation derives addresses based on certain codes provided to the Oracle e-Commerce Gateway in inbound transaction interface files. The address precedence has three categories of components. They have unique address ids, location code/translator codes, location names, and physical addresses. These addresses are verified and validated as transactions are processed. The user has the option of defining which derivation sequence the transaction will follow. You can determine the order that the Oracle e-Commerce Gateway attempts to derive the address site in the base application, given the data in the transaction file. Three searches are attempted; for example the combination LTC,PHA, LON for the EDI Location Code/Translator Code, Physical address, and Location name respectively. If the first rule, EDI Location Code/Translator Code combination (LTC), does not determine the address site in the base application, then use the full physical address (PHA) found in the transaction to find the address site. The final attempt will be with the ocation name (LON) found in the transaction. The address derivation precedence profile value requires users to define a sequence in which validation is performed for each inbound transaction prior to processing. The valid combinations are: LTC, PHA, LON LTC, LON, PHA PHA, LTC, LON PHA, LON, LTC LON, LTC, PHA LON, PHA, LTC where: LTC represents the EDI Location Code/Translator Code combination PHA represents the Physical Address LON represents the Location Name
4-14
Set Up Profiles
Transaction Specific Options

Purchase Order Transactions
Additional profiles exist for the Purchase Order transactions, for the handling of attachment data to suppliers. These profiles require the user to define if attachments are to be enabled at various levels of a transaction. The purpose of these profile options is to make the transaction interface file size manageable. The available values for the profile names listed below are Yes or No. Yes will enable the attachments, and No will disable the attachments. If using attachments you also need to define the attachment segment size profile option. Attachments are supported at different levels: Header Level: header attachment Inventory Item level: master item attachment and inventory item attachment PO Line Level: line attachment Shipment level: shipment attachment
Purchase Order Specific Transaction Profile Option ECE:POO_ATTACHMENT_ SEGMENT_SIZE Default Required Value Yes 400
Description Sets the attachment segment size for the outbound Purchase Order transaction. Attachments can be split into segments to accommodate their insertion into the data file. The segment size is expressed in bytes. Enables the header attachment for the outbound Purchase Order transaction. Enables the master inventory item attachment for the outbound Purchase Order Request transactions Enables the inventory item attachment for the outbound Purchase Request transactions Enables the line attachment for the outbound Purchase Order transactions Enables the shipment attachment for the outbound Purchase Order transactions
ECE:POO_HEADER_ATTACHMENT_ ENABLED ECE:POO_INVENTORY_MITEM_ ATTACHMENT ECE:POO_INVENTORY_ITEM_ ATTACHMENT ECE:POO_LINE_ATTACHMENT_ ENABLED ECE:POO_SHIPMENT_ ATTACHMENT_ENABLED
Yes
No
Yes
No
Yes
No
Yes Yes
No No
Set Up Profiles
Table 45 Table 3. Purchase Order Specific Transaction Profiles
Note: The same options apply to the outbound Purchase Order Change Request transaction.
Outbound Purchase Order Transaction Profile
The ECE_POO_ATT_SEG_SIZE sets the attachment segment size for the outbound purchase order transaction. Attachments can be split into segments to accommodate their insertion into the interface file. The segment size is expressed in bytes. The default is 400. You can change the default value to a value that matches the length of the target field. For example, if the attachment test is being mapped to an ASC X12 NTE segment, then set the profile value to 80 so that the attachment text is written to the interface file in 80
4-16
Set Up Profiles
byte increments. This will make it easier for the Translator to map attachment text from the Oracle transaction interface file to the target field of the message. The size of the attachment should be synchronized in three places. The following table illustrates where to change it:
Set Up for Text Length Profile Options window: Transaction Profile Set up Interface File Definition window Note Set the length of the attachments that the full data element will be divided. Set it to the length needed for the translation process. The default is 400. Set to the same length as the attachment. If the data element on the file is excessively long, the data element will have many trailing blanks. If the data element on the file is not long enough, the data may be truncated. The translator will map each data element to a field that is your specified length. You do not need to manipulate text size to fit into a standard data element if the data was divided into several record in the transaction interface file. Original 400 Change Use 80 80
800
80
80
Translator Data Map
80
The use of attachments is not required. If not used, consider disabling the attachment record defined for the transaction. Refer to section entitled Modify Transaction Interface File for more details.
Common Set Up Errors

The following are common set up errors related to system/transaction level profiles:
s
Did not define system level profile options Concurrent Manager log file reflects an error indicating transaction is not enabled Errors regarding address derivation occurred
Refer to the Trouble Shooting chapter for more details.
Determine Process and Column Rules and Actions

Oracle e-Commerce Gateways exception handler is designed to provide quick and easy analysis of any exception detected during inbound processing. It is a tool to pre-validate incoming data before the data is imported into Oracle Applications Open Interface tables for processing into Oracle Applications base tables. The exception handler uses tree style navigation and color-coded icons to help you quickly identify the exception. Dynamic windows and drill downs provide summary and detailed information to help you analyze and diagnose the cause of any exception. Once the cause of an exception is identified and resolved, you have the option to resubmit the transaction for processing, ignore the exception or delete the transaction. To take advantage of Oracle e-Commerce Gateways exception handler, you must first define the validation rules. There are two types of validation rules; one at the process level for the overall transaction and the second at the column level for the individual data elements within a transaction. You define the validation rules using the Assign Process Rules or Assign Column Rules window accessible via the Interface File Definition window.
Process Rules
Process rules are defined at the transaction level and apply to the entire transaction. Process rules are required and should not be changed although the Assign Process Rules window does not prevent it. Oracle e-Commerce Gateways exception handler supports three process rules as follows: Invalid Trading Partner This rule checks if the incoming translator code/location code combination (on the interface file, control record) is defined for a trading partner. Additionally, the transaction type identified on the incoming interface file must be enabled for the trading partner identified. Test/Production Discrepancy This rule checks if the incoming test flag (on the control record 0010 in the transaction interface file) matches the flag setting for the Trading Partner identified by the Translator Code/EDI Location Code combination (in the Trading Partner set-up). If they are different, then this rule is violated. Invalid Document Address There are several procedures, which validate and derive different types of addresses (Ship-to, Bill-to, Sold-To, etc.). If one of these procedures are unable to derive a
4-18
unique address site, then this rule is violated. This validation occurs for all the key address sites associated with the transaction except for the location code on the control record. Seeded Process Rules Each inbound transaction is seeded with the three process rules outlined above. In addition, each rule is seeded with a default rule action of Skip Document that tells Oracle e-Commerce Gateway to skip the current document and proceed to the next document if a process rule exception is detected. You can change the corresponding process rule action if the default behavior is not desired (see below regarding Rule Actions).
Column Rules
Column rules are defined at the column level and apply to a specific data element of a given transaction. Except for the seeded column rules (see below regarding Seeded Column Rules), column rules are not required. If they are used, you must define an associated rule action that tells Oracle e-Commerce Gateway how to proceed if a column rule exception is detected. The same set of rule actions available for process rules are used for column rules (see below regarding Rule Actions). Oracle e-Commerce Gateways exception handler supports seven column rules as follows: Datatype Checking Examples of data types are alphanumeric, numeric, and date. This rule compares the data type defined in the ece_interface_columns table with the data type of the data in the incoming interface file. If the data types do not match, then this rule is violated. Default If Null This rule is used to put a value into the column if it is null (blank) in the incoming interface file. This is the only rule that modifies the incoming data as a value is placed in the Application Open Interface table. The interface file is not updated. Use the Log Only rule action for this column rule. Null Dependency This rule is used to create complex comparisons for a column within the document. Null Dependency allows the user to set up conditional expressions that indicate whether the assigned column must be null or cannot be null depending on the values in other columns.
Predefined List This rule is used to validate the incoming data for a given column against a user defined list. For example, transaction_method Must Equal EDI implies the value EDI is on the user defined list. If Cannot Equal is checked, then transaction_ method cannot equal EDI. Simple Lookup This rule requires you to identify the specific table and column containing a list of valid values. The table and column names are used to dynamically build a select statement that is used to select data to compare to the assigned column. The tables may be user-defined tables outside of the Oracle Applications. For example of a Simple Lookup, the dynamically built select statement is select lookup_code from ece_lookup_values. If the incoming transaction value does not exist in the list of selected values, then this rule is violated. No List of Value (LOV) is provided for the table, column or condition field. Instead a Validate button may be used to verify the syntax of the dynamically built select statement. Valueset Lookup This rule is used to compare the value in the assigned column to an Oracle Application Valueset. Value is Required This rule checks if the incoming data for a given column has a non null value. If it is null, then it violates the rule. General guidelines regarding column rule definitions are as follows:
s
A column may have more than one rule defined A column may have the same rule defined multiple times each with different conditions The same rule may apply to multiple columns of a given transaction Different rules for a given column can have different rule actions (see below regarding Rule Action Precedence)
Seeded Column Rules

Each inbound transaction is seeded with column rules for required fields, date fields, and numeric fields. The default settings are as follows:
4-20
Field Types Required Fields Date Fields Numeric Fields
Column Rule Value is Required Data type Checking Data type Checking
Rule Action Skip Document Skip Document Skip Document
A column is identified as required if it is required by Oracle e-Commerce Gateway or the Application Open Interface to successfully import an interface file. Examples include values to key fields or parameters that identify a business rule to be used when validating incoming data. Refer to the Applications Set Up chapters for a list of required fields relevant to the transaction being implemented. The Assign Column Rules window allows you to change or delete the column rules for required, date or numeric fields but this type of change is not recommended unless the potential exception can be resolved in the Application Open Interface. You can change the corresponding column rule action if the default behavior is not desired. Whether you use Oracle e-Commerce Gateways exception handler to pre-validate incoming data or not is dependent on your business rules and the accuracy of your trading partners interface files. If you do not define any column rules at all, you are assured that at minimum the seeded column rules are executed. Given the variety of ways in which Oracle Applications modules support error detection, error reporting and error research tools, it is easier to do as much pre-validation as possible via Oracle e-Commerce Gateway so that you can centralize the error research effort. This way all errors may be reviewed and resolved at the same time allowing the transaction to be reprocessed in a timely manner.
Column Rules and Code Conversion

Oracle e-Commerce Gateway applies code conversion prior to applying the column rules, therefore you can define a column rule for a column allocated for the internal value although the actual value is not placed on the transaction interface file but is derived during code conversion. This derived value will be validated using the column rule and then placed in the Application Open Interface table if valid or staged if invalid. Refer to section entitled Set Up Code Conversion for more details.
Rule Actions
Each process or column rule requires a rule action that tells Oracle e-Commerce Gateway how to proceed if an exception is detected. There are four rule actions as follows: Skip Document This action skips the current document and continues processing the next document. You can view the detected exceptions for this document via the View Staged Documents window. Log Only This action writes a message to the log file. It treats the document as a successful document and continues processing the remaining documents. Abort Run This action rolls back the entire run and sets the concurrent request status to Error. Disabled This action temporarily disables the rule until you reactivate it by assigning an appropriate rule action.
Rule Action Precedence

Since a given data column can have more than one rule defined for it, it implies that there can be more than one rule action defined for it. If this occurs, the exception handler applies the rule actions beginning with most conservative to least conservative as follows:
1. 2. 3.
Abort Run Skip Document Log Only
Exception Handler
Once the validation rules and associated actions are defined and the process is initiated, the run-time execution engine proceeds according to your validation rules. The status of a transaction process and any detected exceptions may be viewed using a single workbench style window known as the View Staged Documents window. Summary or detailed inquiries are available to help you analyze the cause of an exception.
4-22
If necessary, a user-activated run-time execution log is available to assist with trouble shooting. This diagnostic tool supports multiple levels of trace details for both technical and non-technical analysts. Refer to the Trouble Shooting chapter for more details on how to use the Run-time Execution Log and View Staged Documents window(s) to research any detected exceptions. Once the cause of an exception is identified and resolved, you have the option to resubmit the transaction for processing, ignore the exception or delete the transaction.
Error Correction
If you agree that a detected exception is an error, you must proceed to get the error corrected. Since the documents being transmitted between you and your trading partner represent legal documents, Oracle e-Commerce Gateway does not allow you to correct any errors, so the errors must be corrected at the source. If you cannot resolve the exception using the appropriate Oracle Applications set up, you can bypass the validation in Oracle e-Commerce Gateway by enabling the IGNORE check box via the View Staged Documents window. Alternately, you can delete the transaction and ask your trading partner to resend a corrected transaction. If the error originated in Oracle Applications, you must correct the error in the appropriate Oracle Applications module and then resubmit the transaction using the View Staged Documents window. There is no need to re-import the interface file from the sender. If you determine that a detected exception is really a warning that does not adversely affect the process, you can do one of the following:
s
Un-assign the column rule using the Assign Column Rules window. This change applies to all documents of the same transaction type until you re-assign the rule. Assign a less restrictive column rule or column rule action using the Assign Column Rules window. This change applies to all documents of the same transaction type until you reset the rule. Request that Oracle e-Commerce Gateway ignore the validation by enabling the IGNORE flag via the View Staged Documents window
Delete the transaction using the View Staged Documents window
Once you processed the warning exception, you can resubmit the transaction using the View Staged Documents window for processing into the Application Open Interface tables. When the import process of loading data into the Application Open Interface tables completes successfully, you must resubmit the request to execute the Application Open Interface process so the data can be imported into the Oracle Applications base tables. Oracle e-Commerce Gateways exception handler is designed to validate the entire inbound file and report all exceptions to you so that you can make the necessary corrections all at once. However, if there are errors at multiple levels of the transaction, Oracle e-Commerce Gateways exception handler proceeds as far as it can and then continue processing only after the necessary corrections are made and the transaction is resubmitted for processing. In the best case scenario, all exceptions are reported the first time. In the worse case scenario, this is an iterative process requiring your attention at each iteration until all exceptions are resolved.

The Assign Process Rules and Assign Column Rules window prevents you from defining invalid or incomplete validation rules. However, if you define an incorrect rule or the rule is assigned incorrectly, the expected pre-validation may not be performed. The following are errors related to defining validation rules:
s
Deleted or changed a required process rule Deleted a column rule for a required field Changed a column rule for a date or numeric field Assigned a column rule that does not match the type of data expected for the data element Did not activate a rule defined with a Disabled rule action Did not provide a list of valid values for Predefined List column rule Did not provide a valid Oracle Applications valueset for Valueset Lookup column rule Did not provide a valid table, column, or condition for Simple Lookup column rule
Refer to the Trouble Shooting chapter for more details.
4-24
Enable Additional Transaction Data

The information presented in this section is of an advisory nature and assumes you have attended an Oracle e-Commerce Gateway training course and is familiar with standard Oracle features such as Flexfields. Oracle e-Commerce Gateway provides several methods to add data elements to the transactions that are not defined in the base Oracle Applications data model, to obtain data that is missing from the inbound file, or required by multiple organizations. These methods are listed in the table along with an indicator as to where they may be used.
Applies to Outbound Transactions Yes Yes Yes Yes Yes No Applies to Inbound Transactions No Yes No No Yes Yes
Method Trading Partner Header Reference fields Descriptive Flexfields in the Oracle e-Commerce Gateway Descriptive Flexfields in the base Oracle Applications Oracle e-Commerce Gateway Extensible Architecture Interface File Definition Interface Data File processing
Trading Partner Header Reference fields

There are two Trading Partner reference fields on the Trading Partner header defined in the Define Trading Partner window as TP_REFERENCE_EXT1 and TP_ REFERENCE_EXT2.
s
These fields are written to the control record 0010 in every outbound transaction. This data can be mapped to a standard transaction field by the Translator if required These fields are not examined by the Oracle e-Commerce Gateway for inbound transactions.
Descriptive Flexfields in Oracle e-Commerce Gateway

Oracle e-Commerce Gateway standard mapping contains a selection of flexfields that allow for the transmission of additional data outbound/inbound if that data has its origin or destination in activated flexfields within the Oracle Applications.
s
The availability and transaction level - header, line, shipment etc. - of these flexfields in the Oracle e-Commerce Gateway is dependent on the transaction involved. It cannot be assumed that every transaction will always have all flexfields available to be mapped, the mapping should therefore be verified on a case by case basis. Unlike the extensible architecture (see below) the data that can be mapped into the flexfields is limited to the number of flexfields that have been activated within Oracle Applications, and is also limited by the scope of the Application Open Interface for a given inbound transaction. Any additional data that is passed via flexfields must have a suitable corresponding position within the fields available in the message standard being used.
Descriptive Flexfields in the base Oracle Applications

Subject to the comments mentioned in the previous section, data contained within the flexfields activated in the Oracle Applications can be transmitted outbound via the Oracle e-Commerce Gateway. Most additional data transmission requirements can be met using mapped flexfields where the extra data required is to be found within the relevant Oracle Applications.
Oracle e-Commerce Gateway Extensible Architecture

The Oracle e-Commerce Gateway Extensible Architecture feature is used when data from an outside application must be merged with Oracle Applications data to create a single outbound transaction. This feature affords great flexibility to customize outbound transactions based on individual business needs. For example, there may be data contained in legacy systems tables or files that must be included in a transmission along with data extracted from the base Oracle Application. Data that is stored in additional columns in Oracle application tables, which are not in the standard Oracle application or Oracle e-Commerce Gateway configuration, may also be written to the extension tables. Refer to the chapter on Extension Tables for more details.
4-26
Interface File Definition

The size, location and relative order of the fields processed by Oracle e-Commerce Gateway can be modified using the Interface File Definition window. The width of a field may be increased or decreased to suit customer or standards requirements. The relative position of a field within the interface file record may be changed, or a field may be activated to appear in the transaction interface file by allocating it a record number, relative position, and column width. Alternatively fields may be inactivated if they are not required, for example to reduce inbound/outbound file sizes, though it is recommended that the reasons for deactivating fields, other than not used flexfields, be well understood.
s
External (code conversion) fields may be re-numbered (changing the position numbers) to allow them to be inserted into, or read from, the interface file in a different order to their position in the Interface File Definition display - refer to the Users Guide. However, changing the position number impacts the data map in the Translator. Newly activated columns may be positioned after the seeded columns on a record or even written to another record to minimize the impact on existing data maps. The Internal (code conversion) field numbered 0 must not be altered. The 0 is an indicator that this field is the Internal code for the Oracle Application. Any changes to the interface file definition must be synchronized with the mapping to the Translator. Removing fields is a simple action, but the implications of finding that the fields are required at a later date will affect the Translator mapping and also may affect the Transaction Specification agreement with Trading Partners.
Refer to the section entitled Modify Transaction Interface File for guidelines on changing transaction interface file definitions.
Interface Data File Processing

The file produced by Oracle e-Commerce Gateway for outbound transactions, and imported by it for inbound transactions, is a flat text file. It may be manipulated by standard editor or programming languages such as SQL and COBOL. Because of this the file may, for example, be padded in the case of transmission via software that requires fixed length fields. For inbound transmissions, data may be added by reference to the Oracle Applications, or third party tables in the case where data is missing from the inbound transactions, or data such as tax coding needs to be added based upon specific geographic supply sources. Oracle e-Commerce Gateway files may also be easily read, or test files easily created, using standard editors. It should be noted, however, that because the file
may extend to a width of 1024 characters the editor should be set to minimum margins with fixed, non-proportional width font to ensure properly formatted display without wrapped data.
4-28
Modify Transaction Interface File

Oracle e-Commerce Gateway creates outbound and receives inbound transaction interface files. The transaction record layouts (a.k.a. file formats) are pre-defined by Oracle e-Commerce Gateway and stored in a data repository. The seeded transaction layout definitions may be used as is or customized to match the data you transmit to or receive from your trading partner. You may want to change the seeded transaction layout definitions for the following reasons: Change file structure Change record layout Change column attributes Delete unused data elements and records Activate additional external fields for code conversion Activate unmapped data elements Extend Oracle e-Commerce Gateway supported transactions Use the Transaction Layout Definition Report to review the seeded definitions including any modifications you may have entered. Use the Interface File Definitions window to make any necessary definition changes. Since the transaction layout definitions are stored in a data repository, all changes entered using the Interface File Definition window are effective at run-time without any code modifications. Once the necessary changes are entered, re-run the Transaction Layout Definition Report and use the report output to synchronize your new transaction layout definitions with the Translator. Refer to the Users Guide for details on how to use the Transaction Layout Definition Report and the Interface File Definitions window. The following is a quick review of the key terminology used in this section:
Item Data Element Record Common Key Control Record (Record 0010) Transaction Interface File
Definition The smallest component of an transaction interface file A collection of data elements The first 100 bytes of every record containing key data about the Trading Partner and document The first record of every transaction containing key data about the transaction and trading partner A collection of records containing transaction specific data
Refer to the chapter on Transaction Interface File Architecture for a detailed description of Oracle e-Commerce Gateways transaction interface file structure.
Change File Structure

The structure of a transaction interface file is defined during the design process and is based on how the data will be mapped per the message standards. The objective is to group the data in logical groups so that it can be easily mapped by the Translator. The following are some guidelines regarding file structure changes: Due to the one-to-many relationship between header and detail level data, do not move detail level data to the header level. If you move header level data to the detail level, make sure the header level aggregated data is accurately represented as de-aggregated data at the detail level. This may require some re-mapping or custom coding to accomplish. Do not use the same record number across different data levels Moving records around within the same data level is acceptable
Change Record Layout

Each data element is defined to a relative position within a record. The relative position indicates the order the data elements are written to the transaction interface file. Except for the control record, the relative position of a data element in a record may be changed as necessary. The following are some guidelines regarding record layout changes:
4-30
Do not change the record layout of the common key in any record. The Interface File Definition window prevents this so this guideline applies to custom coding only. Do not change the record layout of the control record. If you move a data element from one record to another, make sure the total length of the record does not exceed 1024 bytes with the first 100 bytes reserved for the common key.
Change Column Attribute

Aside from being defined to a relative position within the record, each data element has seeded column attributes for record number, position, width, sequence, layout code, layout qualifier, process rules, and column rules. Any one of these column attributes may be changed as necessary with the following guidelines: Do not change the column attributes of the common key in any record. The Interface File Definition window prevents this so this guideline applies to custom coding only. Do not change the column attributes of the control record. Do not use detail level record numbers in header records. Do not repeat record numbers within or outside the same data level. Do not repeat position numbers within the same record. Define a column width less than or equal what Oracle Applications supports to prevent data from being truncated. Make sure the total length of the record does not exceed 1024 bytes with the first 100 bytes reserved for the common key. Do not use sequence number 0 as it is reserved for the data elements internal value. Make sure the external fields defined for code conversion are uniquely sequenced from 1 to 5. If you change a layout code, make sure you make the same change for every data element in the record. The layout code from the first data element in the record is written to the transaction interface file. If you change a layout qualifier, make sure you make the same change for the related data elements in the record. The layout qualifier from the first data element in the record is written to the transaction interface file.
Do not change the seeded process rules, these are required. You may change the process rule action as necessary. Do not change the seeded column rules for data elements that are required by Oracle e-Commerce Gateway or Oracle Applications Open Interface. These data elements have the Value is Required column rule defined for it. Refer to Applications Set Up section for a list of required fields by transaction.
Delete Unused Data Elements and Records

During the design process, the transaction interface file is defined to accommodate every relevant data element from Oracle Applications including descriptive flexfields. However, not all data elements are mapped or used because either the message standards or the trading partner did not require it. To maximize efficiency, delete all unused data elements and records using the following guidelines: Delete all unused Oracle e-Commerce Gateway and Oracle Applications descriptive flexfields. Delete all unused Oracle Applications free form text fields such as attachment, notes and descriptions Retain at minimum one of the five allocated external fields in case you want to activate code conversion for the data element in the future. Delete all other unused external fields. Do not delete the control record or any data elements in the record. This record is required. Do not delete any data elements in the common key. These data elements are required. Do not delete data elements containing a process rule, as process rules are required. Do not delete data elements required by Oracle e-Commerce Gateway or Oracle Applications Open Interface. These data elements have the Value is Required column rule defined for it. Refer to Applications Set Up section for a list of required fields by transaction.
Activate Additional External Fields for Code Conversion

During the design process, five external fields are defined for each data element identified as a candidate for code conversion. However, the actual number of external fields that are activated are based on the requirements of the receiving system. Examples of the receiving systems requirements are the EDI standards,
4-32
ISO 9000 standards (i.e. UOM codes or currency codes) or specific trading partner requirements. Any of the five external fields that are not activated are available for you. You can activate these unmapped external fields by assigning the appropriate column attributes including record number, position number, width, sequence, layout code, layout qualifier and column rules. The following are guidelines for activating unmapped external fields: Use the same record number as the other related external fields if the maximum does not exceed 1024 bytes with the first 100 bytes reserved for the common key. To minimize re-mapping of existing data maps, use a position number that will position this data element to the end of the record. Define a column width less than or equal what Oracle Applications supports to prevent data from being truncated. Review the sequence number of the other related external fields and assign a sequence number not already used by the other fields. If you need to re-sequence the existing external fields to accommodate the new external field, make sure they are uniquely sequenced from 1 to 5. Do not use sequence number 0 as it is reserved for the data elements internal value. Use the same layout code and qualifier as the other related external fields in the record. Assign a column rule for the external field as necessary.
Activate Unmapped Data Elements

Similar to additional external fields for code conversion, there are other Oracle e-Commerce Gateway or Oracle Applications fields which were included in the transaction design but not mapped to the transaction interface file. You can activate these unmapped fields to add new data elements to existing transactions by assigning the appropriate column attributes. The guidelines are similar to those stated above for activating unmapped external fields for code conversion although these data elements are not limited to supporting code conversion requirements only.
Extend Oracle e-Commerce Gateway Supported Transactions

Oracle e-Commerce Gateway provides several methods to extend currently supported transactions through the use of trading partner reference fields,
descriptive flexfields, and Oracle e-Commerce Gateway Extensible Architecture. Refer to the section entitled Enable Additional Transaction Data for details on when and how to use each method.
4-34
Synchronize New Transaction Layout Definitions with Translator
Synchronize New Transaction Layout Definitions with Translator

Once the necessary changes are entered, re-run the Transaction Layout Definition Report and use the report output to synchronize your new transaction layout definitions with the translator.
Common Transaction Interface File Definition Errors
Common Transaction Interface File Definition Errors

Moving data elements from the line level to the header level Changing the record layout or column attributes of the control record Deleting the control record Incorrect usage of external fields for code conversion Exceeding maximum record length of 1024 bytes Deleting data element containing a process rule Deleting data elements that are required by Oracle e-Commerce Gateway or Oracle Applications Refer to the Trouble Shooting section for more details.
4-36
Set Up Trading Partners

The steps for setting up a Trading Partner are detailed below. First read the section on Trading Partner Detail for important details about Trading Partner. Reference the Oracle e-Commerce Gateway User Guide for details to complete the windows.
Step 1: Define Trading Partner Group

Enter a new Trading Partner Group or access an existing Trading Partner Group. Enter a new Trading Partner name or position on an existing Trading Partner name. Select the appropriate New or Open button.
Step 2: Define Trading Partner - Assignment

From the Define Trading Partner window, select the Assignment tab. Select the name and site from the list of values. Only the names and sites from the organization associated with your sign on EDI Responsibility are presented in the list of values. The EDI Location Code is returned from the base Oracle Application where the site is defined.
4-38
Step 3: Define Trading Partner - Details

From the Define Trading Partner window, select the Detail tab. Enter the transactions, the transaction types, the translator code, and the document standard for code conversion for the trading partner. It also enables a document (transaction) for processing, and flags the transaction as test or production.
Step 4: Define Trading Partner - Contact (Optional)

From the Define Trading Partner window, select the Contact tab. The contact tab is optional. It contains contact data for the specified trading partner. It may be used by the EDI Coordinator for the trading partners EDI Coordinators contact data. This data is for reference only. It is not used by Oracle e-Commerce Gateway.

The following are common Trading Partner set up errors:
s
Invalid Trading Partner/EDI Location Code Transaction not enabled Invalid Trading Partner Trading Partner Group already exists
4-40
Set Up Code Conversion
This location already has a different Trading Partner value. Overwrite? INVALID_OPERATION error occurred while writing to output file
Refer to the Trouble Shooting section for more details.

The steps for setting up a Code Conversion are detailed below. First read the section on Code Conversion Detail for important details about Code Conversion. Refer to the Oracle e-Commerce Gateway Users Guide for details to complete the forms.
Step 1: Review/Define Code Conversion Categories

Review the list of seeded Code Conversion Categories. Add additional Code Conversion Categories if needed for your code conversion value table entries. Enable the number of search keys that you will use in the code conversion value table for each Code Conversion Category if you are using search keys.
4-42
Step 2: Enable Code Conversion

Locate the transaction, format map, and transaction level that has the column (data element) name that you need to enable for code conversion. You enable a column for code conversion by entering a code conversion category in the Category column. When this is done, only code conversion value table entries with the code conversion category will be accessed during code conversion for that column. If you use search keys, enter the column name that contains the value to be used as part of the search key.
Step 3: Define Code Conversion Values

Enter all the data for the code conversion value tables: Category, Description, Direction, Search Key 1 - Key 5, Oracle internal code, External code 1 - external code 5.
4-44
Interface with Translators

The Translator is a third-party software application designed to transform a formatted file into any other format. Traditionally, it transforms proprietary formats to EDI transactions according to the designated standard (e.g., X12, EDIFACT). It considers both the data required by the chosen standard and the data required by the trading partner. It maps the data from the transaction interface file to the required file format according to the requirements. A Translator data map may be defined to produce a transaction according to the recommendations of any industry guideline such as UCS, EIDX, or AIAG. A single data map may accommodate the data requirements of a single trading partner or many trading partners. The Translator identifies each trading partners transactions with a unique code, and then invokes a communication method (ftp, e-mail, fax, etc.) to transmit this file either to the trading partner directly or to a third party for further processing or communication. The process is reversed (received communication of standard EDI file through translator to interface file) for inbound transactions. The following should be considered for interfacing with a Translator: Accurate Translator Code Available reports Changes in Record Layout due to upgrade or patch. Predefined record layouts and data maps in the Translator. Synchronize record layouts in the Oracle e-Commerce Gateway and the Translator Create data maps in the Translator for inbound transaction Create data maps in the Translator for outbound transactions Detecting Files Transferring Files Communications Accurate Translator Code The Translator Code is used to identify Trading Partners between the Oracle e-Commerce Gateway and the Translator. The Translator Code is first defined in the Translator. In the Translator, it is used to access trading partner specific maps, codes, data, and their entire profile. It is copied to the Translator Code field in the Trading Partner Detail tab in the Define Trading Partner window in the Oracle
e-Commerce Gateway. It must be accurate. The Translator Code along with the EDI Location Code are used to derive the trading partner site in the base Oracle Application. It is written on every Control Record 0010 at the start of each transaction in the transaction interface file. If the Translator Code is wrong, then the data may be mapped to the wrong data map, and/or sent to the wrong Trading Partner. Available Reports These reports should be present in one form or another on a Translator. Some Translators provide additional reports, the ability to develop different reports and the ability to execute user-defined queries on Oracle and other databases to produce other reports. Transaction Interface File Definition Report The record layout expected for outbound transactions and produced for inbound transactions.
Transaction Data File Report

Used to validate a data file against its record layout. Trading Partner Definition Report Shows the data entered for each Trading Partner, such as contacts, Translator Code, method of communication, etc. Trading Partner Map Report Show the translation map for a given Trading Partner or set of trading partners. Changes in Record Layout due to Upgrade, Patch, or Customisation. The Oracle Applications and the Oracle e-Commerce Gateway may change the layout or actual data contained in the transaction interface file because of an upgrade, or a patch. They may also change because of your customization to meet your own or a Trading Partners requirements. Predefined Record Layouts and Data Maps in the Translator. Many Translator vendors provide pre-defined data maps in standard EDI formats for the most common transactions, such as purchase orders and invoices. They may even provide pre-defined base maps for particular large vendors, however, these maps will almost always need further definition for your particular situation.
4-46
Synchronize Record Layouts in the Oracle e-Commerce Gateway and the Translator. The Translator must know where to look for data to map to a given standard transaction and format. They rely on the Record Number on each record in the transaction interface file to identify the data on that record, given the transaction definitions in the Oracle e-Commerce Gateway. At the same time, a Translator may have a preference for getting certain data elements earlier in the outbound transaction interface file so that it can use that data in multiple places. In an inbound file, it may be easier for the Translator to process the incoming data into a certain order. Adjusting the layouts between the Oracle e-Commerce Gateway and the Translator can optimize the processing for both. Create Data Maps in the Translator for Inbound Transaction Some trading partners may want to use different data segments of the EDI standard or use other standard formats such as XML for inbound transactions. The Translator stores this layout and formatting information in a file called a data map or simply a map. This allows the translator to know where to look in the inbound transaction file for the data needed to populate the EDI segment. The translator can also use this map to perform code conversions from the values in the Oracle Applications to the EDI standard for weight, for example. Deciding which code conversions can be done on the Oracle e-Commerce Gateway and which on the translator is part of the Synchronization process above. One map can serve multiple trading partners. Create Data Maps in the Translator for Outbound Transactions Some trading partners may want to use different data segments of the EDI standard or use other standard formats such as XML for outbound transactions. The Translator stores this layout and formatting information in a file, called a data map, or simply a map. This allows the Translator to know where to put the data from the EDI segment in the output transaction file. The Translator can also use this map to perform code conversions from the values the EDI standard uses to those the Oracle Application expects for weight, for example. Deciding which code conversions can be done on the Oracle e-Commerce Gateway and which on the Translator is part of the Synchronization process above. One map can serve multiple Trading Partners. Detecting Files The Translator must recognize when it has data waiting to be translated or communicated. Normally this is done manually by the user or by the presence of a file in a given directory. This is why the files built by the Oracle e-Commerce
Gateway are in one directory, moved to another directory to be translated, and once formatted to the desired standard moved into a third directory to be communicated. Transferring Files The link between the Translator and the Gateway must also be considered, i.e. are they on the same server, on different UNIX boxes, or is the Translator on a mainframe. This affects both the file structures going back and forth - e.g. variable for UNIX but fixed width for mainframe transfers - and (possibly) the functionality of the Translator. For example the mainframe based Translator may use an older architecture which means it is potentially less flexible in set-up terms than its (newer) UNIX cousin.
Communications
The Translator identifies and uses the communication method specified for each trading partner. This can be any method supported by the hardware and software of the system.
4-48
Archive/Backup
Archive/Backup
The goal of archiving or backing up data is to preserve data at each stage of its creation and transmission so that it can be recovered if it is lost or deleted. The first level is the backup of the Oracle database performed by the DBA, and makes sure that changes made to the applications in the database, from any source, are preserved for any needed recovery. The second level is the backup of the entire system, performed by the system administrator. This backs up the files from the operating system level, whether they are part of the database or not. The strategy you choose for these functions is the first step to determine how much archiving needs to be done. The Oracle e-Commerce Gateway often needs another level of archiving. Once the data has been extracted from the base application into a transaction interface file, and again once that transaction interface file has been processed into a transaction file by the Translator, these files should be preserved. The first reason is to save them as an audit trail, showing what data was sent through the process to the trading partner. This audit trail also serves to identify the transformation done by the Oracle e-Commerce Gateway and the Translator, so that you can correct the conversions they do. The second reason is that there may be legal constraints in the trading partner's country and/or industry which require commercial documents to be kept for a period of months if not years. It is also possible that the trading partner's industry sector may deal in huge value or high risk goods, e.g. aerospace, in which case secure archiving of transactions is essential in the case of disputes, investigations, or legal action. The other purpose of archiving is to be able to re-transmit outbound transactions to trading partners if necessary. But whatever the reason, or the transaction(s) involved, archiving should apply to both inbound and outbound transactions. Transactions may be processed through the Oracle e-Commerce Gateway several times per day. Each time the extraction process is executed, an output file name must be provided to the Concurrent Request. To preserve each of these output files separately, a unique name is generated with each run. The application generates a default file name that starts with the transaction code, or you may enter your own file name. Another place the archiving is handled is in the translator. Almost all translators archive the files they create either immediately after creation or after an attempted transmission whether successful or not. Some translators may handle archiving the input file from the Oracle e-Commerce Gateway. However, this only removes the need for the preceding step if the translator is run immediately after the extraction every time. For outbound transactions, it may also be necessary to designate the directories where a file will be placed by the Oracle e-Commerce Gateway, archived
Archive/Backup
from the Oracle e-Commerce Gateway, picked up by the translator for processing, output by the translator, archived from the translator, or picked up by the communication process. For inbound transactions, the directories must be the directory the file is deposited into by the communication process; the directory the translator picks up the file from, the directory the pre-translation file is archived into, the directory the Translator writes the translated interface file into, and the directory the Oracle e-Commerce Gateway reads the file from.
Outbound Directory Structure

A sample set of directories and files are listed below. D:\outbound_flat_file: Directory the Oracle e-Commerce Gateway places outbound transaction files. It should be defined in UTL_FILE_DIR in the init.ora file and the Oracle e-Commerce Gateway profile ece:outbound file path. D:\outbound_flat_file\archive: Directory the files from the Oracle e-Commerce Gateway are copied into after generation. The reason for having this directory and the next one separate the source of file generation, so the translator cannot attempt to open a file the Oracle e-Commerce Gateway is generating. D:\outbound_flat_file\Translator_input: Directory the Translator reads its input file from. Although this can be the same as the Oracle e-Commerce Gateway archive directory, it generally should not be. This is because the translator usually looks in the outbound directory and reads every file in it. It assumes that if the file is in this directory, it should be processed. D:\outbound_flat_file\Translator_input\archive: Directory the translator archives each file as it successfully translates it. D:\outbound_flat_file\Translator_output: This is where the translator writes its outbound transaction files. D:\outbound_flat_file\communication: This is where the communication process looks for files that are ready to be sent. D:\outbound_flat_file\communication\archive: This is where the communication process copies files it has successfully transmitted.
4-50
Archive/Backup
Inbound Directory Structure

A sample set of directories and files are listed below. D:\inbound_flat_file\communication: This is where the receiving communication process deposits the incoming file. Once the communication process finishes, the file(s) are copied to the following file. D:\inbound_flat_file\translator_input: This is the directory where the translator looks for its input. Again, the translator generally gets all files in the directory. Once it successfully translates a given file, it copies it to the following file: D:\inbound_flat_file\translator_input\archive: D:\inbound_flat_file\translator_output: This is where the translator writes the translated file. When the translation run is complete for all files in the translator_input directory, the files are copied into the following file. D:\inbound_flat_file\Gateway_input: This is where the Oracle e-Commerce Gateway looks for transaction interface files to process. It should be defined in UTL_FILE_DIR in the init.ora file. Once it processes a file, that file is copied into the final directory below. D:\inbound_flat_file\Gateway_input\archive: Obviously, mechanisms such as UNIX shell scripts or Windows batch files need to be defined to move these files between some of these directories. Execution in some cases can be set up in the translator; the movements from D:\outbound_flat_file\ to D:\outbound_flat_file\archive and D:\inbound_flat_file\Gateway_input to D:\inbound_flat_file\Gateway_input\archive will have to be set up to execute in Concurrent Processing as part of a Process Set running the Oracle e-Commerce processing. A degree of operating system expertise will be required for successful implementation. For example, a UNIX cron job needs to be set up to run the communication process (ftp, or mail file processing) and then move the files to the other directories at certain times of the day. If this process is followed, you will be able to examine the files created at each step. They will also be able to process without contention, however, there are eventually going to be a lot of files out there. Even if disk space is fairly cheap, eventually performance will force the removal of older files. You may want to consider removing the files after you make the operating system backup. Once they are preserved on a separate medium, they can always be recovered as needed.
Archive/Backup
4-52
5
Transaction Interface File Architecture
This chapter contains the following information about Oracle e-Commerce Gateway implementation: File Structure Overview on page 5-2 Interface Data File Structure on page 5-5 Optional Outbound Trading Partner Flexfield Records (0020-0070) on page 5-12 Code Conversion Internal and External Codes on the File on page 5-25
Transaction Interface File Architecture 5-1
File Structure Overview

Oracle e-Commerce Gateway produces ASCII files for outbound transactions. For inbound transactions, Oracle e-Commerce Gateway processes ASCII file produced by a Translator. Each file consists of several records that are uniquely identified by its record number. A set of record numbers are assigned to a level of data in the transaction, for example, the records in range 1000-1999 may contain data at the header level of the document. Records in range 2000-2999 may contain data at the item level of the document. Each transaction consists of multiple levels of data. They are indicated by their level names show in the Interface File Definition window. Usually the data from a level is written to many records in the transaction interface file. Each record may consist of a single set of data elements such as all the currency data on the same record, or it may consist of several groups of related data. The amount of data on any record is constrained only by a maximum record length of 1024. The following figure illustrates the architecture of the records such as 0010-3000 that define a transaction and the two portions of data that define a single record. The first portion is the data in record positions 1-100 and the second portion is the application data in positions 101-1024.
Record Content Control record Trading Partner Header Flexfields Trading Partner Detail Flexfields Base Application Data Base Application Data Base Application Data Number 0010 0020-0050 0060-0070 1000 etc. 2000 etc. 3000 etc. Record Position 1-100 Common Key Common Key Common Key Common Key Common Key Common Key Record Positions 101-1024 Base Application Data Base Application Data Base Application Data Base Application Data Base Application Data Base Application Data
Reference the Modify Transaction Interface File section, the Code Conversion Detail section, and the Oracle e-Commerce Users Guide for detail on how to modify the records.
5-2
Control Record (Record 0010) Each transaction must start with a control record that has key data to pass between Oracle e-Commerce Gateway and a Translator. The control record is identified by record number 0010. Key data includes the Translator code, a key EDI Location Code for that transaction, and a Document Code like POO for the outbound purchase order. For inbound transactions, batch control numbers from standard transactions may be written on the control record for tracking. The transaction data in the transaction detail records follow the control record. Descriptive Flexfield Records (Records 0020-0070) The Oracle e-Commerce Gateway has descriptive flexfields in records 0020-0070 in any outbound transaction interface file. This flexfield data is written to the outbound transaction interface file whenever the flexfields are defined. They are available for data mapping in the Translator. Common Record Key Each record has two sections, the record common key (positions 1-100) and the application data area (positions beyond 100). The common key is written on every record in the file. It is used as a visual reference on each record to facilitate browsing the file or extracting transaction from a file if needed. The following key data is in the common key: (Not all the fields are mentioned here.)
s
Translator Code is the code that identifies the Trading Partner in the Translator. Reference 1 is the document or transaction identifier from the header record of the transaction. For example, it may be the invoice number or the purchase order number. Reference 2 is an identifier from the next document level such as a line or detail level. For example, it may be a line number. Reference 3 is an identifier from the next document level such as a shipment level. For example, it may be a shipment number. (Note that only the first three levels are showing for this visual reference in the file.) The record number uniquely identified the set of data in the given transactions. This is the only required data in the first hundred bytes of each record. Record Layout and Record Qualifier are labels to identify the type of data on the record if someone must read the file. There are some Record Layouts like AD for address that you will see in all transactions. An address record may
have a Record Qualifier like ST to indicate a ship-to address or BT for a bill-to address. See below for a list of common Record Layouts and Record Qualifier that may be seen in many transactions. The following illustrates the content of a common key.
Translator Code AB-01 AB-01 AB-01 AB-01 AB-01 AB-01 AB-01 AB-01
Refer. 1 101111 101111 101111 101111 101111 101111 101111 101111
Refer. 2
Refer. 3
Record Record Record Number Layout Qualifier 0010 1000 PO IT SH SH IT SH SH PO1 IT1 SH1 SH1 IT1 SH1 SH1
00001 00001 00001 00002 00002 00002
00001 00002 00001 00002
2000 3000 3000 2000 3000 3000
Figure 51 Common Key
Application Descriptive Flexfields Records Many descriptive flexfields are found throughout the transaction. They are extracted from the application for outbound transactions. They may be loaded into the application open interface tables for inbound transaction. Most descriptive flexfields are defined to a shorter length on the transaction interface file than they are defined in the application due to realistic length on most business data. Any field may be increased up to its maximum length defined in the base Oracle application. You can assign a different record number to the flexfield if the maximum length of the record is attained. See the Interface File Definition section in the Oracle e-Commerce Gateway Users Guide for details.
5-4
Interface Data File Structure

Each data file consists of several records. Each record has two sections, the common record key (positions 1-100) and the application data area (positions 101 to 1024). The structure is shown in the following table:
Data Common Key (1-100) Translator Code (short) Key 1 (Document identifier) Key 2 Key 3 Record Number Record Layout Record Layout Qualifier Application Data (101 1024) 1-25 26-47 48-69 70-91 92-95 96-97 98-100 101-1024 25 22 22 22 4 2 3 up to 924 Position Length
Table 51 Record Structure
Each record is referenced by a number that identifies the level and block of data in the data file. The numbering scheme for each level is usually in increments of 1000.
Record Number 0010 0020-0070 1000-1999 2000-2999 3000-3999 4000-4999 Content Control Record Oracle e-Commerce Gateway Flexfields Application Header Level Application Detail Level Application Next Detail Level Application Next Detail Level
Table 52 Sample Record Numbers and Levels
The exact record number blocks varies by transaction due to variations in the data required. However, the hierarchy remains the same. Large transactions may have any level span over several blocks of 1000. For example, the header level may span from 1000 to 3999, and the item level may span from 4000 to 5999.
Sample File Structure

The following table illustrates the record number range and levels of data for a sample transaction.
Record Number Data Type Control Record Trading Partner Header Flexfields Trading Partner Detail Flexfields Bill To Address /Code Bill to Misc. Data, Contacts Bill to Customer Flexfields Bill to Site Flexfields Ship to Address/code Ship to Misc. data, contacts Ship From Codes Basic Header Data Amount Data Currency Data, Misc. data Payment Terms Data Sales Representative, Comments Header Flexfields Header Allowance/Charges Extension Tables: Header Data (custom) Basic Item Data Data Level CONTROL TRADING PARTNER TRADING PARTNER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER ITEM (Position 92-95) 0010 0020-0050 0060-0070 1000 1010 1020-1050 1060-1090 1100 1110 1400 2000 2010 2040 2050 2060 3000-3030 3080-3090 3900 4000
5-6
Sales Order Data Part Descriptions, Sales Channel, Order Status Transaction Reference Key Line Flexfields Extension Tables: Item Data (custom) Line Tax Data Line Tax Flexfields Extension Tables: Transaction Line Detail Data
ITEM ITEM ITEM ITEM ITEM ITEM DETAIL ITEM DETAIL ITEM DETAIL
4010 4020 4030 5000-5030 5900 6000-6010 6020-6060 (custom)
Table 53 Sample File Structure
Special Records
Control Record (0010) Layout
Control Record 0010 is used by both the Oracle e-Commerce Gateway and the Translator for Trading Partner identification. It includes data identifying the document (transaction) type, transaction date and time, Trading Partner code, and whether it is a test or production transaction. This record is 1024 characters long. This record contains key data needed by the Oracle e-Commerce Gateway. Control Record 0010 is the first record for every transaction.
Sample Inbound Seq. 01 02 03 04 05 06 Data Element Translator Code (short) Key 1: (may be truncated) Key 2: Key 3: Record Number Record Layout Length 25 22 22 22 4 2 Position 1-25 26-47 48-69 70-91 92-95 96-97 0010 CT 0010 CT Transaction A1-ACME-2 Sample Outbound Transaction A1-ACME-1
1234567890123 64564522
07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Record Qualifier Communication Method Test Flag Document ID Document Type Document Purpose Code Document Code (full) Translator Code (full) TP Location Code, External
3 2 1 6 5 2 35 30 35
98-100 101-102 103 104-109 110-114 115-116 117-151 152-181 182-216 217-290 291-370 371-450 451-465 466-480 # # # # #
CTL ED P POI STAND OR
CTL ED T POO BLANK CH
1234567890123 64564522 A1-ACME-2 AC7654 ACME CORP 1234 9875 19970616 230723 534342 Not applicable 19970626 A1-ACME-1 AC9832 ACME INC
Trading Partner Description 74 TP Reference 1 TP Reference 2 Transaction Date/Time Transmission Run ID Organization ID Document Standard Control Number 1 Control Number 2 Control Number 3 80 80 15 15 15 10 10 10 10
654 897 3423
(not applicable) (not applicable) (not applicable)
Table 54 Control Record Layout
# Check the Control Record 0010 layout using the Interface File Definition window for the position of this data if they are defined for the transaction.
5-8
Control Record Field Descriptions

Seq. 1 2 Data Element Translator Code (short) Key 1: (short) Value First 25 characters of the Translator Code Note This is the Trading Partner identifier for this transaction as defined by the Translator. First 22 characters of Document Code. Do not use in the Translator data map, since it may be truncated. Second level document identifier Third level document identifier 0010 CT CTL E (EDI) T (test) P (production) Fixed value 0010. Fixed value CT. Fixed value CTL. This code indicates if this transaction is to be faxed or sent via the EDI standard process. This code is the flag to indicate that the transaction is to be treated as test (T) or production (P) by the Translator. This code must remain synchronized with the Test flag defined in the Translator. Which code overrides the other if they are out of sync depends on the Translator. For inbound transactions, the EDI Trading Partner detail flag prevails. This code identifies the transaction type and its direction, e.g., POI for purchase orders inbound. This code identifies sub types of the given transactions, such as blanket order or standard orders to process. This code identifies the transaction as the original, change, replacement or other appropriate status for the given transaction. This is the primary transaction code such as the purchase order or invoice number. The code is the key document identified for the specific transaction.
3 4 5 6 7 8 9
Key 2: Key 3: Record Number Record Layout Record Qualifier Communication Method Test Flag
10
Document ID
Depends on the transaction. Sample: POI = PO Inbound
11
Document Type
Depends on the transaction. Sample: BLANKET, STANDARD
12
Document Purpose Code
Depends on the transaction. Sample: OR (original), CH (change),
13
Document Code (full)
14
Translator Code (full)
This is the full length Translator Code defined in the Translator to identify this Trading Partner. This code is the EDI Location code as defined for the Trading Partner for the given transaction. This is usually found in the ASC X12 N104 ID code or the EDIFACT NAD segment. This code is maintained in the Oracle Application.
15
Trading Partner Location Code, external
16
Trading Partner Description
This is the Trading Partner description as defined in Oracle e-Commerce Gateway for outbound transactions or by the Translator for inbound transactions. This is the Trading Partner reference 1 code defined in Oracle e-Commerce Gateway for the primary Trading Partner location for outbound transactions. This is the Trading Partner reference 2 code defined in Oracle e-Commerce Gateway for the primary Trading Partner location for outbound transactions. This is the date and time that the transaction is created by Oracle e-Commerce Gateway or the Translator. Run ID from the Concurrent Manager which created the transaction. from inbound transaction This is the internal id associated with the organization. as defined in Oracle Applications. This is the standard identified for the document enabled for the Trading Partner. from inbound transaction This is the batch control number from the outer most electronic envelope for inbound transactions only. This is the ASC X12 ISA or EDIFACT UNB control number.
17
TP Reference 1
18
TP Reference 2
19
Transaction Date/Time Transmission Run ID Organization ID
20 21
22 23
Document Standard Control Number 1 (external)
5-10
24
Control Number 2 (external)
from inbound transaction
This is the batch control number from the inner electronic envelope for inbound transactions only. This is the ASC X12 GS or EDIFACT UNG control number.
23
Control Number 3 (external)
from inbound transaction
This is the batch control number from the starting transactions segment for inbound transactions only. This is the ASC X12 ST or EDIFACT UNH control number.
Table 55 Control Record Field Descriptions
Optional Outbound Trading Partner Flexfield Records (0020-0070)

For outbound transactions, you may enable descriptive flexfield data at the Trading Partner header level (Record Numbers 0020-0050) and at the Trading Partner Detail level (Record Numbers 0060-0070). The Trading Partner header level flexfields are written for every transaction type for the Trading Partner such as all their outbound purchase order transactions and all their outbound purchase order change transactions. The Trading Partner detail level flexfields are written for the transaction type enabled for the Trading Partner. This flexfield data is written to the outbound transaction interface file whenever the flexfields are defined. They are available for data mapping by the Translator. The records may appear in the interface data file with no data if the columns are not enabled. Trading Partner flexfields are not applicable to inbound transactions. You must enable the Trading Partner header flexfields and Trading Partner detail flexfields (system administration required) to use them.
5-12
Common Record Key (1-100)

Table y below describes the Oracle transaction interface file record key which occupies the first 100 characters of each record in every transaction. This record area facilitates any visual audit and research into the file. Note: The content of the first 100 characters on the control record (0010) is defined the same as every other record for a given transaction. The record number allows the Translator to uniquely identify a record layout within the transaction. Do not rely on the record layout code and record layout qualifier to uniquely identify a record. Some transaction data in the record key may be truncated so the Translator should refer to the full transaction data in the data area (positions 101-1024) of the record. The data in Key 1 through Key 3 varies by the transaction and the record level within the transaction.
Data Element Translator Code (short) Key 1 (Primary Key) Key 2 Key 3 Record Number Record Layout Code Record Layout Qualifier
Seq. 1 2
Position 1-25 26-47
Length 25 22
3 4 5 6 7
48-69 70-91 92-95 96-97 98-100
22 22 4 2 3
Table 56 Record Key (1-100) Data Element Summary
Translator Code (1-25) This code is the Trading Partner identifier as defined in the Translator. The code identifies the communications method, electronic mailbox, standard, and data maps
for the specific transaction. This code is the link between the Oracle e-Commerce Gateway and the Translator. This code is defined as the Translator code in Define Trading Partner window, Details tab. Keys 1-3 (26-91) Keys 1-3 represent key data from the first three levels of the given transaction. This data is for audit or research purposes to facilitate reading the file directly. The data may be truncated. Key 1 is the Primary Key from the transaction. It may be the purchase order number, invoice number, or shipment number for corresponding transactions. Full primary document key is written in positions 117-151 of the control record 0010. Keys 2-3 represents other data at the second and third level within the transaction. A transaction may have more than three levels of data which are not stored in the key area. Record Number (92-95) The record number is a unique number within a transaction to identify specific data in a transaction. Translators should rely on the record number to uniquely identify a record in the data file. A sample of a simple numbering scheme and a larger range numbering scheme are displayed in the following table. Any transaction may use any range of numbers for a data level.
5-14
Record Number Sample-Simple Transaction 0010 0020-0070 1000-1890 1900-1990 2000-2890 2900-2990 3000-3890 3900-3990 4000-4890 4900-4990
Record Number Sample-Longer Transaction 0010 0020-0070 1000-4890 4900-4990 5000-5890 5900-5990 6000-6890 6900-6990 7000-7890 7900-7990
Content Control Record Oracle e-Commerce Gateway Flexfields Application Header Level Application Header Level Extension Table (Custom) Application Detail Level 1 Application Detail Level 1 Extension Table (Custom) Application Detail Level 2 Application Detail Level 2 Extension Table (Custom) Application Detail Level 3 Application Detail Level 3 Extension Table (Custom)
Table 57 Sample Record Numbers
The numbering scheme per data level is in increments of 1000. The numbering scheme per record is in increments of 10 allowing for new data levels and records to be inserted. The record numbers are not used consistently across transactions. For example, the record 1050 may contain different data depending upon the transaction. The X900 series in any range is reserved for the Oracle e-Commerce Gateway extension tables for consistency. Record Layout Code (96-97) The record layout code is used to indicate the type of data in the record. These codes are particularly useful when reusable records such as addresses and flexfields are used in the file. Except for reusable records defined by the Oracle e-Commerce Gateway, the record layout may have a different meaning across transactions. For example, the record layout IT may contain different data depending upon the transaction. Record Layout Qualifiers (98-100) Record qualifier codes qualify what type of data is on the reusable records or any other record in the transaction. For example, an AD address record must be
qualified to be a ship-to, bill-to, remit-to, and so on address record for visual purposes. Other record qualifiers are assigned to every record in the transaction to complete the record key, but they do not necessarily facilitate data mapping since only the record number uniquely identifies a record to the Translator. Refer to the section on Common Records (based on Record Layout Codes) for record layouts.
Record Number 0010 1010 1040 1060 1070 2000 2100 2110 Record Layout CT AD AD A1 A2 IT A1 A2 Record Qualifier CTL ST1 BT1 HD1 HD2 ITM IT1 IT2
Content Control Record Address Record with Ship to Location Data Address Record with Bill to Location Data Flex Field data with Reusable Record A1 Layout qualified by HD1 Flex Field data with Reusable Record A2 Layout qualified by HD2 IT for Item data qualified by ITM to distinguish the data from other IT records in this transaction. Flex Field data with Reusable Record A1 Layout qualified by IT1 Flex Field data with Reusable Record A2 Layout qualified by IT2
Table 58 Sample Record Number, Record Layout, and Record Qualifier
5-16
Common Records (Based on Record Layout Code)

Record Layout codes are indicated in positions 96-97 of the common record key. Several data elements relate to each other and can be found in several standard transactions. These related elements, for example, include addresses, contact data, and flexfields. The actual content of any record is qualified by the record layout qualifier, for example, ST or ST1 for ship-to address, and BT or BT1 for bill-to address. Verify the record layout for any record in a transaction including its data element, length of the field, and its position using the record in the Interface File Definition window. Note: You can modify these record layouts. However, any changes may affect the Translator data map you may be using. These record layouts may be seen in many transactions.
Record Layout Codes A1
Description Flexfield Layout 1
Meaning Flexfields Layout 1 Layout 1 contains the Flexfield Context plus attributes each with length 80. The interface table has the flexfield with the full length of 150 characters if needed.
A2
Flexfield Layout 2
Flexfields Layout 2. Layout 2 contains attributes each with length 80. The interface table has the flexfield with the full length of 150 characters if needed.
A3
Flexfield Layout 3
Flexfields Layout 3 Layout 3 contains the Flexfield Context plus attributes each with length 100. The interface table has the attribute with the full length of 150 characters if needed. Flexfields Layout 4. Layout 4 contains attributes each with length 100. The interface table has the flexfield with the full length of 150 characters if needed.
A4
Flexfield Layout 4
A5
Flexfield Layout 5
Flexfields Layout 5 Layout 5 contains four pairs of internal defined flexfields and its external converted codes plus the Flexfield Context. The interface table has the flexfield with the full length of 150 characters if needed.
A6
Flexfield Layout 6
Flexfields Layout 6 Layout 6 contains four pairs of internal defined flexfields and its external converted codes. The interface table has the flexfield with the full length of 150 characters if needed.
AD
Address Record
Full Name and Addresses and Codes for each business entity where State and county codes are explicit. This is usually data from RA-tables.
AX
Address Record
Full Name and Addresses and Codes for each business entity where REGION 1, REGION2, REGION3 contain the state and county. This is usually data from HR-tables.
CN CM
Contact Record-Format 1 Contact Record-Format
Primary Personnel Contact, title and phones. Primary Contact phone numbers
Table 59
Seq. 1 2 3 4 5 6
Record Layout
Length 100 30 80 80 80 80
Control Level Flexfields Common key including Record Number Any Flexfield Context Any Flexfield 1 Any Flexfield 2 Any Flexfield 3 Any Flexfield 4
Table 510 Descriptive Flexfields (A1) Record Layout
5-18
Seq. 1 2 3 4 5 6
Control Level Flexfields Common key including Record Number Any Flexfield 1 Any Flexfield 2 Any Flexfield 3 Any Flexfield 4 Any Flexfield 5
Length 100 80 80 80 80 80

Seq. 1 2 3 4 5 Control Level Flexfields Common key including Record Number Any Flexfield Context Any Flexfield 1 Any Flexfield 2 Any Flexfield 3 Length 100 30 100 100 100

Seq. 1 2 3 4 5 Control Level Flexfields Common key including Record Number Any Flexfield 1 Any Flexfield 2 Any Flexfield 3 Any Flexfield 4 Length 100 100 100 100 100
Seq. 1 2 3 4
Flexfields Common Key including Record Number Shipment Allowance/Charge Flexfield Context Shipment Allowance/Charge Flexfield 1-Internal Shipment Allowance/Charge Flexfield 1-External (AC-Special Services_code)
Length 100 30 70 25
5 6
Shipment Allowance/Charge Flexfield 2-Internal Shipment Allowance/Charge Flexfield 2-External (AC_Special_Charges_code)
70 25
Shipment Allowance/Charge Flexfield 3-Internal (AETC_number)
70
8 9
Shipment Allowance/Charge Flexfield 3-External Shipment Allowance/Charge Flexfield 4-Internal (AETC_Responsibility_Code)
25 70
10
Shipment Allowance/Charge Flexfield 4-External
25
5-20
The following table has a similar layout to A5 for flexfields 5-8, 9-12, and 13-15:
Seq. 1 2 Flexfields Common Key including Record Number Shipment Allowance/Charge Flexfield 5-Internal (AETC_Reason_Code) 3 4 5 6 7 8 9 Shipment Allowance/Charge Flexfield 5-External Shipment Allowance/Charge Flexfield 6-Internal Shipment Allowance/Charge Flexfield 6-External Shipment Allowance/Charge Flexfield 7-Internal Shipment Allowance/Charge Flexfield 7-External Shipment Allowance/Charge Flexfield 8-Internal Shipment Allowance/Charge Flexfield 8-External 25 70 25 70 25 70 25 Length 100 70
Table 515 Address (A6) Record Layout
All name and address records that have explicit state/province and county data have the following format. There may be cases where the interface process does not populate some of the data fields depending on data availability.
Seq. 1 2 3 Business Entity Data Common Key including Record Number Business Entity Site Code (internal) Business Entity Site Code (external) EDI Location Code 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Business Entity Name Business Entity Address Line 1 Business Entity Address Line 2 Business Entity Address Line 3 Business Entity Address Line 4 Business Entity City Business Entity Postal Code Business Entity Country (Internal) Business Entity Country (ISO) (external) Business Entity State (internal) Business Entity State (External) Business Entity Province (internal) Business Entity Province (External) Business Entity County 60 35 35 35 35 30 15 20 03 20 10 20 10 25 N402 N402 N404 N102 N301 N302 N301 N302 N401 N403 Length 100 60 35 Internal N104 ASC X12
Table 516 Address (AD) Record Layout
5-22
All name and address records that have REGION 1, REGION2, and REGION3 in place of explicit state/province and county data have the following format. This data is extracted from Human Resources tables. There may be cases where the interface process does not populate some data fields depending on data availability.
Seq. 1 2 3 Business Entity Data Common Key including Record Number Business Entity Site Code (Internal) Business Entity Site Code (External) (EDI Location Code) 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Business Entity Name Business Entity Address Line 1 Business Entity Address Line 2 Business Entity Address Line 3 Business Entity City Business Entity Postal Code Business Entity Country (Internal) Business Entity Country (ISO) (External) Business Entity REGION 1 (Internal) Business Entity REGION 1 (External) Business Entity REGION 2 (Internal) Business Entity REGION 2 (External) Business Entity REGION 3 (Internal) Business Entity REGION 3 (External) 60 35 35 35 30 15 20 03 25 10 25 10 25 10 N402 N402 N404 N102 N301 N302 N301 N401 N403 Length 100 20 20 Internal N104 ASC X12
Table 517 Address (AX) Record Layout
Contact Format 1 (CN) Record Layout You may add secondary contact data to this record.
Seq . 1 2
Business Entity Contact Data Common Key including Record Number Business Entity Primary Contact Last Name
Length ASC X12 100 35 PER02
Business Entity Primary Contact First Name
35
Business Entity primary Contact Job Title
40
PER09
5 6 7 8 9 10
Business Entity Primary Area Code 1 Business Entity Primary Telephone 1 Business Entity Primary Area Code 2 Business Entity Primary Telephone 2 Business Entity Primary Area Code 3 Business Entity Primary Telephone 3
10 60 10 60 10 60
PER04 PER04 PER04 PER04 PER04 PER04
Table 518 Contact Format 1
Contact Format 2 (CM) Record Layout These records can store phone numbers when contact personnel data is not available. Area Codes are not stored separately in the application.
Seq. 1 2 3 4 Business Entity Contact Data Common Key including Record Number Business Entity Primary Telephone 1 Business Entity Primary Telephone 2 Business Entity Primary Telephone 3 Length ASC X12 100 60 60 60 PER04 PER04 PER04
Table 519 Contact Format 2
5-24
Code Conversion Internal and External Codes on the File

The transaction interface file may have one to five external fields activated for the file for a given internal code that is marked as a candidate for code conversion. Usually only the external 1 fields is activated by the seeded transaction. You may activate other external fields using the Interface File Definition window. Reference the Modify Transaction Interface File section, the Code Conversion Detail section, and the Oracle e-Commerce Users Guide.
Oracle Applications (internal) code
External codes 1-5
Int E1 Int E1 E2 Int E1 E2 E3 Int E1 E2 E3 E4 Int E1 E2 E3 E4 E5

Figure 52 Figure x Sample Records with a Field Eligible for Code Conversion
5-26
6
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Oracle Inventory on page 6-2 Oracle Order Management on page 6-5 Oracle Payables on page 6-6 Oracle Process Manufacturing on page 6-24 Oracle Purchasing on page 6-25 Oracle Receivables on page 6-55 Oracle Release Management on page 6-62 Oracle Shipping Execution on page 6-63 Oracle Supplier Scheduling on page 6-64
6-1
Oracle Inventory
Oracle Inventory
The implementation of any transaction requires some set up in Oracle Applications and Oracle e-Commerce Gateway. This chapter focuses on the application set-ups necessary to implement a transaction that integrates with Oracle Inventory. Note: For the summary layout see Appendix A.
Transaction Transaction Name Movement Statistics Direction Outbound Code MVSTO ASC X12 N/A EDIFACT CUSDEC
The topics covered for outbound transactions include the following:

s
Trading Partner Link to Oracle e-Commerce Gateway Relevant Oracle Application Profiles and Set Ups Extract Criteria Columns Updated Upon Extraction
Current Information
The transaction requirements may change when enhancements are made such as additional data added to the transaction. Current transaction details can be found on Oracle Supports web site. Current detail record layouts are reported via the Transaction Layout Definition Report and the Interface File Data Report.
Outbound Movement Statistics (MVSTO/No X12/CUSDEC) Trading Partner Link to Oracle e-Commerce Gateway
Legal entities are defined in Oracle Human Resources. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code, a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a legal entity in Oracle Human Resources and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the legal
6-2
Oracle Inventory
entity in Oracle Human Resources without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Human Resources is set up properly, verify that the legal entity and the EDI Location Code in Oracle Human Resources is the correct legal entity selected for the trading partner definition in Oracle e-Commerce Gateway. The selected legal entity and the EDI Location Code defined in Oracle Human Resources are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be extracted for the correct trading partner. This could involve either altering the legal entity in Oracle Human Resources, or assigning a different legal entity to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Extract Criteria
The outbound Movement Statistics transaction is controlled by four database views that are defined according to the Oracle Inventory data model for inventory movement statistics. The four views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The four database views are as follows:
s
ECE_MTL_MOV_STAT_V ECE_MVSTO_DETAILS_V ECE_MVSTO_HEADERS_V ECE_MVSTO_LOCATIONS_V
The ECE_MVSTO_DETAILS_V view is used to identify which movement statistics are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type enabled for the trading partner Material movement statistics have not been previously extracted Material movement statistics status is either FROZEN or VERIFIED
6-3
Oracle Inventory
Material movement type matches type selected when transaction was initiated
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows:
SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_MVSTO_DETAILS_V;
Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.
Columns Updated Upon Extraction

Once an eligible material movement statistic entry is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the ECEMVSOB.pls file to update the MTL_ MOVEMENT_STATISTICS table:
Table MTL_MOVEMENT_ STATISTICS Column EDI_SENT_FLAG EDI_TRANSACTION_DATE EDI_TRANSACTION_ REFERENCE Value Y SYSDATE see below
EDI_TRANSACTION_REFERENCE is the concatenation of the parameter values entered when the transaction was initiated:
s
Legal entity Zone code Period Name Stat type - either INSTAT or EXSTAT Movement Type - either A for arrivals, D for Dispatch, AC for arrival adjustments or DC for dispatch adjustments
6-4
Oracle Order Management
Oracle Order Management

The following transactions are delivered with Release 11i.1:
Transaction Transaction Name Purchase Order Purchase Order Change Purchase Order Acknowledgment PO Change Acknowledgment Direction Inbound Inbound Outbound Outbound Code POI POCI POAO PCAO ASC X12 850 860 855 865 EDIFACT ORDERS ORDCHG ORDRSP ORDRSP
The Release 11 inbound Purchase Order (POI) transaction is replaced in Release 11i.1 utilizing the new Order Management data model. Note: For the summary layout see Appendix A.
Current Information
6-5
Oracle Payables
Oracle Payables
The implementation of any transaction requires some set up in Oracle Applications and Oracle e-Commerce Gateway. This chapter focuses on the application set-ups necessary to implement a transaction that integrates with Oracle Payables. Note: For the summary layout see Appendix A.
Transaction Transaction Name Invoice Shipment and Billing Notice Application Advice Payment Order/Remittance Advice Direction Inbound Inbound Outbound Outbound Code INI SBNI ADVO PYO ASC X12 810 857 824 820 EDIFACT INVOIC N/A APERAK PAYORD-REMADV PAYEXT-REMADV
The topics covered for inbound transactions include the following:

s
Trading Partner Link to Oracle e-Commerce Gateway Oracle e-Commerce Gateway Required Fields Review Oracle e-Commerce Gateway Exceptions Resolve Oracle e-Commerce Gateway Exceptions Relevant Oracle Payables Profiles and Set Ups Payables Open Interface Required Fields Review Payables Open Interface Exceptions Return Application Advice to Trading Partner (if appropriate) Resolve Payables Open Interface Exceptions

s
Two forms of Electronic Funds Transfer (EFT) PAYORD, PAYEXT, PAYMUL Pre-note Payment Transaction Handling Options
6-6
Oracle Payables
Trading Partner Link to Oracle e-Commerce Gateway Relevant Oracle Payables Profiles and Set-ups Extract Criteria Columns Updated Upon Extraction
Current Information
6-7
Oracle Payables
Inbound Invoice (INI/810/INVOIC)

Trading Partner Link to Oracle e-Commerce Gateway
Suppliers and supplier sites are defined in either Oracle Purchasing or Oracle Payables. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a supplier/supplier site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the supplier or supplier site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the supplier/supplier site and the EDI Location Code in Oracle Applications is the correct supplier/supplier site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected supplier/supplier site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be imported for the correct trading partner. This could involve either altering the supplier/supplier site in the base Oracle Application, or assigning a different supplier/supplier site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Oracle e-Commerce Gateway Required Fields

The following is a list of the Oracle e-Commerce Gateway required fields. These fields are required to authenticate the trading partner and transaction. If the required data is not provided in the transaction, the Oracle e-Commerce Gateway import process fails the transaction. Then an exception message is displayed in the View Staged Documents window. If the trading partner is valid and the transaction is enabled, the import process proceeds to validate the transaction using the user-defined column rules. If no process or column rule exceptions are detected, the Oracle e-Commerce Gateway
6-8
Oracle Payables
import program will write the transaction to the Payables Open Interface tables to be processed by the Payables Open Interface API.
Oracle e-Commerce Gateway Column Name for Required Fields TEST_INDICATOR TP_DOCUMENT_ID TP_TRANSLATOR_CODE TP_LOCATION_CODE INVOICE_NUM INVOICE_AMOUNT ITEM_LINE_TYPE_CODE AMOUNT Record Number 0010 0010 0010 0010 1000 1000 3000 3000 Position Number 20 30 70 80 10 40 10 110 Note T or P ASNI or SBNI Translator identifier for this trading partner The EDI Location Code
Control Record 0010 TEST_INDICATOR This column represents the test or production indicator from the Trading Partner. If this value does not match the test or production indicator associated with the trading partner defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. The valid values are T for test and P for production. TP_DOCUMENT_ID This column identifies the type of document being sent by the Trading Partner. If this document type is not enabled for the trading partner defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. The valid value is INI for standard invoice. TP_TRANSLATOR_CODE, TP_LOCATION_CODE (EDI Location Code) The two columns in combination uniquely identify a Trading Partner in Oracle e-Commerce Gateway. Once the trading partner definition is accessed, Oracle
6-9
Oracle Payables
e-Commerce Gateway can verify whether the transaction is enabled for the Trading Partner. If this trading partner is not defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. Refer to the Trading Partner section for details on how to properly define your trading partners and get a better understanding of how these fields are used in the process. Transaction Detail Records AMOUNT This column represents the invoice distribution amount. If the Invoice Match Option indicated on the transaction interface file is Purchase Order, this column is the quantity invoiced multiplied by the unit price. If the Invoice Match Option indicated on the transaction interface file is Receipt, this amount is distributed across the non-invoiced receipts beginning with the oldest. If the invoice amount exceeds the total amount for the non-invoiced receipts, the overage is applied to the newest non-invoiced receipt. INVOICE_AMOUNT This column represents the total amount for the invoice calculated as the sum of the invoice line amounts. INVOICE_NUM This column represents the invoice number for the supplier invoice being imported into Oracle Payables. The number must be unique for the supplier, as the Payables Open Interface Import program will reject duplicate invoice numbers. ITEM_LINE_TYPE_CODE This column identifies the invoice line type. The valid values are ITEM, TAX, FREIGHT or MISCELLANEOUS.
Review Oracle e-Commerce Gateway Exceptions

Use the Oracle e-Commerce Gateway View Staged Documents window to review the Oracle e-Commerce Gateway transaction exceptions. Once the exceptions are identified and resolved, you can submit the transaction for reprocessing, ignore the exception during reprocessing, or delete the transaction. Select the option in the View Staged Documents window.
6-10
Oracle Payables
Resolve Oracle e-Commerce Gateway Exceptions

To resolve Oracle e-Commerce Gateway exceptions, you can either correct the set-up data in Oracle e-Commerce Gateway or Oracle Applications, or ask the Trading Partner to send a corrected transaction. If the Trading Partner sends a corrected transaction, be sure to delete the erroneous transaction from Oracle e-Commerce Gateways staging tables using the View Staged Documents window. The duplicate transaction may cause confusion.
Relevant Oracle Payables Profiles and Set Ups

The following is a list of the Payables set ups related to the Receiving Open Interface. Invoice Hold Reason You can optionally set up an Invoice Hold Reason unique to this transaction. All invoices being imported into Oracle Payables may be placed on hold using the unique Invoice Hold Reason. This may be useful during implementation of a new trading partner so that you can review the electronically transmitted invoices before approving them for payment. Use the Invoice Approvals window to define an invoice hold reason. Refer to the Oracle Payables Users Guide for the details.
Payables Open Interface Required Fields

The Payables Open Interface is used by the Inbound Invoice transaction. It is used to validate the incoming data entered into the Payables Open Interface tables by the Oracle e-Commerce Gateway import program. The following is a list of the Payables Open Interface required fields. These fields are required for the Payables Open Interface Import program to successfully process and move the data from the Payables Open Interface tables into the Oracle Payables base application tables. Required fields noted as derived or hardcoded do not require a value in the transaction on the transaction interface file since the values are determined by the Oracle e-Commerce Gateway process. Refer to the Oracle Payables Users Guide, Payables Open Interface appendix for details on derived, defaulted and conditional fields (see Cond. items in the table below).
Application Transaction Detail 6-11
Oracle Payables
Oracle Applications Column Name for Required Fields AP_INVOICES_INTERFACE INVOICE_NUM PO_NUMBER INVOICE_AMOUNT TERMS_NAME INVOICE_CURRENCY_ CODE EXCHANGE_RATE EXCHANGE_DATE INVOICE_ID SOURCE EXCHANGE_RATE_TYPE* AP_INVOICE_LINES_ INTERFACE LINE_TYPE_LOOKUP_ CODE AMOUNT PO_NUMBER INVOICE_ID LINE_NUMBER Yes Yes Yes Yes Yes Yes Yes
Oracle e-Commerce Gateway Cond. Column Name
Hardcoded/ Derived
Record Number
Position Number
INVOICE_NUM PO_NUMBER INVOICE_AMOUNT TERMS_NAME_INT INVOICE_CURRENCY_ CODE EXCHANGE_RATE EXCHANGE_DATE Derived H:EDI_ GATEWAY
1000 1000 1000 1000 1010 1010 1010
10 30 40 70 10 30 40
LINE_TYPE_LOOKUP_ CODE AMOUNT PO_NUMBER Derived Derived
3000 3000 3010
10 110 10
* Not mapped/referenced by Oracle e-Commerce Gateway because the data is not required by the transaction/message AP_INVOICES_INTERFACE Table INVOICE_AMOUNT This column represents the total amount for the invoice calculated as the sum of the invoice line amounts.
6-12
Oracle Payables
INVOICE_CURRENCY_CODE, EXCHANGE_DATE, EXCHANGE_RATE Currency code, exchange date and exchange rate are required for foreign currency invoices (where the currency code is different from the functional currency). The exchange date identifies the exchange rate to be used to compute the invoice amount. INVOICE_NUM This column represents the invoice number for the supplier invoice being imported into Oracle Payables. The number must be unique for the supplier, as the Payables Open Interface Import program will reject duplicate invoice numbers. PO_NUMBER This column represents the purchase order to match the invoice to. Purchase order numbers may be entered at the header or line item level. TERMS_NAME This column represents the payment terms and is required if you did not define payment terms for the supplier. AP_INVOICE_LINES_INTERFACE Table AMOUNT This column represents the invoice distribution amount. If the Invoice Match Option indicated on the transaction interface file is Purchase Order, this column is the quantity invoiced multiplied by the unit price. If the Invoice Match Option indicated on the transaction interface file is Receipt, this amount is distributed across the non-invoiced receipts beginning with the oldest. If the invoice amount exceeds the total amount for the non-invoiced receipts, the overage is applied to the newest non-invoiced receipt. LINE_TYPE_LOOKUP_CODE This column identifies the invoice line type. The valid values are ITEM, TAX, FREIGHT or MISCELLANEOUS. PO_NUMBER This column represents the purchase order to match the invoice to. Purchase order numbers may be entered at the header or line item level.
Oracle Payables
Review Payables Open Interface Exceptions

At the completion of the Payables Open Interface Import program, the Payables Open Interface Report is automatically initiated to report the status of all supplier invoices processed. The report contains two sections as follows: Payables Open Interface Audit Report Payables Open Interface Rejections Report The Audit section lists the invoices that were successfully imported while the Rejections section lists invoices that were not successfully imported and the reason for the rejection. Refer to the Oracle Payables Users Guide, Payables Open Interface Import section for a detailed list of the rejection codes and their meaning.
Return Application Advice to Supplier

To return invoice acknowledgments to the supplier, execute the Payables Open Interface Outbound Advice program to populate the Oracle e-Commerce Gateway Application Advice tables (ECE_ADVO_HEADERS and ECE_ADVO_DETAILS) with the status of all supplier invoices processed. Once the Application Advice tables are populated, you can initiate the outbound Application Advice (ADVO/824/APERAK) transaction to acknowledge all invoices processed or just those containing exceptions.
Resolve Payables Open Interface Exceptions

There are three ways to resolve Payables Open Interface exceptions as follows: Correct set up data in Oracle Applications Correct erroneous entries in the Payables Open Interface table using Open Interface Invoices window Request supplier to send a corrected transaction If you chose to update Oracle Applications data or change the erroneous entries using the Open Interface Invoices window in Payables, you can resubmit the Payables Open Interface Import process to re-validate the transaction. If you chose to have the supplier send a corrected transaction, you must first purge the rejected invoice data in the Payables Open Interface tables by submitting the Purge Payables Open Interface program and then re-import the updated transaction using Oracle e-Commerce Gateway.
6-14
Oracle Payables
Inbound Shipment and Billing Notice (SBNI/857/No EDIFACT)

Refer to the Oracle Purchasing section for details regarding this transaction.
Oracle Payables
Outbound Application Advice (ADVO/824/APERAK)

Suppliers and supplier sites are defined in either Oracle Purchasing or Oracle Payables. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a supplier/supplier site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the supplier or supplier site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the supplier/supplier site and the EDI Location Code in Oracle Applications is the correct supplier/supplier site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected supplier/supplier site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be extracted for the correct trading partner. This could involve either altering the supplier/supplier site in the base Oracle Application, or assigning a different supplier/supplier site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Extract Criteria
The outbound Application Advice transaction is controlled by two database views that are defined according to the Oracle e-Commerce Gateway data model for application advice data. The two views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The two database views are as follows:
s
ECE_ADVO_DETAILS_V
6-16
Oracle Payables
ECE_ADVO_HEADERS_V
The ECE_ADVO_HEADERS_V view is used to identify which application advice data is eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type enabled for the trading partner Application advice has not been previously extracted Application advice provided by one of the following three inbound transactions: Ship Notice/Manifest (from Oracle Purchasing (Receivables)) Shipment and Billing Notice (from Oracle Purchasing (Receivables) Invoice (from Oracle Payables)
Refer to the details for the relevant inbound transaction to determine how it populates the ECE_ADVO_HEADERS and ECE_ADVO_DETAILS tables. If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows: SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_ADVO_HEADERS_V; Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.

Once an eligible application advice is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the ECADVOB.pls file to update the ECE_ADVO_HEADERS table:
Table ECE_ADVO_HEADERS Column EDI_PROCESSED_FLAG EDI_PROCESS_DATE Value Y SYSDATE
Oracle Payables
Outbound Payment Order/Remittance Advice (PYO/820/PAYORD-PAYEXT-REMADV)

Two Forms of Electronic Funds Transfer (EFT)
Oracle Applications supports two forms of Electronic Funds Transfer (EFT). The first is directly from Oracle Payables via a Payables created payment file that is sent to the bank for disbursement directly into the suppliers bank account. Refer to the Payables Users Guide, Creating Electronic Funds Transfer Payments without the Oracle e-Commerce Gateway section for details. The second form of EFT is via the Oracle e-Commerce Gateway outbound Payment Order/Remittance Advice (820/PAYORD-REMADV, 820/PAYEXT-REMADV) transaction. See below for details on how to set up this transaction.
PAYORD, PAYEXT, PAYMUL

The EDIFACT PAYORD message is for payments to a single supplier. The EDIFACT PAYEXT message is for payments to multiple suppliers. The EDIFACT PAYMUL message is for multiple currency payment batches. Oracle Payables does not support this feature.
Pre-note Payment
You can set up a pre-note payment by creating a zero dollar invoice. Select Allow Zero Invoices when you create the payment batch to include this invoice. Your disbursement bank will process this pre-note payment to verify the accuracy of the payer and payee bank account data.
Transaction Handling Options

The outbound Payment Order/Remittance Advice transaction is designed to accommodate both the payment and associated invoice data. With a single transaction, you can instruct your disbursement bank to do one of the following:
s
Disburse funds directly to the suppliers bank account and process the remittance advice Disburse funds directly to the suppliers bank account, do nothing with the remittance advice Send remittance advice electronically to the supplier, do nothing with the payment
6-18
Oracle Payables
Disburse funds directly to the suppliers bank account and send remittance advice to the supplier electronically
You indicate your instructions to the disbursement bank by setting the Transaction Handling code when you define your supplier or supplier sites. Regardless of how you set the Transaction Handling code, Oracle e-Commerce Gateway will construct the entire file so your disbursement bank has everything it needs. If your supplier cannot receive an electronic remittance advice, a hard copy may be printed using Oracle Payables and sent to the supplier.

Bank branch data for the disbursement bank is defined in Oracle Payables. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a bank branch in Oracle Payables and the trading partner site (bank branch) definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the bank branch in the Oracle Payables without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Payables is set up properly, verify that the bank branch and the EDI Location Code in Oracle Payables is the correct bank branch selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected bank branch and the EDI Location Code defined in Oracle Payables are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be extracted for the correct bank branch. This could involve either altering the bank branch in the base Oracle Payables, or assigning a different bank branch to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Oracle Payables
Relevant Oracle Payables Profiles and Set Ups

The outbound Payment Order/Remittance Advice transaction is an event driven process initiated in Oracle Payables as a payment format after the invoices are selected and the payment batch is created. This transaction cannot be initiated from Oracle e-Commerce Gateway. The following is a list of the Payables set ups related to the outbound Payment Order/Remittance Advice transaction. Refer to the Oracle Payables Users Guide, Creating Electronic Payments with Oracle e-Commerce Gateway section for the details.
1. 2.
Enter an EDI ID Number in the Banks window for your disbursement bank. Refer to Oracle Payables Users Guide, Defining Banks section for the details. Define a payment document that uses the EDI Outbound Program as the payment format and assign this payment document to your disbursement bank account. Refer to Oracle Payables Users Guide, Defining and Maintaining Payables Payment Documents section for the details. Enter bank data for each supplier site you want to pay. Refer to Oracle Payables Users Guide, Defining Supplier Bank Accounts section for the details. Enter electronic payment data for each supplier site you want to pay. Refer to Oracle Payables Users Guide, Electronic Data Interchange Region of the Suppliers and Supplier Site Windows section for the details. This is where you specify the following: EDI Location - An identifier for the supplier that links to e-Commerce Gateway trading partner EDI ID Number - ID number used by Oracle Energy Payment Method - Indicates how the electronic payment will be made
3. 4.
6-20
Oracle Payables
Payment Method ACH BACS BOP CWT FEW FWT SWT
Description Automatic Clearing House Bankers Automatic Clearing System Financial Institution Option Clearing House Inter-bank Payment System (CHIPS) Funds/Wire Transfer Federal Reserve Fund/Wire Transfer, Repetitive Federal Reserve Fund/Wire Transfer, Non-repetitive Society for World-wide Inter-bank Financial Telecommunications (SWIFT)
Payment Format - Indicates type of data being transmitted and the format of the data.
Payment Format CCD CCP CTP CTX PPD PPP
Description Cash Concentration/Disbursement (ACH, CCD) Cash Concentration/Disbursement plus Addenda (ACH, CCP) Corporate Trade Payment (ACH, CTP) Corporate Trade Exchange (ACH, CTX) Prearranged Payment and Deposit (ACH, PPD) Prearranged Payment and Deposit plus Addenda (ACH, PPP)
Remittance Method - Indicates which party is responsible for sending remittance advice to the payee. The valid options are as follows:
s
EDI to Payers bank EDI to Payees bank EDI to Payee EDI to third party Do not route
Oracle Payables
Remittance Instruction - Additional text instructions. Transaction Handling - Indicates how payment and remittance advice should be processed
Handling Code C D I U Z 1. 2. 3. 4. 5. 6. 7. 8.
Description Payment accompanies remittance advice Payment only Remittance advice only Split payment and remittance advice Other types of handling
Verify that the invoices you wish to pay electronically are defined with Electronic as the payment method. Verify that the invoices you wish to pay do not have active holds placed on them. Approve the invoices you wish to pay. Verify that you have confirmed the default remit-to bank account for each scheduled payment. Create a Pay Group type lookup specifically for EDI payments to separate the non-EDI payments from the EDI payments. This is an optional set-up step. Create the Payment Batch. Refer to Oracle Payables Users Guide, Initiating Payment Batches section for the details. Refer to Oracle Payables Users Guide, Modifying Payment Batches section for details on how to modify a payment batch if necessary. Format the Payment Batch. This process initiates the Oracle e-Commerce Gateway outbound Payment Order/Remittance Advice transaction that creates a transaction interface file.
Extract Criteria
The outbound Payment Order/Remittance Advice transaction is controlled by two database views that are defined according to the Oracle Payables data model for payments and their corresponding invoices. The two views contain variables which are dynamically set based on your responses to the extract program parameters
6-22
Oracle Payables
(refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The two database views are as follows:
s
ECE_PYO_INVOICE_V ECE_PYO_PAYMENT_V
The ECE_PYO_PAYMENTS_V view used to identify which payments and associated invoices are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type enabled for the trading partner Payments have not been previously extracted Payments are flagged as OK to pay Payments have not been voided Bank account ID, bank name and bank branch ID assigned to the payment match those in the payment batch
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows:
SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_PYO_PAYMENTS_V;
Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.

Once the Translator sends the transactions to the bank and you have verified the bank has received the file, you can confirm the payment batch to indicate the invoices have been paid. This prevents the same invoice from being included in a future payment batch. Refer to Oracle Payables Users Guide, Confirming Payment Batches section for the details.
Oracle Process Manufacturing
Oracle Process Manufacturing

The following transactions are delivered with the Oracle Process Manufacturing product:
Transaction Transaction Name OPM: Purchase Order OPM: Purchase Order Acknowledgment OPM: Ship Notice/Manifest Direction Inbound Outbound Outbound Code GPOI GPOAO GASNO ASC X12 850 855 856 EDIFACT ORDERS ORDRSP DESADV
Refer to the product documentation for details on how to implement these transactions. Note: For the summary layout see Appendix A.
Current Information
6-24
Oracle Purchasing
Oracle Purchasing
The implementation of any transaction requires some set up in Oracle Applications and Oracle e-Commerce Gateway. This chapter focuses on the application set-ups necessary to implement a transaction that integrates with Oracle Purchasing. Note: For the summary layout see Appendix A. The following transactions integrate with Oracle Purchasing.
Transaction Transaction Name Price/Sales Catalogue Response to Request for Quotation Ship Notice/Manifest Shipment and Billing Notice Application Advice Purchase Order Purchase Order Change Direction Inbound Inbound Inbound Inbound Outbound Outbound Outbound Code CATI RRQI ASNI SBNI ADVO POO POCO ASC X12 832 843 856 857 824 850 860 EDIFACT PRICAT QUOTES DESADV N/A APERAK ORDERS ORDCHG
The topics covered for inbound transactions include the following:

s
Trading Partner Link to Oracle e-Commerce Gateway Oracle e-Commerce Gateway Required Fields Review Oracle e-Commerce Gateway Exceptions Resolve Oracle e-Commerce Gateway Exceptions Relevant Oracle Application Profiles and Set-ups Oracle Application Open Interface Required Fields Review Application Open Interface Exceptions Return Application Advice to Trading Partner (if appropriate) Resolve Application Open Interface Exceptions

s
Oracle Purchasing
Relevant Oracle Purchasing Set-ups Extract Criteria Columns Updated Upon Extraction
Current Information
6-26
Oracle Purchasing
Inbound Price/Sales Catalog (CATI/832/PRICAT) Inbound Response to Request for Quotation (RRQI/843/QUOTES
Suppliers and supplier sites are defined in either Oracle Purchasing or Oracle Payables. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a supplier/supplier site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the supplier or supplier site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the supplier/supplier site and the EDI Location Code in Oracle Applications is the correct supplier/supplier site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected supplier/supplier site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be imported for the correct trading partner. This could involve either altering the supplier/ supplier site in the base Oracle Application, or assigning a different supplier/supplier site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.

The following is a list of the Oracle e-Commerce Gateway required fields. These fields are required to authenticate the trading partner and transaction. If the required data is not provided in the transaction, the Oracle e-Commerce Gateway import process fails the transaction. Then an exception message is displayed in the View Staged Documents window. If the trading partner is valid and the transaction is enabled, the import process proceeds to validate the transaction using the user-defined column rules. If no
Oracle Purchasing
process or column rule exceptions are detected, the Oracle e-Commerce Gateway import program will write the transaction to the Purchasing Documents Open Interface tables to be processed by the Purchasing Documents Open Interface API.
Oracle e-Commerce Gateway Column Name for Required Fields TEST_INDICATOR DOCUMENT_ID TP_TRANSLATOR_CODE TP_LOCATION_CODE Record Number 0010 0010 0010 0010 Position Number 20 30 70 80 Note T or P Constant CATI or RRQI Translator identifier for this Trading Partner The EDI Location Code
Control Record 0010 DOCUMENT_ID This column identifies the type of document being sent by the Trading Partner. If this document type is not enabled for the trading partner defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. The valid values are CATI for prices/sales catalog or RRQI for response to Request for Quote (RFQ). TEST_INDICATOR This column represents the test or production indicator from the Trading Partner. If this value does not match the test or production indicator associated with the trading partner defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. The valid values are T for test and P for production. TP_TRANSLATOR_CODE, TP_LOCATION_CODE (EDI Location Code) The two columns in combination uniquely identify a Trading Partner in Oracle e-Commerce Gateway. Once the trading partner definition is accessed, Oracle e-Commerce Gateway can verify whether the transaction is enabled for the Trading Partner.
6-28
Oracle Purchasing
If this trading partner is not defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. Refer to the Trading Partner section for details on how to properly define your trading partners and get a better understanding of how these fields are used in the process.
Review Oracle e-Commerce Gateway Exceptions

Use the Oracle e-Commerce Gateway View Staged Documents window to review the Oracle e-Commerce Gateway transaction exceptions. Once the exceptions are identified and resolved, you can submit the transaction for reprocessing, ignore the exception during reprocessing, or delete the transaction. Select the option in the View Staged Documents window.
Resolve Oracle e-Commerce Gateway Exceptions

To resolve Oracle e-Commerce Gateway exceptions, you can either correct the set up data in Oracle e-Commerce Gateway or Oracle Applications, or ask the Trading Partner to send a corrected transaction. If the Trading Partner sends a corrected transaction, be sure to delete the erroneous transaction from Oracle e-Commerce Gateways staging tables using the View Staged Documents window. The duplicate transaction may cause confusion.
Relevant Oracle Purchasing, Inventory Profiles and Set Ups

The following is a list of the Purchasing set-ups related to the Purchasing Documents Open Interface. Refer to the Oracle Purchasing Users Guide and the Oracle Manufacturing, Distribution, Sales and Service Open Interface Manual, Purchasing Open Interfaces section for the details.
1.
PO: Archive Catalog on Approval If the profile option is set to Yes, Oracle Purchasing archives the price/sales catalog once it is approved. This profile option works in conjunction with the Approval Status parameter. If the Approval Status was set to Incomplete, then the imported catalog must be approved before it is archived. If the Approval Status was set to Approved, then the imported catalog is archived immediately after it is imported into Oracle Purchasing.
Oracle Purchasing
If the profile option is set to No, Oracle Purchasing will not archive the price/sales catalog.
2.
Allow Updating of the Item Master Create or Update Item Master is one of the program parameters to indicate whether to allow creation of a new item or updating of an existing item in the item master. To ensure that item descriptions and item status codes may be updated, the following must be set up: Allow Item Description Update is enabled in the Purchasing Options window, Control Options region. INV: Default Item Status is set to Active
3.
PO: Write Server Output to File To facilitate the debugging of the Purchasing Documents Open Interface, error logs normally written to the Concurrent Manager log screen may be written to the file system if this profile option is set to Yes.
4.
Set Up Price Tolerance Define price tolerances in Oracle Purchasing for price increases associated with a price/sales catalog update.
Purchasing Documents Open Interface Required Fields

The Purchasing Documents Open Interface is used by the Inbound Price/Sales Catalog and Inbound Response to Request for Quotation transactions. It is used to validate the incoming data entered into the Purchasing Documents Open Interface tables by the Oracle e-Commerce Gateway import program. The following is a list of the Purchasing Documents Open Interface required fields. These fields are required for the Purchasing Documents Open Interface API to successfully process and move the data from the Purchasing Documents Open Interface tables into the Oracle Purchasing base application tables. Required fields noted as derived or hardcoded do not require a value in the transaction on the transaction interface file since the values are determined by the Oracle e-Commerce Gateway process. Refer to the Oracle Manufacturing, Distribution, Sales and Service Open Interface Manual for details on derived, defaulted and conditional fields (see Cond. items in the table below).
6-30
Oracle Purchasing
Oracle Applications Column Name for Required Fields PO_HEADERS_INTERFACE VENDOR_DOC_NUM EFFECTIVE_DATE EXPIRATION_DATE ACTION VENDOR_SITE_CODE VENDOR_ID VENDOR_SITE_ID DOCUMENT_TYPE_CODE* INTERFACE_HEADER_ID PO_LINES_INTERFACE LINE_NUM ITEM QUANTITY EFFECTIVE_DATE EXPIRATION_DATE ITEM_DESCRIPTION UNIT_PRICE SHIPMENT_NUM INTERFACE_LINE_ID INTERFACE_HEADER_ID Yes Yes Yes Yes Yes Yes Yes Yes Yes Cond.
Oracle e-Commerce Gateway Column Name
Hardcoded / Derived
Record Number
Position Number
VENDOR_DOC_NUMBER EFFECTIVE_DATE EXPIRATION_DATE ACTION_TYPE_CODE_INT SHIP_FROM_ADDRESS_ CODE SHIP_FROM_CUSTOMER_ ID SHIP_FROM_ADDRESS_ID
1000 1000 1000 1030 1120 1120 1120
10 20 30 10 10 170 180
INTERFACE_HEADER_ID
Derived
LINE_NUM ITEM QUANTITY EFFECTIVE_DATE EXPIRATION_DATE ITEM_DESCRIPTION UNIT_PRICE SHIPMENT_NUM INTERFACE_LINE_ID INTERFACE_HEADER_ID Derived Derived
2000 2000 2010 2010 2010 2010 2020 2050
10 20 10 60 70 80 10 10
* Not mapped/referenced by Oracle e-Commerce Gateway because the data is not required by the transaction/message PO_HEADERS_INTERFACE Table
Oracle Purchasing
ACTION_TYPE_CODE_INT This column is the catalog type indicator. The valid values are as follows: ORIGINAL: New catalog REPLACE: Replacement catalog UPDATE: Catalog change The following types of data are supported with a catalog change: Unit price Item description Unit of measure Price breaks for blanket purchase agreements Expiration date for blanket purchase agreements Supplier URL to get additional item data EFFECTIVE_DATE, EXPIRATION_DATE These two columns are required if you are replacing an existing catalog or if sourcing rules (i.e. if you answered YES to Create Sourcing Rules parameter) are to be created. The values are used to locate the old price/sales catalog and retire it. SHIP_FROM_ADDRESS_CODE This column represents the supplier site code. The value is derived by the Purchasing Documents Open Interface based on the supplier site id. SHIP_FROM_ADDRESS_ID This column represents the vendor site id. The value is derived by Oracle e-Commerce Gateway based on the vendor id which itself is derived from the Translator Code (on record 0010, element 70) and EDI Location Code (on record 0010, element 80). The Purchasing Documents Open Interfaces uses the supplier site id to derive the supplier site code. SHIP_FROM_CUSTOMER_ID This column represents the supplier ID. Oracle e-Commerce Gateway derives this value based on the Translator Code (on record 0010, element 70) and EDI Location Code (on record 0010, element 80) combination. The Purchasing Documents Open Interface uses the supplier ID to derive the supplier name and number. VENDOR_DOC_NUMBER
6-32
Oracle Purchasing
This column represents the suppliers catalog number as the supplier may not know your Oracle catalog number. The suppliers catalog number is used to locate an existing catalog for catalog replacement or update. If you are importing a new catalog, this column is used to verify that the catalog is not a duplicate. PO_LINES_INTERFACE Table EFFECTIVE_DATE This column is required if you want to create sourcing rules (i.e. if you answered YES to Create Sourcing Rules parameter) along with importing a catalog. Whether a new sourcing rule is created or an existing rule is updated depends on whether you are importing a new catalog, catalog changes or replacing an existing catalog. Refer to the Oracle Purchasing Open Interfaces document, Sourcing section for a detail description of how this data is used. EXPIRATION_DATE This column is required if you want to create sourcing rules (i.e. if you answered YES to Create Sourcing Rules parameter) along with importing a new or replacement catalog. If you are importing catalog changes, the value is used to retire the old catalog item. Refer to the Oracle Purchasing Open Interfaces document, Sourcing section for a detail description of how this data is used. ITEM, ITEM_DESCRIPTION These two columns are required if you want to create or update an item in the item master (i.e. if you answered YES to the Create or Update Item parameter). If you are creating new items, both ITEM and ITEM DESCRIPTION are required. If you are updating the item master, ITEM DESCRIPTION is required. LINE_NUM, SHIPMENT_NUM, QUANTITY, UNIT_PRICE To enter price break data, the supplier must provide line number, shipment number, quantity and unit price on the transaction interface file in the following format to accommodate Oracle Purchasings data model.
Oracle Purchasing
Line Number (Rec 2000) 1 1 1
Shipment Number (Rec 2050) 1 2 3
Unit Quantity (Rec 2010) 500 1000 5000 Price (Rec 2020) 10.00 7.00 5.00
The price break data is loaded by Oracle e-Commerce Gateway into the PO_LINES_ INTERFACE (for PO lines and shipments) table. The Purchasing Documents Open Interface API validates this data and moves the valid data into the PO_LINES (for PO lines) and PO_LINE_LOCATIONS (for PO shipments) tables. If your supplier offers fixed pricing, then they only need to supply a unit price.
Review Purchasing Documents Open Interface Exceptions

The processing strategy of the Purchasing Documents Open Interface is to process line by line. This means if the Purchasing Documents Open Interface detected an exception at the document header, it will not proceed to the document lines. At the document line level, the Purchasing Documents Open Interface will write valid document lines to the base application tables or write an exception message to the PO_INTERFACE_ERRORS table for each invalid document line thereby accepting partial transactions You can use the Purchasing Interface Errors Report in Oracle Purchasing to review all exceptions detected by the Purchasing Documents Open Interface API. Refer to the Oracle Manufacturing, Distribution, Sales & Service Open Interface manual, Oracle Purchasing Open Interfaces document for a detailed list of detectable errors and their meaning.
Resolve Purchasing Documents Open Interface Exceptions

To resolve Purchasing Documents Open Interface exceptions, you can either correct the set up data in Oracle Applications or ask the supplier to resend the transaction with the corrected values. If you chose to update Oracle Applications data, you can resubmit the Purchasing Documents Open Interface process to re-validate the transaction.
6-34
Oracle Purchasing
If you chose to have the supplier send a corrected transaction, you must first purge the rejected data sitting in the Purchasing Documents Open Interface tables by submitting the Purge Purchasing Documents Open Interface Processed Data program and then re-import the updated transaction using Oracle e-Commerce Gateway.
Oracle Purchasing
Inbound Ship Notice/Manifest (ASNI/856/DESADV) Inbound Shipment and Billing Notice (SBNI/857/No EDIFACT)
Suppliers and supplier sites are defined in either Oracle Purchasing or Oracle Payables. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a supplier/supplier site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the supplier or supplier site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the supplier/supplier site and the EDI Location Code in Oracle Applications is the correct supplier site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected supplier/supplier site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be imported for the correct trading partner. This could involve either altering the supplier/ supplier site in the base Oracle Application, or assigning a different supplier/supplier site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.

The following is a list of the Oracle e-Commerce Gateway required fields. These fields are required to authenticate the trading partner and transaction. If the required data is not provided in the transaction, the Oracle e-Commerce Gateway import process fails the transaction. Then an exception message is displayed in the View Staged Documents window. If the trading partner is valid and the transaction is enabled, the import process proceeds to validate the transaction using the user-defined column rules. If no process or column rule exceptions are detected, the Oracle e-Commerce Gateway
6-36
Oracle Purchasing
import program will write the transaction to the Receiving Open Interface tables to be processed by the Receiving Open Interface API.
Oracle e-Commerce Gateway Column Name for Required Fields TEST_INDICATOR ASN_TYPE (Document ID) TRAN_PURPOSE_EXT1 TP_TRANSLATOR_CODE TP_LOCATION_CODE Record Number 0010 0010 0010 0010 0010 Position Number 20 30 50 70 80 Note T or P ASNI or SBNI NEW or CANCEL Translator identifier for this Trading Partner The EDI Location Code
PICK_SLIP_NUMBER TRAN_PURPOSE_APPLICATION PURCHASE_ORDER_NUM ORIGINAL_SYSTEM_LINE_ REFERENCE QUANTITY SHIPPED_UNIT_CODE_INT
1000 1000 2000 2000
10 110 50 70 Defaulted to ship quantity in record 2000, position 80 NEW or CANCEL
2000
90
Control Record 0010 ASN_TYPE (Document ID) This column identifies the type of document being sent by the Trading Partner. If this document type is not enabled for the trading partner defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. The valid values are ASNI for the ship notices and SBNI shipment and billing notice. TEST_INDICATOR This column represents the test or production indicator from the Trading Partner. If this value does not match the test or production indicator associated with the trading partner defined in Oracle e-Commerce Gateway, a process rule exception is
Oracle Purchasing
detected. Then an exception message is displayed in the View Staged Documents window. The valid values are T for test and P for production. TP_TRANSLATOR_CODE, TP_LOCATION_CODE (EDI Location Code) The two columns in combination uniquely identify a Trading Partner in Oracle e-Commerce Gateway. Once the trading partner definition is accessed, Oracle e-Commerce Gateway can verify whether the transaction is enabled for the Trading Partner. If this trading partner is not defined in Oracle e-Commerce Gateway, a process rule exception is detected. Then an exception message is displayed in the View Staged Documents window. Refer to the Trading Partner section for details on how to properly define your trading partners and get a better understanding of how these fields are used in the process. TRAN_PURPOSE_EXT1 This column represents the transaction purpose code. The valid values are NEW or CANCEL. The default value is NEW if no value is provided on the inbound flat file. The value entered for TRAN_PURPOSE_EXT1 should be the same value entered for TRAN_PURPOSE_APPLICATION in record 1000, position 110. Transaction Detail Records ORIGINAL_SYSTEM_LINE_REFERENCE This column represents the purchase order line number associated with the shipment. PICK_SLIP_NUMBER This column represents the packing slip number from the supplier. This number will be used during the PO receipt process to recall the shipment data related to the purchase orders and items in the shipment. If no value is provided, the Receiving Open Interface tries to default a value from the PACKING_SLIP or INVOICE_NUM columns. The values in this column must be unique from the supplier for one year. PURCHASE_ORDER_NUM This column represents the purchase order number associated with the shipment. SHIPPED_UNIT_CODE_INT
6-38
Oracle Purchasing
This column represents the shipment quantity unit of measure. TRAN_PURPOSE_APPLICATION This column represents the transaction purpose code. The valid values are NEW or CANCEL. Place the value in record 1000, position 110. The default value is NEW if no value is provided on the inbound flat file. The value entered for TRAN_PURPOSE_APPLICATION should be the same value entered for TRAN_PURPOSE_EXT1 in record 0010, position 50. Review Oracle e-Commerce Gateway Exceptions Use the Oracle e-Commerce Gateway View Staged Documents window to review the Oracle e-Commerce Gateway transaction exceptions. Once the exceptions are identified and resolved, you can submit the transaction for reprocessing, ignore the exception during reprocessing, or delete the transaction. Select the option in the View Staged Documents window. Resolve Oracle e-Commerce Gateway Exceptions To resolve Oracle e-Commerce Gateway exceptions, you can either correct the set up data in Oracle e-Commerce Gateway or Oracle Applications, or ask the Trading Partner to send a corrected transaction. If the Trading Partner sends a corrected transaction, be sure to delete the erroneous transaction from Oracle e-Commerce Gateways staging tables using the View Staged Documents window. The duplicate transaction may cause confusion.
Relevant Oracle Purchasing Profiles and Set-ups

The following is a list of the Purchasing set-ups related to the Receiving Open Interface.
1.
RCV: Fail All ASN Lines if One Line Fails If the profile option is set to Yes and any line failed validation, no further validation is performed for the ship notice. If the profile option is set to No and any line failed validation, the process continues with the next line.
2.
ASN Control In the Receiving Options window in Purchasing, select Warning, Reject, or None in the ASN Control field to determine how Purchasing handles the receipt against a purchase order shipment for which a ship notice exists. Refer to the
Oracle Purchasing
Oracle Purchasing Users Guide, Defining Receiving Options sections for details.
3.
PO: Enable SQL Trace for Receiving Processor If the profile option is set to Yes, more detailed error data is provided in the View Log screen of the Submit Request window when you run the Receiving Transaction Processor.
Refer to the Oracle Purchasing Users Guide and the Oracle Manufacturing, Distribution, Sales and Service Open Interface Manual, Purchasing Open Interfaces section for the details.
Receiving Open Interface Required Fields

The Inbound Ship Notice/Manifest and Inbound Shipment and Billing Notice transactions use the Receiving Open Interface. It is used to validate the incoming data entered into the Receiving Open Interface tables by the Oracle e-Commerce Gateway import program. The following is a list of the Receiving Open Interface required fields. These fields are required for the Receiving Open Interface API to successfully process and move the data from the Receiving Open Interface tables into the Oracle Purchasing base application tables. Required fields noted as derived or hardcoded do not require a value in the transaction on the transaction interface file since the values are determined by the Oracle e-Commerce Gateway process. Refer to the Oracle Manufacturing, Distribution, Sales and Service Open Interface Manual for details on derived, defaulted and conditional fields (see Cond. items in the table below).
Oracle Applications Column Name for Required Fields RCV_HEADERS_INTERFACE SHIPMENT_NUM SHIPPED_DATE AUTO_TRANSACT_CODE TRANSACTION_TYPE Yes Yes Yes PICK_SLIP_NUMBER SHIPPED_DATE AUTO_TRANSACT_CODE TRAN_PURPOSE_ APPLICATION 1000 1000 1000 1000 10 70 100/120 110 Oracle e-Commerce Gateway Cond. Column Name
Hardcoded/ Record Derived Number
Position Number
6-40
Oracle Purchasing
INVOICE_NUM INVOICE_DATE TOTAL_INVOICE_AMOUNT VENDOR_ID SHIP_TO_ORGANIZATION_ CODE CREATED_BY CREATION_DATE GROUP_ID HEADER_INTERFACE_ID LAST_UPDATE_DATE LAST_UPDATED_BY PROCESSING_STATUS_ CODE RECEIPT_SOURCE_CODE VALIDATION_FLAG EMPLOYEE_NAME* EMPLOYEE_ID* RECEIPT_NUM* VENDOR_NAME* VENDOR_NUM* RCV_TRANSACTIONS_ INTERFACE ITEM_NUM VENDOR_ITEM_NUM ITEM_REVISION DOCUMENT_NUM DOCUMENT_LINE_NUM QUANTITY
Yes Yes Yes
INVOICE_NUM INVOICE_DATE INVOICE_AMOUNT SHIP_FROM_CUSTOMER_ ID
1030 1030 1030 1100 1120 Derived Derived Derived Derived Derived Derived H: PENDING H: VENDOR H:Y
10 20 30 170 10
Yes
SHIP_TO_INT_LOCATION_ ID CREATED_BY CREATION_DATE GROUP_ID HEADER_INTERFACE_ID LAST_UPDATE_DATE LAST_UPDATED_BY
Yes
ITEM_NUMBER Yes Yes VENDOR_ITEM_NUM ITEM_REVISION PURCHASE_ORDER_NUM ORIGINAL_SYSTEM_LINE_ REFERENCE SHIPPED_QUANTITY
2000 2000 2000 2000 2000 2000
10 20 30 50 70 80
Oracle Purchasing
UNIT_OF_MEASURE ITEM_DESCRIPTION AUTO_TRANSACT_CODE SHIP_TO_LOCATION_ID SHIP_TO_LOCATION_CODE DELIVER_TO_LOCATION_ CODE DELIVER_TO_PERSON_ NAME CREATED_BY CREATION_DATE GROUP_ID HEADER_INTERFACE_ID INTERFACE_ TRANSACTION_ID LAST_UPDATE_DATE LAST_UPDATED_BY PROCESSING_MODE_CODE PROCESSING_STATUS_ CODE RECEIPT_SOURCE_CODE SOURCE_DOCUMENT_ CODE TRANSACTION_DATE TRANSACTION_STATUS_ CODE TRANSACTION_TYPE VALIDATION_FLAG CATEGORY_ID* Yes Yes
SHIPPED_UNIT_CODE_INT PRODUCT_DESCRIPTION AUTO_TRANSACT_CODE SHIP_TO_INT_LOCATION_ ID SHIP_TO_INT_LOCATION_ NAME DELIVER_TO_LOCATION_ CODE_ INT DELIVER_TO_PERSON_ NAME CREATED_BY CREATION_DATE GROUP_ID Derived Derived Derived Derived INTERFACE_ TRANSACTION_ID LAST_UPDATE_DATE LAST_UPDATED_BY Derived Derived Derived H: BATCH H: PENDING H: VENDOR H: PO H: SYSDATE H: PENDING H: SHIP H: Y
2000 2000 2000 3000 3000 3020
90 140 160 10 30 10
3020
70
6-42
Oracle Purchasing
CUSTOMER_ID* DELIVER_TO_LOCATION_ ID* DELIVER_TO_PERSON_ID* EMPLOYEE_ID* EXPECTED_RECEIPT_DATE* ITEM_CATEGORY* ITEM_ID* LOCATOR* OE_ORDER_HEADER_ID* OE_ORDER_LINE_ID* PO_HEADER_ID* PO_LINE_ID* SUBINVENTORY* TO_ORGANIZATION_ CODE* TO_ORGANIZATION_ID* VENDOR_ID* VENDOR_NUM* VENDOR_NAME*
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes
* Not mapped/referenced by Oracle e-Commerce Gateway because the data is not required by the transaction/message. The <field>_ID fields are derived by the Receiving Open Interface API. RCV_HEADERS_INTERFACE Table AUTO_TRANSACT_CODE This column identifies the type of incoming data. The valid values are SHIP, RECEIVE or DELIVER. The default value is RECEIVE if no value is provided in the transaction. A value of SHIP tells the Receiving Open Interface to process the inbound ship notice as a ship notice only. You will need to execute the PO receipt process in Purchasing when the physical goods arrive at your dock.
Oracle Purchasing
Use this setting if the physical goods are scheduled to arrive after the ship notice. A value of RECEIVE tells the Receiving Open Interface to process the inbound ship notice as a ship notice and a PO receipt. Use this setting if the physical goods are scheduled to arrive with the ship notice or this is a service PO that does not require a physical receipt. A value of DELIVER tells the Receiving Open Interface to process the inbound ship notice as a ship notice, a PO receipt and delivery. Use this setting to receive and deliver the physical goods to the requester or to inventory. This option assumes you do not want to inspect the goods. INVOICE_NUM, INVOICE_DATE, INVOICE_AMOUNT Invoice number, date and amount are required for the Inbound Shipment and Billing Notice transaction to create an invoice. The invoice number must be unique for the supplier. PICK_SLIP_NUMBER This column represents the packing slip number from the supplier. This number will be used during the PO receipt process to recall the shipment data related to the purchase orders and items in the shipment. If no value is provided, the Receiving Open Interface tries to default a value from the PACKING_SLIP or INVOICE_NUM columns. The values in this column must be unique from the supplier for one year. SHIPPED_DATE This column represents the date the shipment was shipped. The value must be earlier than or equal to the system date. SHIP_FROM_CUSTOMER_ID This column represents the vendor ID. Oracle e-Commerce Gateway derives this value based on the Translator Code (on record 0010, element 70) and EDI Location Code (on record 0010, element 80) combination. The Receiving Open Interface uses the vendor ID to derive the vendor name and number. SHIP_TO_INT_LOCATION_ID This column represents the destination organization for the shipment. A valid inventory organization code in Purchasing is required for the Inbound Ship Notice/Manifest or Inbound Shipment and Billing Notice transactions. The destination organization code may be specified at the header or line level. However, if it is specified at the header level, then the same value applies to all the shipment lines.
6-44
Oracle Purchasing
TRANS_PURPOSE_APPLICATION This column represents the transaction purpose code. The valid values are NEW or CANCEL. Place the value in record 1000, position 110. The default value is NEW if no value is provided on the inbound flat file. The value entered for TRAN_PURPOSE_APPLICATION should be the same value entered for TRAN_PURPOSE_EXT1 in record 0010, position 50. RCV_TRANSACTIONS_INTERFACE Table AUTO_TRANSACT_CODE This column identifies the type of incoming data. The valid values are SHIP, RECEIVE or DELIVER. The default value is RECEIVE if no value is provided on the inbound flat file. A value of SHIP tells the Receiving Open Interface to process the inbound ship notice as a ship notice only. You will need to execute the PO receipt process in Purchasing when the physical goods arrive at your dock. Use this setting if the physical goods are scheduled to arrive after the ship notice. A value of RECEIVE tells the Receiving Open Interface to process the inbound ship notice as a ship notice and a PO receipt. Use this setting if the physical goods are scheduled to arrive with the ship notice or this is a service PO that does not require a physical receipt. A value of DELIVER tells the Receiving Open Interface to process the inbound ship notice as a ship notice, a PO receipt and delivery. Use this setting to receive and deliver the physical goods to the requester or to inventory. This option assumes you do not want to inspect the goods. DELIVER_TO_PERSON_NAME, DELIVER_TO_LOCATION_CODE_INT These two columns are required by the Receiving Open Interface if AUTO_ TRANSACT_CODE is set to DELIVER. It represents the deliver-to information associated with the requester. ITEM_NUMBER, PRODUCT_DESCRIPTION These two columns represents the buyers item number and item descriptions as defined in Oracle Purchasing. ITEM_REVISION
Oracle Purchasing
This column represents the items revision level. A value is required if this is an inventory item under revision control and you have distributions with an inventory destination. ORIGINAL_SYSTEM_LINE_REFERENCE This column represents the purchase order line number associated with the shipment. PURCHASE_ORDER_NUM This column represents the purchase order number associated with the shipment. SHIP_TO_INT_LOCATION_ID, SHIP_TO_INT_LOCATION_NAME These two columns represents the destination organization for the shipment. A valid inventory organization code in Purchasing is required for the Inbound Ship Notice/Manifest or Inbound Shipment and Billing Notice transactions. If no values are provided at the line level, the header values are used as the default for all lines. SHIPPED_QUANTITY This column represents the shipment quantity. SHIPPED_UNIT_CODE_INT This column represents the shipment quantity unit of measure. VENDOR_ITEM_NUM This column represents the suppliers item number for the buyer item defined in Oracle Purchasing. This must be specified if buyer item number is not available.
Review Receiving Open Interface Exceptions

All exceptions detected by the Receiving Open Interface are written to the PO_ INTERFACE_ERRORS table to be reviewed using the Receiving Interface Errors Report (for 856/DESADV) or Purchasing Interface Errors Report (for 857). Refer to the Oracle Manufacturing, Distribution, Sales & Service Open Interface manual, Oracle Purchasing Open Interfaces document for a detailed list of detectable errors and their meaning.
Return Application Advice to Supplier

In addition to writing error data to the PO_INTERFACE_ERRORS table, the Receiving Open Interface program writes an entry to Oracle e-Commerce Gateways Application Advice tables (ECE_ADVO_HEADERS and ECE_ADVO_
6-46
Oracle Purchasing
DETAILS) to be reported back to the supplier via the outbound Application Advice (824/APERAK) transaction.
Resolve Receiving Open Interface Exceptions

To resolve Receiving Open Interface exceptions, you can either correct the set up data in Oracle Applications or ask the supplier to resend the corrected transaction. If you chose to update Oracle Applications data, you can resubmit the Receiving Open Interface process to revalidate the transaction. If you chose to have the supplier send a corrected transaction, you must first purge the rejected data sitting in the Receiving Open Interface tables using the Transactions Status Summary window and then re-import the updated transaction using Oracle e-Commerce Gateway.
Oracle Purchasing
Outbound Application Advice (ADVO/824/APERAK)

Refer to the Oracle Payables section for details regarding this transaction.
6-48
Oracle Purchasing
Outbound Purchase Order (POO/850/ORDERS)

Suppliers and supplier sites are defined in either Oracle Purchasing or Oracle Payables. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a supplier/supplier site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the supplier or supplier site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the supplier/supplier site and the EDI Location Code in Oracle Applications is the correct supplier/supplier site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected supplier/supplier site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be extracted for the correct trading partner. This could involve either altering the supplier/ supplier site in the base Oracle Application, or assigning a different supplier/supplier site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Relevant Oracle Purchasing Profiles and Set Ups

The following is a list of the Purchasing set ups related to the outbound Purchase Order transaction.
1.
Archive on <Attribute> for original orders: In the Setup->Purchasing->Document Types window, set the following: Set the Archive on Approve for each document type enabled.
Oracle Purchasing
DO NOT set the attribute to Archive on Print. This prevents the eligible purchase orders from being extracted since they will print and archive before the extract can happen. Refer to the Oracle Purchasing Users Guide for the details.
Extract Criteria
The outbound Purchase Order transaction is controlled by three database views that are defined according to the Oracle Purchasing data model for purchase orders. The three views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The three database views are as follows:
s
ECE_POO_HEADERS_V ECE_POO_LINES_V ECE_POO_SHIPMENTS_V
The ECE_POO_HEADERS_V view is used to identify which purchase orders are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type enabled for the trading partner Purchase order has not been printed or previously extracted Purchase order status is Approved Purchase order has not been canceled Purchase order is not on hold
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows: SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_POO_HEADERS_V; Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.
6-50
Oracle Purchasing

Once an eligible purchase order is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the UPDATE_PO procedure defined in the ECEPOOB.pls file:
Table PO_HEADERS Column EDI_PROCESSED_FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT PO_HEADERS_ ARCHIVE EDI_PROCESSED_FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT PO_RELEASES EDI_PROCESSED_FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT PO_RELEASES_ ARCHIVE EDI_PROCESSED_FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT Value Y SYSDATE SYSDATE Increment by 1 Y SYSDATE SYSDATE Increment by 1 Y SYSDATE SYSDATE Increment by 1 Y SYSDATE SYSDATE Increment by 1
The PO_HEADERS and PO_HEADERS_ARCHIVE tables are used for standard, planned or blanket purchase orders. The PO_RELEASES and PO_RELEASES_ ARCHIVE tables are used for blanket purchase order releases.
Oracle Purchasing
Outbound Purchase Order Change (POCO/860/ORDCHG)

Suppliers and supplier sites are defined in either Oracle Purchasing or Oracle Payables. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a supplier/supplier site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the supplier or supplier site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the supplier/supplier site and the EDI Location Code in Oracle Applications is the correct supplier/supplier site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected supplier/supplier site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be extracted for the correct trading partner. This could involve either altering the supplier/ supplier site in the base Oracle Application, or assigning a different supplier/supplier site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Relevant Oracle Purchasing Profiles and Set Ups

The following is a list of the Purchasing set ups related to the outbound Purchase Order Change transaction. Archive on <Attribute> for change orders: In the Setup->Purchasing->Document Types window, set the following: Set the Archive on Approve for each document type enabled.
6-52
Oracle Purchasing
DO NOT set the attribute to Archive on Print. This prevents the eligible purchase orders from being extracted since they will print and archive before the extract can happen. Refer to the Oracle Purchasing Users Guide for the details.
Extract Criteria
The outbound Purchase Order Change transaction is controlled by three database views that are defined according to the Oracle Purchasing data model for purchase orders. The three views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The three database views are as follows:
s
ECE_POCO_HEADERS_V ECE_POCO_LINES_V ECE_POCO_SHIPMENTS_V
The ECE_POCO_HEADERS_V view is used to identify which purchase order changes are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type enabled for the trading partner The original purchase order has been printed or previously extracted The current set of purchase order changes have not been printed or previously extracted Purchase order change status is Approved Purchase order is not on hold
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows: SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_POCO_HEADERS_V; Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.
Oracle Purchasing

Once an eligible purchase order change is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the UPDATE_PO (the outbound purchase order and purchase order change share this procedure) procedure defined in the ECPOCOB.pls file:
Table PO_HEADERS Column EDI_PROCESSED_ FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT PO_HEADERS_ ARCHIVE EDI_PROCESSED_ FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT PO_RELEASES EDI_PROCESSED_ FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT PO_RELEASES_ ARCHIVE EDI_PROCESSED_ FLAG LAST_UPDATE_DATE PRINTED_DATE PRINT_COUNT Value Y SYSDATE SYSDATE Increment by 1 Y SYSDATE SYSDATE Increment by 1 Y SYSDATE SYSDATE Increment by 1 Y SYSDATE SYSDATE Increment by 1
The PO_HEADERS and PO_HEADERS_ARCHIVE tables are used for standard, planned or blanket purchase orders. The PO_RELEASES and PO_RELEASES_ ARCHIVE tables are used for blanket purchase order releases.
6-54
Oracle Receivables
Oracle Receivables
The implementation of any transaction requires some set up in Oracle Applications and Oracle e-Commerce Gateway. This chapter focuses on the application set ups necessary to implement a transaction that integrates with Oracle Receivables. Note: For the summary layout see Appendix A.
Transaction Transaction Name Invoice Credit Memo/Debit Memo Direction Outbound Outbound Code INO CDMO ASC X12 810 812 EDIFACT INVOIC CREADV/DEBADV

s
Trading Partner Link to Oracle e-Commerce Gateway Relevant Oracle Application Profiles and Set Ups Extract Criteria Columns Updated Upon Extraction
Current Information
Oracle Receivables
Outbound Invoice (INO/810/INVOIC)

Customer and customer sites are defined in either Oracle Receivables or Oracle Order Management. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a customer/customer site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the customer or customer site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the customer/customer site and the EDI Location Code in Oracle Applications is the correct customer/customer site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected customer/customer site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be extracted for the correct trading partner. This could involve either altering the customer/customer site in the base Oracle Application, or assigning a different customer/customer site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Two Methods of Sending Credit Memos/Debit Memos

The 810/INVOIC transaction supports invoices, credit memos and debit memos. In addition, you can use the 812/CREADV-DEBADV transaction to send just the credit memos and debit memos. The method you chose is dependent on your agreement with your supplier. Any credit memo/debit memo extracted using the 810/INVOIC transaction will not be eligible for extraction by the 812/CREADV-DEBADV transaction.
6-56
Oracle Receivables
Extract Criteria
The outbound Invoice transaction is controlled by five database views which are defined according to the Oracle Receivable data model for supplier invoices. The five views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The five database views are as follows:
s
ECE_INO_ALLOWANCE_CHARGES_V ECE_INO_HEADERS_1_V ECE_INO_HEADER_V ECE_INO_LINE_TAX_V ECE_INO_LINE_V
The ECE_INO_HEADERS_V view is used to identify which supplier invoices are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type (invoice, credit memo or debit memo) enabled for the trading partner Transaction type is invoice, credit memo or debit memo Transaction type (invoice, credit memo or debit memo) has not been printed or previously extracted Transaction type (invoice, credit memo or debit memo) status is COMPLETE Transaction type (invoice, credit memo or debit memo) print option is PRI
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows: SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_INO_HEADERS_V; Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.
Oracle Receivables

Once an eligible supplier invoice is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the UPDATE_AR procedure defined in the ECEINOB.pls file:
Table RA_CUSTOMER_TRX Column EDI_PROCESSED_FLAG EDI_PROCESSED_STATUS LAST_UPDATE_DATE PRINTING_COUNT PRINTING_LAST_PRINTED PRINTING_ORIGINAL_ DATE PRINTING_PENDING Value Y ED SYSDATE increment 1 SYSDATE SYSDATE N
6-58
Oracle Receivables
Outbound Credit Memo/Debit Memo (CDMO/812/CREADV-DEBADV)

Customer and customer sites are defined in either Oracle Receivables or Oracle Order Management. Included in the definition is the EDI Location Code that trading partners agree to exchange to represent the full detailed address. Often they do not send the full address, but just the EDI Location Code. This is a critical data field to Oracle e-Commerce Gateway. The EDI Location Code is the link between a customer/customer site in Oracle Applications and the trading partner site definition in Oracle e-Commerce Gateway. This enables Oracle e-Commerce Gateway to access the detailed data about the customer or customer site in the base Oracle Applications without maintaining the detail data in Oracle e-Commerce Gateway. To ensure that the trading partner link between Oracle e-Commerce Gateway and Oracle Applications is set up properly, verify that the customer/customer site and the EDI Location Code in Oracle Applications is the correct customer/customer site selected for the Trading Partner definition in Oracle e-Commerce Gateway. The selected customer/customer site and the EDI Location Code defined in Oracle Applications are displayed in the Define Trading Partners window, Assignment tab. If the data is not what you intend it to be, you must make the appropriate changes for the transaction to be extracted for the correct trading partner. This could involve either altering the customer/customer site in the base Oracle Application, or assigning a different customer/customer site to that EDI Location Code in Oracle e-Commerce Gateway. Refer to the Trading Partner chapter for recommendations on selecting the correct trading partner EDI Location Code for the control record 0010 for the transaction in the transaction interface file.
Two Methods of Sending Credit Memos/Debit Memos

The 810/INVOIC transaction supports invoices, credit memos and debit memos. In addition, you can use the 812/CREADV-DEBADV transaction to send just the credit memos and debit memos. The method you chose is dependent on your agreement with your supplier. Any credit memo/debit memo extracted using the 812/CREADV-DEBADV transaction will not be eligible for extraction by the 810/INVOIC transaction.
Oracle Receivables
Extract Criteria
The outbound credit memo/debit memo transaction is controlled by five database views which are defined according to the Oracle Receivable data model for credit and debit memos. The five views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The five database views are as follows:
s
ECE_CDMO_ALLOWANCE_CHARGES_V ECE_CDMO_HEADERS_1_V ECE_CDMO_HEADER_V ECE_CDMO_LINE_TAX_V ECE_CDMO_LINE_V
The ECE_CDMO_HEADERS_V view is used to identify which credit/debit memos are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Credit memo or debit memo enabled for the trading partner Transaction type is credit memo or debit memo Credit memo or debit memo has not been printed or previously extracted Credit memo or debit memo status is COMPLETE Credit memo or debit memo print option is PRI Print pending is Y
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows: SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_CDMO_HEADERS_V; Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.
6-60
Oracle Receivables

Once an eligible credit memo or debit memo is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the UPDATE_AR procedure defined in the ECECDMOB.pls file:
Table RA_CUSTOMER_TRX Column EDI_PROCESSED_FLAG EDI_PROCESSED_STATUS LAST_UPDATE_DATE PRINTING_COUNT PRINTING_LAST_PRINTED PRINTING_ORIGINAL_ DATE PRINTING_PENDING Value Y ED SYSDATE increment 1 SYSDATE SYSDATE N
Oracle Release Management
Oracle Release Management

Transaction Transaction Name Planning Schedule Production Sequence Shipping Schedule Direction Inbound Inbound Inbound Code SPSI PSQI SSSI ASC X12 830 866 862 EDIFACT DELFOR N/A DELJIT
Current Information
The transaction requirements may change when enhancements are made such as additional data added to the transaction. Current transaction details can be found on Oracle Supports web site. Note: For the summary layout see Appendix A. Current detail record layouts are reported via the Transaction Layout Definition Report and the Interface File Data Report.
6-62
Oracle Shipping Execution
Oracle Shipping Execution

Transaction Transaction Name Ship Notice/Manifest Direction Outbound Code DSNO ASC X12 856 EDIFACT DESADV
The Release 11 outbound Ship Notice/Manifest transaction is replaced in Release 11i.1 utilizing the new Shipping Execution data model. Note: For the summary layout see Appendix A.
Current Information
Oracle Supplier Scheduling

The implementation of any transaction requires some set up in Oracle Applications and Oracle e-Commerce Gateway. This chapter focuses on the application set-ups necessary to implement a transaction that integrates with Oracle Supplier Scheduling.
Transaction Transaction Name Planning Schedule Shipping Schedule Direction Outbound Outbound Code SPSO SSSO ASC X12 830 862 EDIFACT DELFOR DELJIT

s
Trading Partner Link to Oracle e-Commerce Gateway Relevant Oracle Application Profiles and Set Ups Planning/Shipping Schedule Extract Options Extract Criteria Columns Updated upon Extraction
Current Information
The transaction requirements may change when enhancements are made such as additional data added to the transaction. Current transaction details can be found on Oracle Supports web site. Current detail record layouts are reported via the Transaction Layout Definition Report and the Interface File Data Report. Note: For the summary layout see Appendix A.
6-64
Outbound Planning Schedule (SPSO/830/DELFOR)

Relevant Oracle Application Profiles and Set Ups

Use Oracle Supplier Scheduling Schedulers Workbench to create planning schedules. Oracle Supplier Scheduling will gather the supply and demand data from Oracle Purchasing and Oracle Planning. Refer to the Oracle Purchasing, Planning, and Supplier Scheduling Users Guide for necessary profile set ups related to Purchasing, MRP, MPS and DRP. There are no specific profile options that control how the planning schedules are extracted.
Planning Schedule Extract Options

There are three ways to extract the planning schedules as follows:
Oracle Applications Product Supplier Scheduling Supplier Scheduling Oracle e-Commerce Gateway
Process Schedulers Workbench for manually created schedules AutoSchedule for automatically created schedules Outbound Planning Schedule Transaction
Method Event Driven Event Driven Concurrent Manager Request
Since the purpose of the Planning Schedule is to work closely with your suppliers to get the right materials to the right place at the right time, the most expeditious option is to transmit the planning schedules at the time the schedule is created in the Scheduler Workbench or via AutoSchedule. All planning schedules must be confirmed before they are eligible for extraction. Schedules may be confirmed using the Scheduler Workbench or in AutoSchedule via the AutoConfirm process.
Extract Criteria
The outbound Planning Schedule transaction is controlled by two database views which are defined according to the Oracle Supplier Scheduling data model for planning schedules. The two views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The two database views are as follows:
s
ECE_SPSO_ITEMS_V ECE_SPSO_HEADERS_V
The ECE_SPSO_HEADERS_V view is used to identify which planning schedules are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type enabled for the trading partner Planning schedule has not been printed or previously extracted
6-66
Planning schedule defined in Supplier Scheduling with communication code of EDI or BOTH Planning schedule has a status of CONFIRMED Planning schedule horizon start/end dates fall within the organizations period start/end dates
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows: SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_SPSO_HEADERS_V; Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.

Once an eligible planning schedule is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the UPDATE_CHV_SCHEDULE_HEADERS procedure defined in the ECSPSOB.pls file:
Table CHV_SCHEDULE_ HEADERS Column EDI_COUNT LAST_EDI_DATE LAST_UPDATED_BY LAST_UPDATE_DATE COMMUNICATION_ CODE Value Increment by 1 SYSDATE -1 SYSDATE see below
COMMUNICATION_CODE is set based on the original value as follows:
Original COMMUNICATION_CODE BOTH EDI
Extract Successful Yes Yes
Set New COMMUNICATION_CODE PRINT NONE
6-68
Outbound Shipping Schedule (SSSO/862/DELJIT)

Relevant Oracle Application Profiles and Set Ups

Use Oracle Supplier Scheduling Schedulers Workbench to create shipping schedules. Oracle Supplier Scheduling will gather the supply and demand data from Oracle Purchasing and Oracle Planning. Refer to the Oracle Purchasing, Planning, and Supplier Scheduling Users Guide for necessary profile set ups related to Purchasing, MRP, MPS and DRP. There are no specific profile options that control how the shipping schedules are extracted.
Shipping Schedule Extract Options

There are three ways to extract and transmit electronic shipping schedules as follows:
Oracle Applications Product Supplier Scheduling Supplier Scheduling Oracle e-Commerce Gateway
Process Schedulers Workbench for manually created schedules AutoSchedule for automatically created schedules Outbound Shipping Schedule Transaction
Method Event Driven Event Driven Concurrent Manager Request
Since the purpose of the Shipping Schedule is to work closely with your suppliers to get the right materials to the right place at the right time, the most expeditious option is to transmit the shipping schedules at the time the schedule is created in the Scheduler Workbench or via AutoSchedule. All shipping schedules must be confirmed before they are eligible for extraction. Schedules may be confirmed using the Scheduler Workbench or in AutoSchedule via the AutoConfirm process.
Extract Criteria
The outbound Shipping Schedule transaction is controlled by two database views which are defined according to the Oracle Supplier Scheduling data model for shipping schedules. The two views contain variables which are dynamically set based on your responses to the extract program parameters (refer to Oracle e-Commerce Gateway Users Guide, Outbound Transactions chapter for a list of the program parameters). The two database views are as follows:
s
ECE_SSSO_ITEMS_V ECE_SSSO_HEADERS_V
The ECE_SSSO_HEADERS_V view is used to identify which shipping schedules are eligible for extraction. The extract criteria are as follows:
s
Trading partner is defined Transaction type enabled for the trading partner
6-70
Shipping schedule has not been printed or previously extracted Shipping schedule defined in Supplier Scheduling with communication code of EDI or BOTH Shipping schedule has a status of CONFIRMED Shipping schedule horizon start/end dates fall within the organizations period start/end dates
If necessary, you can use SQLPLUS to verify if there are any eligible documents to be extracted. To do so, you must first set the organization context and then issue the SQL count function as follows: SQLPLUS> execute fnd_client_info.set_org_context('<Org number>'); SQLPLUS> select count(*) ECE_SSSO_HEADERS_V; Review all your set ups if the count value is 0 as this indicates there are no eligible documents to be extracted.

Once an eligible shipping schedule is successfully extracted and written to the transaction interface file, it is marked by Oracle e-Commerce Gateway to prevent it from subsequent extraction. The following is a list of fields updated based on an excerpt of code in the UPDATE_CHV_SCHEDULE_HEADERS procedure defined in the ECSPSOB.pls file. This file is shared by both the Planning and Shipping Schedule transaction with specific procedure calls to support each transaction.
Table CHV_SCHEDULE_ HEADERS Column EDI_COUNT LAST_EDI_DATE LAST_UPDATED_BY LAST_UPDATE_DATE COMMUNICATION_ CODE Value Increment by 1 SYSDATE -1 SYSDATE see below
COMMUNICATION_CODE is set based on the original value as follows:
Original COMMUNICATION_CODE BOTH EDI
Extract Successful Yes Yes
Set New COMMUNICATION_CODE PRINT NONE
6-72
7
Test Transactions
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Testing Inbound Transactions on page 7-2 Testing Outbound Transactions on page 7-6 Printing and Extract of Documents on page 7-8
Test Transactions
7-1
Testing Inbound Transactions

When implementing a new inbound transaction for an existing Trading Partner or a new Trading Partner/transaction combination, it is recommended that you test at several levels. You should first test with your internal systems, followed by your Translator, then finally with your Trading Partner. While you are in the test mode, you can set the trading partner/transaction combination in Oracle e-Commerce Gateway to test status that will alert all parties that this is a test transaction. Set your trading partner/transaction combination to production status when you are ready to receive a production transaction from your Trading Partner. Oracle e-Commerce Gateway and Oracle Applications are designed to protect your system from receiving invalid data. Oracle e-Commerce Gateway validates the incoming data for syntactic accuracy and passes the valid data to the Oracle Application Open Interface tables to validate for semantic accuracy. Optionally, Oracle e-Commerce Gateway may pass invalid data to the Application Open Interface tables for validation by the Application Open Interface API. This can happen if you did not define Oracle e-Commerce Gateway column rules or you chose to ignore (option in View Staged Documents window) the exception. Both Oracle e-Commerce Gateway and Oracle Applications provide Reports/windows for you to review detected exceptions. Exceptions generally result from incorrect set ups in Oracle e-Commerce Gateway or Oracle Applications that may be corrected in the respective applications. Another form of exception is due to incorrect data sent by the Trading Partner. The Trading Partner may be asked to correct the transaction and transmit an updated transaction. Since these business transactions represent legal documents, general data changes cannot be made on the transaction in the Oracle e-Commerce Gateway. However, if the transaction passes all Oracle e-Commerce Gateway validation and is passed to the Application Open Interface tables, some Oracle application modules provide tools for data correction. The focus of this chapter is on testing inbound transactions. Crucial to the successful implementation of an inbound transaction are all the setups necessary in Oracle e-Commerce Gateway and Oracle Applications. So before you initiate the import process, you must verify all your set-ups. This chapter assumes that the inbound transaction interface file resides in the directory specified in the Oracle e-Commerce Gateway system profile ECE: Inbound File Path and is available for the Oracle e-Commerce Gateway import program to pick up and process.
7-2
Refer to the Implementation Manual, Application Setup section for details related to the following for the inbound transaction you are implementing:
s
Transaction specific special considerations Trading partner link between Oracle e-Commerce Gateway and Oracle Applications Oracle e-Commerce Gateway Required Fields Review Oracle e-Commerce Gateway Exceptions Resolve Oracle e-Commerce Gateway Exceptions Relevant Application Profiles and set Ups Oracle Application Open Interface Required Fields Review Application Open Interface Exceptions Resolve Application Open Interface Exceptions
Verify Oracle e-Commerce Gateway Set Ups

Verify the following in the Oracle e-Commerce Gateway:
s
System profiles are set Relevant transaction profiles are set Trading partner is defined and linked to Oracle Applications Transaction is enabled at the system profile level as well as at the trading partner detail level Relevant code conversions are defined Relevant process rule actions are defined Relevant column rules and associated actions are defined Structure of the transaction interface file received matches the definition reported using the Oracle e-Commerce Gateway Transaction Layout Definition Report Transaction interface file contains valid values for all Oracle e-Commerce Gateway required fields. Review this using the Oracle e-Commerce Gateway Interface File Data Report
Test Transactions
7-3
Verify Oracle Applications Set Ups

Verify the following in the appropriate Oracle application:
s
Relevant application profile and set ups are defined Transaction interface file contains valid values. Review this using the Oracle e-Commerce Gateway Interface File Data Report
Testing the Inbound Transaction

Perform the following for inbound transactions:
s
Initiate the inbound transaction and enable run time execution log (debug parameter) to HIGH or MEDIUM to monitor the import process. Specify valid values for the program parameters (refer to Oracle e-Commerce Gateway Users Guide for the parameter list). When the import process completes, review the Concurrent Request Log and report for detected exceptions. If the import process failed Oracle e-Commerce Gateway validations, use the Oracle e-Commerce Gateway View Staged Documents window to review Oracle e-Commerce Gateway exceptions. If the import process failed Oracle Application Open Interface API validations, use the Oracle Applications report to review the exceptions If the exceptions are due to set up errors in Oracle e-Commerce Gateway or Oracle Applications, make the necessary corrections and submit the transaction for reprocessing If the exceptions are due to invalid data from the Trading Partner, request a new transaction interface file containing the corrected transactions. Delete the exceptions using Oracle e-Commerce Gateway View Staged Documents window and then re-import the new file. Continue to initiate the import process, review exceptions, resolve exceptions and re-process the transaction until the transaction completes successfully and the data is loaded into the base Oracle Applications tables
Inbound Transactions in a Multi-Organization Environment

A single inbound transaction interface file may contain data designated for different organizations defined in Oracle Applications. The Oracle e-Commerce Gateway import program will process all the data associated with the organization identified by the Responsibility of the person initiating the import process. All data
7-4
designated for other organizations will be flagged as an exception. To import the remaining data, you must switch to the Responsibility associated with the other organization and then initiate the import process. You can continue this approach until all data for all organizations have been processed.
Test Transactions
7-5
Testing Outbound Transactions

When implementing a new outbound transaction for an existing Trading Partner or a new Trading Partner/transaction combination, it is recommended that you test at several levels. You should first test with your internal systems, followed by your Translator, then finally with your Trading Partner. While you are in the test mode, you can set the trading partner/transaction combination in Oracle e-Commerce Gateway to test status that will alert all parties that this is a test transaction. Set your trading partner/transaction combination to production status when you are ready to transmit a production transaction to your Trading Partner. The focus of this chapter is on testing outbound transactions. Crucial to the successful implementation of an outbound transaction are all the setups necessary in Oracle e-Commerce Gateway and Oracle Applications plus the application process to ensure that documents are eligible for extraction. So before you initiate the extract process, you must verify all your setups. This chapter assumes that the outbound transaction interface file will be placed in the directory specified in the Oracle e-Commerce Gateway system profile ECE: Output File Path and is available for the downstream processes, i.e., Translator or other process. Refer to the Implementation Manual, Application Setup section for details related to the following for the outbound transaction you are implementing:
s
Transaction specific special considerations Trading partner link between Oracle e-Commerce Gateway and Oracle Applications Extract Criteria Columns Updated Upon Extraction
Verify Oracle e-Commerce Gateway Set Ups

Verify the following in the Oracle e-Commerce Gateway:
s
System profiles are set Relevant transaction profiles are set Trading partner is defined and linked to Oracle Applications Transaction is enabled at the system profile level as well as at the trading partner detail level Relevant code conversions are defined
7-6
Verify Oracle Applications Set Ups

Verify the following in the appropriate Oracle application:
s
Relevant application profile and set ups are defined Execute the necessary application process to ensure that documents are eligible for extraction Run available application Reports to identify documents that are eligible for extraction. This can be used to compare the transaction interface file created by Oracle e-Commerce Gateway
Testing the Outbound Transaction

Perform the following for outbound transactions:
s
Initiate the outbound transaction and enable run time execution log (debug parameter) to HIGH or MEDIUM to monitor the import process. Specify valid values for the program parameters (refer to Oracle e-Commerce Gateway Users Guide for the parameter list). When the extract process completes, review the Concurrent Request Log and Report for detected exceptions Make the necessary corrections in Oracle e-Commerce Gateway or Oracle Applications and re-initiate the outbound transaction Continue to initiate the extract process, review exceptions, resolve exceptions and re-initiate the outbound transaction until the transaction completes successfully and a transaction interface file is created Run the Interface File Data Report to review the contents of the transaction interface file.
Verify the following:

s
Report output matches the data entered in Oracle Applications and is consistent with your selection criteria. Code conversion enabled columns are converted according to your conversion rules. Report output matches application report output (if application report is available)
Test Transactions
7-7
Printing and Extract of Documents
Printing and Extract of Documents

Once the documents are extracted by Oracle e-Commerce Gateway, they are flagged to prevent them from being extracted again. If you have a situation where some documents are printed and sent while others are electronically transmitted to the Trading Partner, you must first print the subset of documents before extracting the balance for electronic transmission. A given document can be delivered only once to the Trading Partner. Refer to the Implementation Manual, Application Setup section for the details regarding which fields are updated upon extraction. Some Oracle Applications do allow re-printing of documents previously sent or electronically transmitted, refer to the Oracle Application Users Manual for the specifics related to the outbound transaction you are implementing. Printing and electronically transmitting the same document to your Trading Partner is not recommended. Use this approach during the testing phase and initial implementation only. Using this approach as standard business practice could create confusion for your Trading Partner as they will not know which copy represents the legal document or worse they may process duplicate transactions.
7-8
8
Troubleshooting
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Troubleshooting on page 8-2 Error Messages on page 8-4 Inbound Transactions on page 8-11 Reports on page 8-16
Troubleshooting
8-1
Troubleshooting
Troubleshooting
This chapter provides useful information that aids the user in determining the solutions to common Oracle e-Commerce Gateway issues and error messages. It also provides tips that enable the implementation process to progress smoothly. The topics covered in this chapter include:
s
Utilizing the enhanced run time execution log (or tracing) capabilities Common window and processing error messages Miscellaneous troubleshooting tips The purpose of and how to use the View Staged Documents window The use of Oracle e-Commerce Gateway reports as a troubleshooting tool
Run Time Execution Log When a transaction fails, the information that is reported by the concurrent manager in the output file usually is not sufficient enough to allow the user to determine the possible cause of the error. Many times, the information that is reported has to be physically located in the program to figure out the point of failure. Since access to the program and an extensive knowledge of SQL is required, the user has a difficult time diagnosing the cause of the problem. The user has the ability to activate the run time execution log (or tracing) capabilities at run time to get additional data about the problem. This feature displays as much data as it can about the transaction and the program flow. The user has the option of specifying the level of information they need, i.e., LOW, MEDIUM or HIGH. The amount of trace data that is generated varies depending on the level of trace chosen. The levels are: LOW This is the lowest level of tracing data. This level displays data like Customer/Supplier Name, purchase order number, name, etc., for a given transaction. MEDIUM In addition to the data displayed at the LOW level, this level displays data about the major processes being executed for the transaction. If a process is failing, the user can look at the output to determine which process is failing using this level.
8-2
Troubleshooting
HIGH This is the highest level of tracing data. In addition to the data displayed at the LOW and MEDIUM levels, this level shows all the major processes, sub-processes, actual program variables, and their values. This level may not be suitable for most users. It is designed more for a developer to use in researching difficult to fix problems. All output, regardless of the level, is written to the log file that is created by the concurrent manager and is indented for each sub-process performed to allow for ease of research.
Troubleshooting
8-3
Error Messages
Error Messages
The error messages listed in the tables below are divided into two categories. The first category is a list of common error messages that appear in the Oracle e-Commerce Gateway windows and are usually a result of an input error. The second category is a list of the common error messages that are a result of validating and processing transactions. These error messages can be viewed either in the concurrent manager log file or in the View Staged Documents window.
8-4
Error Messages
Table 81 Common Window Error Messages

Message Code Values are defined for this category code. You cannot delete it. The user attempted to delete a code conversion category from the Define Code Conversion Category window. The category has code conversion values assigned to it. This prevents the category from being deleted. All code conversion values assigned for this category to transactions must be removed before the code conversion category can be deleted. This can be accomplished by using the Define Code Conversion Values window.
Description
Solution
Message Description Solution
The defined lookup table, lookup column, or condition is invalid. The user attempted to define a simple lookup column rule in the Interface File Definition window. Either the value specified for the table, lookup column or the lookup condition is invalid. Research which value is invalid and correct it.
Message
This Category Code is assigned to a transaction. You cannot delete it. The user attempted to delete a code conversion category from the Define Code Conversion Category window. The category is assigned to a transaction. This prevents the category from being deleted. All assignments for this category to transactions must be removed before the code conversion category can be deleted. This can be accomplished by using the Assign Code Conversion Categories window.
Description
Solution
Message Description
This location already has a different Trading Partner value. The value selected in the Site field on the Define Trading Partner window, Assignment tab for either the Customer or the Supplier is already defined to a trading partner. You must be careful how you reply to this question. If you answer 'Yes', you may override a valid Trading Partner assignment made in the Define Trading Partner window, Assignment tab. To be on the safe side, 'No' should be the appropriate response and some research should be performed before continuing.
Solution
Trading Partner Group tp_group_code already exists. Enter a unique group code. The user has attempted to add a trading partner group that already exists. Either add your trading partner information to an existing trading partner group or create a new trading partner group.
Troubleshooting
8-5
Error Messages
Table 82 Common Processing Error Messages

Message Description Solution INVALID_OPERATION error occurred while writing to output file. Read, write and execute permissions need to be established within Unix at both the file and directory levels Make the appropriate permission changes using the Unix chmod command.
Message
Unable to derive a unique address due to ambiguous setup data. This message appears in the View Staged Documents window and is a result of an import process exception. The problem is due to a missing or incorrect data in the Oracle Application or the Oracle e-Commerce Gateway that was insufficient to derive a unique customer site or supplier site. This error occurred during address derivation that may have also used the name field from the transaction. Address Precedence profile in the Profile Set Up section. Resolve the trading partner set up or change the address derivation option, then resubmit the document from the View Staged Documents window.
Description Solution
Message
Unable to derive the address ID for the given address. This message appears in the View Staged Documents window and is a result of an import process exception. The system was not able to determine the correct address based on address derivation process. Usually the Translator Code and EDI Location Code in the transaction were not assigned to a single customer site or supplier site across organizations. This may happen in a multi-org environment where the combined Translator Code and EDI Location Code are assigned in two organizations. The problem is due to missing or incorrect EDI Location Code in the Oracle Applications or the Translator Code in the Oracle e-Commerce Gateway in the Define Trading Partner window, Assignment tab. Resolve the address site and trading partner set ups, then the user should resubmit the document from the View Staged Documents window.
Description
Solution
Message
Field column_name with value value does not match the defined datatype datatype. This message appears in the View Staged Documents window and is a result of an import process exception. The data that is assigned to the noted column_name does not match the datatype definition. For example, the datatype definition may be numeric and the data contained within column_name contains alphabetic characters or the datatype definition may be date and the data contained within column_name is not in the proper date format.
Description
8-6
Error Messages
Check the data map to determine if the transaction data is positioned correctly in the transaction interface file for the given transaction. If the problem exists in the incoming transaction, then the associated records with this document should be deleted from the View Staged Documents window. If the Trading Partner is sending invalid data, the Trading Partner needs to be notified that there was a problem with the transaction. They may need to send a corrected transactions.
Solution
The file file_name is empty for transaction transaction_type. This message appears in the concurrent manager log file. The filename that was entered on the Import Process parameters window contains no data. Confirm that the filename is correct or that the file is in the directory indicated in the Profile Options window and retransmit the data file.
Message Description
Please use a valid organization ID. The Organization ID provided in the transaction is not defined in the HR_LOCATIONS_ALL table. Note that it is unusual for a transaction to contain the Organization ID. The associated records with this document should be deleted from the View Staged Documents window. The data cannot be corrected.
Solution
If the Trading Partner provided the Organization ID in the transactions, inform them to correct the transaction and resend the data.
Message
The incoming test flag is different from that set up for the Trading Partner. This message appears in the View Staged Documents window and is a result of an import process exception. It indicates that the test flag in the transaction is different than the test/production indicator in the Define Trading Partner window, Details tab for the transaction being imported. For example, the test flag in the transaction may contain a value of 'P' (production) and the Test box may be checked in the Details tab for the transaction being imported. These values must correspond for the import process to work properly. If the problem exists in the incoming transaction, then the associated records with this document should be deleted from the View Staged Documents window and the Trading Partner needs to be notified that there was a problem with the transaction. The Trading Partner needs to be informed that this data needs to be corrected by them and the appropriate documents retransmitted. Also check the data map in the translator to review what it writes to the transaction interface file. If the problem is due to incorrect Trading Partner set up in Oracle e-Commerce Gateway, then the user should make the required correction and resubmit the document from the View Staged Documents window.
Description
Solution
Troubleshooting
8-7
Error Messages
Message
A Trading Partner with Translator Code <translator_code>, EDI Location Code <location_code>, map <map_code> for the <transaction_type> transaction is not defined. This message appears in the View Staged Documents window and is a result of an import process exception. The combination of Translator Code, EDI Location Code, map and transaction type are not defined in the Oracle Applications. Set up the Translator Code in the Oracle Application and the EDI Location Code in the Oracle e-Commerce Gateway for the correct Trading Partner. Enable the document and document type in the Define Trading Partner window, Details tab. Obtain the full address for the given EDI Location Code from the Trading Partner if it is necessary to define the site and the EDI Location Code in Oracle Applications. After all set-ups are complete, the user should resubmit the document from the View Staged Documents window. If the problem exists in the incoming transaction, then the associated records with this document should be deleted from the View Staged Documents window and the Trading Partner needs to be notified that there was a problem with the transaction, if necessary. The Trading Partner needs to be informed that this data needs to be corrected by them and the appropriate documents retransmitted.
Description
Solution
Message Description
Unable to process the xxxx transaction because it is disabled. This message appears in the concurrent manager log file. The transaction that is being imported is disabled in the Profile Options window. If appropriate, activate the transaction in the Profile Options window and resubmit the document from the View Staged Documents window. Otherwise, delete the transaction in the View Staged Documents window. Research this transaction with the Trading Partner.
Solution
Message
UTL_FILE. File location or file name was invalid. This message appears in the concurrent manager log file. This message usually indicates that the values specified for the inbound and outbound directories in the utl_file_dir parameter in the INIT.ORA file do not match the values indicated in the Profile Options window for the inbound and outbound directories. Make the appropriate corrections, restart the database (only if the INIT.ORA file was changed) and resubmit the process.
Description Solution
8-8
Error Messages
Table 83 Miscellaneous Troubleshooting Tips

The outbound Payment Order/Remittance Advice (820/PAYORD/REMADV) transaction does not appear on the list of transactions on the Oracle e-Commerce Gateway Export Process. This transaction is event driven and is automatically submitted by the Oracle Payables' Payment Workbench process
Symptom Solution
Symptom
Trouble writing the output file to the specified directory or you cannot find the output file. Check the following: PROFILE OPTIONS: Make sure the profile option for output directory is defined using the correct operating system syntax. Use physical directory name; do not use logical directory names. DIRECTORY: Make sure the utl_file_dir parameter for the outbound file directory is defined in the INIT.ORA file to match the profile option setting. Make sure to restart the database after making any changes.
Solution
ACCESS: Make sure the defined directory is accessible and not write protected. If directory is protected, use "chmod 777" in UNIX to grant access.
Symptom
The outbound Purchase Order (850/ORDERS) or Purchase Order Changes (860/ORDCHG) file is empty. Check the setting of the appropriate Document Type under Setup/Purchasing Options for when archival is performed. The options are "Archive on Print" or "Archive on Approval". For Oracle Purchasing transactions to be extracted properly, the option must be set to "Archive on Approval". The "Archive on Print causes the purchase order to be printed that in turn prohibits Oracle e-Commerce Gateway from extracting it. Not every purchase order change causes a purchase order revision that triggers a purchase order reprint or purchase order retransmit. Check the Oracle Purchasing User Guide for business rules to determine what type of changes create a purchase order revision.
Solution
Symptom
The outbound file is empty.
Troubleshooting
8-9
Error Messages
The Trading Partner (TP) primary site for the transaction must be set up through the Trading Partner Assignment tab and the transaction (and appropriate document types) must be enabled through the Define Trading Partner window, Details tab. The transaction must also be eligible to be extracted. If these set-ups are not done, the Trading Partner's transactions cannot be extracted. Check the following: TP DEFINED: Confirm that a Trading Partner is defined in Oracle e-Commerce Gateway and associated to a valid address entity in Oracle Applications. Trading Partner associations are set up using the Trading Partner window, Assignment tab. TP ENABLED: Confirm that the Trading Partner is enabled for the outbound EDI Document and Document Type. This is done using the Trading Partner window, Details tab. TP DEFINE: If an entity is both a supplier and a customer, make sure to identify two Trading Partners, one for each business relationship. EXPORT PARAMETERS: Confirm that the selection parameters provided for the export process are valid for the documents to be extracted. For the outbound Purchase Order (850/ORDERS) or Purchase Order Changes (860/ORDCHG), the date parameters are inclusive, so make sure the end date parameter is one day later than the actual desired date. The parameter must be one date later because time is included and you need to extract to the midnight hour. Solution FRESH TRANSACTIONS: Make sure the selected group of documents have not been printed or previously extracted.
8-10
Inbound Transactions
Before an inbound transaction can be processed, the user needs to determine if the predefined transaction record definition meets their business requirements and the predefined process rules, and column rules that are assigned to the transactions meet their needs. If the user does not perform this step, the Oracle e-Commerce Gateway uses the seeded rules and actions for data validation. Information concerning the Interface File Definition window and the establishing of process and column rules can be found in this manual. Refer to sections entitled Determine Process and Column Rules and Actions and Modify Transaction Interface File for more details. After an inbound transaction request is executed, users have the ability to view the documents with exceptions using the View Staged Documents window. Users can drill-down to see which documents contained exceptions. After processing any inbound transaction, the user should check the concurrent manager status. If it has a status of warning or error, the user can go to the View Staged Documents window to see the document details such as rule exceptions, column values. Users should also check the log file for other processing information.
View Staged Documents Window
The View Staged Documents window is used to view the results of inbound document processing. Users access this window to display the number of documents in the staging tables and to see if any failed the validation process. Users can drill down and view the document numbers such as PO Number, Invoice Number that have rule exceptions. From this window, users can select documents that have rule exceptions and resubmit (after the errors have been resolved) or delete the documents. This window consists of two major components. The left side shows the transactions in a tree format and the right hand side shows the corresponding selected level summary. It shows different information depending on the tree node that is selected. The tree data is only a snapshot of the staging table. Users need to do a Refresh in order to see any new/modified data in the staging table. Two functions are available on this window. The Resubmit function allows the users to resubmit the given set of documents or a single document to be processed again through the inbound process after errors have been corrected. For example, users can select IN:Invoice (810/INVOIC) and use the resubmit funtion. In this case, the inbound process will revalidate all the Invoices that have a status of Skip
Troubleshooting 8-11
Document. The status will be changed to Reprocess and a concurrent request is submitted to process the documents. Also, the tree is refreshed with new data. The Delete function enables the users to delete the given set of documents or a single document and the corresponding rule exceptions. For example, users can select Trading Partner Alpha and use the Delete function. In this case, it deletes all of the invoices that has a status of Skip Document for Trading Partner Alpha. After deleting the documents, the document tree is refreshed without the deleted documents.
8-12
Transaction Exception Summaries

There are four different summary windows (on the right hand side) for different level tree nodes. The summary window for the Status tab tree and Transaction tab are very similar. The only difference is the order of the status and the transaction fields. The status level 1 summary for the Status tab shows the following:
Status: Transaction: Number of Documents: Total Exceptions: Status of selected documents currently in the staging table List of transaction type name for given status Number of documents for given status, transaction type Total number of exceptions (including all the processing and column exceptions) for given status, transaction type
The status level 2 summary for the Status tab shows the following:
Status: Transaction: Trading Partner: Number of Documents: Total Exceptions: Status of selected documents currently in the staging table Identifies the transaction type name List of trading partner names for the selected transaction Number of documents for given status, transaction type, and trading partner Total number of exceptions (including all the processing and column exceptions) for given status, transaction type, and trading partner
Status: Transaction: Trading Partner: Status of selected documents currently in the staging table The transaction name Trading Partner name for the selected transactions
Number of Documents: Number of documents for given status, transaction type, and trading partner Total Exceptions: Total number of exceptions (including all the processing and column exceptions) for given status, transaction type, and trading partner
Transaction: Status: Trading Partner: Document Number: Level: Process Exceptions: Column Exceptions: The transaction name Status of selected documents currently in the staging table Trading partner name for the selected transactions The primary identifier for the document in the staging table. The value depends on the transaction such as POI for PO Number, INI for Invoice Number. The text description of the level Total number of process exceptions for the given document Total number of column exceptions for the given level of the document
Process Violation and Column Violation Buttons At the bottom of the status level window are two buttons labeled Process Violations and Column Violations. The Process Violations button opens the Process Violations window and displays the process exceptions for the given document. The Column Violations button opens the Column Violations window and displays the column exceptions for the given level of the document. This window displays the following data:
8-14
Transaction: Document Number: Message
Transaction type and the translated transaction type name The primary identifier for the document in the staging table. The value depends on the transaction (i.e. POI has the PO Number, INI has the Invoice Number). The process exception text When this box is checked, it gives users the ability to ignore the violated rule when resubmitting the document. This is the only field that can be modified in this window.
Ignore Check Box
The Column Violations window displays each column of the selected level in the given document and the number of exceptions for the column. The users have the ability to only show columns with exceptions or all columns by selecting the appropriate combination box. This window displays the following data: Transaction: Document Number: Level: Column Name: Column Value: Exception: Message Transaction type and the translated transaction type name The primary identifier for the document in the staging table. The value depends on the transaction such as POI has the PO Number, INI has the Invoice Number. Text description of the level. These values are seeded in the FND_LOOKUP_ VALUES table Name of the column storing the transaction data in the View Staging tables. Value stored in the Column Name. This data came directly from the transaction or was derived in the Oracle e-Commerce Gateway. Number of column exceptions violations for the selected column Column exception text for the selected column When this box is checked, the violation that was determined by the Column Rule will be ignored when resubmitting the document. This is the only field that can be modified in this window.
Ignore Check Box
Reports
Reports
The Oracle e-Commerce Gateway provides two reports that allow the user to verify the transaction layout and contents of their data files. Transaction Layout Report: This report allows the user to produce an on-line report or a hard copy listing of the transaction interface file layouts for the any transaction within the Oracle e-Commerce Gateway. Each transaction interface file consists of several records. Each record has two sections, the record key (positions 1-100) and the application data area (positions 101 & beyond). Every record is referenced by a record number that is unique to a set of data elements. This report displays all the data elements in positions 101 and beyond. The record key (1-100) is not reported as these seeded values may not be changed by the user. The report parameters are in the following table. Refer to the Report section of the Oracle e-Commerce Gateway User Guide for more detail.
List of Values Yes Yes
Report Parameters Transaction Code Include Data not Mapped
Valid Values Enter <blank> to select all Transactions or enter a specific Transaction. Enter Yes or No to include/exclude data not mapped. Default is No.
Required? No Yes
Interface File Data Report:

This report allows the user to produce a hard copy listing of the data contained within a specific transaction data file. The report contains the transaction record layout and the actual data stored in each of the data fields. The report parameters are in the following table
8-16
Reports
Report Parameters Transaction Code Path to Data File
Valid Values Enter specific Transaction Code. Enter the directory path where the data file resides. Default from profile option value for inbound/outbound based on transaction code. Enter the name of the data file.
List of Values Yes No
Required? Yes Yes
Data File Name
No
Yes
Reports
8-18
9
Trading Partner
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Trading Partner on page 9-2 Trading Partner Group on page 9-3 EDI Location Codes on page 9-4 Translator Codes on page 9-6 Translator Code and EDI Location Code Across Applications on page 9-9 EDI Location Codes in the Transaction Interface Files on page 9-13 Multi Organizations on page 9-20
Trading Partner 9-1
Trading Partner
Trading Partner
In the Oracle e-Commerce Gateway, the term Trading Partner refers to an entity such as a customer, supplier or bank - at a particular location or address - with which you exchanges routine commercial documents via EDI. Since a given entity may have several locations, you must define one Trading Partner for each customer address, supplier site, or bank branch as required for processing by the Oracle e-Commerce Gateway. Trading Partner data must be set up both in your EDI translator software and in the Oracle e-Commerce Gateway. The set up parameters are quite different to satisfy their particular needs. In the Oracle e-Commerce Gateway, Trading Partner data is used to: Link a particular address location in Oracle Applications to the Trading Partner definition in the Oracle e-Commerce Gateway Provide a means of telling the EDI Translator which Trading Partner data maps and mailbox is to be used (outbound transactions) Enable specific transactions for Trading Partners Determine if the EDI status of a Trading Partner is Test or Production This section provides important detail about Trading Partner definitions, EDI Location Codes, Translator Codes, their importance on the transaction interface files, and multi-org considerations. The Trading Partner windows along with some recommendations are at the end of this chapter for your reference.
9-2
Trading Partner Group
Trading Partner Group

The Oracle e-Commerce Gateway allows the Trading Partners to be listed in convenient groups to facilitate access to individual organization records as described below. For example a car manufacturer may group its Trading Partners by seat suppliers, tier manufacturers, windscreen companies, engine parts suppliers, or each individual supplier. A publisher may group Trading Partners by printer, major outlet, distributor, exporter, bank, and their individual customers. The group may depend on whether the Trading Partners are customers or suppliers. The Trading Partner group title is a free text field that is not used in any EDI processing. It may consist of any title that is meaningful to your organization.
Trading Partner 9-3
EDI Location Codes
EDI Location Codes

Site address data is used within EDI transactions, for instance as a ship-to address or a bill-to address. Each Trading Partner address site in Oracle Applications to be used in EDI transactions should have an EDI Location Code assigned to it in the base application. The EDI Location Code represents the customer address, supplier site, or bank branch full address. It is typically a code in the EDI transaction in the X12 N104 segment or in the EDIFACT NAD segment, it may also be a made up code according to any existing or agreed naming conventions. The EDI Location Code is part of the address entities set up in the Oracle Application. The Oracle e-Commerce Gateway derives the column ID for the full address stored in Oracle Receivables, Oracle Payables, or HR-Locations given the EDI Location Code and Translator Code found in the Oracle e-Commerce Gateway Trading Partner windows - see below. The EDI Location Code is displayed on the Trading Partner Assignment tab once the Trading Partner site is selected. Although the EDI standards allow for full address details to be used, the Oracle e-Commerce Gateway only supports the use of Location Codes in the transaction interface file for most transactions. For some inbound transactions, the application open interface may accept the full name and addresses into the tables for certain business functions. However, they are generally expecting the column ID to be predetermined. Do not confuse the EDI Location Code with the other Location Codes in base Oracle Applications where address sites are defined. The EDI Location Code exists to link the address site in the base Oracle Application to the Oracle e-Commerce Gateway process. The following table summarizes the purpose of the EDI Location Codes as defined in the base Oracle Application and when used in the transaction interface file.
9-4
EDI Location Codes
EDI Location Define in base Oracle Application
Purpose for Outbound Transactions Extract EDI Location Code retrieved with the full address for each address within transaction so they are available for data mapping in an EDI translation process. The EDI Location Code for the primary site in the transaction is placed on the Control Record. Each transaction has a predefined site (e.g. a bill to site for payment transactions) that it will use to access the Oracle e-Commerce Gateway tables to check that it is enabled. The Primary site must have been defined as a Trading Partner in the Oracle e-Commerce Gateway so its transactions could be enabled for processing for the specific transaction.
Purpose for Inbound Transactions The EDI Location (and Translator) code are used to find each address in the base application to retrieve the column ID if it is needed for the application open interface tables. The EDI Location (and Translator) code must be defined as a Trading Partner in the Oracle e-Commerce Gateway to verify that this transaction is enabled for this Trading Partner. If it is not enabled the transaction is rejected. If it is enabled, the column ID for the customer or supplier associated with the site on the Control Record is retrieved and passed to the Oracle Application open interface tables. All the address sites in the transaction will be associated to this derived customer or supplier.
Found in the transactions Control Record (0010)
Found in the transaction other than on Control Record (0010)
The EDI Location Code for the address site is retrieved along with the full address when the transaction was extracted then written to the transaction interface file. (Note: Only the primary site for the Control Record was checked in the Oracle e-Commerce Gateway.)
The EDI Location (and Translator) code are used to find each address in the base application to retrieve the column ID if it is needed for the application open interface tables.
Trading Partner 9-5
Translator Codes
Translator Codes
The Translator Code can be any arbitrary text value that you use to define the Trading Partner identifier in the EDI translator. The format or selection of the Translator Code might be dictated by the functionality of the EDI translator software. A naming convention for the identifier may have been used. Typical sources for the Translator Code include: Electronic post box number Interchange sender/receiver ID (ISA06/08 or EDIFACT equivalent) Customer or supplier code as used in Oracle Applications Customer name or Supplier name Dun & Bradstreet's DUNS or DUNS+4 number. The Translator Code provides an additional identifier in the transaction interface file. It is assigned at the transaction type level in the Trading Partner Detail window. This allows Trading Partner sites to have different Translator Codes (hence, electronic mailboxes) for different transactions. For outbound transactions, the Translator Code provides an identifier that the EDI translator software can use to identify the Trading Partner set up for the transaction. EDI translator software might use the Translator Code alone, or in conjunction with the EDI Location Code to identify its Trading Partner set up. For inbound transactions, the Translator Code is used in conjunction with the EDI Location Code to uniquely identify the Trading Partner set up in the Oracle e-Commerce Gateway that the transaction refers to. This also allows multiple Trading Partners to use the same EDI Location Codes since the actual Trading Partners can be distinguished by their Translator Code. Since an Oracle e-Commerce Gateway Trading Partner represents an address site, multiple Trading Partners defined in the Oracle e-Commerce Gateway may share the same Translator Code in the EDI translator. Since the Trading Partner definition is identified using both the Translator Code and the Location Code, then it is the combination of these two codes that must uniquely identify the Trading Partner setup. Both the Translator Code and the EDI Location Code can be shared by a number of Trading Partner setups, as long as there is only one Trading Partner setup for each combination of codes.
9-6
Translator Codes
Multiple Translator Codes per Trading Partner A given address site may use different Translator Codes for different transactions. One business entity may route their financial transactions to an electronic mailbox for their financial center, while their procurement center uses a different electronic mailbox; hence, different Translator Codes are associated with different transactions.
Trading Partner Assignment Tab Translator Code Same address site is used for the Supplier and Remit location C-SJ EDI Location Code for Supplier Site C-SJ EDI Location Code for Remit To Site
Trading Partner Detail Tab Transaction Document Type POO Outbound Purchase Orders Inbound Invoices MAILBOX_ PROC MAILBOX_FIN
INI
Shared Translator Codes Note: Do Not Assume One Translator Code to One Trading Partner Definition in the Oracle e-Commerce Gateway. Several organizations or divisions of a Trading Partner depending on how the Trading Partners are defined in the base Oracle Application may use the same Translator Code (like the electronic mailbox that it is associated with). For instance, one Trading Partner mailbox may be shared by a corporations east coast and west coast offices, though they may be defined as two Trading Partner (customers or suppliers) in the base Oracle Application. In the following illustration, the Oracle Supplier is derived from the Supplier site associated with the EDI Location Code and Translator Code found on the Control Record (0010).
Oracle e-Commerce Gateway Translator Code A1-ACME-10 A1-ACME-10 EDI Location AC-BOST AC-DEN
Oracle Purchasing Supplier Site Boston Denver Supplier Site ID 64354345 12343221 ACME-EAST Supplier Supplier ID 135678
ACME-WEST 654322
Trading Partner 9-7
Translator Codes
Oracle e-Commerce Gateway does not need to know how many real business entities are associated with a given Translator Code. There may be one business entity or dozens associated with that Translator Code. That determination is totally in the realm of Trading Partner definitions as you determine and set up within the EDI Translator.
9-8
Translator Code and EDI Location Code Across Applications

The relationship of the Translator Code and the EDI Location Code across the three applications is illustrated below. The Oracle e-Commerce Gateway shares the following codes with the other applications for the following reasons: EDI Location Codes shared with base Oracle Application to identify an address site. EDI Translator is shared with a Translator. It is used to identify the Trading Partner in the translation software. This code is first defined in the translator then copied to the Oracle e-Commerce Gateway For outbound transactions, this code is written on the Control Record 0010 so the translator can identify the Trading Partner. For inbound transactions, the Translator Code is used to distinguish Trading Partners who may use the same set of EDI Location Codes.
base Oracle Application Computer Warehouse Services.

Site Address with
Oracle e-Commerce Gateway

(Trading Partner)
EDI Translator Computer Warehouse Services San Jose
CWS-San Jose
124 45th St. San Jose, CA

Link established in Assignment Window ofTrading Partner Form
Location Code C-SJ
124 45th St. San Jose, CA CWS004

Link established in the Detail Window in the Trading Partner Form
Translator Code
CWS004
Set-Up in EDI Translator
The Translator Code CWS004, defined in the EDI Translator, is not limited to one Trading Partner address site using that code in the Oracle e-Commerce Gateway.
Trading Partner 9-9
Other sites may also use it for Computer Warehouse Services. (The Translator Code used between the Oracle e-Commerce Gateway and the EDI Translator may also consist of a concatenation of Translator Code and Location Code - for example, in this case, CWS004+C-SJ. You determine the naming convention.)
9-10
Linking Trading Partner Data to the Oracle Application Source

The following illustration relates the Trading Partner data in the Oracle e-Commerce Gateway windows to the address site in the Oracle Application. Sample Illustration using a Supplier Site in Oracle Payables
Define Trading Partner

Define a Trading Partner (address site level) Partner:
Computer WS, San Jose Loc 4
B A S E
A P P L I C A T I O N
Supplier Computer Warehouse Services Supplier Site 124 45th St. San Jose, CA EDI Location C-SJ
Assignment Tab Supplier: Computer Warehouse Services Supplier Site: 124 45th St. San Jose, CA Location:
C-SJ
Inbound: Checks Enabled Transaction ONLY for EDI Location on Control Record (0010) Outbound: Enable all Trading Partners to be extracted
Detail Tab Document Doc Type Translator IN: PO OUT:Invoice CSW-SFO CSW-CHIC
The supplier illustration above highlights the following key items when assigning a Trading Partner to a suppler/supplier site in Oracle Payables: The Trading Partner area within the Trading Partner Group window establishes the following: A name and description for the Trading Partner definition. Both fields are free form text though a naming convention is recommended on the Trading Partner name and Trading Partner Group. (Note: Trading Partner Group is not linked to other Oracle Applications.) This Trading Partner name will be associated to a single suppler/supplier site in the Trading Partner Assignment tab. The Trading Partner Assignment tab establishes the following:
Trading Partner 9-11
Links the Trading Partner definition to the appropriate suppler/supplier site in Oracle Payables. The EDI Location Code from Oracle Payables is displayed for the selected address site. The Trading Partner Details tab establishes the following within the Oracle e-Commerce Gateway: Enables a document (transaction) / document type for processing. Defines the Translator Code for that transaction. Flags the transaction as test or production. Display the format of the transaction. Flat File (FF) in this case.
9-12
EDI Location Codes in the Transaction Interface Files

Control Record (0010) The Control Record is the first record in each transaction. It contains a field called the Trading Partner Location Code. For inbound transactions, this field must have one of the EDI Location Codes for the Trading Partner sending the transaction. The Trading Partner site represented by that EDI Location code must be fully defined in the Oracle e-Commerce Gateway and base Oracle Application. Note: For inbound transactions, the only time that a Trading Partner must be fully defined in the Oracle e-Commerce Gateway and the base Oracle Application is when its EDI Location code is used in the Control Record. A fully defined Trading Partner means the following:
s
In the Trading Partner Group window, the Trading Partner group and Trading Partner name are defined. In the Trading Partner Details tab, the appropriate transaction and transaction types are enabled, the Test/Production flag is set to the correct code, the Translator Code is accurately entered, and the EDI box is enabled. In the Trading Partner Assignment tab, the Trading Partner is linked to the appropriate address site in the base Oracle Application. In the base Oracle Application, the Trading Partner and Trading Partner site is defined and the EDI Location Code for the site is entered.
The combination of the Translator Code and the EDI Location Code on the Control Record (0010) must lead to a single Trading Partner definition in the Oracle e-Commerce Gateway. The Oracle e-Commerce Gateway uses the EDI Location Code in the Control Record for two reasons:
s
To identify that the Trading Partner site is setup and enabled for the specific transaction. For example, EDI Location Code HC-CHIC is defined to Trading Partner Herbert-Chicago, where the specific outbound transaction is enabled for EDI processing.
To derive the customer, supplier or bank in the Oracle Application to associate with all the address sites in the transaction detail. For example, the customer Herbert Corporation is derived from the base Oracle Application tables given that the EDI Location Code HC-CHIC for the Chicago site was found on the Control Record.
Either a constant EDI Location Code for the Trading Partner may be entered in the Control Record (see Default EDI Location section below), or the first appropriate site found in the detail of the transaction may be copied to the Control Record by the EDI Translator. The recommended type of location code to copy from the transaction detail into the Control Record 0010 is listed in the following table. These type of locations are likely to be in the transaction detail; however, any EDI Location Code for the Trading Partner will work as long as it is fully defined in the Oracle e-Commerce Gateway.
Type of Sites Location Code to Copy from the Transaction Detail into the Control Record 0010 Supplier Site Supplier Ship To Site Supplier Site Supplier Ship To Site ORDERS REQOTE Customer Ship To Site Supplier Site Customer Ship To Site DESADV DELJIT Customer Ship To Site Supplier Ship To Site
Transaction Invoice Planning Schedule Price/Sales Catalog Production Sequence Purchase Orders Response to Request for Quotation Ship Notice and Billing
Transaction Code INI SPSI CATI PSQI POI RRQI SBNI
ASC X12 810 830 832 866 850 843 857 856 862 EDIFACT INVOIC DELFOR PRICAT
Ship Notice/Manifest ASNI Shipping Schedule SSSI
Type of Sites Location Code on the Control Record for Inbound Transactions
9-14
Transaction Detail Address Records The transaction detail records contain address records, such as the ship-to address or bill-to address. The records usually have record types of AD to identify them as address records and a record qualifier like ST for ship- to or BT for bill-to to identify the type of address. The Oracle e-Commerce Gateway does not examine address site usage such as bill-to usage or ship-to usage in the base Oracle Application trading partner tables. The site usage for an address in the file is defined by what record the address is found in the transaction interface file. Each address record has an internal address Location Code and an external address Location Code. The EDI Location Code as defined in the base Oracle Application for that address must be placed in the Address Location external code field so the Oracle e-Commerce Gateway can use it to determine the address site in the base Oracle Application. Do not place it in the Address Location internal code field. Once the Oracle e-Commerce Gateway locates the address site in the base Oracle Application, the sites column ID can be passed to the Oracle Application open interface table. The EDI Location Codes found in the address records in the transaction detail do not need to be defined as a Trading Partner in the Oracle e-Commerce Gateway unless that EDI Location Code may also appear on the Control Record 0010 for any transaction. (See Control Record section above.) Any address site in the transaction detail such as the customer/customer site or supplier/supplier site must be defined in the base Oracle Application and the EDI Location Code for the site must be entered. If the EDI Location Code is not entered, the address cannot be determined by the Oracle e-Commerce Gateway.
Outbound Transactions
One transaction may contain several types of address sites in the transaction detail, but only one business address type, such as bill to, ship to, remit to, in the transaction is recognized by the Oracle e-Commerce Gateway as the key address site to examine for the Trading Partner set ups. The Oracle e-Commerce Gateway predetermined which Trading Partner site in an outbound transaction is reviewed to determine if the transaction should be extracted. A Trading Partner must be fully defined in the Oracle e-Commerce Gateway if that sites outbound transactions are to be extracted.
These key sites must be fully defined Oracle e-Commerce Gateway in order to identifying the Trading Partner set-up and selecting the EDI Location Code to be written to Control Record 0010. They are listed in the following table
ASC X12 824 EDIFACT APERAK Site Address Type for the Control Record 0010 Supplier Site
Transaction Application Advice (for 810) Invoice Movement Statistics Payment/Remittance Advice
Transaction Code ADVO
INO MVSTO PYO
810
INVOIC CUSDEC
Customer Bill To Site Legal Entity Paying Bank Branch
820
REMADV / PAYORDPAYEXT
Planning Schedule Purchase Order Change Purchase Orders Ship Notice/Manifest Shipping Schedule
SPSO POCO POO ASNO SSSO
830 860 850 856 862
DELFOR ORDCHG ORDERS DESADV DELJIT
Supplier Site Supplier Site Supplier Site Customer Ship to Site Supplier Site
Sample Primary Address Site Types on the Control Record (0010) for Outbound Transactions Note: The Trading Partner site must be fully defined as a Trading Partner in the Oracle e-Commerce Gateway and the base Oracle Application to have the Trading Partner sites transaction extracted. Like the inbound transaction, a fully defined Trading Partner means the following:
s
In the Trading Partner Group window, the Trading Partner group and Trading Partner name are defined. In the Trading Partner Details tab, the appropriate transaction and transaction types are enabled, the Test/Production flag is set to the correct code, the Translator Code is accurately entered, and the EDI box is enabled. In the Trading Partner Assignment tab, the Trading Partner is linked to the appropriate address site in the base Oracle Application.
9-16
In the base Oracle Application, the Trading Partner and Trading Partner site is defined and the EDI Location Code for the site is entered.
Control Record (0010) The primary EDI Location Code for a transaction is written to the Control Record 0010 along with the Translator Code. These are critical for each process to identify the Trading Partner. Transaction Detail Address Records Like the inbound transaction, the outbound transaction detail records contain address records, such as the ship-to address or bill-to address. The records usually have record types of AD to identify them as address records and a record qualifier like ST for ship to or BT for bill-to to identify the type of address. Each address record has an internal address Location Code and an external address Location Code. The Oracle e-Commerce Gateway populates both location fields in the transaction interface file. The EDI Location Code for that address is placed in the external address Location code. Usually the address column ID from the base Oracle Application is placed in the Location internal address EDI Location Code field. The full site address is also placed on the address record. The EDI Location Codes found in the address records in the transaction detail do not need to be defined as a Trading Partner in the Oracle e-Commerce Gateway unless that EDI Location Code may also appear on the Control Record for any transaction. (See Control Record section above.) Any address site in the transaction detail such as the customer/customer site or supplier/supplier site must still be defined in the base Oracle Application and the EDI Location Code for the site must be entered. If the EDI Location Code is not entered in the base Oracle Application, it will not be written to the transaction interface file and not be available for data mapping in the Translator by the Oracle e-Commerce Gateway.
Default EDI Location Code (Inbound Transactions Only)

The EDI Translator may provide an EDI Location Code in the Control Record (0010) to identify a particular Trading Partner address site, even if that same EDI Location Code is not found in the transaction detail address records. This particular Trading Partner address site will be used to determine the Customer, Supplier, or Bank to be associated with all the address sites in the detail of that transaction, plus check that the transaction is enabled for that Trading Partner address site.
If an EDI Location Code is used exclusively in the Control Record as a default, it does not need to be a real location of the customer e.g. it need not be a real ship-to location for a customer for an inbound purchase order. The EDI Translator could assign a default EDI Location Code on the Control Record, which could be associated with the Translator Code so the Trading Partner determinations can be done in the Oracle e-Commerce Gateway. The address site still must be fully defined in Oracle e-Commerce Gateway (see above section).
Note: A constant or default EDI Location Code for a given Oracle Customer or
Oracle Supplier may be used for any inbound transaction. The address site associated with that EDI Location Code is used to determine the Oracle Customer or Oracle Supplier to be associated with all the address sites in the detail of that transaction. For example, from the three customer addresses defined in Oracle Order Entry/Oracle Receivables, the EDI Location Code CHIC could be used as a Default EDI Location Code in the Control Record (0010) for this customer. Whatever is placed in the EDI Location Code in the Control Record, in this case CHIC, it will be used to retrieve the customer level data (Acme Corp., with Customer ID 123423). The Trading Partner set up for the address associated with CHIC must be fully defined as a Trading Partner in the Oracle e-Commerce Gateway.
9-18
Customer Table Customer
Customer Name Acme Corp.
Customer ID 123423
Address Table Address 1
Physical Address 654 South Blvd., Indianapolis, IN 123 Main St., Chicago, IL
EDI Location Code* INDY
EDI Location Code Determines Address ID 23245
Address is Linked to Customer ID 123423
Use as a Default for EDI Location Code on the Control Record (0010)
Address 2
CHIC
74536
123423
CHIC
Address 3
876 North Ave., Atlanta GA
ATLA
45234
123423
* All these EDI Location Codes point to the same Customer ID 123423 In this case, the Trading Partner site must still be fully defined as a Trading Partner in the Oracle e-Commerce Gateway and the base Oracle Application including entering the EDI Location code in order to process the transaction.
Multi Organizations
Multi Organizations
The Oracle e-Commerce Gateway process limits its address site table search to base Oracle Application address column IDs defined with the same organization specified in the Oracle e-Commerce Gateway responsibility for that execution. The following example illustrates the same EDI Location Code coming from two Trading Partners defined in two organizations. Suppose both Trading Partners use the same code, AB123. In the base Oracle Application, the EDI locations are defined as two address sites.
Trading Partner Trading Partners Customer or Supplier Acme Inc. Translator Address Site Code 123 Main St. Chicago , IL Beta Inc. 123 Main St. Chicago , IL
Sample of Trading Partner set up data
Location Code (on N1 or NAD segment) + AB123
base Oracle Application has two Address Site ID * = 12345678 Organization for the Address Site ID ** A
E1-ACME
E3-BETA
+ AB123
= 13567890
* The address Site column ID is assigned via the Trading Partner Assignment tab. It is retrieved by the Oracle e-Commerce Gateway during transaction processing. ** The Organization is defined in the base Oracle Application for this address site. It is not validated by the Oracle e-Commerce Gateway. It may be passed to the Application Open Interface table given the Address Site ID that is retrieved by the Oracle e-Commerce Gateway. If the EDI responsibility has organization A and the Trading Partner sites in the transactions are defined to organization B in the base Oracle Application, then EDI Location Codes cross reference process will not successfully find the addresses in the base Oracle application tables. This happens because the Oracle e-Commerce Gateway reads only trading partner sites for the specified organization in the responsibility.
9-20
Multi Organizations
EDI Responsibility
The Oracle e-Commerce Gateway import and export process executes against a single organization in a Multi-Org environment. That single organization is defined in the EDI Responsibility setup for that particular execution of the Oracle e-Commerce Gateway. All organizations in the Multi-Org environment share the same code conversion tables and Trading Partner definition tables in the Oracle e-Commerce Gateway. However, the process limits the Trading Partner EDI Location Code cross-referencing to the base Oracle Application address sites, which are assigned to the single organization specified in the EDI Responsibility. For outbound transactions, the Oracle e-Commerce Gateway export process must run separately against each organization. (Use different output file names for each organization to differentiate them, if necessary.) For inbound transactions, the EDI import process also has a single organization assigned in the EDI Responsibility for that particular execution. If the transaction interface file contains transactions associated with several organizations, the transactions for the other organizations not defined in the current processs EDI Responsibility will not successfully find the Trading Partners EDI Location Codes with the base Oracle Application customer, supplier, or bank site addresses. Only the address sites associate with the current organization are examined; the other address sites are not included in the process to examine the EDI Location Code to determine the address site in the base Oracle Application. One of the following happens:
1.
The transactions for each responsibility can be in separate transaction interface files then processed by each appropriate responsibility. The EDI Translator, another process, or the sending Trading Partner may separate the transactions by organization before the Oracle e-Commerce Gateway process is executed. All transactions can be loaded from one file. However, only one organization will successfully find the Trading Partner definitions. Transactions that could not find the Trading Partners sites will remain in the View Staging tables. Log on with a responsibility of each of the Trading Partner exceptions then on-line resubmit the transaction for revalidation. Position the cursor at the desired level in the document tree on the left, then press the resubmit button. The transaction will be revalidated and search for Trading Partner locations defined to the new organization. Transactions for yet another organization will continue to reject. Continue changing the responsibility and resubmitting transactions until all locations are found. If any transactions cannot be
2.
Multi Organizations
processed, their Trading Partners must be set up in the base application for that organization (under the correct responsibility). Note: The EDI Location Code will encounter a Trading Partner (implying a Trading Partner with the current responsibly) not found condition, even though the Trading Partner is defined to another organization. This may cause confusion because the Trading Partner definition is seen in the Oracle e-Commerce Gateway and the customer/suppler/bank tables. The organizational relationship to the current responsibility is not indicated.
Separating Transactions in a File by Organization

Given the processing rules of the Oracle e-Commerce Gateway described above, inbound transactions separated into separate transaction interface files per organization may facilitate your processing. Transactions may be separated by the following methods:
s
Different electronic mailboxes. Different electronic envelope and/or functional group. Trading Partner has multiple Location Codes set up in the source application. Trading Partner can provide the organization code in the transaction.
EDI Translators can easily separate transactions into different files, if the transactions are segregated into different Trading Partner electronic mailboxes or envelopes, or at least separated by functional groups within the electronic envelope. For instance, for an X12 transaction the element Application Receiver's Code (GS03) is often used for this sort of routing. Since Trading Partners do not want to incur the cost of additional electronic mailboxes, they may be willing to separate the transactions into different functional groups within an existing electronic envelope (provided they can isolate the transaction in their processes). Another feasible solution to separate transactions by their organization code is to have the Trading Partner create the transactions in separate address locations that are in synchronization with your organization definitions. If you have a single physical address that you have defined to two or more organizations, you may request that your Trading Partner also distinguish the locations within their application. They can define a unique address site in their application so a different Location Code may be assigned to each location, even if it has the same physical address. This location set up will allow their EDI translator to separate the transactions to different electronic envelopes or functional groups within the
9-22
Multi Organizations
electronic envelope. Consequently, transactions can be processed into different organizations, because they could be separated.
Table 1:
SENDING TRADING PARTNER Sending Trading Partner (set up different Location Codes with the same physical address) Location Code ABC-A for 11 State St., Chicago, IL Assume Items must be booked to different Organizations Send to same EDI Mailbox but different Functional Group RECEIVING TRADING PARTNER Receiving Trading Partner (separate each location into separate files for processing in the Oracle e-Commerce Gateway) Location Code ABC-A has table address site ID 97531 This address site ID has organization A The EDI Translator writes data from EDI mailbox 123456789 with functional group 900 to the file for Organization A for the Oracle e-Commerce Gateway. The EDI Translator writes data from EDI mailbox 123456789 with functional group 911 to the file for Organization B for the Oracle e-Commerce Gateway. Organization Note
Enter orders for Mailbox 123456789; Items A, B, C functional group 900
Location Code ABC-B for 11 State St., Chicago, IL
Enter orders for Items X, Y, Z
Mailbox 123456789; functional group 911
Location Code ABC-AB has table address site ID 54321
This address site ID has organiza-tion B
Sample of transactions separated into different locations by the sending Trading Partner
Multi Organizations
Sending Trading Partner
Sending EDI Translator Electronic Envelope (X12 ISA or UN/EDIFACT UNB) Functional Group (X12 GS or UN/EDIFAC T UNG) 900
Receiving EDI Translator
Transaction with Location ABC-A code in their application Transaction with Location ABC-B code in their application
123456789
Writes the data from this functional group to file for Organization A processing
123456789
911
Writes the data from this functional group to file for Organization B processing
Sample of transactions separated into different electronic envelopes or functional groups by the sending Trading Partner
Organizations in Oracle Application Open Interface Tables

Even if transactions across all organizations could be loaded into the Application Open Interface tables by the Oracle e-Commerce Gateway during one execution, each application open interface has its own requirements about executing all organizations simultaneously or separately. Some Application Open Interfaces may only allow transactions from a single organization in its Application Open Interface tables at one time; while others may allow transactions across several organizations in the Application Open Interface tables. Even if transactions across organizations could simultaneity reside on the Application Open Interface tables, the Application Open Interface process may process each organization separately or all organizations at the same time. Review the documentation on Application Open Interfaces for each Oracle product for their specific processing rules.
9-24
Multi Organizations
Trading Partner Windows

The Trading Partner windows are discussed below. Read the preceding section on Trading Partner detail. Reference the Oracle e-Commerce Gateway User s Guide and the Trading Partner Set up in this manual for detail on using these windows.
Define Trading Partner Group and Trading Partner

A Trading Partner Group is a code that is assigned to a set of Trading Partners to allow them to appear in the Trading Partner list together. Trading Partner group may be a supplier or customer name, or any entity that you choose. Under the Trading Partner Group name is the list of Trading Partner names associated with it.
Trading Partner Naming Convention A Trading Partner naming convention is recommended to easily recognize address sites. The following three components in the table below are recommended. The combination of codes must be unique. Note that a delimiter between fields improves readability.
Multi Organizations
A naming convention also facilitates custom code to generate Partner names from the base Oracle Application for initialization of the Trading Partner tables or during updates after implementation.
Component 1 2 3 Organization Trading Partnership Trading Partner Site Description Description Organization Code Trading Partner Address Site Code Free window text which describes the components above, plus other descriptive data may be added Sample A ACME INDY This may be a site or more refined descriptor. Note
A, Acme, Indy, 45 Meridian
Example: A-ACME-INDY
for A,Acme, Indy, 45 Meridian
Prefix Organization on Partner Name A-Acme-SJ A-Beta-Chic B-Acme-Atl B-Beta-Indy C-Acme-Bos C-Beta-Atl Result: Listed by Organization
Suffix Organization on Partner Name Acme-Atl-B Acme-Bos-C Acme-SJ-A Beta-Atl-B Beta-Chic-A Beta-Indy-B Result: Listed by Partner name
Trading Partner Lists All Trading Partners, regardless of organization (in a multi-org environment) are included, in the list of values of Partner names in the Define Trading Partner window. The Trading Partner names are not limited to the org context associated with the EDI Responsibility.
9-26
Multi Organizations
Multi-Org Note: The list of values for Partners in the Define Trading Partner (header) window lists Partner definitions from ALL organizations. If the Trading Partner names need to be identified by organization, an organization indicator may be entered as a suffix or prefix in the Trading Partner Name. The use of a suffix or prefix gives a different sort order of the Partner list. Implement the preference, which your organization finds helpful for sorting and viewing Trading Partner names on-line.
Define Trading Partner - Assignment Tab

The Assignment tab of the Define Trading Partner window links the Trading Partner definition to the appropriate Trading Partner and Trading Partner address site in the base Oracle Application. Select the correct Trading Partner and Trading Partner site to associate with this Trading Partner site. The Oracle e-Commerce Gateway defines Trading Partner at the address level. The base Oracle Application is likely to define many address sites for a single customer, supplier, or bank. Consequently, there will be many Oracle e-Commerce Gateway Trading Partners associated with a single customer, supplier, or bank as defined in the base Oracle Application. In a multi-org environment, only those customer addresses defined to the organization for the current EDI responsibility are presented for selection. Multi-Org Note: The list of values of Trading Partner addresses in the Assignment tab list only those addresses associated with the org context of EDI Responsibility.
Multi Organizations
Define Trading Partner - Contact Tab

The Contact tab of the Define Trading Partner window is optional. It contains contact data for the specified Trading Partner. It may be used by the EDI Coordinator for the Trading Partners EDI Coordinators contact data. This data is for reference only. It is not used by Oracle e-Commerce Gateway. The Contact tab of the Define Trading Partner window is optional. It contains contact data for the specified Trading Partner. It may be used by the EDI Coordinator for the Trading Partners EDI Coordinators contact data. This data is for reference only. It is not used by Oracle e-Commerce Gateway.
9-28
Multi Organizations
Define Trading Partner - Details Tab

The Details tab of the Define Trading Partner window defines the transactions, the transaction types, the Translator Code and the document standard (for code conversion only) to the Trading Partner. It also enables a document (transaction) for processing, and flags the transaction as test or production. The Trading Partner Details tab requires the following:
s
A line for the each document/document type. For inbound transactions, there must be a 'Translator Code' entry that exactly matches the Translator Code in Control Record (0010) of the transaction interface file. For outbound transactions, the value of the 'Translator Code' must exactly match the Translator Code expected in the EDI Translator. The Enable box must be checked to enable the transaction for this Trading Partner site.
Multi Organizations
9-30
10
Code Conversion
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Code Conversion on page 10-2 Concatenated Search Key for Outbound Transactions on page 10-38
Code Conversion 10-1
Code Conversion
Code Conversion
The Oracle e-Commerce Gateway code conversion function provides a method by which codes used by Trading Partners and electronic data standards can be converted from and to codes used in the Oracle applications. For example, assume that the ABC Corporation transmits a purchase order to the XYZ Corporation. The XYZ Corporation processes the incoming data using its own internal codes (i.e., unit of measure, currency, freight carriers, etc.), but XYZ is required to return ABCs original codes. In this way, the Trading Partner that created the original transaction receives response transactions containing their own internal codes. Code conversion enables you to:
s
Convert Trading Partner and electronic data standards external data to their equivalent internal Oracle application data and vice versa. Identify up to five levels of keys to uniquely associate codes to a specific Trading Partner or other entity. For example, a Trading Partner has multiple ship-to locations which each have unique carrier codes. Each set of carrier codes can be entered into the code conversion value table to be used only for the specific Trading Partner site.
Definitions
Code The value of a data element, field, or database table column. For purposes of code conversion, a code is typically a freight carrier, a unit of measure. For example, the value of a carrier code may be FED. Code Conversion Category A label for a set of codes. For example, SHIP_VIA, UOM, ORDER_TYPE, PAY_ TERMS are code conversion categories. Data Element The smallest unit of a record. Each record contains many data elements, including but not limited to carrier code, and unit of measure. Data elements correspond to fields in Oracle Applications windows or database tables. External Code A code in the transactions transaction interface file, regardless if it is an inbound or outbound transaction, that represents data in the Trading Partners perspective. Internal codes, in contrast, are found in Oracle Applications. Internal Code
10-2
Oracle e-Commerce Gateway Implemenatation Manual
Code Conversion
A code defined in the Oracle Applications, regardless if it is an inbound or outbound transaction. External codes, in contrast, are found in the transaction interface file. Key n (1-5) Value A value contained in a key column (also 1-5), that when concatenated with other keys, comprise a search key. Keys are concatenated beginning with 1 and continuing through all defined keys, up to a maximum of 5, during the code conversion table search. Key n (1-5) Column Table or view columns that contain values used as part of the search key. Search Key Accessing the code conversion table includes a concatenated search key consisting of the 1-5 user-defined search keys. If all five search keys have data then the table entries are very restricted to whom the codes apply. Data in Key 1 is less restricted on access and may apply to several Trading Partners. If all five search keys are blank, the table entries will be read for all Trading Partners transactions for that code category. The maximum number of search keys that you enabled in the Assign Code Conversion Categories window are concatenated for the first search. If a code conversion table entry is not found, the highest order key is removed then a subsequent search of the code conversion table is made. Removing the highest order search key of the remaining search keys and accessing the table with the modified key continues until a table entry is found or no table entry is found. This modification of the key continues until the last access is made with all five search keys set to blanks. Table entries with the 1-5 search keys set to blanks means that the table entry is applicable to all Trading Partners. Code Conversion Process While the setup steps for code conversion are identical for inbound and outbound transactions, the specific process of code conversion differs. Inbound Transactions An inbound transaction arrives in a transaction interface file that is then processed by the Oracle e-Commerce Gateway. The import program reads the transaction interface file, stores the data in memory, and performs code conversion.
Code Conversion
For each data element activated for code conversion, a search key, made up of up to five concatenated values defined in the code conversion windows, is searched for in the transaction columns specified in the Assign Categories window. Any number of values from 1 to 5 can be specified when you define code conversion values in the Code Conversion Values window. These values are concatenated to form the search key. Multiple searches are performed, first using all defined values. If no match is found, the last value is dropped from the search key and the search is performed again using the remaining concatenated values. This process is performed again until either a match is found or until all values are exhausted. If a match is found using the external value(s), an internal value from the Code Conversion value table is passed to the application open interface table, if no transaction exceptions are found by the Oracle e-Commerce Gateway . If a match is not found, a null value is returned and the external-1 field is passed to the application open interface table, if no transaction exceptions are found by the Oracle e-Commerce Gateway. Outbound Transactions An outbound transaction begins when data is extracted from Oracle applications. The Oracle e-Commerce Gateway performs code conversion, where applicable. For each data element activated for code conversion, a search key, made up of up to five concatenate values defined in the Code Conversion windows, is searched for in the transaction columns specified in the Assign Categories window. Any number of values from 1 to 5 can be specified when you define code conversion values in the Define Code Conversion Values window. These values are concatenated to form the search key. Multiple searches are performed, first using all defined values. If no match is found, the last value is dropped from the search key and the search is performed again using the remaining concatenated values. This is performed until either a match is found or until all values are exhausted. If a match is found using the external value(s), an internal value from the Code Conversion value table is written to the transaction interface file. If a match is not found, a null value is returned and the internal value copied to the external-1 field then written to the transaction interface file.
Code Conversion Windows

There are three windows used in code conversion. Their purpose is summarized in the following table.
10-4
Code Conversion
Code Conversion Windows Define Code Conversion Category
Purpose - Define a code conversion category which identifies a subset of code conversion values - Indicates how many search keys will be examined during actual code conversion.
Assign Code Conversion Categories
- Enable code conversion for a data element in a given transaction. - Indicate the columns that have the code values to use in the search key.
Define Code Conversion Value
1.
- Lists the actual code conversion values to cross reference the internal and 1-5 external codes
Code Conversion Window Summary
Code Conversion
Code Conversion Categories Window
A code conversion category is a label for a set of entries in the code conversion table that contains the internal codes and external codes that you defined. During code conversion, only the code conversion table entries with the assigned category are accessed for the given data element. The Code Conversion Categories window lists predefined categories or new categories that you created. The code categories are used to enable a data element for code conversion in the Assign Categories window. You also indicate in this window how many search keys you will use in Code Conversion Values window for that category of data. A search key is a data element that limits the use of the code conversion table entry to a specific Trading Partner, Trading Partner site, or other entity that you define. For example, customer ACME their Chicago site has its own list of carrier codes. The search keys would have the first key value to represent Acme Corporation, and the second search key value to represent their Chicago site.
10-6
Code Conversion
Assign Categories Window
The Assign Categories window lists which data elements in the transaction are candidates for code conversion. These are the only data elements in a transaction that you can enable for code conversion. A data element is enabled for code conversion by entering a code category next to the data element in this window. You will also indicate the 1-5 source column names from the transaction that contains the actual data that you want reviewed as the 1-5 search keys, if you use keys. In the previous window, Code Conversion Categories window, you also enable the corresponding 1-5 search keys by checking the appropriate boxes to correspond to the number of column entries you made in this Assign Categories window. This tells the program the maximum number of keys to use for that category. In the Assign Categories window, the Key 1-5 column names for the search keys are in a list of values. These column names presented are all the column names in the current level (table) being reviewed plus all the levels (tables) above it. For example, if a data element at the item level is activated, column names from both the header level and item level are in the list of values. Once you selected the source column of the data, the actual values that you would find in those columns for the given transaction are used as search key entries when the code conversion value table is read.
Code Conversion
The source columns may be a customer name, customer ID, location code, site name, or whatever you choose. You just scroll through the columns in the List of Values that have been defined for that transaction. Enabling Code Conversion The code conversion table will be accessed only if the data element in the transaction is activated for code conversion. This is done by assigning a code conversion category to the specific data element in a transaction using the Assign Categories window. Source of Data for Search Keys Data to indicate a specific Trading Partner or Trading Partner site to be used, as the search keys may be data found in several places in the transaction. For example, they may be one of the following:
s
In the detail of the transaction, Derived Trading Partner data from the Trading Partner site on transactions Control Record (0010), or Data found on the transactions Control Record (0010).
Control Record Data as Search Keys For inbound transactions, the Trading Partner reference 1 and reference 2 data does not have to match the Trading Partner reference 1 and reference 2 data defined in the Trading Partner window. You could move data from the electronic envelope or any data you choose into Trading Partner reference 1 or reference 2 so they can be used as search keys during code conversion if you desire. Use the Assign Categories window to assign the Trading Partner reference 1 or reference 2 column to be search keys like any other column assignment if you choose to use these fields.
10-8
Code Conversion
Code Conversion Values Window
The Code Conversion Values window is where the actual internal codes and 1-5 external codes to be converted are entered plus any search keys that apply to the entries.
s
Internal codes are the codes defined or recognized in the base Oracle application. External codes are the codes defined or recognized by external sources such as your Trading Partners or transaction standards.
When Not to Use Keys 1-5: If the internal and external code entries apply universally to all Trading Partners, the codes in the code conversion tables do not have keys 1-5 for the entry. When to Use Keys 1-5: Besides the internal and external codes, you can limit the applicability of a table entry to a specific Trading Partner or any other entity that you chose by entering values in the search keys. The search key will be data of your choice that identifies that Trading Partner or other entity.
Code Conversion
If internal and external code entries apply to specific Trading Partners or a group of Trading Partners, one to five limiting search keys plus the internal and external codes must be entered into the code conversion table. To use Keys 1-5, set ups are required in the Code Conversion Categories window and the Assign Categories window previously discussed. Users must indicate what the full search key will be during code conversion set up. For example, it may be the sales channel, customer code, and customer site. Users select what columns to examine from columns in the specific transaction tables in the Oracle e-Commerce Gateway. These columns contain the actual code values examined during code conversion.
Relationship of the Code Conversion Windows

The following illustration shows the relationship of the five keys across the three code conversion windows.
1.
Code Conversion Categories window: A maximum of two search keys will be read during code conversion.
2.
Assign Categories window:
These two columns contain the data in the transaction to be used as the search keys in the code conversion value table.
3.
Code Conversion Values window:
The value_1 of 1000 is the customer code, and the value_2 of 1004 is the customer site number to be used as part of the full search key during code conversion.
10-10 Oracle e-Commerce Gateway Implemenatation Manual
Code Conversion
Keys Used: 1 X Key 1 column_1 Key 1 value_1
Code Conversion Categories window 2 3* 4* 5* X Key 2 Assign Category window Key 3* Key 4* Key 5*
column_2 Code Conversion Values window Key 2 Key 3* Key 4* Key 5* value_2
* Keys 3, 4, and 5 are not activated in this example

Relationship of Keys in the Code Conversion windows
The following illustration shows the relationship of the five keys across the three code conversion windows with actual data.
Keys Used: 1 X
Code Conversion Categories window 2 3* 4* 5* X
Assign Categories window Key 1 Key 2 Key 3* Key 4* Key 5* Customer_CD Customer_Site Code Conversion Values window Key 2 Key 3* Key 4* Key 5* 1004
* Keys 3, 4, and 5 are not activated
Relationship of Keys in the Code Conversion windows with Actual Data
Key 1 1000
Reading the Code Conversion Values Table

Outbound and inbound transactions use different full search keys to access data in the code conversion table. The following must be considered when creating the full search keys for successful code conversion in the code conversion table.
Code Conversion
10-11
Code Conversion
To create any full search key in the code conversion value window, the data elements that comprise it come from the following sources:
Code Conversion
Full Search Key Component Code Conversion Category
Source Defined in the Code Conversion Categories window. Then user assigned to a specific data element in a transaction in the Assign Categories window.
Direction
This is the transaction direction that is accessing the code conversion table entry. It is part of the full search key. It determines if the table entry will be read for the inbound or outbound transactions or transactions in both directions. The values are IN for inbound transactions; OUT for outbound transactions; and BOTH for both inbound and outbound transactions.
Keys 1-5
User determined data that limits to what the code conversion value applies. Usually it is limited to a Trading Partner site. No keys indicated means that the table entry applies to all Trading Partners.
Internal code (inbound transactions)
This is the data defined or recognized by the Oracle application. It is usually data found in the code conversion value table that will be written to the application open interface table.
Internal code (outbound transactions)
Data found on the base application document or derived by the Oracle e-Commerce Gateway. This data will be written to the transaction interface file. Data found on the transaction interface file or derived by the Oracle e-Commerce Gateway. This data is used to derive the Oracle internal code for the application open interface table. Data found in the code conversion table given the internal code then written to the transaction interface file. Defined in the Code Conversion Categories window. Then user assigned to a specific data element in a transaction in the Assign Categories window.
External codes 1-5 (inbound transactions) External codes 1-5 (outbound transactions) Code Conversion Category
Direction
Code Conversion
10-13
Code Conversion
Keys 1-5
Data found on the base application document or derived by the Oracle e-Commerce Gateway. This data will be written to the transaction interface file. Data found on the transaction interface file or derived by the Oracle e-Commerce Gateway. This data is used to derive the Oracle internal code for the application open interface table. Data found in the code conversion table given the internal code then written to the transaction interface file.
External codes 1-5 (inbound transactions) External codes 1-5 (outbound transactions)
Full Search Key Components
Code Conversion
Direction
Keys 1-5
Code Conversion
10-15
Code Conversion
Direction
Keys 1-5
Code Conversion
The transaction Direction field in the code conversion tables allows table entries to be entered with duplicate internal codes or duplicate external codes depending on the value of the Direction code.
The code conversion value table has a data element called direction meaning transaction direction. The transaction direction determines if the table entry is accessed during the code conversion process. Direction is in the table to allow additional flexibility to code conversion values and eliminate repeating entries for multiple Trading Partners as search keys.
For inbound transactions, duplicate external codes can be entered in the table, which converts to the same internal code. For outbound transactions, duplicate internal codes can be entered in the table as long as the 1-5 external codes are unique. If the Direction is BOTH, the entire search key including the internal and external codes are unique. The Define Code Conversion Values window does not allow you to create duplicate table entries even across entries using the other directions: IN, OUT, and BOTH. You may need to remove an entry for another direction in order to accommodate a table entry that uses direction BOTH. Transaction direction is discussed further after we understand how the code conversion value table is read in general for inbound and outbound transactions as illustrated in the following two tables. Full Search Key for Outbound Transaction: Goal: Create a key including the known internal code from the Oracle application to find all the external codes so they may be written to the transaction interface file. Keys 1-5 are optional. Keys are used when the table entry does not apply to all Trading Partners.
Outbound Transaction: Entire Search Key Category Direction Keys 1 thru 5 UOM UOM OUT OUT Internal Code Each Box
Retrieved Data for the Transaction Interface File External Code 1 EA BX External Code 2 PC BX External Code 3 External Code 4 External Code 5
Outbound Transactions Full Search Key
Code Conversion
10-17
Code Conversion
Full Search Key for Inbound Transaction: Goal: Create a key including the known 1-5 external codes on the transaction interface file to find the internal code that is needed for the base Oracle application open interface table. Keys 1-5 are optional. Keys are used when the table entry does not apply to all Trading Partners.
Retrieved Data to write to the Application Open Inbound Transaction: Entire Search Key Category Direction Keys 1 thru 5 UOM UOM IN IN Externa l Code 1 EA PC Externa l Code 2 Each Each External Code 3 External Code 4 External Code 5 Interface Tables Internal Code
Inbound Transactions Full Search Key
Understanding Code Conversion for Outbound Transaction using Direction OUT For outbound transactions, the entire search key to access the table entries consists of the following.
s
Category Direction Keys 1-5 Internal Code
This full search key is used to find a table entry to return the external codes 1-5 that can be copied to the transaction interface files. During code conversion for outbound transactions, code conversion table entries marked with the direction OUT and BOTH are read. See section below on the direction BOTH. Entering the direction OUT allows you to enter the entire search key for outbound transactions, yet allow duplicate data to be entered for the external codes 1-5.
Code Conversion
If code conversion is enabled and a table entry is not found, then internal code is also copied to the external 1 data element to be written on the transaction interface file. The following tables have illustrations using only 2 of the 5 allowable keys and 2 of the 5 external codes for simplicity. Use as many keys and external codes, as necessary for your business needs. Though the illustrations have separate samples by the direction (IN, OUT, BOTH), all the table entries reside in one table.
Outbound Transaction: Entire Search Key (Must be Unique) * Directio n OUT OUT OUT OUT OUT OUT OUT OUT OUT OUT OUT EDIFACT X12 1004 1004 1004 2010 2010 1005 1005 1110 1110 Retrieved Data for the Transaction Interface File External Code 1 EA EA PC EA TRUCK TRUCK TRUCK ALPHA ALPHA BETA BETA A J J A J A J External Code 2 PC PC
note (1) (1) (2) (2) (3) (3) (3) (3) (3) (1)(4) (1)(4)
Category UOM UOM UOM UOM SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA
Key 1
Key 2
Internal Code Each Box Each Each Truck-air Truck-motor Truck-air/motor Alpha-air Alpha-ground Beta-Overnight Beta-Ground
Used to retrieve external 1-5 given the entire search key. Outbound Transactions Code Conversion
NOTES:
1.
Since keys 1-5 are blank, these table entries may be retrieved for all data elements assigned code category UOM for inbound transactions whose internal codes are listed above. You may use external 1 for the X12 codes and external 2 for the EDIFACT codes. External 3-5 may contain alternative codes for one of those standards or other standards. Given the Trading Partner, the translation data map will choose the desired internal and external data elements to use.
Code Conversion
10-19
Code Conversion
Since key 1 has the Document Standard Code, only Trading Partners given the specific Document Standard Code showing in key 1 will access those records. The default Document Standard Code is assigned to a Trading Partner's transaction via the Detail tab in the Define Trading Partner .
2.
Since keys 1-2 are entered in the code conversion table, those table entries are found only when the transaction has the values found in key 1 and 2. What data elements are represented by keys 1-5 are specified in the Assign Code Conversion Categories window, for example, they may be customer number and customer site number. Select your column values based on the data elements that are available to you in that transaction. In the illustration, the customer number and customer site numbers were available in the transaction so they could be used in the code conversion value tables.
3.
Since keys 1-5 are blank and the (3) table entries did not apply, all code conversion enabled data elements will find the (4) table entries given the external codes as part of the key. Not finding a value in the code conversion table is not an error. There may be cases where only select values for a data element need code conversion. To require all values to have a code conversion table entry may cause you to do an excessive number of code conversion entries that are not necessary or desired.
Understanding Code Conversion for Inbound Transactions using Direction IN For inbound transactions, the entire search key to access the table consists of the following.
s
Category Direction Keys 1-5 External Codes 1-5
This full search key is used to find a table entry for the internal code that can be copied to the base Oracle Applications open interface table. During code conversion for inbound transactions, code conversion table entries marked with the direction IN and BOTH are read. See section below on the direction BOTH. Code conversion table entries, which are given the direction IN, are accessed during code conversion for inbound transactions only.
Code Conversion
Entering the direction IN allows you to enter the entire search key for inbound transactions, yet allow duplicate data to be entered for the Internal codes.
s
Inbound Transaction: Entire Search Key (Must be unique) * Retrieved Data for the Application Open Interface Tables
Code Conversion
10-21
Code Conversion
Note (1) (1) (2) (2) (2) (3) (3) (3) (3) (3) (1)(4) (1)(4)
Category UOM UOM UOM UOM UOM
Direction IN IN IN IN IN
Key 1
External Key 2 Code 1 EA PC
External Code 2 Internal Code Each Each Each Each Each A J J A J A J Truck-air Truck-motor Truck-air/motor Alpha-air Alpha-ground Beta-Overnight Beta-Ground
EDIFACT X12 X12 1004 1004 1004 2010 2010 1005 1005 1110 1110
PC PC EA TRUCK TRUCK TRUCK ALPHA ALPHA BETA BETA
SHIP_VIA IN SHIP_VIA IN SHIP_VIA IN SHIP_VIA IN SHIP_VIA IN SHIP_VIA IN SHIP_VIA IN
* Used to retrieve the internal code given the entire search key. Inbound Transactions Code Conversion
Notes:
1.
Since keys 1-5 are blank, these table entries may be retrieved for all data elements looking for code category UOM for inbound transactions whose external codes 1-2 are listed above. The external 1 may be a mixture of EDI standard codes expected from the transaction. For example, the EA may be the expected X12 code, while the PC may be the expected EDIFACT code. Since key 1 has the document standard code, only Trading Partners given the specific document standard showing in key 1 will access those records. The default document standard, which is used for this code conversion value table, is assigned to a Trading Partners transaction via the Detail tab in the Define Trading Partner window. Remember that the Document Standard Code applies to the entire transaction for the Trading Partner. It does not change per data element. Since keys 1-2 are entered in the code conversion table, these entries apply only to the entities whose values are entered in keys 1-2.
2.
3.
Code Conversion
4.
Since keys 1-5 are blank and the (3) table entries did not apply, all code conversion enabled data elements will find the (4) table entries given the external codes as part of the key. If code conversion is enabled and a table entry is not found, the external 1 code is written to the application open interface tables. They may fail data validation when the application open interface is executed if not entered properly in the code conversion tables. The data should be visible for the applications regular error handling procedures.
Understanding Code Conversion for Inbound and Outbound Transactions using Direction BOTH Table entries, that are given the direction BOTH, are accessed during code conversion for both inbound and outbound transactions. All the rules specified above for inbound and outbound transactions apply to the entries with direction BOTH. Usually you should be able to enter the direction BOTH for most table entries, if there is a one-to-one correspondence between the Oracle internal code and its set of external 1-5 codes. For an outbound transaction, the shaded table entries in Table 4 cannot be entered into the tables. This is because the single internal code Each would access multiple table entries for the external codes, one with the external code EA and the other with the external code PC. To be a successful table search, only one table entry can be found. An error message is displayed when the entry is attempted. Even creating table entries using the document standard in key 1 may still cause a conflict within a standard. For example, this may happen when EA and PC may be values both within X12 and within EDIFACT. If separating the codes by standards still has this problem, you can select document standard Other for the exceptions and assign Other to those Trading Partners to retrieve the properly code for their transactions.
Code Conversion
10-23
Code Conversion
Direction BOTH for Inbound and Outbound Transactions:
External codes are part of the key for inbound transactions to find the Internal code. External 1 EA PC External 2
Internal codes are part of the key for outbound transactions to find the external 1-5 codes. Internal Each Each * Each Each Each *
note (1) (2) (1) (1) (2) (1) (1) (1) (1) (1) (1) (1)
Category UOM UOM UOM UOM UOM SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA
Direction BOTH BOTH BOTH BOTH BOTH BOTH BOTH BOTH BOTH BOTH BOTH BOTH
Key 1
Key 2
EDIFACT X12 X12 1004 1004 1004 2010 2010 1005 1005 1110 1110
PC EA PC TRUCK TRUCK TRUCK ALPHA ALPHA BETA BETA A J J A J A J
Truck-air Truck-motor Truck-air/moto r Alpha-air Alpha-ground Beta-Overnight Beta-Ground
* There would not be a unique search key for outbound transaction if the table entry were allowed. An alternate code conversion scheme must be chosen. Inbound and Outbound Transactions Code Conversion
Notes:
1. 2.
(1) Simple table entry exists. (2) Items marked (2) will not be allowed as table entries since the full search key for outbound transactions will not be unique.
Document Standard as Part of the Search Key Document standard is a code to represent the common EDI standards such as X12 and EDIFACT. Its purpose is to use the selected code as a search key in the code conversion value table.
Code Conversion
The document standard may be set for a Trading Partner for a specific transaction in the Define Trading Partner Detail tab. Follow the usual code conversion set up through the three code conversion windows.
Outbound Transaction: Entire Search Key note Category Direction Key 1 Key 2 Internal Code Each X12 X12 EDIFACT EDIFACT Each Piece Each Piece External Codes External Code 1 EA EA PC EA PC External Code 2 PC
(1) (2) (2) (2) (2)
UOM UOM UOM UOM UOM
OUT BOTH BOTH BOTH BOTH
Document Standards in the Search Key
1.
(1) Assume that you entered X12 codes in external code 1 and EDIFACT in external code 2. This method allows you to enter just one table entry to have the internal code set to Each then return the external codes EA and PC for outbound transactions. This entry cannot be used for inbound transactions, since only the X12 or only the EDIFACT code is in the transaction or message, but not both codes in a given transaction. You need a separate set up for the inbound transactions.
2.
(2) Enter separate table entries by document standard if it is an alternate method for (1). Since key 1 is the document standard, only the table entries with key 1 set to one of the standards (X12, EDIFACT, etc.) are retrieved for a given Trading Partner if they are assigned a document standard for that transaction. If a Trading Partners transaction is not given a document standard, then the entry (1) will be read for the outbound transactions.
Planning the Use of Direction in Code Conversion

Review your code conversion needs and develop a plan for your code conversion value table entries. The values that you enter in the table are case sensitive.
Code Conversion
10-25
Code Conversion
Not all scenarios of code conversion table entries can be documented. This information illustrates how the code conversion value table is accessed. Use it to develop your code conversion strategy. The following tables provide some considerations to help you develop that strategy. Planning for Direction OUT for Outbound Transactions
Outbound Transaction: Entire Search Key (Must be Unique) * Retrieved Data for the Transaction Interface File
Category (1) (2) UOM UOM
Direction OUT OUT
Key 1
Key 2
Internal Code Each Each
External Code 1 EA PC
External Code 2 PC EA Entire Search Key is duplicate to (1)
(3) (4)
UOM UOM
OUT OUT
EDIFACT X12
Each Each
PC EA
All Entries Not Feasible for Direction OUT
In table 9 items (1) (2): Internal code is part of the entire search key. For direction OUT, both these entries (1) and (2) are not feasible, because the entire search key is not unique. One entry can be made where you define the external 1 code to have X12 and external 2 code to have EDIFACT. Your EDI translator data map will determine which field to use for the Trading Partner. If needed alternative entries may be where external 1 and 2 may both have X12 codes and external 3 and 4 may both have EDIFACT codes since each standard has multiple codes meaning each to the Oracle application. Again you will rely on the EDI translator data map to choose the correct external field for the transaction. In table 9 items (3) (4): If a document standard is entered for the Trading Partner (in the Trading Partner Detail tab) and the a data element is assigned the column DOCUMENT_STANDARD (in the Code Conversion Assignment tab), these table entries will be accessed in the code conversion process before the global entries (1) are accessed.
Code Conversion
Planning for Direction IN for Inbound Transactions

Retrieved Data for the Application Open Inbound Transaction: Entire Search Key (Must be unique) * External Category (1) (1) (2) (2) (2) (2) UOM UOM UOM UOM UOM UOM Direction IN IN IN IN IN IN EDIFACT EDIFACT X12 X12 Key 1 Key 2 Code 1 EA PC EA PC EA PC Interface Tables External Internal Code 2 Code Each Each Each Each Each Each
* For direction IN, the external code is part of the entire search key. All Entries are Feasible for Direction IN
In table 10: External codes are part of the entire search key. For direction IN, all the entries in table 10 even without the document standard are feasible, because the entire search key is unique. It does not matter what the internal codes are since they are not part of the entire search key. In table 10, items (2): If a document standard is entered for the Trading Partner (in the Trading Partner Detail tab) and the a data element is assigned the column DOCUMENT_STANDARD (in the Code Conversion Assignment tab), these table entries will be accessed in the code conversion process before the entries (1) are accessed by all Trading Partners.
Code Conversion
10-27
Code Conversion
Planning for Direction BOTH for Inbound and Outbound Transactions

Part Key for Part Key for Inbound Outbound
Direction BOTH for Inbound and Outbound Transaction:
External Category Direction UOM UOM UOM UOM UOM UOM BOTH BOTH BOTH BOTH BOTH BOTH X12 X12 EDIFACT EDIFACT Key 1 Key 2 Code 1 EA PC EA PC EA PC
External Code 2 Internal Each Each Each Each Each Each
All Entries Not Feasible for Direction BOTH
Though you may wish to use the data in the code conversion value for both inbound and outbound transactions, the entry in (2) will not be accepted into the code conversion value table after (1) is entered. The reason that entries (1) and (2) are not feasible at the same time is that outbound transactions are using the Internal codes as part of the entire search key. When the value Each is found in the transaction, (even if the Trading Partner was given a default standard to use for code conversion), the internal code Each cannot determine whether EA or PC should be written to the transaction interface file. Similar reasoning applies to (3)/(4), and (5)/(6) when items (4) and (6) are attempted to be entered. Multiple Standard Codes Convert to a Single Internal Code There may be code conversion entries needed where multiple codes in a single standard may need to be converted to a single code in the Oracle application. The following table illustrates this case.
Code Conversion
Outbound Transaction: Entire Search Key (Must be Unique) Key 2 Acm e Internal Code Each
Retrieved Data for the Transaction Interface File External Code 1 EA External Code 2 Trading Partner site specified will have EA on the file. * Trading Partner site specified will have BX on the file. * Trading Partner site specified will have PC on the file. * Majority of Trading Partners want EA. They were assigned the Document Standard X12. Other Trading Partners want PC. They were assigned the Document Standard OTHER to allow this entry in the table.
Category Direction (1) UOM OUT
Key 1 X12
Key 3 Denver
(2)
UOM
OUT
X12
Acm e
Chicag o
Each
BX
(3)
UOM
OUT
X12
Acm e
Each
PC
(4)
UOM
OUT
X12
Each
EA
(5)
UOM
OUT
OTHE R
Each
PC
Code Conversion
10-29
Code Conversion
(6)
UOM
OUT
Each
EA
PC
Default: write two codes to the file; EDI translator will choose one based on the data mapping rule for the given Trading Partner. This avoids making entries for each Trading Partner needing the PC on the file.
Multiple Codes within a Standard converting to the Same Internal Code
In table 12, items (1)-(5): The exact code for the data map is in external code 1 on the file given the Trading Partner data in the search key. You chose not to have the translator choose between EA or PC by accessing item (5). Items (1) through (3) is Trading Partner specific. If there are many Trading Partners needing separate entries, it may be desirable to assign another document standard to group set of Trading Partners though it is not really their true document standard. Recall that Document Standard Code exist to facilitate the code conversion table entries. If you choose the strategy in table 13, you need a set of code conversion value codes with the direction IN for inbound transactions since direction BOTH could not be used because of duplicate internal codes.
Retrieved Data for the Application Open Interface Tables External Category (1) (2) (3) (4) UOM UOM UOM UOM Direction IN IN IN IN X12 X12 Key 1 Key 2 Code 1 EA PC EA PC External Code 2 Internal Code Each Each Each Each
Inbound Transaction: Entire Search Key (Must be unique)
* For direction IN, the External code is part of the entire search key.
Code Conversion
Multiple Codes within a Standard converting to the Same External Code
In table 13, there is no need for table entries with OTHER in search key 1. For the inbound transactions, the actual document standard X12 suffices since the external codes are unique.
Both Internal Code and External Codes on the Transaction Interface File
You could set up Column Rules on the internal column in the transaction though the internal value is not found on the transaction interface file. This may occur when the Application Open Interface file may require a value in certain columns, but the values are derived by the Oracle e-Commerce Gateway. This assumes that code conversion is performed on the data element using the internal and external values on the files that are associated with that data element. Code conversion is performed before any column rule validation is performed on a column (data element) defined in the transaction. The code conversion process associates (in memory) the internal code found in the code conversion table to the internal field that has the assigned the Column Rule. The value of that internal field is validated against all the Column Rules enabled for that field. Code Conversion is performed before Column Rules are applied. Consider the following to satisfy the data requirement if code conversion is performed on a field.
Oracle e-Commerce Gateway Columns Sample Record Number Sample Position Number
Application Open Interface Column
Code Conversion Performed
No Code Conversion Performed
Code Conversion
10-31
Code Conversion
UOM_CODE (Some value must be moved here by one of the following methods: Determined in the Oracle e-Commerce Gateway through code conversion Directly from the file if it is present.)
UOM_CODE_INT (If data is in this field on the file, code conversion is not performed. In this case, the value is moved directly into the Application Open Interface tables.)
2010
100
The Internal code is derived in code conversion given the codes in the External 1-5 fields . The internal code is moved to the Open Interface Table if found during code conversion. if no code conversion value is found, external 1 is copied to the Application open Interface Table. Note that the derived Internal value is not written to the inbound file.
If placed in the UOM_CODE_ INT field by a translator and there is no code conversion performed, this value is copied to the Application Open Interface Table.
UOM_CODE_ EXT1
2010
110
Place on the file by a translator to be used for code conversion.
If data is placed in the External codes by a translator and there is no code conversion performed, this code is copied to the Application Open Interface Table.
UOM_CODE_ EXT2 UOM_CODE_ EXT3 UOM_CODE_ EXT4 UOM_CODE_ EXT5
not not not not
activate d activate d activate d activate d
Use as part of code conversion if properly enabled
Activated External Data Fields on the Transaction Interface File

Though there may be data in all five external codes in the code conversion tables, the only external codes to actually be copied to the transaction interface file are the ones that are activated for the file. They are activated if the data element shows a
Code Conversion
record number, position and width on the data element in the Interface File Definition window or the Transaction Layout Definition report. If data elements are not activated but you wish to use them in the transaction interface file, activate them by entering a record number, position, and width using the Interface File Definition window. For outbound transactions, both the internal code and external codes are written to the transaction interface file. They are available on the file for mapping to the EDI standard transaction by an EDI translator. For inbound transactions, the external codes are expected in the file for code conversion or to be passed directly to the application open interface table if an internal code is not derived by code conversion. If another process determines the internal code and writes it to the transaction interface file, that internal code is passed to the application open interface table. Note: Code conversion is not performed on the data element by the Oracle e-Commerce Gateway if data is already found in the internal field for that data element. Concatenated Search Key for Inbound Transactions The following example illustrates the use of the concatenated search key in several attempts to find code conversion table entries for an inbound transaction. The Oracle e-Commerce Gateway moves data from the transaction interface file into its transaction tables for processing. The data may come directly in the transaction from your Trading Partner or be derived by the Oracle e-Commerce Gateway. Some date elements need code conversion on 1-5 external codes to the internal code defined in the base Oracle application. The external codes are defined by Trading Partners or standard transactions. You may activate code conversion only on the data elements (columns) listed in the Assign Categories window. By entering search keys, the table entry does not apply to all Trading Partners. Trading Partner codes and Trading Partner site codes are often search keys in the code conversion value tables since Trading Partners often have site specific codes. This example steps through a code conversion table searching for a table entry where the value AIR in the CARRIER_EXT1 (external 1) column along with its search keys with the value GAMMA in CUSTOMER_NAME in Key 1 and value 9999 in CUSTOMER_SITE in Key 2 are in the transaction. The intent is to find the corresponding internal code given the 1-5 external CARRIER_EXT1 through CARRIER_EXT5 codes so they may be written to Oracle application open interface tables.
Code Conversion
10-33
Code Conversion
The code conversion value table is read with the following parameters and conditions:
s
Access code conversion values table entries with the SHIP_VIA Category, since SHIP_VIA was assigned to the CARRIER_INT column via the Assign Code Conversion window. The Oracle e-Commerce Gateway moves the transaction values GAMMA into the CUSTOMER NAME column, and the value 9999 into the CUSTOMER_SITE column, which are the column names for the search keys. In this sample, only Key 1 and Key 2 were enabled for the customer name and customer site respectively. (The Oracle e-Commerce Gateway derived the customer name given the customer site 9999 in the transaction.) The external code is part of the full search key for inbound transactions. Since this is an inbound transaction, the process accesses table entries only with transaction direction IN and BOTH.
Code Conversion Set Ups

The following code conversion table setups were done for this example. The Code Conversion Categories window has two of the potential five search keys enabled for Category SHIP_VIA to accommodate the customer name and customer site search keys in the other code conversion windows. The Assign Code Conversion window enables code conversion on a column and specifies which columns to examine for the actual search key values. You decide which columns are used as the Key1 through Key5. The following were set up for this transaction: Column is CARRIER_INT. The Category SHIP_VIA is assigned to CARRIER_INT to enable code conversion. Key 1 is assigned the CUSTOMER_NAME column in the transaction table. Key 2 is assigned the CUSTOMER_SITE column in the transaction table. You selected the keys from a list of values. The full search key to access the code conversion value table for inbound transactions include the code category, direction, Key 1, Key 2, and the 1-5 external code. For example, the first entry in the table includes the following search key values: (See table 8 for all entries.) Key 1 has value ALPHA for the CUSTOMER_NAME.
Code Conversion
Key 2 has value 1006 for the CUSTOMER_SITE. The Code Conversion Value window includes the search key values applicable to the internal and external codes for all the Trading Partners and all transactions. The Category that you assign to a column limits the access to just those table entries that have been assigned that Category.
Creating the Search Key

Table 5 has data found in the transaction or derived by the Oracle e-Commerce Gateway. The data was moved to the transaction columns in the Oracle e-Commerce Gateway for processing.
Data Description Transaction Data Transaction Column
Specific Transaction Data
Data Customer Site 9999 CUSTOMER_SITE
Transaction Data Carrier Code AIR CARRIER_EXT1
Customer GAMMA CUSTOMER_NAME
Table 6 has the full search key parameters given the data found in the transaction or data derived by the Oracle e-Commerce Gateway. Use the data in these columns to find a code conversion value table entry to retrieve the external code.
Code Conversion
10-35
Code Conversion
Code Category SHIP_VIA This code category was assigned to a data element in the transaction via the Assign Category window.
Key 1 Direction IN and BOTH Determined by the inbound transaction to be processed. (Customer) GAMMA Source Column for this key 1 is: CUSTOMER_ NAME. The value GAMMA was derived by the Oracle e-Commerce Gateway given the Trading Partner for this transaction.
Key 2 (Customer Site) 9999 Source Column for this key 2 is: CUSTOMER_ SITE The value 9999 was derived by the Oracle e-Commerce Gateway given the Trading Partner site for this transaction.
Key 3
Key 4
Key 5
External 1 Code AIR
not used
not used
not used
AIR is the value in CARRIER_ EXT1in the transaction interface file.
All Search Key Parameters given the data in the Transaction Table 7 shows the three set of full search keys to access the code conversion value table for the three attempts to read the table. The number of attempts is always one more than the number of Key boxes that you enabled in the Code Conversion Categories window.
Code Category SHIP_ VIA SHIP_ VIA SHIP_ VIA Direction OUT BOTH OUT CUSTOMER_ NAME CUSTOMER_SITE Key 1 (Customer) GAMMA GAMMA Key 2 (Customer Site) 9999 Key 3 Key 4 Key 5 External 1 Code AIR AIR AIR
Search Order First Search Second Search Third Search Source Column
Code Conversion Search Key Algorithm
Code Conversion
Searching the Code Conversion Value Table

The code conversion value table is read using the search keys in table 7. Three accesses to the code conversion value table may be attempted. The order of the search and the constructed keys are shown in table 7. In table 7, the first search has the full key including the external 1 code AIR. Since there was no table entry for CUSTOMER_NAME with value GAMMA and CUSTOMER_SITE with value 9999, the highest order key is removed for the second search attempt. In this case, the customer site 9999 was removed from the search key parameters. KEY2 with CUSTOMER_SITE was the highest number search key at this time. The second search with just CUSTOMER_NAME with value GAMMA and the external 1 code AIR also did not find a table entry. So the current highest order key is removed for the next search attempt. In this case, the customer GAMMA was removed from the search key parameter. KEY1 with CUSTOMER_NAME was the highest number search key at this time. The third search is made with all blank search keys. The internal code is code AIR. This search found a table entry. It is shown in table 8 entry 7. Consequently, the internal value Over Night from the code conversion value table is copied to CARRIER_INT column in the transaction table. If no table entry is found, then the CARRIER_EXT1 (external 1) value is moved into the column CARRIER_INT field in the transaction table. Over Night is the valid value for the Oracle Application open interface.
Code Conversion
10-37
Code Conversion
Table Entry
Code Category
Key Direction 1 Customer
Key 2 Customer Site 1006 1099
Key 3-5
External 1 Code
Internal Code
1 2 3 4 5 6 7* Source Column
SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA
IN IN IN IN IN IN IN
ALPHA ALPHA ALPHA BETA BETA BETA
Alpha-Air Alpha-Air Alpha-Air
Alpha-Air Alpha-Fast Alpha-Quick Beta-Travel Beta-Faster Beta-Quicker Over Night
1099 1100
Beta-Air Beta-Air Beta-Air AIR
CUSTOMER_ CUSTOMER_ NAME SITE
Sample Code Conversion Table
Concatenated Search Key for Outbound Transactions

The following example illustrates the use of the concatenated search key in several attempts to find code conversion table entries for an outbound transaction. The Oracle e-Commerce Gateway extracts data from Oracle Application tables and optional extension tables then ultimately writes the data to the transaction interface file. Some date elements need code conversion from the internal code defined in the base Oracle application to external codes that are required by the Trading Partners or standard transactions. You may activate code conversion only on the data elements (columns) listed in the Assign Categories window. By entering search keys, the table entry does not apply to all Trading Partners. Trading Partner codes and Trading Partner site codes are often search keys in the code conversion value tables since Trading Partners often have site specific codes. This example steps through a code conversion table searching for a table entry where the value Over Night in the CARRIER_INT (internal) column along with its search keys with the value GAMMA in CUSTOMER_NAME in Key 1 and value 9999 in CUSTOMER_SITE in Key 2 are set up for the transaction. The intent is to find its corresponding 1-5 external CARRIER_EXT1 through CARRIER_EXT5 codes so they may be written to the transaction interface file. The code conversion value table is read with the following parameters and conditions. It is used to derive the 1-5 external codes desired for the transaction interface file.
s
Access code conversion values table entries with the SHIP_VIA Category, since SHIP_VIA was assigned to the CARRIER_INT column via the Assign Code Conversion window. The Oracle e-Commerce Gateway moves the transaction values GAMMA into the CUSTOMER NAME column, and the value 9999 into the CUSTOMER_SITE column, which are the column names for the search keys. In this sample, only Key 1 and Key 2 were enabled for the customer name and customer site respectively. (The Oracle e-Commerce Gateway derived the customer name given the customer site 9999 in the transaction.) The internal code is part of the full search key for outbound transactions. Over Night is moved into the CARRIER_INT (internal field) on the transaction interface file. Any one of the CARRIER_EXT1 through CARRIER_EXT5 external codes is written to the transaction interface file if a record number, record position, and field length are assigned to the particular field.
Code Conversion
10-39
Since this is an outbound transaction, the process accesses table entries only with transaction direction OUT and BOTH.
Code Conversion Set Ups

The following code conversion table setups were done for this example. The Code Conversion Categories window has two of the potential five search keys enabled for Category SHIP_VIA to accommodate the customer name and customer site search keys in the other code conversion windows. The Assign Code Conversion window enables code conversion on a column and specifies which columns to examine for the actual search key values. You decide which columns are used as the Key1 through Key5. The following were set up for this transaction: Column is CARRIER_INT. The Category SHIP_VIA is assigned to CARRIER_INT to enable code conversion. Key 1 is assigned the CUSTOMER_NAME column in the transaction table. Key 2 is assigned the CUSTOMER_SITE column in the transaction table. You selected the keys from a list of values. The full search key to access the code conversion value table for outbound transactions include the code category, direction, Key 1, Key 2, and the internal code. For example, the first entry in the table includes the following search key values: (See table 11 for all entries.) Key 1 has value ALPHA for the CUSTOMER_NAME. Key 2 has value 1006 for the CUSTOMER_SITE. The Code Conversion Value window includes the search key values applicable to the internal and external codes for all the Trading Partners and all transactions. The Category that you assign to a column limits the access to just those table entries that have been assigned that Category.
Creating the Search Key

Table 8 has data found in the transaction or derived by the Oracle e-Commerce Gateway. The data was moved to the transaction columns in the Oracle e-Commerce Gateway process.
Data Description Transaction Data Transaction Column

Specific Transaction Data
Data Customer Site 9999 CUSTOMER_SITE
Transaction Data Carrier Code Over Night CARRIER_INT
Customer GAMMA CUSTOMER_NAME
Table 9 has the full search key parameters given the data found in the transaction or data derived by the Oracle e-Commerce Gateway. Use the data in these columns to find a code conversion value table entry to retrieve the internal code.
Key 1 Direction OUT and BOTH Determined by the inbound transaction to be processed. (Customer) GAMMA Source Column for this key 1 is: CUSTOMER_ NAME. The value GAMMA was derived by the Oracle e-Commerce Gateway given the Trading Partner for this transaction. Key 2 (Customer Site) 9999 Source Column for this key 2 is: CUSTOMER_ SITE The value 9999 was derived by the Oracle e-Commerce Gateway given the Trading Partner site for this transaction. not used not used not used Key 3 Key 4 Key 5 Internal Code Over Night Over Night was the value in CARRIER_ INT from the base Oracle Application.
Code Category SHIP_VIA This code category was assigned to a data element in the transaction via the Assign Category window.
All Search Key Parameters given the data in the Transaction Table 10 shows the three sets of full search keys to access the code conversion value table for the three attempts to read the table. The number of attempts is always one more than the number of Key boxes that you enabled in the Code Conversion Categories window.
Code Conversion
10-41
Search Order First Search Second Search Third Search Source Column
Code Category SHIP_ VIA SHIP_ VIA SHIP_ VIA Direction OUT BOTH OUT
Key 1 (Customer) GAMMA GAMMA
Key 2 (Customer Site) 9999
Key 3
Key 4
Key 5
Internal Code Over Night Over Night Over Night
CUSTOMER_ NAME
CUSTOMER_SITE
Code Conversion Search Key Algorithm
Searching the Code Conversion Value Table

The code conversion value table is read using the search keys in table 10. Three accesses to the code conversion value table may be attempted. The order of the search and the constructed keys are shown in table 10.
1.
In table 10, the first search has the full key including the internal code Over Night. Since there was no table entry for CUSTOMER_NAME with value GAMMA and CUSTOMER_SITE with value 9999, the highest order key is removed for the second search attempt. In this case, the customer site 9999 was removed from the search key parameters. KEY2 with CUSTOMER_SITE was the highest number search key at this time. The second search with just CUSTOMER_NAME with value GAMMA and the internal code Over Night also did not find a table entry. So the current highest order key is removed for the next search attempt. In this case, the customer GAMMA was removed from the search key parameter. KEY1 with CUSTOMER_NAME was the highest number search key at this time. The third search is made with all blank search keys. The internal code is code Over Night. This search found a table entry. It is shown in table 11 entry 7. Consequently, the External-1 value AIR from the code conversion value table is copied to CARRIER_EXT1 column in the transaction table. If no table entry is found, then the CARRIER_INT value is copied to the CARRIER_EXT1 column in the transaction table. Ultimately, the data in CARRIER_INT and CARRIER_ EXT1 appears in the transaction interface file, if they are assigned a record
2.
3.
number, record position, and length respectively. These record assignments are displayed in the Transaction Interface Definition window.
Key Direction 1 Customer 1 2 3 4 5 6 7* Source Column
Sample Code Conversion Table
Table Entry
Code Category
Key 2 Customer Site 1006 1099
Key 3-5
Internal Code
External 1 Code
SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA SHIP_VIA
IN IN IN IN IN IN IN
ALPHA ALPHA ALPHA BETA BETA BETA
Alpha-Air Alpha-Fast Alpha-Quic k
Alpha-Air Alpha-Air Alpha-Air Beta-Air Beta-Air Beta-Air AIR
1099 1100
Beta-Travel Beta-Faster Beta-Quicke r Over Night
CUSTOMER _NAME
CUSTOMER_ SITE
Code Conversion
10-43
11
This chapter contains the following information about Oracle e-Commerce Gateway implementation: Customizing EDI Transactions on page 11-2 Descriptive Flexfields on page 11-4 Steps for Extensible Architecture on page 11-8
Extensible Architecture 11-1
Customizing EDI Transactions

The Oracle e-Commerce Gateway provides two methods to add data elements to transactions that are not defined in the Oracle Applications data model. The two methods are: Descriptive Flexfields Extensible Architecture Either method may be used separately or both methods may be used to customize a specific transaction to meet the business needs. Descriptive flexfields may be used for both inbound and outbound transactions, while the Extensible Architecture feature applies only to outbound transactions. The following transactions use the Extensible Architecture described below. Refer the Oracle Supports web site for documentation for the other outbound transactions using another method of Extensible Architecture, which does not use transaction-specific ECE_ tables.
11-2
Table 2:
Transaction Code ASC X12 EDIFACT Description
Oracle Payables Transactions PYO 820 PAYORD/ REMADV Oracle Receivables Transactions INO 810 INVOIC Invoice Payment/Remittance Advice
Oracle Purchasing Transactions POO POCO 850 860 ORDERS ORDCHG Purchase Orders Purchase Order Changes
Oracle Process Manufacturing Transactions Oracle Supplier Scheduling Transactions SPSO SSSO 830 862 DELFOR DELJIT Planning Schedule Shipping Schedule
Oracle Receivables and Purchasing ADVO 824 APERAK Application Advice (This is a response transaction to tell the transaction originator that there were problems.)
Transactions using the Described Extensible Architecture.
Descriptive Flexfields
The Descriptive Flexfields feature of the Oracle Applications provides a flexible method for adding implementation-specific data elements to any of the applications without programming. These data elements are stored in the ATTRIBUTE* columns in the base applications tables. All of the ATTRIBUTE* columns associated with the relevant application base tables for a specific transaction are included in the Oracle e-Commerce Gateway interface tables for outbound transactions and in the Application open interface tables for inbound transactions. Like all Application base tables, the Oracle e-Commerce Gateway table ECE_TP_ HEADERS and ECE_TP_DETAILS contains ATTRIBUTE* columns. The ATTRIBUTE* columns in ECE_TP_HEADERS and ECE_TP_DETAILS may be used to include additional Trading Partner-specific data in the interface file given the trading partner definition used with the transaction. Use of the Descriptive Flexfields feature in the Oracle Applications requires no additional setup for inclusion in Oracle e-Commerce Gateway transactions. Once the desired flexfields are set up and defined in the Applications, any data stored in them is automatically included in the relevant Oracle e-Commerce Gateway transaction. Reference the Oracle Application Flexfields Guide for details.
The Extensible Architecture feature of the Oracle e-Commerce Gateway provides a powerful and flexible method to include additional data for outbound transactions. While most business needs for additional data can be accommodated by the use of the Descriptive Flexfields feature in the Oracle Applications, the Extensible Architecture feature is useful when: More data elements are required than are allowed by the use of Descriptive Flexfields Data elements need to be extracted from custom Oracle application tables Data elements need to be extracted from outside the Oracle Applications Each outbound transaction in the Oracle e-Commerce Gateway contains a series of interface tables to hold the data that is extracted and denormalized from the relevant Oracle application base tables before being written to the outbound interface file. Every interface table in the Oracle e-Commerce Gateway also has an associated extension table, which may be customized to fit the business needs. Each record in
11-4
an interface table is linked to the corresponding record in the associated extension table. Consequently, when the interface table record is written to the outbound transaction interface file, the corresponding extension table record is written as well.
Oracle e-Commerce Gateway Interface and Extension Tables
Oracle Applications Custom Table
ECE_PO_INTERFACE_LINES * * o * * * o ... o o ... #* PO Number PO Type Release Number Line Number Line Order Quantity Line UOM Item ID Line Attribute 1 Line Attribute 2 Transaction Record ID o o o o o ... Material Analyst Code Material Analyst Last Name Material Analyst First Name Material Analyst Phone Material Analyst Email
MATERIAL_ANALYST
#* Inventory Item ID ...
ECE_PO_INTERFACE_LINES_X #* o o o o o Transaction Record ID Material Analyst Code Material Analyst Last Name Material Analyst First Name Material Analyst Phone Material Analyst Email
#* * o
Legend Unique ID Reqired Optional
The source data to be copied to the extension tables may come from a standard or custom Oracle database table, an external (non-Oracle) relational database or a file. Collectively call these tables and files external tables or external source data in this chapter. The external table must contain the unique key, which is a data element also found in the Oracle e-Commerce Gateway interface table. If the data is not already in the Oracle e-Commerce Gateway transaction interface table, the code needs customization to add that unique identifier to the interface tables in order to become a key to the records in the external source data.
The following process is performed to bring all the data together into the common interface tables before writing the records to the output file.
1.
The Oracle e-Commerce Gateway extracts and denormalizes all the relevant Oracle base application data (including Trading Partner data) into the transaction-specific interface tables. Any enabled code conversions are performed after the data is extracted from the base application tables but before the data is written to the interface tables. Using a unique identifier from the interface tables as search keys, data elements are selected from the appropriate external source and written to the extension tables. All data elements from both the interface tables and their corresponding extension tables are formatted into 1024-byte (or less) records, sequenced and written to the transaction-common ECE_OUTPUT table. The formatted records in the ECE_OUTPUT table are written in the proper sequence to the output file. The transaction records are deleted from the interface tables, extension tables and the output table.
2. 3.
4.
5. 6.
Using the outbound Purchase Order transaction as an example, the process flow is visualized as follows:
11-6
Oracle EDI Gateway
Oracle Purchasing
ECE_PO_INTERFACE_HEADERS ECE_PO_INTERFACE _HEADERS _X ECE_OUTPUT
EDI Extract Program

ECE_PO_INTERFACE _LINES ECE_ PO_INTERFACE_LINES_X
Other Data Source
Extension Extract Program (Custom)
POO Data Flatfile

ECE_PO_INTERFACE _SHIPMENTS
ECE_ PO_INTERFACE _SHIPMENTS _X
EDI Translator
Steps for Extensible Architecture

The Oracle e-Commerce Gateway uses interface tables, extension tables, packaged procedures and setup tables to create interface data files for outbound EDI transactions. The setup process to use the Extensible Architecture in the Oracle e-Commerce Gateway is a three-step process, as follows:
1.
Define the columns in the extension table. Task: Add the desired new column(s) to the appropriate extension table.
2.
Define data positions in the outbound interface file. Task: For each new column added to the extension table (step 1 above), insert a record into ECE_INTERFACE_COLUMNS to position the data element in the interface file.
3.
Modify procedures to move the external source data to the extension tables. Task: Modify the appropriate procedure in the extension package body to populate the new column(s) with data. Check the Oracle Support web site for updates in these procedures.
Define Columns in the Extension Table Task: Add columns to the appropriate extension table. When the Oracle e-Commerce Gateway is installed, all extension tables are created. There is one extension table for each interface table and each extension table has only column: TRANSACTION_RECORD_ID. This column corresponds to the TRANSACTION_ RECORD_ID column in the associated interface table. It is used to maintain the link between the two tables. Simple SQL DDL statements like the ALTER TABLE command may be used to add columns to the desired extension table. For example, suppose a business assigns a material analyst to each purchased item to determine data like item specifications, tolerances and quality standards. Further suppose that the business has created a custom database table to hold the data about the material analyst, calling it: MATERIAL_ANALYSTS. The business wishes to send contact data from this custom table with each Purchase Order line in the event that the vendor has any item-related questions; specifically, data from the following columns in the custom table: MATERIAL_ANALYST_CODE MATERIAL_ANALYST_LAST_NAME
11-8
MATERIAL_ANALYST_FIRST_NAME MATERIAL_ANALYST_PHONE MATERIAL_ANALYST_EMAIL First, locate the proper extension table in the database. The Oracle e-Commerce Gateway interface table that holds Purchase Order line data is ECE_PO_ INTERFACE_LINES, and the corresponding extension table is ECE_PO_ INTERFACE_LINES_X. As installed, the interface and extension tables may be visualized as follows:
ECE_PO_INTERFACE_LINES * * * ... o o ... #* Line Number Line Order Quantity Line UOM Line Attribute 1 Line Attribute 2 Transaction Record ID
#* * o
Legend Unique ID Reqired Optional
ECE_PO_INTERFACE_LINES_X
#* Transaction Record ID
Determine Table Ownership:

Since database tables may only be altered either by their owner or by a user that has been granted this privilege, it is necessary to determine the owner (or schema) for the extension table. By default, all Oracle e-Commerce Gateway tables are owned by the user EC when the Oracle Applications are installed, while the APPS user is usually created as a privileged account. To verify the owner of the extension table, type the following from any SQL*Plus session:
SQL> select owner from all_tables where table_name = ECE_PO_INTERFACE_LINES_X; OWNER ______ EC 1 row selected
Add Columns to Extension Table:

To add the desired columns to the extension table, log into SQL*Plus either as the owner (in this case, the user EC) or as a privileged user (such as APPS) and type the following:
SQL> alter table EC.ECE_PO_INTERFACE_LINES_X add ( Material_Analyst_Code VARCHAR2(30), Material_Analyst_Last_Name VARCHAR2(40), Material_Analyst_First_Name VARCHAR2(20), Material_Analyst_Phone VARCHAR2(30), Material_Analyst_Email VARCHAR2(30) );
Table altered The new extension table structure can be verified by typing the following:
SQL> describe EC.ECE_PO_INTERFACE_LINES_X; ECE_PO_INTERFACE_LINES_X _________________________________________________________ TRANSACTION_RECORD_ID NOT NULL NUMBER MATERIAL_ANALYST_CODE VARCHAR2(30) MATERIAL_ANALYST_LAST_NAME VARCHAR2(40) MATERIAL_ANALYST_FIRST_NAME VARCHAR2(20) MATERIAL_ANALYST_PHONE VARCHAR2(30) MATERIAL_ANALYST_EMAIL VARCHAR2(30)
The extension table has now been modified to fit the business requirements, and the modifications may be visualized as follows:
ECE_PO_INTERFACE_LINES * * * ... o o ... #* Line Number Line Order Quantity Line UOM Line Attribute 1 Line Attribute 2 Transaction Record ID #* * o Legend Unique ID Reqired Optional
ECE_PO_INTERFACE_LINES_X
o o o o o #*
Material Analyst Code Material Analyst Last Name Material Analyst First Name Material Analyst Phone Material Analyst Email Transaction Record ID
Define Data Positions in the Outbound Interface File. Task: Add records to the ECE_INTERFACE_COLUMNS table
11-10 Oracle e-Commerce Gateway Implementation Manual
The Oracle e-Commerce Gateway employs a series of tables that function as a data dictionary. When the Oracle e-Commerce Gateway is installed, these tables are seeded with all the data necessary to support the standard transactions. For outbound transactions, the table ECE_INTERFACE_COLUMNS contains the data that informs the extract process which data elements to write to the interface file, as well as where in the output file to position them. Only the data elements that appear in this table will be written to the interface file for a given outbound transaction. Consequently, records for the user-defined data in the extension tables must be added to ECE_INTERFACE_COLUMNS. Continuing the earlier example, for each column that was added to ECE_PO_ INTERFACE_LINES_X, a record must be inserted into ECE_INTERFACE_ COLUMNS for the new data to appear in the output file. Log into a SQL*Plus session either as the owner of ECE_INTERFACE_COLUMNS (typically EC) or as a privileged user (such as APPS), and type the following command to insert the first column of the new extension table data. Do this for each column that was previously defined.
INSERT Statement follows:

INSERT INTO ece_interface_columns( interface_column_id, interface_table_id, interface_column_name, base_table_name, base_column_name, record_number, position, width, data_type, conversion_sequence, record_layout_code, record_layout_qualifier, conversion_group_id, xref_category_allowed, element_tag_name, external_level, map_id, staging_column, creation_date, created_by, last_update_date, last_updated_by,
11-11
last_update_login) SELECT ece_interface_column_id_s.NEXTVAL, (SELECT eit.interface_table_id FROM ece_interface_tbls_upg eit, ece_mappings_upg em WHERE em.map_code = 'EC_POO_FF' AND eit.output_level = '5' AND em.map_id = eit.map_id), NULL, NULL, 'MATERIAL_ANALYST_CODE', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'N', NULL, 5, ece_map_id_s.CURRVAL, 'FIELD500', SYSDATE, 1, SYSDATE, 1, 1 FROM DUAL;
One INSERT statement is required for each column that was added to the extension table.
FIELDnnn Numbers:
In the INSERT statement above you define your specific field to a generic FIELDnnn column in the Oracle e-Commerce Gateway. Five hundred generic FIELD names (FIELD1 through FIELD500) are predefined for any table within a transaction. It is recommended that you start using FIELD500 then decrease the field number by one for each of your fields. The highest number fields are not likely to be used by the provided transaction. There is a potential problem if you need more columns than are available for the given table. You will lose data if you reuse FIELDnnn columns already used by the Oracle e-Commerce Gateway provided transaction.
Transaction: Purchase Order Outbound Interface Table Name
Starting FIELD number
Ending FIELD number
Oracle e-Commerce Gateway Transaction Available fields for transaction changes Your new fields
1 N+1 Use numbers moving backwards from 500.
n 500 500
Record Numbers:
The value for Record_Number may be any value within the range of the corresponding interface table values. For example, the Purchase Order Outbound (POO) transaction has the typical Header-Line-Line Detail output structure, with the following ranges:
Transaction: Purchase Order Outbound Interface Table Name
Record Number Range
ECE_PO_INTERFACE_HEADERS ECE_PO_INTERFACE_LINES ECE_PO_INTERFACE_SHIPMENTS
1000 - 1999 2000 - 2999 3000 - 3999
Although extension table data elements may be interwoven with data elements from the corresponding interface table (provided the total number of bytes for any record does not exceed 1024), it is customary to begin the extension table data with the x900 record. The value for Position determines the relative output order of data elements within the specified Record_Number. Attention: Extension table data elements may only be mapped within the range of the corresponding interface table, and no single record number may contain more than 1024 bytes of data. Modify Procedures to Move Data to the Extension Tables. Task: Modify the package body code
11-13
Just as the Extensible Architecture of the Oracle e-Commerce Gateway provides extension tables that may be customized to fit the business needs, it also provides packaged procedures that may be customized to populate the extension tables with data. There is one extension package for each outbound transaction, and each extension package contains one procedure for every extension table in that transaction. Extension packages consist of two source code files, a package specification, and a package body, with file names in the respective window: ECExxxxXS.pls ECExxxxXB.pls where xxxx denotes the unique three or four letter identifier for a given transaction. These source code files are usually found in the directory: $APPL_TOP/ec/admin/sql and may be modified with any text editor. Only the package body requires modification; the package specification file should not be altered. For example, the Purchase Order Outbound (POO) transaction has the corresponding extension package body ECEPOOXB.pls containing the following procedures: Populate_Ext_Header Populate_Ext_Line Populate_Ext_Shipment To populate the new columns added to ECE_PO_INTERFACE_LINES_X in the earlier example, the procedure Populate_Ext_Line requires modification. As installed, the entire procedure reads as follows: Procedure follows:
PROCEDURE Populate_Ext_Line (l_fkey IN NUMBER, l_plsql_table IN ece_flatfile_pvt.interface_tbl_type) IS BEGIN NULL; END PROCEDURE Populate_Ext_Line;
which does absolutely nothing, although the procedure is called each time a record is inserted into ECE_PO_INTERFACE_LINES. The procedure takes two parameters: a 'key' value, and a PL/SQL table. The 'key' value is the TRANSACTION_RECORD_ID value, which is the primary key for both the interface table and the extension table.
'interface_tbl_type' is a PL/SQL table typedef with the following structure:

base_table_name base_column_name interface_table_name interface_column_name record_num NUMBER position NUMBER data_type data_length value layout_code layout_qualifier interface_column_id conversion_sequence xref_category_id conversion_group_id xref_key1_source_column xref_key2_source_column xref_key3_source_column xref_key4_source_column xref_key5_source_column ext_val1 ext_val2 ext_val3 ext_val4 ext_val5 VARCHAR2(50) -- Application table name VARCHAR2(50) -- Application column name VARCHAR2(50) -- Interface table name VARCHAR2(50) -- Interface column name -- Interface File Record Num -- Interface File Position VARCHAR2(50) -- Data type NUMBER -- Data length VARCHAR2(400) -- Interface table value VARCHAR2(2) -- Layout Code VARCHAR2(3) -- Layout Qualifier NUMBER -- Interface Column Id NUMBER -- Conversion Sequence NUMBER -- Cross-reference category NUMBER -- Conversion Group Id VARCHAR2(50) -- Cross-reference source 1 VARCHAR2(50) -- Cross-reference source 2 VARCHAR2(50) -- Cross-reference source 3 VARCHAR2(50) -- Cross-reference source 4 VARCHAR2(50) -- Cross-reference source 5 VARCHAR2(80) -- Cross-reference value 1 VARCHAR2(80) -- Cross-reference value 2 VARCHAR2(80) -- Cross-reference value 3 VARCHAR2(80) -- Cross-reference value 4 VARCHAR2(80) -- Cross-reference value 5
Each record in the PL/SQL table represents a single column in the interface table, and there is one record in the PL/SQL table for every column in the interface table. (In other words, the PL/SQL table can be viewed as an array of records, with each record having the above structure.) The 'int_val' attribute holds the value stored in the interface table column (converted to VARCHAR2). Attention: It is important to note that the PL/SQL table is built using the COLUMN_NAMEs from the associated outbound transaction view, and not from the associated outbound interface table. Therefore, when using the ece_flatfile_pvt package procedures and functions, make sure that the COLUMN_NAME value that is passed matches the column name in the associated view. To complete the earlier example, suppose that the custom table MATERIAL_ ANALYSTS contains the column INVENTORY_ITEM_ID to associate the material analyst contact data with a specific purchasable item. The following modifications
11-15
to the Populate_Ext_Lines procedure will extract the necessary data from the custom database table and insert it into the extension table. The Procedure:
PROCEDURE Populate_Ext_Line (l_fkey IN NUMBER, l_plsql_table IN ece_flatfile_PVT.interface_tbl_type) IS /* ** ** Variable definitions. ** */ v_ItemID INTEGER; v_ItemIDPosition INTEGER; BEGIN /* ** Find the position of the ITEM_ID in the PL/SQL table. Then ** use the value stored in that position to select the necessary ** contact data from the MATERIAL_ANALYSTS custom table. ** */ ece_flatfile_PVT.find_pos ( l_plsql_table, ITEM_ID, v_ItemIDPosition ); /* ** Every value in the PL/SQL table is stored as VARCHAR2, ** so convert the value to a number. ** */ v_ItemID := TO_NUMBER(l_plsql_table(v_ItemIDPosition).value); /* ** Get the necessary data from MATERIAL_ANALYSTS and insert it ** into ECE_PO_INTERFACE_LINES_X. */
INSERT INTO ece_po_interface_lines_x( Transaction_Record_ID, Material_Analyst_Code, Material_Analyst_Last_Name, Material_Analyst_First_Name, Material_Analyst_Phone, Material_Analyst_Email ) SELECT l_fkey, material_analyst_code, material_analyst_last_name, material_analyst_first_name, material_analyst_phone, material_analyst_email FROM material_analysts WHERE inventory_item_id = v_ItemID; END PROCEDURE Populate_Ext_Line;
Once the procedure has been modified, it must be recompiled for the changes to take effect. Log into SQL*Plus as the APPS user, and issue the following command:
SQL> @ECEPOOXB.pls Package body created.
The customization process is complete; each subsequent execution of the outbund Purchase Order transaction will include the new extension table data elements in the output transaction interface file.
11-17
A
Transaction Summary Layouts
This appendix contains the following information about Oracle e-Commerce Gateway implementation: Oracle Inventory Transaction Summaries on page A-2 Oracle Order Management Transaction Summaries on page A-7 Oracle Payables Transaction Summaries on page A-8 Oracle Process Manufacturing Transaction Summaries on page A-28 Oracle Purchasing Transaction Summaries on page A-29 Oracle Receivables Transaction Summaries on page A-72 Oracle Release Management Transaction Summaries on page A-90 Oracle Shipping Execution Transaction Summaries on page A-91 Oracle Supplier Scheduling Transaction Summaries on page A-92
Transaction Summary Layouts A-1
Oracle Inventory Transaction Summaries

The following Oracle Inventory transaction is summarized in this appendix.
Transaction Transaction Name Movement Statistics Direction Outbound Code MVSTO
ASC X12 N/A
EDIFACT CUSDEC
Current Information
The transaction file may change when enhancements are made such as additional data added to the transaction. Current transaction summaries can be found on Oracle Supports web site. Current detail record layouts are reported via the Transaction Definition Layout Report and the Interface File Data Report.
Outbound Movement Statistics (INTRASTAT)

(MVSTO/No X12/CUSDEC) Record Structure A single transaction has the following data hierarchy and data looping.
A-2 Oracle e-Commerce Gateway Implementation Manual
(MVSTOO) Outbound Movement Statistics Structure

Record Numbers Control Record Movement Statistics Header Item Detail Addresses (0010) (1000-1900) (2000-2900) (3000-3900)
Item Detail Addresses
(2000-2900) (3000-3900)
denotes a hierarchical level or loop that may repeat within the transacton file
Table A1
Records Content
Record occurrences within the transaction:

Occurrences Only one record occurrence per transaction
0010-0050 EDI Gateway Control Records
1000-1020 Movement Header Records Only one record occurrence per transaction 2000-2230 Movement Detail Records 3000-3020 Movement Location Records One set of records per item within the movement header One set of records per item within the movement detail
Table A2 Record Summary:

Data 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Control Record Trading Partner Header Flexfields Movement Type, Status, Period Legal Entity Address Total Units, Records & Weight Nature of Transaction/Movement Post, Area, Zone Code Currency, Cost, Price Transaction Qty, UOM, Weight Commodity Code/Description Item Description, Comments Document Source/Reference Shipment/Receipt Reference, Container Invoice Date/Reference/Qty Bill to Address Vendor Name/Site Movement Flexfields Bill to Address Ship to Address Vendor Address Data Level HEADER HEADER HEADER HEADER HEADER DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL LOCATION LOCATION LOCATION Record Number 0010 0020-0050 1000 1010 1020 2000 2010 2020 2030 2040 2050 2060 2070 2080 2090 2100 2200-2230 3000 3010 3020 Flexfields Custom Note
Table A3 Transaction specific Data in the Common Key positions 1-100:

Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD HEADER DETAIL LOCATION (Varies) (Varies) (Varies) Content Trading Partner Code as defined in the EDI Translator Movement Header Movement Detail Move Detail Location Record Number Record Layout Record Layout Qualifier
Table A4 Transaction specific Data in the Common Key positions 1-100 per record:
Ref. Ref. 1 22 26-47 HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 0020 0030 0040 0050 1000 1010 1020
Data Length Position 1 2 3 4 5 6 7 8 Control Record Trading Partner Hdr Flexfields 1-4 Trading Partner Hdr Flexfields 4-9 Trading Partner Hdr Flexfields 10-14 Trading Partner Hdr Flexfield 15 Movement Type, Status, Period Legal Entity Address Total Units, Records & Weight
Trading Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
Record Layout 2 96-97 CT A1 A2 A2 A2 RP AX RP
Record Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 RPT LE1 TOT
Nature of Transaction/Moveme nt Post, Area, Zone Code Currency, Cost, Price Transaction Qty, UOM, Weight Commodity Code/Description Item Description, Comments Document Source/Reference Shipment/Receipt Reference, Container Invoice Date/Reference/Qty Bill to Address Vendor Name/Site Movement Flexfields 1-4 Movement Flexfields 5-9 Movement Flexfields 10-14 Movement Flexfield 15 Bill to Address Ship to Address Vendor Address
TP_CD
HEADER
DETAIL
2000
MV
MOV
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER
DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL DETAIL LOCATIO N LOCATIO N LOCATIO N
2010 2020 2030 2040 2050 2060 2070 2080 2090 2100 2200 2210 2220 2230 3000 3010 3020
MV MV MV MV MV MV MV MV LC LC A1 A2 A2 A2 AD AD AD
MV1 CUR AMT COM CMT DOC MSC INV CUS VEN MV1 MV2 MV3 MV4 BT1 ST1 VN1
Oracle Order Management Transaction Summaries
Oracle Order Management Transaction Summaries

Table A5 The following Oracle Release Management transactions are available in Release 11i.1.
Transaction Transaction Name Purchase Order Purchase Order Change Purchase Order Acknowledgment Purchase Order Acknowledgment Direction Inbound Inbound Outbound Outbound Code POI POCI POAO PCAO
ASC X12 850 860 855 865
EDIFACT ORDERS ORDCHG ORDRSP ORDRSP
Current Information
The transaction file may change when enhancements are made such as additional data added to the transaction. Current transaction summaries can be found on Oracle Supports web site when they are released. Current detail record layouts are reported via the Transaction Definition Layout Report and the Interface File Data Report.
Oracle Payables Transaction Summaries

Table A6 appendix. The following Oracle Payables transactions are summarized in this
Transaction Transaction Name Invoice Shipment and Billing Notice Application Advice Payment Order/Remittance Advice Direction Inbound Inbound Outbound Outbound Code INI SBNI ADVO PYO
ASC X12 810 857 824 820
EDIFACT INVOIC N/A APERAK PAYORD/P AYEXT/ REMADV
Current Information
Inbound Invoice
(INI/810/INVOIC) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Invoice Header Item Detail (0010) (1000-2900) (3000-4900)
Item Detail
(3000-4900)
Item Detail
(3000-4900)
Table A7 Record occurrences within the transaction:

Records Content 0010 0020-007 0 1000-299 9 3000-499 9 Control Records Gateway Flexfields Invoice Header Records Invoice Item Records Occurrences Only one record occurrence per transaction One set of records per transaction. Only one record occurrence per transaction One set of records per item within the invoice header

Record Number 0010 1000 1010 1020 2000-2030 2100-2140 2900 Flexfields Flexfields (Custom)
Data 1 2 3 4 5 6 7 Control Record Basic Invoice Header Currency Bill From Address Invoice Header Flexfields Invoice Header Global Flexfields Extension Tables: Invoice Header 8 9 10 11 12 13 Basic Item Basic Item (Description, Tax) Invoice Line Flexfields Invoice Line Flexfields
Data Level INVOICE HEADER INVOICE HEADER INVOICE HEADER INVOICE HEADER INVOICE HEADER INVOICE HEADER INVOICE HEADER
Note
INVOICE LINE INVOICE LINE INVOICE LINE INVOICE LINE
3000 3010 3020 4000-4030 4100-4140 4900 Misc. Description Flexfields Flexfields (Custom)
Invoice Line Global Flexfields INVOICE LINE Extension Tables: Invoice Item Data INVOICE LINE
A-10
Inbound Invoice
(INI/810/INVOIC)
Table A9 Transaction specific data in the Common Key positions 1-100:
Position Code 1-25 26-47 48-69 70-91 92-95 96-97 98-100 TP_CD INVOICE ITEM (blank) (Varies) (Varies) (Varies) Content Trading Partner Code as defined in the EDI Translator Invoice number Purchase Order Line Item Number (blank) Record Number Record Layout Record Layout Qualifier
Table A10 Transaction specific data in the Common Key positions 1-100 per record:
Record Trading Data Length Position 1 2 3 4 5 6 7 Control Record Basic Invoice Header Basic Invoice Header Vendor Site Invoice Header Flexfields 1-4 Invoice Header Flexfields 5-9 Invoice Header Flexfields 10-14 Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD Ref. 1 22 26-47 INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 1000 1010 1020 2000 2010 2020 Record Layout Layout 2 96-97 CT IV IV AD A1 A2 A2 Qualifier 3 98-100 CTL IV1 IV2 BF IV1 IV2 IV3
A-11
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Invoice Header Flexfield 15 Invoice Header Global Flexfields1-4 Invoice Header Global Flexfields 5-9 Invoice Header Global Flexfields 10-14 Invoice Header Global Flexfields 15-19 Invoice Header Global Flexfield 20 Extension Tables: Invoice Header Basic Item Data
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE INVOICE ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM
2030 2100 2110 2120 2130 2140 2900 3000 3010 3020 4000 4010 4020 4030 4100 4110 4120 4130 4140 4900
A2 A1 A2 A2 A2 A2
IV4 HG1 HG2 HG3 HG4 HG5 (Custom)
IT IT IT A1 A2 A2 A2 A1 A2 A2 A2 A2
IT1 IT2 IT3 IT1 IT2 IT3 IT4 IG1 IG2 IG3 IG4 IG5 (Custom)
Basic Item Data (description) TP_CD Misc. Description Invoice Line Flexfields 1-4 Invoice Line Flexfields 5-9 Invoice Line Flexfields 10-14 Invoice Line Flexfield 15 Invoice Line Global Flexfields 1-4 Invoice Line Global Flexfields 5-9 Invoice Line Global Flexfields 10-14 Invoice Line Global Flexfields 15-19 Invoice Line Global Flexfield 20 Extension Tables: Item TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
A-12
Inbound Shipment and Billing Notice

(SBNI/857/No EDIFACT) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Ship Notice/Billing Header Item Detail (0010) (1000-1900) (2000-3900)
Item Detail
(2000-3900)
Item Detail
(2000-3900)
A-13

Records 0010 Content Control Records Occurrences Only one record occurrence per transaction Only one record occurrence per transaction One set of records per item within the Shipment Notice header
1000-1900 Shipment Notice Header Records 2000-3900 Shipment Notice Item Records
Table A12 Record Summary

RECORD Seq. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Type of Data Control Record Shipment Notice Basic Header Carrier, Weights, Packaging Shipment Method of Payment Currency, Tax, Payment Terms Allowances/Charges (Freight) Hazardous Material, Special Handling Header Note Vendor Address/Code Destination Address/Code Destination Contact Shipment Header Flexfields Basic Item Data Hazardous Material Codes Currency, Tax (Item Level) Notes Shipment Line Flexfields Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER LINE LINE LINE LINE LINE (Pos. 92-95) 0010 1000 1010 1020 1030 1040 1050 1090 1100 1120 1130 1200-1230 2000 2010 2020 2030 2100-2130 Flexfields Flexfields Note
A-14
18 19 20
Transaction Flexfields Destination Address Destination Location
LINE LINE LINE
2140-2170 3000 3020
Flexfields
A-15
Inbound Shipment and Billing Notice

(SBNI/857/No EDIFACT)
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100
Code TP_CD SHIPMENT LINE (blank) (varies) (varies) (varies)
Content Trading Partner Code as defined in the EDI Translator Shipment Number Item Number N/A Record Number Record Layout Record Layout Qualifier
Table A14
Transaction specific Data in the Common Key positions 1-100 per record:
Record Ref. Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 1000 1010 1020 1030 Record Layout 2 96-97 CT L1 L2 L3 L4 Layout Qualifier 3 98-100 CTL DL1 DL2 DL3 DL4
Record Length Position 1 2 3 4 5 Control Record Shipment Notice Basic Header Carrier, Weights, Packaging Shipment Method of Payment Currency, Tax, Payment Terms
TP_CD 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD
1 22 26-47 SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT
A-16
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Allowances/Charges (Freight) Hazardous Material, Special Handling Header Note Vendor Address/Code Destination Address/Code Destination Contact Shipment Header Flexfields 1-4 Shipment Header Flexfields 5-9 Shipment Header Flexfields 10-14 Shipment Header Flexfield 15 Basic Item Data Hazardous Material Codes Currency, Tax (Item Level) Notes Shipment Line Flexfields1-4 Shipment Line Flexfields 5-9 Shipment Line Flexfields 10-14 Shipment Line Flexfield 15 Order Line Flexfields 1-4 Order Line Flexfields 5-9
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE
1040 1050 1090 1100 1120 1130 1200 1210 1220 1230 2000 2010 2020 2030 2100 2110 2120 2130 2140 2150
L5 HZ N1 AD AX CN A1 A2 A2 A2 L1 L2 L3 N1 A1 A2 A2 A2 A1 A2
DL5 HZ1 NH1 SF ST ST SH1 SH2 SH3 SH4 IT1 IT2 IT3 ND1 SL1 SL2 SL3 SL4 RC1 RC2
A-17
26 27 28 29
Order Line Flexfields 10-14
TP_CD
SHIPMENT SHIPMENT SHIPMENT SHIPMENT
LINE LINE LINE LINE
2160 2170 3000 3020
A2 A2 AX CO
RC3 RC4 ST ST
Order Line Flexfield 15 TP_CD Destination Address/Code Destination Location TP_CD TP_CD
A-18
Outbound Application Advice

(ADVO/824/APERAK) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Application Advice Header Error (0010) (1000-1900) (2000-2900)
Error
(2000-2900)
Error
(2000-2900)

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction One set of records per transaction. Only one record occurrence per transaction One set of detail records per error within the transaction.
0020-0070 Gateway Flexfields 1000-1999 Application Advice Header Records 2000-2999 Application Advice Detail Records
A-19

Type of Data 1 2 3 4 6 8 9 10 12 14 15 16 Control Record Trading Partner Header Attributes Trading Partner Detail Attributes Advice Header External References Advice Header Internal References Trading Partner Address Extension Table: Header Level Advice Detail External References Advice Detail Internal References Advice Detail Data (Error) Advice Detail Data (Accepted) Extension Table: Detail Level Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER DETAIL DETAIL DETAIL DETAIL DETAIL Record Number 0010 0020-050 0060-0070 1000-1010 1020-1030 1040 1900 2000-2010 2020--2030 2040 2050 2900 (Custom) (Custom) Flexfields Flexfields Custom Custom Flexfields Flexfields
A-20
Outbound Application Advice

(ADVO/824/APERAK)
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD DOC ERR_CNT (blank) (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Related Document ID Error Counter Not Used Record Number Record Layout Record Layout Qualifier
Ref. Record Length Position 1 2 3 4 5 6 Control Record Trading Partner Header Attributes Trading Partner Header Attributes Trading Partner Header Attributes Trading Partner Header Attributes Trading Partner Detail Attributes TP_CD 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD 1 22 26-47 Ref. 2 22 48-69 Ref. 3 22 70-91 Record Record Record Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 TD1
Number Layout 4 92-95 0010 0020 0030 0040 0050 0060 2 96-97 CT A1 A2 A2 A2 A1
A-21
7 8 9 10 11 12 13 14 15 16 17 18 19 20
Trading Partner Detail Attributes Advice Header External References 1-4 Advice Header External References 5-6 Advice Header Internal References 1-5 Advice Header Internal Reference 6 Trading Partner Address Extension Table: Header Level Advice Detail External References 1-4 Advice Detail External References 5-6 Advice Detail Internal References 1-5 Advice Detail Internal Reference 6 Advice Detail Data (Error) Advice Detail Data (Accepted) Extension Table: Detail Level
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC ERR_ CNT ERR_ CNT ERR_ CNT ERR_ CNT ERR_ CNT ERR_ CNT ERR_ CNT
0070 1000 1010 1020 1030 1040 1900 2000 2010 2020 2030 2040 2050 2900
A2 HD HD HD HD AD
TD2 EX1 EX2 IN1 IN2 TP1
(custom) (custom) DT DT DT DT ER AC EX1 EX2 IN1 IN2 ER1 AC1
(custom) (custom)
Outbound Payment Order/Remittance Advice

(PYO/820/PAYORD/REMADV) A single transaction has the following data hierarchy and data looping.
A-22
Record Numbers Control Record Payment/Rem Advice Header (Batch) Invoice (0010) (1000-1900) (2000-2900)
Invoice
(2000-2900)
Invoice
(2000-2900)

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction One set of records per transaction. Only one record occurrence per transaction One set of records per invoice within the Payment Header
0020-0070 Gateway Flexfields 1000-1250 Payment Header Records 2000-2090 Remittance/Invoice Records
A-23

Record Type of Data 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Control Record Trading Partner Header Attributes Trading Partner Detail Attributes Account Data Payment Data Vendor Flexfields Bank Address/Code Bank Contacts Supplier Bank Vendor Site Address/Code Global ABA Attribute Flexfields Global ABAS Attribute Flexfields Global PVS Attribute Flexfields Bill To Internal Address VAT Registration Extension Tables: Payment Data Remittance/Invoice Details Remittance Advice Flexfields Global INV Attribute Flexfields Data Level CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK CHECK INVOICE INVOICE INVOICE Number 0010 0020-0050 0060-0070 1000 1010 1020 1030 1040 1050 1080 1090-1130 1140-1180 1190-1230 1240 1250 1900 2000 2010-2040 2050-2090 Flexfields Flexfields (custom) Flexfields Flexfields Flexfields Custom Custom
Outbound Payment Order/Remittance Advice

(PYO/820/PAYORD/REMADV)
A-24
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD BATCH INVOICE (blank) (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Payment Batch Number Invoice Number Not Used Record Number Record Layout Record Layout Qualifier
Table A22
Transaction specific data in the Common Key positions 1-100 per record:
Ref. Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 0020 0030 0040 0050 0060 0070 BATCH BATCH BATCH 1000 1010 1020 Record Record Layout 2 96-97 CT A1 A2 A2 A2 A1 A2 BK PY VN Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 TD1 TD2 BK1 PAY VN1
RECORD Length Position 1 2 3 4 5 6 7 8 9 10 Control Record Trading Partner Header Attributes Trading Partner Header Attributes Trading Partner Header Attributes Trading Partner Header Attributes Trading Partner Detail Attributes Trading Partner Detail Attributes Account Data Payment Data Vendor Flexfields
TP_CD 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
1 22 26-47
A-25
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Bank Address/Code Bank Contacts Supplier Bank Vendor Site Address/Code Global ABA Flexfields 1-4 Global ABA Flexfields 5-9 Global ABA Flexfields 10-14 Global ABA Flexfields 15-19 Global ABA Flexfield 20 Global ABAS Flexfields 1-4 Global ABAS Flexfields 5-9 Global ABAS Flexfields 10-14 Global ABAS Flexfields 15-19 Global ABAS Flexfield 20 Global PVS Flexfields 1-4 Global PVS Flexfields 5-9 Global PVS Flexfields 10-14 Global PVS Flexfields 15-19 Global PVS Flexfield 20 Bill To Internal Address VAT Registration Extension Tables: Payment Data
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH
1030 1040 1050 1080 1090 1100 1110 1120 1130 1140 1150 1160 1170 1180 1190 1200 1210 1220 1230 1240 1250 1900
AD CN AD AD GA GA GA GA GA GA GA GA GA GA GA GA GA GA GA AX VA (custo m)
BK1 BK1 SB1 VS1 BK1 BK2 BK3 BK4 BK5 SK1 SK2 SK3 SK4 SK5 VS1 VS2 VS3 VS4 VS5 PY TAX (custom)
A-26
33 34 35 36 37 38 39 40 41 42
Remittance/Invoice Details Remittance Advice Flexfields 1-4 Remittance Advice Flexfields 5-9 Remittance Advice Flexfields 10-14 Remittance Advice Flexfield 15 Global INV Flexfields 1-4 Global INV Flexfields 5-9 Global INV Flexfields 10-14 Global INV Flexfields 15-19 Global INV Flexfield 20
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH BATCH
INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E
2000 2010 2020 2030 2040 2050 2060 2070 2080 2090
IV A1 A1 A1 A1 GA GA GA GA GA
INV RE1 RE2 RE3 RE4 IN1 IN2 IN3 IN4 IN5
A-27
Oracle Process Manufacturing Transaction Summaries
Oracle Process Manufacturing Transaction Summaries

Table A23 The following Oracle Process Manufacturing transactions are available.
Transaction Transaction Name OPM: Purchase Order OPM: Purchase Order Acknowledgment OPM: Ship Notice/Manifest Direction Inbound Outbound Outbound Code GPOI GPOAO GASNO
ASC X12 850 855 856
EDIFACT ORDERS ORDRSP ORDADV
Current Information
Refer to the Oracle Process Manufacturing Users Guide for transaction details. Current detail record layouts are reported via the Transaction Definition Layout Report and the Interface File Data Report.
A-28
Oracle Purchasing Transaction Summaries

Table A24 The following Oracle Purchasing transactions are summarized in this appendix.
Transaction Transaction Name Price/Sales Catalog Response to Request for Quotation Ship Notice/Manifest Shipment and Billing Notice Application Advice Purchase Order Purchase Order Change Direction Inbound Inbound Inbound Inbound Outbound Outbound Outbound Code CATI RRQI ASNI SBNI ADVO POO POCO ASC X12 832 843 856 857 824 850 860 EDIFACT PRICAT QUOTES DESADV N/A APERAK ORDERS ORDCHG
Current Information
A-29
Inbound Price/Sales Catalog

(CATI/832/PRICAT) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Price/Sales Catalog Header Item Detail (0010) (1000-1900) (2000-2900)
Item Detail
(2000-2900)
Item Detail
(2000-2900)

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction Only one set of records per price/sales catalog One set of item records per item within the transaction.
1000-1999 Transaction Header 2000-2999 Transaction Item

Type of Data 1 2 Control Record Transaction Identification Data Level HEADER HEADER Record Number 0010 1000
A-30
3 4 5 6 7 8 9 10 11 12 13 14 15 16
Currency, Payment Terms FOB, Carrier, Freight Terms Action Type, Group Code Comments Ship to Address Bill to Address Ship From Address Header Flexfields Item Identification Quantity, Description Prices, Dates Payment Terms (Item Level) FOB, Carrier, Freight Terms (Item Level) Hazardous data, Weight, Volume, Lead Time
HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER LINE LINE LINE LINE LINE LINE
1010 1020 1030 1040 1100 1110 1120 1200-1230 2000 2010 2020 2030 2040 2050 Flexfields
17 18 19 20 21 22
Ship To Data (Item Level) Line Level Flexfields Shipment Flexfields Item Level Flexfields Item Level Flexfields Item Level Flexfields
LINE LINE LINE LINE LINE LINE
2100 2200-2230 2240-2270 2280-2310 2280-2310 2280-2310 Flexfields Flexfields Flexfields Flexfields Flexfields
Inbound Price/Sales Catalog

(CATI/832/PRICAT)
A-31
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD DOC ITEM (blank) (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Transaction Identification from trading partner Supplier Item Number Not Used Record Number Record Layout Record Layout Qualifier
Ref. Record Length Position 1 2 3 4 5 6 7 8 9 10 11 12 13 Control Record Transaction Identification Currency, Payment Terms FOB, Carrier, Freight Terms Action Type Comments Ship to Address Bill to Address Ship From Address Header Flexfields 1-4 Header Flexfields 5-9 Header Flexfields 10-14 Header Flexfields 15 TP_CD 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD 1 22 26-47 DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC Ref. 2 22 48-69 Ref. 3 22 70-91 Record Record Record Qualifier 3 98-100 CTL HD1 HD2 HD3 HD5 HCM ST BT SF HD1 HD2 HD3 HD4
Number Layout 4 92-95 0010 1000 1010 1020 1030 1040 1100 1110 1120 1200 1210 1220 1230 2 96-97 CT HA HB HC HE NT AX AX AD A1 A2 A2 A2
A-32
14 15 16 17 18 19
Item Identification Quantity, Description Prices, Dates Payment Terms (Item Level) FOB, Carrier, Freight Terms (Item Level) Hazardous data, Weight, Volume, Lead Time
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
DOC DOC DOC DOC DOC DOC
LINE LINE LINE LINE LINE LINE
2000 2010 2020 2030 2040 2050
IA IB IC ID IE IF
IT1 IT2 IT3 IT4 IT5 IT6
21 22 23 24 25 26 27 28 29 30 31 32 33
Ship To Data (Item Level) Line Level Flexfield 1-4 Line Level Flexfield 5-9 Line Level Flexfield 10-14 Line Level Flexfield 15 Shipment Flexfield 1-4 Shipment Flexfield 5-9 Shipment Flexfield 10-14 Shipment Flexfield 15 Item Level Flexfield 1-4 Item Level Flexfield 5-9 Item Level Flexfield 10-14 Item Level Flexfield 15
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC
LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE
2100 2200 2210 2220 2230 2240 2250 2260 2270 2280 2290 2300 2310
AX A1 A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2
ST LN1 LN2 LN3 LN4 SH1 SH2 SH3 SH4 IT1 IT2 IT3 IT4
A-33
Inbound Response to Request for Quotation

(RRQI/843/QUOTES) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Response to RFQ Header Item Detail (0010) (1000-1900) (2000-2900)
Item Detail
(2000-2900)
Item Detail
(2000-2900)

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction Only one set of records per request quote One set of item records per item within the transaction.
1000-1999 Transaction Header 2000-2999 Transaction Item
A-34

Type of Data 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Control Record Transaction Identification Currency, Payment Terms FOB, Carrier, Freight Terms Action Type, Group Code Comments Ship to Address Bill to Address Ship From Address Header Flexfields Item Identification Quantity, Description Prices, Dates Payment Terms (Item Level) FOB, Carrier, Freight Terms (Item Level) Hazardous data, Weight, Volume, Lead Time 17 18 19 20 Ship To Data (Item Level) Line Level Flexfields Shipment Flexfields Item Level Flexfields LINE LINE LINE LINE 2100 2200-2230 2240-2270 2280-2310 Flexfields Flexfields Flexfields Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER LINE LINE LINE LINE LINE LINE Record Number 0010 1000 1010 1020 1030 1040 1100 1110 1120 1200-1230 2000 2010 2020 2030 2040 2050 Flexfields
Inbound Response to Request for Quotation

(RRQI/843/QUOTES)
A-35
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD DOC ITEM (blank) (varies) (varies) (varies) Content Trading Partner Code as defined in the Translator Transaction Identification from trading partner Supplier Item Number Not Used Record Number Record Layout Record Layout Qualifier
A-36
Ref. Record Length Position 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Control Record Transaction Identification Currency, Payment Terms FOB, Carrier, Freight Terms Action Type Comments Ship to Address Bill to Address Ship From Address Header Flexfields 1-4 Header Flexfields 5-9 Header Flexfields 10-14 Header Flexfield 15 Item Identification Quantity, Description Prices, Dates Payment Terms (Item Level) FOB, Carrier, Freight Terms (Item Level) Hazardous data, Weight, Volume, Lead Time 21 22 Ship To Data (Item Level) Line Level Flexfields 1-4 TP_CD TP_CD DOC DOC LINE LINE 2100 2200 AX A1 ST LN1 TP_CD 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD 1 22 26-47 DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC LINE LINE LINE LINE LINE LINE Ref. 2 22 48-69 Ref. 3 22 70-91 Record Record Record Qualifier 3 98-100 CTL HD1 HD2 HD3 HD5 HCM ST BT SF HD1 HD2 HD3 HD4 IT1 IT2 IT3 IT4 IT5 IT6
Number Layout 4 92-95 0010 1000 1010 1020 1030 1040 1100 1110 1120 1200 1210 1220 1230 2000 2010 2020 2030 2040 2050 2 96-97 CT HA HB HC HE NT AX AX AD A1 A2 A2 A2 IA IB IC ID IE IF
A-37
23 24 25 26 27 28 29 30 31 32 33
Line Level Flexfields 5-9 Line Level Flexfields 10-14 Line Level Flexfield 15 Shipment Flexfields 1-4 Shipment Flexfields 5-9 Shipment Flexfields 10-14 Shipment Flexfield 15 Item Level Flexfields 1-4 Item Level Flexfields 5-9 Item Level Flexfields 10-14 Item Level Flexfield 15
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC DOC
LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE
2210 2220 2230 2240 2250 2260 2270 2280 2290 2300 2310
A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2
LN2 LN3 LN4 SH1 SH2 SH3 SH4 IT1 IT2 IT3 IT4
A-38
Inbound Ship Notice/Manifest

(ASNI/856/DESADV) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Ship Notice/Manifest Header Item Detail (0010) (1000-1900) (2000-2900)
Item Detail
(2000-2900)
Item Detail
(2000-2900)

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction Only one record occurrence per transaction One set of records per item within the Shipment Notice header

RECORD Seq. Type of Data Data Level (Pos. 92-95) Note
A-39
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Control Record Shipment Notice Basic Header Carrier, Weights, Packaging Shipment Method of Payment Currency, Tax, Payment Terms Allowances/Charges (Freight) Hazardous Material, Special Handling Header Note Vendor Address/Code Destination Address/Code Destination Contact Shipment Header Flexfields Basic Item Data Hazardous Material Codes Currency, Tax (Item Level) Notes, Shipping Instructions Shipment Line Flexfields Transaction Flexfields Destination Address Destination Location
HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER LINE LINE LINE LINE LINE LINE LINE LINE
0010 1000 1010 1020 1030 1040 1050 1090 1100 1120 1130 1200-1230 2000 2010 2020 2030 2100-2130 2140-2170 3000 3020 Flexfields Flexfields Flexfields
A-40
Inbound Ship Notice/Manifest

(ASNI/856/DESADV)
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD SHIPMENT LINE (blank) (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Shipment Number Item Number N/A Record Number Record Layout Record Layout Qualifier
A-41
Table A36
Record Ref. Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 1000 1010 1020 1030 1040 1050 1090 1100 1120 1130 1200 1210 1220 Record Layout 2 96-97 CT L1 L2 L3 L4 L5 HZ N1 AD AX CN A1 A2 A2 Layout Qualifier 3 98-100 CTL DL1 DL2 DL3 DL4 DL5 HZ1 NH1 SF ST ST SH1 SH2 SH3
Record Length Position 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Control Record Shipment Notice Basic Header
TP_CD 25 1-25 TP_CD TP_CD
1 22 26-47 SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T
Carrier, Weights, Packaging TP_CD Shipment Method of Payment Currency, Tax, Payment Terms Allowances/Charges (Freight) Hazardous Material, Special Handling Header Note Vendor Address/Code Destination Address/Code Destination Contact Shipment Header Flexfields 1-4 Shipment Header Flexfields 5-9 Shipment Header Flexfields 10-14 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
A-42
15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Shipment Header Flexfield 15 Basic Item Data Hazardous Material Codes Currency, Tax (Item Level) Notes Shipment Line Flexfields 1-4 Shipment Line Flexfields 5-9 Shipment Line Flexfields 10-14 Shipment Line Flexfield 15 Order Line Flexfields 1-4 Order Line Flexfields 5-9 Order Line Flexfields 10-14 Order Line Flexfield 15 Destination Address/Code Destination Location
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T SHIPMEN T LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE
1230 2000 2010 2020 2030 2100 2110 2120 2130 2140 2150 2160 2170 3000 3020
A2 L1 L2 L3 N1 A1 A2 A2 A2 A1 A2 A2 A2 AX CO
SH4 IT1 IT2 IT3 ND1 SL1 SL2 SL3 SL4 RC1 RC2 RC3 RC4 ST ST
Inbound Shipping and Billing Notice

(SBNI/857/No EDIFACT) A single transaction has the following data hierarchy and data looping.
A-43
Record Numbers Control Record Ship Notice/Billing Header Item Detail (0010) (1000-1900) (2000-3900)
Item Detail
(2000-3900)
Item Detail
(2000-3900)

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction Only one record occurrence per transaction One set of records per item within the Shipment Notice header
A-44

RECORD Seq. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Type of Data Control Record Shipment Notice Basic Header Carrier, Weights, Packaging Shipment Method of Payment Currency, Tax, Payment Terms Allowances/Charges (Freight) Hazardous Material, Special Handling Header Note Vendor Address/Code Destination Address/Code Destination Contact Shipment Header Flexfields Basic Item Data Hazardous Material Codes Currency, Tax (Item Level) Notes Shipment Line Flexfields Transaction Flexfields Destination Address Destination Location Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER LINE LINE LINE LINE LINE LINE LINE LINE (Pos. 92-95) 0010 1000 1010 1020 1030 1040 1050 1090 1100 1120 1130 1200-1230 2000 2010 2020 2030 2100-2130 2140-2170 3000 3020 Flexfields Flexfields Flexfields Note
Inbound Shipping and Billing Notice

(SBNI/857/No EDIFACT)
A-45
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD SHIPMENT LINE (blank) (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Shipment Number Item Number N/A Record Number Record Layout Record Layout Qualifier
A-46
Record Ref. Record Length Position 1 2 3 4 5 Control Record Shipment Notice Basic Header TP_CD 25 1-25 TP_CD TP_CD 1 22 26-47 SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT Ref. 2 22 48-69 Ref. 3 22 70-91 Record Record Layout Qualifier 3 98-100 CTL DL1 DL2 DL3 DL4
Number Layout 4 92-95 0010 1000 1010 1020 1030 2 96-97 CT L1 L2 L3 L4
Carrier, Weights, Packaging TP_CD Shipment Method of Payment Currency, Tax, Payment Terms Allowances/Charges (Freight) Hazardous Material, Special Handling Header Note Vendor Address/Code Destination Address/Code Destination Contact Shipment Header Flexfields 1-4 Shipment Header Flexfields 5-9 Shipment Header Flexfields 10-14 Shipment Header Flexfield 15 Basic Item Data Hazardous Material Codes TP_CD TP_CD
6 7 8 9 10 11 12 13 14 15 16 17
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT LINE LINE
1040 1050 1090 1100 1120 1130 1200 1210 1220 1230 2000 2010
L5 HZ N1 AD AX CN A1 A2 A2 A2 L1 L2
DL5 HZ1 NH1 SF ST ST SH1 SH2 SH3 SH4 IT1 IT2
A-47
18 19 20 21 22 23 24 25 26 27 28 29
Currency, Tax (Item Level) Notes
TP_CD TP_CD
SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT
LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE
2020 2030 2100 2110 2120 2130 2140 2150 2160 2170 3000 3020
L3 N1 A1 A2 A2 A2 A1 A2 A2 A2 AX CO
IT3 ND1 SL1 SL2 SL3 SL4 RC1 RC2 RC3 RC4 ST ST
Shipment Line Flexfields1-4 TP_CD Shipment Line Flexfields 5-9 Shipment Line Flexfields 10-14 Shipment Line Flexfield 15 Order Line Flexfields 1-4 Order Line Flexfields 5-9 Order Line Flexfields 10-14 Order Line Flexfield 15 Destination Address/Code Destination Location TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
A-48
Outbound Application Advise

(ADVO/824/APERAK) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Application Advice Header Error (0010) (1000-1900) (2000-2900)
Error
(2000-2900)
Error
(2000-2900)

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction One set of records per transaction. Only one record occurrence per transaction One set of detail records per error within the transaction.
0020-0070 Gateway Flexfields 1000-1999 Application Advice Header Records 2000-2999 Application Advice Detail Records
A-49

Type of Data 1 2 3 4 6 8 9 10 12 14 15 16 Control Record Trading Partner Header Attributes Trading Partner Detail Attributes Advice Header External References Advice Header Internal References Trading Partner Address Extension Table: Header Level Advice Detail External References Advice Detail Internal References Advice Detail Data (Error) Advice Detail Data (Accepted) Extension Table: Detail Level Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER DETAIL DETAIL DETAIL DETAIL DETAIL Record Number 0010 0020-0050 0060-0070 1000-1010 1020-1030 1040 1900 2000-2010 2020--2030 2040 2050 2900 (Custom) (Custom) Flexfields Flexfields Custom Custom Flexfields Flexfields
A-50
Outbound Application Advise

(ADVO/824/APERAK)
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD DOC ERR_CNT (blank) (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Related Document ID Error Counter Not Used Record Number Record Layout Record Layout Qualifier
A-51
Table A44
Ref. Ref. 2 22 48-69 Ref. 3 22 70-91 Record Record Record Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 TD1 TD2 EX1
Record Length Position 1 2 3 4 5 6 7 8 Control Record
TP_CD 25 1-25 TP_CD
1 22 26-47
Number Layout 4 92-95 0010 0020 0030 0040 0050 0060 0070 2 96-97 CT A1 A2 A2 A2 A1 A2 HD
Trading Partner TP_CD Header Attributes Trading Partner TP_CD Header Attributes Trading Partner TP_CD Header Attributes Trading Partner TP_CD Header Attributes Trading Partner Detail; Attributes Trading Partner Detail Attributes Advice Header External References 1-4 Advice Header External References 5-6 Advice Header Internal References 1-5 Advice Header Internal Reference 6 Trading Partner Address Extension Table: Header Level TP_CD TP_CD TP_CD DOC
1000
TP_CD
DOC
1010
HD
EX2
10
TP_CD
DOC
1020
HD
IN1
11
TP_CD
DOC
1030
HD
IN2
12 13
TP_CD TP_CD
DOC DOC
1040 1900
AD (custom)
TP1 (custom)
A-52
14
Advice Detail External References 1-4 Advice Detail External References 5-6 Advice Detail Internal References 1-5 Advice Detail Internal Reference 6 Advice Detail Data (Error) Advice Detail Data (Accepted) Extension Table: Detail Level
TP_CD
DOC
ERR_CNT
2000
DT
EX1
15
TP_CD
DOC
ERR_CNT
2010
DT
EX2
16
TP_CD
DOC
ERR_CNT
2020
DT
IN1
17
TP_CD
DOC
ERR_CNT
2030
DT
IN2
18 19 20
TP_CD TP_CD TP_CD
DOC DOC DOC
ERR_CNT ERR_CNT ERR_CNT
2040 2050 2900
ER AC (custom)
ER1 AC1 (custom)
Outbound Purchase Orders

(POO/850/ORDERS) A single transaction has the following data hierarchy and data looping.
A-53
Record Number Control Record Purchase Order Header (0010) (1000)
Header Attachment Header Header Attachment Detail
(1800) (1810)
Item Item Attachment Header Item Attachment Detail Master Item Attachment Header Master Item Attachment Detail Inventory Item Attachment Header Inventory Item Attachment Detail Shipments Shipment Attachment Header Shipment Attachment Detail
(2000-2130) (2800) (2810)
(2820) (2830) (2840) (2850) (3000) (3800)
(3810)
Projects
(4000-4060)
A-54

Records 0010 Content Control Record Occurrences Only one record occurrence per transaction One set of records per transaction. Only one record occurrence per transaction One set of records per line within the PO header One set of records per schedule within the PO line
0020-0070 Gateway Flexfields 1000-1900 PO Header Records 2000-2900 PO Line Records 3000-3900 PO Shipment Records

Record Number 0010 0020-005 0 0060-007 0 1000 1010 1020 1030 1040-107 0 Flexfields Custom Custom
Seq. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Data Control Record Trading Partner Header Flexfields Trading Partner Detail Flexfields Purchase Order Basic Header Payment Terms Purchase Order Basic Header Purchase Order Notes to Supplier Purchase Order Flexfields Supplier Flexfields Supplier Site Flexfields Supplier Site Address/Code Supplier Site Contacts Ship to Address/code Ship to Contacts Bill to Address/Code
Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER
Note
1080-1110 Flexfields 1120-1150 Flexfields 1160 1170-1180 1190 1200 1210
A-55
16 17 18 19 20 21 22 23 24
Bill to Contact Buyer Name Buyer Communications Procurement Card Header Attachment Master Header Attachment Detail Basic Item Data Basic Item Data Basic Item Data, Hazardous Material Codes
HEADER HEADER HEADER HEADER HEADER ATTACHMENT HEADER HEADER ATTACHMENT DETAIL LINE LINE LINE
1220 1230 1240 1250 1800 1810 2000 2010 2020
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Item Note to Supplier Line Flexfields Line Part Flexfields Line Part Segments Line Part Segments Line Attachment Master Line Attachment Detail Master Item Attachment Master Master Item Attachment Detail Inventory Item Attachment Master Inventory Item Attachment Detail Basic Shipment Data Shipment Flexfields Ship To Address/Code Ship To Contact Shipment Attachment Master Shipment Attachment Detail
LINE LINE LINE LINE LINE LINE ATTACHMENT HEADER LINE ATTACHMENT DETAIL MASTER ITEM ATTACHMENT HEADER MASTER ITEM ATTACHMENT DETAIL INVENTORY ITEM ATTACHMENT HEADER INVENTORY ITEM ATTACHMENT DETAIL SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT ATTACHMENT HEADER SHIPMENT ATTACHMENT DETAIL
2030 2040-207 0 Flexfields
2080-2110 Flexfields 2120 2130 2800 2810 2820 2830 2840 2850 3000 3010-304 0 3050 3060 3800 3810 Flexfields
A-56
42 43
Projects Data Projects Flexfields
PROJECT PROJECT
4000 4010-405 0
A-57
Outbound Purchase Orders

(POO/850/ORDERS)
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD PO LINE SHIPMENT (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Purchase order number Purchase order line number Shipment Number Record Number Record Layout Record Layout Qualifier
Table A48
Record Trading Ref. 1 22 26-47 PO PO PO PO PO PO Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 0020 0030 0040 0050 0060 Record Layout 2 96-97 CT A1 A2 A2 A2 A1 Layout Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 TD1
Data Length Position 1 2 3 4 5 6 Control Record Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Detail Flexfields
Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
A-58
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Trading Partner Detail Flexfields Purchase Order Basic Header Payment Terms Purchase Order Basic Header Purchase Order Notes to Supplier Purchase Order Flexfields Purchase Order Flexfields Purchase Order Flexfields Purchase Order Flexfields Supplier Flexfields Supplier Flexfields Supplier Flexfields Supplier Flexfields Supplier Site Flexfields Supplier Site Flexfields Supplier Site Flexfields Supplier Site Flexfields Supplier Site Address Supplier Site Contact Supplier Site Contact Ship to Address/Code Ship to Contacts Bill to Address/Code Bill to Contact
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO
0070 1000 1010 1020 1030 1040 1050 1060 1070 1080 1090 1100 1110 1120 1130 1140 1150 1160 1170 1180 1190 1200 1210 1220
A2 PO PO PO PO A1 A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2 AD CN CN AX CN AX CN
TD2 PO1 PO2 PO3 PO3 PO1 PO2 PO3 PO4 SU1 SU2 SU3 SU4 SS1 SS2 SS3 SS4 SU1 SS1 SS2 ST1 ST1 BT1 BT1
A-59
31 32 33 34 35 36 37 38
Buyer Name Buyer Communications Procurement Card Header Attachment Master Header Attachment Detail Basic Item Data Basic Item Data Basic Item Data, Hazardous Material Codes
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PO PO PO PO PO PO PO PO LINE LINE LINE
1230 1240 1250 1800 1810 2000 2010 2020
PO PO PR AT AT IT IT IT
PO4 PO5 CRD HAH HAD IT1 IT2 IT3
39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
Item Note to Supplier Line Flexfields Line Flexfields Line Flexfields Line Flexfields Line Part Flexfields Line Part Flexfields Line Part Flexfields Line Part Flexfields Line Part Segments Line Part Segments Line Attachment Master Line Attachment Detail Master Item Attachment Master Master Item Attachment Detail Inventory Item Attachment Master
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO
LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE
2030 2040 2050 2060 2070 2080 2090 2100 2110 2120 2130 2800 2810 2820 2830 2840
IT A1 A2 A2 A2 A1 A2 A2 A2 PS PS AT AT AT AT AT
IT4 LN1 LN2 LN3 LN4 LP1 LP2 LP3 LP4 PS1 PS2 LAH LAD MAH MAD IAH
A-60
55 56
Inventory Item Attachment Detail Basic Shipment Data
TP_CD TP_CD
PO PO
LINE LINE SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T
2850 3000
AT SH
IAD SH1
57
Shipment Flexfields
TP_CD
PO
LINE
3010
A1
SH1
58
Shipment Flexfields
TP_CD
PO
LINE
3020
A2
SH2
59
Shipment Flexfields
TP_CD
PO
LINE
3030
A2
SH3
60
Shipment Flexfields
TP_CD
PO
LINE
3040
A2
SH4
61
Ship To Address/Code
TP_CD
PO
LINE
3050
AX
SL1
62
Ship To Contact
TP_CD
PO
LINE
3060
CN
SL1
63
Shipment Attachment Master Shipment Attachment Detail Projects Data
TP_CD
PO
LINE
3800
AT
SAH
64
TP_CD
PO
LINE
3810
AT
SAD
65
TP_CD
PO
LINE
4000
PR
PR1
66
Projects Flexfields
TP_CD
PO
LINE
4010
PR
PR2
67
Projects Flexfields
TP_CD
PO
LINE
4020
PR
PR3
A-61
68
Projects Flexfields
TP_CD
PO
LINE
SHIP MEN T SHIP MEN T SHIP MEN T
4030
PR
PR4
69
Projects Flexfields
TP_CD
PO
LINE
4040
PR
PR5
70
Projects Flexfields
TP_CD
PO
LINE
4050
PR
PR6
Outbound Purchase Order Changes

(POCO/860/ORDCHG) A single transaction has the following data hierarchy and data looping.
A-62
Record Number Control Record Purchase Order Header (0010) (1000)
Header Attachment Header Header Attachment Detail
(1800) (1810)
Item Item Attachment Header Item Attachment Detail Master Item Attachment Header Master Item Attachment Detail Inventory Item Attachment Header Inventory Item Attachment Detail Shipments Shipment Attachment Header Shipment Attachment Detail
(2000-2130) (2800) (2810)
(2820) (2830) (2840) (2850) (3000) (3800)
(3810)
Projects
(4000-4060)
A-63

Records 0010 Contents Control Record Occurrences Only one record occurrence per transaction One set of records per transaction. Only one record occurrence per transaction One set of records per line within the PO header One set of records per schedule within the PO line
0020-0070 Gateway Flexfields 1000-1900 PO Header Records 2000-2900 PO Line Records 3000-3900 PO Shipment Records

Record Number 0010 0020-0050 0060-0070 1000 1010 1020 1030 1040-1070 1080-1110 1120-1150 1160 1170-1180 1190 1200 1210 1220 Flexfields Flexfields Flexfields Custom Custom
Seq. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Data Control Record Trading Partner Header Flexfields Trading Partner Detail Flexfields Purchase Order Basic Header Payment Terms Purchase Order Basic Header Purchase Order Notes to Supplier Purchase Order Flexfields Supplier Flexfields Supplier Site Flexfields Supplier Site Address/Code Supplier Site Contacts Ship to Address/Code Ship to Contacts Bill to Address/Code Bill to Contact
Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER
Note
A-64
17 18 19 20 21 22 23 24
Buyer Name Buyer Communications Procurement Card Data Header Attachment Data Header Attachment Data Basic Item Data Basic Item Data Basic Item Data, Hazardous Material Codes
HEADER HEADER HEADER HEADER ATTACHMENT HEADER HEADER ATTACHMENT DETAIL LINE LINE LINE
1230 1240 1250 1800 1810 2000 2010 2020
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Item Note to Supplier Line Flexfields Line Part Flexfields Line Part Segments Line Part Segments Line Attachment Header Line Attachment Detail Master Item Attachment Header Master Item Attachment Detail Inventory Item Attachment Master Inventory Item Attachment Detail Basic Shipment Data Shipment Flexfields Ship To Address/Code Ship To Contact Shipment Attachment Master Shipment Attachment Detail
LINE LINE LINE LINE LINE LINE ATTACHMENT HEADER LINE ATTACHMENT DETAIL MASTER ITEM ATTACHEMENT HEADER
2030 2040-2070 2080-2110 2120 2130 2800 2810 2820 Flexfields Flexfields
MASTER ITEM ATTACHEMENT DETAIL 2830 INVENTORY ITEM ATTACHEMENT HEADER INVENTORY ITEM ATTACHEMENT DETAIL SHIPMENT SHIPMENT SHIPMENT SHIPMENT SHIPMENT ATTACHMENT HEADER SHIPMENT ATTACHMENT DETAIL 2840 2850 3000 3010-3040 3050 3060 3800 3810 Flexfields
A-65
42 43
Project Data Project Flexfields
PROJECT PROJECT
4000 4010-4050 Flexfields
A-66
Outbound Purchase Order Changes

(POCO/860/ORDCHG)
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD PO ITEM SHIPMENT (varies) (varies) (varies) Contents Trading Partner Code as defined in the EDI Translator Purchase order number Purchase order line number Shipment Number Record Number Record Layout Record Layout Qualifier
Table A52
Record Trading Ref. 1 22 26-47 PO PO PO PO PO PO Ref. 2 22 48-69 Ref. 3 22 70-91 Record Record Layout Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 TD1
Data Length Position 1 2 3 4 5 6 Control Record Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Detail Flexfields
Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
A-67
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Trading Partner Detail Flexfields Purchase Order Basic Header Payment Terms Purchase Order Basic Header Purchase Order Notes to Supplier Purchase Order Flexfields Purchase Order Flexfields Purchase Order Flexfields Purchase Order Flexfields Supplier Flexfields Supplier Flexfields Supplier Flexfields Supplier Flexfields Supplier Site Flexfields Supplier Site Flexfields Supplier Site Flexfields Supplier Site Flexfields Supplier Site Address Supplier Site Contact Supplier Site Contact Ship to Address/Code Ship to Contacts Bill to Address/Code Bill to Contact Buyer Name Buyer Communications
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO
0070 1000 1010 1020 1030 1040 1050 1060 1070 1080 1090 1100 1110 1120 1130 1140 1150 1160 1170 1180 1190 1200 1210 1220 1230 1240
A2 PO PO PO PO A1 A2 A3 A4 A1 A2 A3 A4 A1 A2 A3 A4 AD CN CN AX CN AX CN PO PO
TD2 PO1 PO2 PO3 PO4 PO1 PO2 PO3 PO4 SU1 SU2 SU3 SU4 SS1 SS2 SS3 SS4 SU1 SS1 SS2 ST1 ST1 BT1 BT1 PO5 PO6
A-68
33 34 35 36 37 38
Procurement Card Header Attachment Master Header Attachment Detail Basic Item Data Basic Item Data Basic Item Data, Hazardous Material Codes
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PO PO PO PO PO PO LINE LINE LINE
1250 1800 1810 2000 2010 2020
PR AT AT IT IT IT
CRD HAH HAD IT1 IT2 IT3
39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Item Note to Supplier Line Flexfields Line Flexfields Line Flexfields Line Flexfields Line Part Flexfields Line Part Flexfields Line Part Flexfields Line Part Flexfields Line Part Segments Line Part Segments Line Attachment Header Line Attachment Detail Master Item Attachment Header Master Item Attachment Detail Inventory Item Attachment Header Inventory Item Attachment Detail Basic Shipment Data
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO PO
LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE SHIP MEN T
2030 2040 2050 2060 2070 2080 2090 2100 2110 2120 2130 2800 2810 2820 2830 2840 2850 3000
IT A1 A2 A3 A4 A1 A2 A3 A4 PS PS AT AT AT AT AT AT SH
IT4 LN1 LN2 LN3 LN4 LP1 LP2 LP3 LP4 PS1 PS2 LAH LAD MAH MAD IAH IAD SH1
A-69
57
Shipment Flexfields
TP_CD
PO
LINE
SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T SHIP MEN T
3010
A1
SH1
58
Shipment Flexfields
TP_CD
PO
LINE
3020
A2
SH2
59
Shipment Flexfields
TP_CD
PO
LINE
3030
A3
SH3
60
Shipment Flexfields
TP_CD
PO
LINE
3040
A4
SH4
61
Ship To Address/Code
TP_CD
PO
LINE
3050
AX
SL1
62
Ship To Contact
TP_CD
PO
LINE
3060
CN
SL1
63
Shipment Attachment Header
TP_CD
PO
LINE
3800
AT
SAH
64
Shipment Attachment Detail TP_CD
PO
LINE
3810
AT
SAD
65
Projects Data
TP_CD
PO
LINE
4000
PR
PR1
66
Projects Flexfields
TP_CD
PO
LINE
4010
PR
PR2
68
Projects Flexfields
TP_CD
PO
LINE
4020
PR
PR3
69
Projects Flexfields
TP_CD
PO
LINE
4030
PR
PR4
70
Projects Flexfields
TP_CD
PO
LINE
4040
PR
PR5
A-70
71
Projects Flexfields
TP_CD
PO
LINE
SHIP MEN T
4050
PR
PR6
A-71
Oracle Receivables Transaction Summaries

Table A53 The following Oracle Purchasing transactions are summarized in this appendix.
Transaction Transaction Name Credit Memo/Debit Memo Invoice Direction Outbound Outbound Code CDMO INO
ASC X12 812 810
EDIFACT CREADV/DEBADV INVOIC
Current Information
A-72
Outbound Credit Memo/Debit Memo

(CDMO/812/CREADV/DEBADV) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Credit Memo/Debit Memo Header Header Allowance and Charges (0010) (1000-3075) (3080-3900)
Credit Memo/Debit Memo Item Line Tax
(4000-5900) (6000-6095) (7000-7900)
Item Allowances and Charges

Records Contents Occurrences Only one record occurrence per transaction Only one record occurrence per transaction One set of records per line within the memo header One set of records per item within the memo line
0010-0070 EDI Gateway Control Records 1000-3900 Memo Header Records 4000-5900 Memo Line Records 6000-7900 Memo Line Detail Records
A-73
Record Data 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Control Record Trading Partner Header Flexfields Trading Partner Detail Flexfields Bill To Address /Code Bill to Misc. Data, Contacts Bill to Customer Flexfields Bill to Site Flexfields Ship to Address/Code Ship to Misc. Data, Contacts Sold to Address/Code Sold to Misc. data, Contact Remit to Address/Code Ship From Codes Basic Memo Header Data Memo Misc. Data Shipment Data Currency Data, Misc. Data, Payment Terms Data Sales Representative, Comments Transaction Flexfields Interface Flexfields Equipment Data Header Allowance/Charges Header Allowance/Charges Flexfields Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER1 HEADER1 HEADER1 ALLOWANCE CHARGES HEADER ALLOWANCE CHARGES HEADER Number 0010 0020-0050 0060-0070 1000 1010-1015 1020-1050 1060-1090 1100 1110-1115 1200 1210-1215 1300-1315 1400 2000 2010-2020 2030 2040 2050 2060 3000-3030 3040-3070 3075 3080-3090 3091-3094 Flexfields Flexfields Flexfields Flexfields Flexfields Custom Custom Note
A-74
25
Extension Tables: Memo Header Data
ALLOWANCE CHARGES HEADER LINE LINE
3900
(Custom)
26 27
Basic Line Data Sales Order Data, Part Descriptions
4000 4010
28 29
Sales Channel Order Status, Transaction Reference Key
LINE LINE
4020 4030
30 31 32 34 34 35 36 37 38 39 40 41 42
Interface Line Flexfields Line Flexfields Line Part Flexfields TP Header Flexfields TP Line Flexfields Industry Flexfields Extension Tables: Item Data Line Tax Data VAT Tax Data Line Tax Flexfields VAT Tax Flexfields Detail Allowance/Charges Detail Allowance/Charges Flexfields Extension Tables: Transaction Line Detail Data
LINE LINE LINE LINE LINE LINE LINE LINE TAX LINE TAX LINE TAX LINE TAX ALLOWANCE CHARGES LINE ALLOWANCE CHARGES LINE ALLOWANCE CHARGES LINE
5000-5030 5040-5070 5100-5130 5140-5160 5170-5190 5200-5220 5900 6000-6020 6025 6030-6060 6070--6095 7000-7010 7100-7130 7900
Flexfields Flexfields Flexfields Flexfields Flexfields Flexfields (Custom)
Flexfields Flexfields
Flexfields (Custom)
A-75
Table A56 Transaction specific Data in the Common Key positions 1-100:
Position 1-25 26-47 48-69 70-91 92-95 96-97 98-100 Code TP_CD MEMO ITEM TAX (Varies) (Varies) (Varies) Content Trading Partner Code as defined in the EDI Translator Credit/Debit Memo number Item sequence number Tax sequence number Record Number Record Layout Record Layout Qualifier
Table A57 Transaction specific Data in the Common Key positions 1-100 per record:
Record Trading Data Length Position 1 2 3 4 5 6 7 8 Control Record Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Bill To Address /Code Bill to Misc. Data, Contacts Bill to TP Reference Codes Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD Ref. 1 22 26-47 MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 0020 0030 0040 0050 1000 1010 1015 Record Layout 2 96-97 CT A3 A4 A4 A4 AD CM RF Layout Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 BT1 BT1 BT1
A-76
9 10 11 12 13 14 15 16 17 18 19 20 21 22 22 23 24 25 26 27 28 29 30
Bill to Customer Flexfields 1-4 Bill to Customer Flexfields 5-9 Bill to Customer Flexfields 10-14 Bill to Customer Flexfield 15 Bill to Site Flexfields 1-4 Bill to Site Flexfields 5-9 Bill to Site Flexfields 10-14 Bill to Site Flexfield 15 Ship to Address/Code Ship to Misc. Data, Contacts Ship to Misc. Data, Contacts Sold to Address/Code Sold to Misc. Data, Contact Sold to TP Reference Remit to Address/Code Remit to TP Reference Ship From Codes Basic Invoice Header Data Memo Amount Data Memo Misc. Data Shipment Data Currency Data, Shipping Data, Miscellaneous Data Payment Terms Data
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO
1020 1030 1040 1050 1060 1070 1080 1090 1100 1110 1115 1200 1210 1215 1300 1315 1400 2000 2010 2020 2030 2040 2050
A1 A2 A2 A2 A1 A2 A2 A2 AD CM RF AD CM RF AD RF SF IV IV IV IV IV IV
BT1 BT2 BT3 BT4 BS1 BS2 BS3 BS4 ST1 ST1 ST1 SO1 SO1 SO1 RE1 RE1 SF1 IV1 IV2 IV3 IV4 IV5 IV6
A-77
31 32 33 34 35 36 37 38 39 40 41 42 43
Sales Representative, Comments Transaction Flexfields 1-4 Transaction Flexfields 5-9 Transaction Flexfields 10-14 Transaction Flexfield 15 Interface Flexfields 1-4 Interface Flexfields 5-9 Interface Flexfields 10-14 Interface Flexfield 15 Memo Header Shipping Instructions Header Allowance/Charges Header Allowance/Charges Header Allowance/Charges Flexfields 1-4 Header Allowance/Charges Flexfields 5-9 Header Allowance/Charges Flexfields 10-14 Header Allowance/Charges Flexfield 15 Extension Tables: Memo Header Data Basic Line Data Sales Order Data, Part, Customer Item Description
MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO
2060 3000 3010 3020 3030 3040 3050 3060 3070 3075 3080 3090 3091
IV A1 A2 A2 A2 A1 A2 A2 A2 IV AH AH AH
IV7 IH1 IH2 IH3 IH4 IH5 IH6 IH7 IH8 IV8 AH1 AH2 IH1
44
TP_CD
MEMO
3092
AH
IH2
45
TP_CD
MEMO
3093
AH
IH3
46
TP_CD
MEMO
3094
AH
IH4
47 48 49
TP_CD TP_CD TP_CD
MEMO MEMO MEMO LINE LINE
3900 4000 4010 IT IT
(Custom) IT1 IT2
A-78
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
Sales Channel, Order Status Transaction Reference Key, Order Status Interface Line Flexfields 1-4 Interface Line Flexfields 5-9 Interface Line Flexfields 10-14
TP_CD TP_CD TP_CD TP_CD TP_CD
MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO
LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE TAX
4020 4030 5000 5010 5020 5030 5040 5050 5060 5070 5100 5110 5120 5130 5140 5150 5160 5170 5180 5190 5200 5210 5220 5900 6000
IT IT A1 A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2 A2 A2 A2 A2 A2 A2 A2 A2 A2
IT3 IT4 IL1 IL2 IL3 IL4 LN1 LN2 LN3 LN4 LP1 LP2 LP3 LP4 HT1 HT2 HT3 LT1 LT2 LT3 IA1 IA2 IA3 (Custom)
Interface Line Flexfield 15 TP_CD Line Flexfields 1-4 Line Flexfields 5-9 Line Flexfields 10-14 Line Flexfield 15 Line Part Flexfields 1-4 Line Part Flexfields 5-9 Line Part Flexfields 10-14 Line Part Flexfield 15 TP Header Flexfields 1-5 TP Header Flexfields 6-10 TP Header Flexfields 11-15 TP Line Flexfields 1-5 TP Line Flexfields 6-10 TP Line Flexfields 11-15 Industry Flexfields 1-5 Industry Flexfields 6-10 Industry Flexfields 11-15 Extension Tables: Item Data Line Tax Data TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
TX
TX1
A-79
75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
Line Tax Type Line Tax Classification Line Tax Code VAT Tax Data Line Tax Flexfields 1-4 Line Tax Flexfields 5-9 Line Tax Flexfields 10-14 Line Tax Flexfield 15 Line VAT Tax Flexfields 1-4 Line VAT Tax Flexfields 5-9 Line VAT Tax Flexfields 10-14 Line VAT Tax Flexfield 15 Detail Allowance/Charges Detail Allowance/Charges Detail Allowance/Charges Flexfields 1-4 Detail Allowance/Charges Flexfields 5-9 Detail Allowance/Charges Flexfields 10-14 Detail Allowance/Charges Flexfield 15 Extension Tables: Transaction Line Detail Data
MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO MEMO
LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE LINE
TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX
6005 6010 6020 6025 6030 6040 6050 6060 6070 6080 6090 6095 7000 7010 7100
TX TX TX TX A1 A2 A2 A2 A1 A2 A2 A2 AL AL AL
TX2 TX3 TX4 TX5 TX1 TX2 TX3 TX4 VT1 VT2 VT3 VT4 AD1 AD2 IL1
90
TP_CD
MEMO
LINE
TAX
7110
AL
IL2
91
TP_CD
MEMO
LINE
TAX
7120
AL
IL3
92
TP_CD
MEMO
LINE
TAX
7130
AL
IL4
93
TP_CD
MEMO
LINE
TAX
7900
(Custom)
A-80
Outbound Invoice
(INO/810/INVOIC) A single transaction has the following data hierarchy and data looping.
Record Numbers Control Record Invoice Header Header Allowance and Charges (0010) (1000-3075) (3080-3900)
Invoice Item Line Tax
(4000-5900) (6000-6095) (7000-7900)
Item Allowances and Charges

Records 0010 Contents Control Records Occurrences Only one record occurrence per transaction One set of records per transaction Only one record occurrence per transaction One set of records per line within the invoice header One set of records per item within the invoice line
0020-0070 Gateway Flexfields 1000-3900 Invoice Header Records 4000-5900 Invoice Line Records 6000-7900 Invoice Line Detail Records
A-81
Record Data 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Control Record Trading Partner Header Flexfields Trading Partner Detail Flexfields Bill To Address /Code Bill to Misc. Data, Contacts Bill to Customer Flexfields Bill to Site Flexfields Ship to Address/Code Ship to Misc. Data, Contacts Sold to Address/Code Sold to Misc. data, Contact Remit to Address/Code Ship From Codes Basic Invoice Header Data Invoice Misc. Data Shipment Data Currency Data, Misc. Data, Payment Terms Data Sales Representative, Comments Invoice Header Flexfields Invoice Header Interface Flexfields Equipment Data Header Allowance/Charges Header Allowance/Charges Flexfields Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER1 HEADER1 HEADER1 ALLOWANCE CHARGES HEADER ALLOWANCE CHARGES HEADER Number 0010 0020-0050 0060-0070 1000 1010-1015 1020-1050 1060-1090 1100 1110-1115 1200 1210-1215 1300-1315 1400 2000 2010-2020 2030 2040 2050 2060 3000-3030 3040-3070 3075 3080-3090 3091-3094 Flexfields Flexfields Flexfields Flexfields Flexfields Custom Custom Note
A-82
25
Extension Tables: Invoice Header Data
ALLOWANCE CHARGES HEADER LINE LINE
3900
(Custom)
26 27
Basic Line Data Sales Order Data, Part Descriptions
4000 4010
28 29
Sales Channel Order Status, Transaction Reference Key
LINE LINE
4020 4030
30 31 32 34 34 35 36 37 38 39 40 41 42 43
Interface Line Flexfields Line Flexfields Line Part Flexfields TP Header Flexfields TP Line Flexfields Industry Flexfields Extension Tables: Item Data Line Tax Data VAT Tax Data Line Tax Flexfields VAT Tax Flexfields Detail Allowance/Charges Detail Allowance/Charges Flexfields Extension Tables: Transaction Line Detail Data
LINE LINE LINE LINE LINE LINE LINE LINE TAX LINE TAX LINE TAX LINE TAX ALLOWANCE CHARGES LINE ALLOWANCE CHARGES LINE ALLOWANCE CHARGES LINE
5000-5030 5040-5070 5100-5130 5140-5160 5170-5190 5200-5220 5900 6000-6020 6025 6030-6060 6070--6095 7000-7010 7100-7130 7900
Flexfields Flexfields Flexfields Flexfields Flexfields Flexfields (Custom)
Flexfields Flexfields
Flexfields (Custom)
Position 1-25 26-47 Code TP_CD INVOICE Content Trading Partner Code as defined in the EDI Translator Invoice number
A-83
48-69 70-91 92-95 96-97 98-100
ITEM TAX (Varies) (Varies) (Varies)
Item sequence number Tax sequence number Record Number Record Layout Record Layout Qualifier
Record Trading Data Length Position 1 2 3 4 5 6 7 8 9 10 Control Record Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Detail Flexfields Trading Partner Detail Flexfields Bill To Address /Code Bill to Misc. Data, Contacts Bill to TP Reference Codes Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD Ref. 1 22 26-47 INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 0020 0030 0040 0050 0060 0070 1000 1010 1015 Record Layout 2 96-97 CT A3 A4 A4 A4 A3 A4 AD CM RF Layout Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 TD1 TD2 BT1 BT1 BT1
A-84
11 12 13 14 15 16 17 18 19 20 21 22 22 23 24 25 26 27
Bill to Customer Flexfields 1-4 Bill to Customer Flexfields 5-9 Bill to Customer Flexfields 10-14 Bill to Customer Flexfield 15 Bill to Site Flexfields 1-4 Bill to Site Flexfields 5-9 Bill to Site Flexfields 10-14 Bill to Site Flexfield 15 Ship to Address/Code Ship to Misc. Data, Contacts Ship to Misc. Data, Contacts Sold to Address/Code Sold to Misc. Data, Contact Sold to TP Reference Remit to Address/Code Remit to TP Reference Ship From Codes Basic Invoice Header Data
INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E
1020 1030 1040 1050 1060 1070 1080 1090 1100 1110 1115 1200 1210 1215 1300 1315 1400 2000
A1 A2 A2 A2 A1 A2 A2 A2 AD CM RF AD CM RF AD RF SF IV
BT1 BT2 BT3 BT4 BS1 BS2 BS3 BS4 ST1 ST1 ST1 SO1 SO1 SO1 RE1 RE1 SF1 IV1
A-85
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Invoice Amount Data Invoice Misc. Data Shipment Data Currency Data, Shipping Data, Miscellaneous Data Payment Terms Data Sales Representative, Comments Invoice Header Flexfields 1-4 Invoice Header Flexfields 5-9 Invoice Header Flexfields 10-14
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E INVOIC E
2010 2020 2030 2040 2050 2060 3000 3010 3020 3030 3040 3050 3060 3070 3075 3080 3090 3091
IV IV IV IV IV IV A1 A2 A2 A2 A1 A2 A2 A2 IV AH AH AH
IV2 IV3 IV4 IV5 IV6 IV7 IH1 IH2 IH3 IH4 IH5 IH6 IH7 IH8 IV8 AH1 AH2 IH1
Invoice Header Flexfield 15 TP_CD Invoice Header Interface Flexfields 1-4 Invoice Header Interface Flexfields 5-9 Invoice Header Interface Flexfields 10-14 Invoice Header Interface Flexfield 15 Invoice Header Shipping Instructions Header Allowance/Charges Header Allowance/Charges Header Allowance/Charges Flexfields 1-4 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
A-86
46
Header Allowance/Charges Flexfields 5-9 Header Allowance/Charges Flexfields 10-14 Header Allowance/Charges Flexfield 15 Extension Tables: Invoice Header Data Basic Line Data
TP_CD
INVOIC E INVOIC E INVOIC E INVOIC E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E
3092
AH
IH2
47
TP_CD
3093
AH
IH3
48
TP_CD
3094
AH
IH4
49 50 51 52 53 54 55 56 57 58 59 60 61 62
TP_CD TP_CD
3900 4000 4010 4020 4030 5000 5010 5020 5030 5040 5050 5060 5070 5100 IT IT IT IT A1 A2 A2 A2 A1 A2 A2 A2 A1
(Custom) IT1 IT2 IT3 IT4 IL1 IL2 IL3 IL4 LN1 LN2 LN3 LN4 LP1
Sales Order Data, Part, TP_CD Customer Item Description Sales Channel, Order Status Transaction Reference Key, Order Status Interface Line Flexfields 1-4 Interface Line Flexfields 5-9 Interface Line Flexfields 10-14 Interface Line Flexfield 15 Line Flexfields 1-4 Line Flexfields 5-9 Line Flexfields 10-14 Line Flexfield 15 Line Part Flexfields 1-4 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
A-87
63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
Line Part Flexfields 5-9 Line Part Flexfields 10-14 Line Part Flexfield 15 TP Header Flexfields 1-5 TP Header Flexfields 6-10 TP Header Flexfields 11-15 TP Line Flexfields 1-5 TP Line Flexfields 6-10 TP Line Flexfields 11-15 Industry Flexfields 1-5 Industry Flexfields 6-10 Industry Flexfields 11-15 Extension Tables: Item Data Line Tax Data Line Tax Type Line Tax Classification Line Tax Code VAT Tax Data
INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E TAX TAX TAX TAX TAX
5110 5120 5130 5140 5150 5160 5170 5180 5190 5200 5210 5220 5900 6000 6005 6010 6020 6025
A2 A2 A2 A2 A2 A2 A2 A2 A2 A2 A2 A2
LP2 LP3 LP4 HT1 HT2 HT3 LT1 LT2 LT3 IA1 IA2 IA3 (Custom)
TX TX TX TX TX
TX1 TX2 TX3 TX4 TX5
A-88
81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
Line Tax Flexfields 1-4 Line Tax Flexfields 5-9 Line Tax Flexfields 10-14 Line Tax Flexfield 15 Line VAT Tax Flexfields 1-4 Line VAT Tax Flexfields 5-9 Line VAT Tax Flexfields 10-14 Line VAT Tax Flexfield 15 Detail Allowance/Charges Detail Allowance/Charges Detail Allowance/Charges Flexfields 1-4 Detail Allowance/Charges Flexfields 5-9 Detail Allowance/Charges Flexfields 10-14 Detail Allowance/Charges Flexfield 15 Extension Tables: Transaction Line Detail Data
INVOIC LINE E INVOIC E LINE
TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX TAX
6030 6040 6050 6060 6070 6080 6090 6095 7000 7010 7100 7110 7120 7130 7900
A1 A2 A2 A2 A1 A2 A2 A2 AL AL AL AL AL AL
TX1 TX2 TX3 TX4 VT1 VT2 VT3 VT4 AD1 AD2 IL1 IL2 IL3 IL4 (Custom)
INVOIC LINE E INVOIC LINE E INVOIC E LINE
INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E INVOIC LINE E
A-89
Oracle Release Management Transaction Summaries
Oracle Release Management Transaction Summaries

Table A62 The following Oracle Release Management transactions are available in Release 11i.1.
Transaction Transaction Name Planning Schedule Production Sequence Shipping Schedule
Current Information
ASC X12 830 866 862 EDIFACT DELFOR N/A DELJIT
Direction Inbound Inbound Inbound
Code SPSI PSQI SSSI
A-90
Oracle Shipping Execution Transaction Summaries
Oracle Shipping Execution Transaction Summaries

Table A63 The following Oracle Shipping Execution transaction is available in Release 11i.1.
Transaction Transaction Name Ship Notice/Manifest Direction Outbound Code DSNO
ASC X12 856
EDIFACT DESADV
Current Information
A-91
Oracle Supplier Scheduling Transaction Summaries

Table A64 The following Oracle Supplier Scheduling transactions are summarized in this appendix.
Transaction Transaction Name Planning Schedule Shipping Schedule Direction Outbound Outbound Code SPSO SSSO ASC X12 830 862 EDIFACT DELFOR DELJIT
Current Information
A-92
Outbound Planning Schedule

(SPSO/830/DELFOR)
Records 0010 0020-0070 1000-1900 2000-2900 4000-4900 Content Control Record Gateway Flexfields Header Records Item Records Authorization/Forecast Schedule Occurrences Only one record occurrence per transaction One set of records per transaction Only one record occurrence per transaction One set of records per item within the Planning Schedule header One records per forecast schedule, authorization or receipt data per item
A-93

Seq. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Data Control Record Trading Partner Header Flexfields Trading Partner Detail Flexfields Basic Planning Schedule Header Supplier Numbers Supplier Site Address/Code Supplier Site Phone Ship to Address/Code Ship to Miscellaneous Data Schedule Header Flexfields Vendor Flexfields Vendor Site Flexfields Shipping Organization Flexfields Ship To Options Flexfields Extension Tables: Purchase Order Header Data 16 17 18 19 20 21 22 23 24 25 Basic Item Data Product Description Hazardous Material Codes Contact Names Last Receipt Data Ship To Organization Address/Code Ship To Organization Data Approved Supplier List Flexfields Item Flexfields Ship To Organization Flexfields ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM 2000 2010 2020 2030 2040 2050 2060 2100-2130 2150-2180 2200-2230 Flexfields Flexfields Flexfields Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER Record Number 0010 0020-0050 0060-0070 1000 1010 1020 1030 1050 1060 1500-1530 1600-1630 1650-1680 1700-1730 1750-1780 1900 Flexfields Flexfields Flexfields Flexfields Flexfields (Custom) Flexfields Flexfields Note
A-94
26 27 28 29 30
Organization Option Flexfields Schedule Item Flexfields Extension Tables: Item Data Forecast and Authorization Data Extension Tables: Forecast and Authorization Data
ITEM ITEM ITEM ITEM DETAILS ITEM DETAILS
2250-2280 2300-2330 2900 (See updates)
Flexfields Flexfields (Custom)
(Custom)
Position Code 1-25 26-47 48-69 70-91 92-95 96-97 98-100 TP_CD PS ITEM SCHEDULE (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Planning Schedule number Planning Schedule line number Schedule Bucket Number Record Number Record Layout Record Layout Qualifier
Record Trading Data Length Position 1 2 3 4 Control Record Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD Ref. 1 22 26-47 PS PS PS PS Ref. 2 22 48-69 Ref. 3 22 70-91 Record Number 4 92-95 0010 0020 0030 0040 Record Layout 2 96-97 CT A1 A2 A2 Layout Qualifier 3 98-100 CTL TH1 TH2 TH3
A-95
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Trading Partner Header Flexfields Trading Partner Detail Flexfields Trading Partner Detail Flexfields Planning Schedule Header Planning Schedule Header Planning Schedule Header Planning Schedule Header Planning Schedule Header Planning Schedule Header Schedule Header Flexfields 1-4 Schedule Header Flexfields 5-9 Schedule Header Flexfields 10-14 Schedule Header Flexfield 15 Vendor Flexfields 1-4 Vendor Flexfields 5-9 Vendor Flexfields 10-14 Vendor Flexfield 15 Vendor Site Flexfields 1-4 Vendor Site Flexfields 5-9
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS
0050 0060 0070 1000 1010 1020 1030 1050 1060 1500 1510 1520 1530 1600 1610 1620 1630 1650 1660 1670 1680 1700 1710
A2 A1 A2 HD SP AD CN AX ST A1 A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2 A1 A2
TH4 TD1 TD2 FRC SU SS SS ST1 ST2 SH1 SH2 SH3 SH4 VN1 VN2 VN3 VN4 VS1 VS2 VS3 VS4 ST1 ST2
Vendor Site Flexfields 10-14 TP_CD Vendor Site Flexfield 5 Shipping Organization Flexfields 1-4 Shipping Organization Flexfields 5-9 TP_CD TP_CD TP_CD
A-96
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Shipping Organization Flexfields 10-14 Shipping Organization Flexfield 15 Ship To Options Flexfields 1-4 Ship To Options Flexfields 5-9 Ship To Options Flexfields 10-14 Ship To Options Flexfield 15 Extension Tables: Schedule Level Basic Item Data Product Description Hazardous Material Data Contact Names Last Receipt Data Ship to Organization Address/Code Ship to Organization Data Approved Supplier List Flexfields 1-4 Approved Supplier List Flexfields 5-9 Approved Supplier List Flexfields 10-14 Approved Supplier List Flexfield 15 Item Flexfields 1-4 Item Flexfields 5-9 Item Flexfields 10-14 Item Flexfield 15
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS PS ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM
1720 1730 1750 1760 1770 1780 1900 2000 2010 2020 2030 2040 2050 2060 2100 2110 2120 2130 2150 2160 2170 2180
A2 A2 A1 A2 A2 A2 (Custo m) IT IT HZ CN LS AX ST A1 A2 A2 A2 A1 A2 A2 A2
ST3 ST4 OP1 OP2 OP3 OP4 (Custom) IT1 IT2 HZ1 IT1 LS1 SI2 SI3 AS1 AS2 AS3 AS4 IT1 IT2 IT3 IT4
A-97
50 51 52 53 54 55 56 57 58 59 60 61 62 63
Ship to Organization Flexfields (item) 1-4 Ship to Organization Flexfields (item) 5-9 Ship to Organization Flexfields (item) 10-14 Ship to Organization Flexfield (item) 15 Organization Option Flexfields 1-4 Organization Option Flexfields 5-9 Organization Option Flexfields 10-14 Organization Option Flexfield 15 Schedule Item Flexfields 1-4 Schedule Item Flexfields 5-9 Schedule Item Flexfields 10-14 Schedule Item Flexfield 15 Extension Tables: Item Level Forecast Dates, Authorization, Receipt Data
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
PS PS PS PS PS PS PS PS PS PS PS PS PS PS
ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM SCHEDU LE
2200 2210 2220 2230 2250 2260 2270 2280 2300 2310 2320 2330 2900 4000
A1 A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2 (Custo m) SC
DI1 DI2 DI3 DI4 SO1 SO2 SO3 SO4 SI1 SI2 SI3 SI4 (Custom) SCH
64
Extension Tables: Forecast Level
TP_CD
PS
ITEM
SCHEDU LE
4900
(Custo m)
(Custom)
Outbound Shipping Schedule

(SSSO/862/DELJIT)
A-98

Records 0010 0020-0070 1000-1900 2000-2900 4000-4900 Content Control Records Gateway Flexfields Header Records Item Records Authorization/Forecast Schedule Occurrences Only one record occurrence per transaction One set of records per transaction Only one record occurrence per transaction One set of records per item within the Shipping Schedule header One records per forecast schedule, authorization or receipt data per item

Seq. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Data Control Record Trading Partner Header Flexfields Trading Partner Detail Flexfields Basic Planning Schedule Header Supplier Numbers Supplier Site Address/Code Supplier Site Phone Ship to Address/Code Ship to Miscellaneous Data Schedule Header Flexfields Vendor Flexfields Vendor Site Flexfields Shipping Organization Flexfields Ship To Options Flexfields Extension Tables: Purchase Order Header Data 16 Basic Item Data ITEM 2000 Data Level HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER HEADER Record Number 0010 0020-0050 0060-0070 1000 1010 1020 1030 1050 1060 1500-1530 1600-1630 1650-1680 1700-1730 1750-1780 1900 Flexfields Flexfields Flexfields Flexfields Flexfields (Custom) Flexfields Flexfields Note
A-99
17 18 19 20 21 22 23 24 25 26 27 28 29 30
Product Description Hazardous Material Codes Contact Names Last Receipt Data Ship To Organization Address/Code Ship To Organization Data Approved Supplier List Flexfields Item Flexfields Ship To Organization Flexfields Organization Option Flexfields Schedule Item Flexfields Extension Tables: Item Data Forecast and Authorization Data Extension Tables: Forecast and Authorization Data
ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM DETAILS ITEM DETAILS
2010 2020 2030 2040 2050 2060 2100-2130 2150-2180 2200-2230 2250-2280 2300-2330 2900 4000 4900 (Custom) Flexfields Flexfields Flexfields Flexfields Flexfields (Custom)
A-100
Outbound Shipping Schedule

(SSSO/862/DELJIT)
Position Code 1-25 26-47 48-69 70-91 92-95 96-97 98-100 TP_CD SS ITEM SCHEDULE (varies) (varies) (varies) Content Trading Partner Code as defined in the EDI Translator Shipping Schedule number Shipping Schedule line number Schedule Bucket Number Record Number Record Layout Record Layout Qualifier
Record Trading Data Length Position 1 2 3 4 5 6 Control Record Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Header Flexfields Trading Partner Detail Flexfields Partner 25 1-25 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD Ref. 1 22 26-47 SS SS SS SS SS SS Ref. 2 22 48-69 Ref. 3 22 70-91 Record Record Layout Qualifier 3 98-100 CTL TH1 TH2 TH3 TH4 TD1
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Trading Partner Detail Flexfields Planning Schedule Header Planning Schedule Header Planning Schedule Header Planning Schedule Header Planning Schedule Header Planning Schedule Header Schedule Header Flexfields 1-4 Schedule Header Flexfields 5-9 Schedule Header Flexfields 10-15 Schedule Header Flexfield 15 Vendor Flexfields 1-4 Vendor Flexfields 5-9 Vendor Flexfields 10-14 Vendor Flexfield 15 Vendor Site Flexfields 1-4 Vendor Site Flexfields 5-9 Vendor Site Flexfields 10-14 Vendor Site Flexfield 15 Shipping Organization Flexfields 1-4 Shipping Organization Flexfields 5-9
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS
0070 1000 1010 1020 1030 1050 1060 1500 1510 1520 1530 1600 1610 1620 1630 1650 1660 1670 1680 1700 1710
A2 HD SP AD CN AX ST A1 A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2 A1 A2
TD2 FRC SU SS SS ST1 ST2 SH1 SH2 SH3 SH4 VN1 VN2 VN3 VN4 VS1 VS2 VS3 VS4 ST1 ST2
A-102
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Shipping Organization Flexfields 10-14 Shipping Organization Flexfield 15 Ship To Options Flexfields 1-4 Ship To Options Flexfields 5-9 Ship To Options Flexfields 10-14 Ship To Options Flexfield15 Extension Tables: Schedule Level Basic Item Data Product Description Hazardous Material Data Contact Names Last Receipt Data Ship to Organization Address/Code
SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM
1720 1730 1750 1760 1770 1780 1900 2000 2010 2020 2030 2040 2050 2060 2100 2110 2120 2130 2150 2160 2170 2180
A2 A2 A1 A2 A2 A2
ST3 ST4 OP1 OP2 OP3 OP4
(Custom (Custom) ) IT IT HZ CN LS AX ST A1 A2 A2 A2 A1 A2 A2 A2 IT1 IT2 HZ1 IT1 LS1 SI2 SI3 AS1 AS2 AS3 AS4 IT1 IT2 IT3 IT4
Ship to Organization Data TP_CD Approved Supplier List Flexfields 1-4 Approved Supplier List Flexfields 5-9 Approved Supplier List Flexfields 10-14 Approved Supplier List Flexfield15 Item Flexfields 1-4 Item Flexfields 5-9 Item Flexfields 10-14 Item Flexfield 15 TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
50 51 52 53 54 55 56 57 58 59 60 61 62 63
Ship to Organization Flexfields (item) 1-4 Ship to Organization Flexfields (item) 5-9 Ship to Organization Flexfields (item) 10-14 Ship to Organization Flexfield (item) 15 Organization Option Flexfields 1-4 Organization Option Flexfields 5-9 Organization Option Flexfields 10-14 Organization Option Flexfield 15 Schedule Item Flexfields 1-4 Schedule Item Flexfields 5-9 Schedule Item Flexfields 10-14 Schedule Item Flexfield 15 Extension Tables: Item Level Forecast Dates, Authorization, Receipt Data
TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD TP_CD
SS SS SS SS SS SS SS SS SS SS SS SS SS SS
ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM ITEM SCHEDU LE
2200 2210 2220 2230 2250 2260 2270 2280 2300 2310 2320 2330 2900 4000
A1 A2 A2 A2 A1 A2 A2 A2 A1 A2 A2 A2
DI1 DI2 DI3 DI4 SO1 SO2 SO3 SO4 SI1 SI2 SI3 SI4
(Custom (Custom) ) SC SCH
64
Extension Tables: Forecast Level
TP_CD
SS
ITEM
SCHEDU LE
4900
(Custom (Custom) )
A-104

Oracle E-Commerce Gateway Implementation Manual, Volume 1

Uploaded by

Copyright:

Available Formats

Oracle E-Commerce Gateway Implementation Manual, Volume 1

Uploaded by

Document Information

Original Title

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

Oracle E-Commerce Gateway Implementation Manual, Volume 1

Uploaded by

Copyright:

Available Formats

Oracle e-Commerce Gateway Implementation Manual