Trading Partner

This chapter contains trading partner information.

This chapter covers the following topics:

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 through 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.

For the consideration of multiple organizations, you can associate Trading Partners with operating units linked to your responsibility through the Trading Partner Group setups. Once a Trading Partner Group is linked to an operating unit, all Trading Partners within the group are all automatically associated with the selected operating unit; the associated Trading Partner addresses are also linked to the selected operating unit as well. Additionally, the Trading Partner Type, such as a customer, supplier, or bank, will also be restricted to the operating unit.

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:

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.

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. For example, a car manufacturer may group its Trading Partners by seat suppliers, tire manufacturers, windshield 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.

Additionally, to support multiple organizations, Oracle e-Commerce Gateway allows you to associate Trading Partner groups with operating units restricted to the security profile linked to your responsibility. All Trading Partners within the groups are assigned to the same operating units; the associated Trading Partner addresses for the same operating units can be viewed and set up. For example, the seat suppliers group for a car manufacturer is associated with the Vision USA operating unit; all Trading Partners and the associated addresses within the seat suppliers group are all assigned to the same operating unit, Vision USA.

When multiple operating units are associated with your responsibility, if you want to associate a different set of addresses for the same Trading Partner group and same Trading Partner, then you have to reselect the operating unit, such as change it from Vision USA to Vision Europe, in the Trading Partner Group form first and then change the setup for the underlying Trading Partners. This way, the associated Trading Partner addresses for Vision Europe can be viewed for selection when defining Trading Partners for the group. The operating unit is relevant to the underlying addresses only and not to the Trading Partner groups or Trading Partner headers.

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.

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 E-Business Suite 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 E-Business Suite. 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 Oracle E-Business Suite 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 E-Business Suite application where address sites are defined. The EDI Location Code exists to link the address site in the base Oracle E-Business Suite application to the Oracle e-Commerce Gateway process.

The following table summarizes the purpose of the EDI Location Codes as defined in the base application and when used in the transaction interface file.

Purposes of EDI Location Codes in Base Oracle E-Business Suite Application
EDI Location Purpose for Outbound Transactions Purpose for Inbound Transactions
Define in base Oracle E-Business Suite application 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 (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.
Found in the transaction's Control Record (0010) 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.		 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 E-Business Suite application Open Interface tables. All the address sites in the transaction will be associated to this derived customer or supplier.
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 Oracle E-Business Suite application open interface tables.

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:

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.

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. The following table shows an example of multiple Translator Codes:

Example of Multiple Translator Codes
Transaction Type Document (from Trading Partner Detail Tab) Translator Code (from Trading Partner Detail Tab) Address Site (from Trading Partner Assignment Tab)
POO Outbound Purchase Orders MAILBOX_PROC C-SJ EDI Location Code for Supplier Site*
INI Inbound Invoices MAILBOX_FIN C-SJ EDI Location Code for Remit To Site*

Note: *Same address site is used for the Supplier and Remit location.

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 may use the same Translator Code (like the electronic mailbox that it is associated with), depending on how the Trading Partners are defined in the base Oracle E-Business Suite application.

For instance, one Trading Partner mailbox may be shared by a corporation's east coast and west coast offices, though they may be defined as two Trading Partners (customers or suppliers) in the base application. In the example in the following table, the Oracle Supplier is derived from the Supplier site associated with the EDI Location Code and Translator Code found on the Control Record (0010).

Example of Shared Translator Codes on the Control Record (0010)
Translator Code (from e-Commerce Gateway) EDI Location (from e-Commerce Gateway) Supplier Site (from Oracle Purchasing) Supplier Site ID (from Oracle Purchasing) Supplier (from Oracle Purchasing) Supplier ID (from Oracle Purchasing)
A1-ACME-10 AC-BOST Boston 64354345 ACME-EAST 135678
A1-ACME-10 AC-DEN Denver 12343221 ACME-WEST 654322

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.

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:

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. 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.)

Linking Trading Partner Data to the Oracle E-Business Suite Application Source

The following illustration relates the Trading Partner data in the Oracle e-Commerce Gateway windows to the address site in the Oracle E-Business Suite.

Trading Partner Data Relates to the Address Site in Oracle E-Business Suite

the picture is described in the document text

The supplier illustration above highlights the following key items when assigning a Trading Partner to a suppler/supplier site in Oracle Payables:

EDI Location Codes in the Transaction Interface Files

Inbound Transactions

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 E-Business Suite 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 E-Business Suite application is when its EDI Location code is used in the Control Record.

A fully defined Trading Partner means the following:

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:

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 types of location 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.

The following table shows examples of Type of Site Location Codes on the Control Record for Inbound Transactions.

Examples of Type of Site Location Code on the Control Record (0010) for Inbound Transactions
Transaction Transaction Code ASC X12 EDIFACT Type of Site Location Code to Copy from the Transaction Detail into the Control Record 0010
Invoice INI 810 INVOIC Supplier Site
Planning Schedule SPSI 830 DELFOR Supplier Ship To Site
Price/Sales Catalog CATI 832 PRICAT Supplier Site
Production Sequence PSQI 866   Supplier Ship To Site
Purchase Orders POI 850 ORDERS Customer Ship To Site
Response to Request for Quotation RRQI 843 REQOTE Supplier Site
Ship Notice and Billing SBNI 857   Customer Ship To Site
Ship Notice/Manifest ASNI 856 DESADV Customer Ship To Site
Shipping Schedule SSSI 862 DELJIT Supplier Ship To Site

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 E-Business Suite 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 E-Business Suite 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 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 application, the site's column ID can be passed to the Oracle E-Business Suite 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.

Any address site in the transaction detail such as the customer/customer site or supplier/supplier site must be defined in the base 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, or remit to) in the transaction is recognized by the Oracle e-Commerce Gateway as the key address site to examine for the Trading Partner setup.

The Oracle e-Commerce Gateway predetermines 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 site's outbound transactions are to be extracted.

The following table shows sample Primary Address Site Types on the Control Record (0010) for Outbound Transactions.

Examples of Primary Address Site Types on the Control Record (0010) for Outbound Transaction
Transaction Transaction Code ASC
X12		 EDIFACT Site Address Type for the Control Record 0010
Application Advice
(for 810)		 ADVO 824 APERAK Supplier Site
Invoice INO 810 INVOIC Customer Bill To Site
Movement Statistics MVSTO   CUSDEC Legal Entity
Payment/Remittance Advice PYO 820 REMADV/
PAYORD-PAYEXT		 Paying Bank Branch
Planning Schedule SPSO 830 DELFOR Supplier Site
Purchase Order Change POCO 860 ORDCHG Supplier Site
Purchase Orders POO 850 ORDERS Supplier Site
Ship Notice/Manifest ASNO 856 DESADV Customer Ship to Site
Shipping Schedule SSSO 862 DELJIT Supplier Site

Note: The Trading Partner site must be fully defined as a Trading Partner in the Oracle e-Commerce Gateway and the base Oracle E-Business Suite application to have the Trading Partner site's transaction extracted.

Like the inbound transaction, a fully defined Trading Partner means the following:

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 E-Business Suite 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.

Any address site in the transaction detail such as the customer/customer site or supplier/supplier site must still be defined in the base application and the EDI Location Code for the site must be entered. If the EDI Location Code is not entered in the base 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 Transaction Detail Address Records.

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, the table below shows the three customer addresses defined in Oracle Order Entry/Oracle Receivables for the Customer "Acme Corp.", with Customer ID "123423." For this customer, the EDI Location Code "CHIC" could be used as a Default EDI Location Code in the Control Record (0010). 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 setup for the address associated with "CHIC" must be fully defined as a Trading Partner in the Oracle e-Commerce Gateway.

Address Table Physical Address EDI Location Code* EDI Location Code Determines Address ID Address is Linked to Customer ID Use as a Default for EDI Location Code on the Control Record (0010)
Address 1 654 South Blvd., Indianapolis, IN INDY 23245 123423  
Address 2 123 Main St., Chicago, IL CHIC 74536 123423 CHIC
Address 3 876 North Ave., Atlanta GA ATLA 45234 123423  

Note: * 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 E-Business Suite application including entering the EDI Location code in order to process the transaction.

Multiple Organizations

Oracle e-Commerce Gateway supports multiple organizations by associating Trading Partners with operating units linked to your responsibility during the Trading Partner group setup. Once the operating units are assigned to Trading Partner groups, the Trading Partners within the groups are automatically associated with the specified operating units. Therefore, when defining Trading Partners, you will find only those addresses associated with the specified operating units that are linked to your responsibility from the list of values for selection.

When multiple operating units are associated with your responsibility, if you want to associate a different set of addresses for the same Trading Partner group and same Trading Partner, then you have to reselect the operating unit in the Trading Partner Group form and then change the setup for the underlying Trading Partners. The operating unit is relevant to the underlying addresses only and not to the Trading Partner groups or Trading Partner headers.

Access Control Security by Operating Units

To have a secured way for users to access operating units, Oracle e-Commerce Gateway uses the security profile concept that allows system administrators to predefine the scope of access privileges as a security profile, and then use the profile option MO: Security Profile to associate the security profile with a responsibility. Multiple operating units are associated with a security profile and the security profile is in turn associated with a responsibility. Therefore, through the access control of security profiles, users can access data in multiple operating units without changing responsibility.

Security profiles are defined based on organization hierarchies. For example, a sales company consists of USA and UK operating units; the USA operating unit has Western Region Sales and East Region Sales. Sales managers are responsible for both USA and UK sales; supervisors are responsible for either USA or UK, and sales representatives are only responsible for their designated sales regions. The Sales organization hierarchy can be illustrated as follows:

Sales Organization Hierarchy

the picture is described in the document text

To secure sales data within the company, relevant operating units can be associated with predefined security profiles. For example, all sales data access privileges are grouped into the Vision Sales security profile; USA Sales security profile is for USA related data, and regional security profiles are for designated regional data. System administrators can associate these security profiles containing multiple operating units with users through appropriate responsibilities. Therefore, sales supervisors can easily access sales data in the Eastern or Western region without changing their responsibilities. The following diagram illustrates the relationship between security profiles, responsibilities, and operating units for this sales company:

Relationship Diagram Between Security Profiles, Responsibilities, and Operating Units

the picture is described in the document text

EDI Location Code in Multiple Organizations

The Oracle e-Commerce Gateway process limits its address site table search to base Oracle E-Business Suite application address column IDs defined with the same organization specified in the Oracle e-Commerce Gateway responsibility.

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 E-Business Suite application, the EDI locations are defined as two address sites.

Example of EDI Location Code in Multiple Organizations
Customer or Supplier Address Site Trading Partner's Translator Code   Trading Partner Location Code (on N1 or NAD segment)   base Oracle Application has two Address Site IDs * Organization for the Address Site ID **
Acme Inc. 123 Main St.
Chicago , IL		 E1-ACME + AB123 = 12345678 A
Beta Inc. 123 Main St.
Chicago , IL		 E3-BETA + AB123 = 13567890 B

Note: * The address Site column ID is assigned through 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 E-Business Suite 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 E-Business Suite application, then EDI Location Codes cross reference process will not successfully find the addresses in the base application tables. This happens because the Oracle e-Commerce Gateway reads only trading partner sites for the specified organization in the responsibility.

EDI Responsibility

All organizations in the multiple-organization 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 application address sites, which are assigned to the single organization specified in the EDI Responsibility.

For inbound transactions, the EDI import process also has a single organization assigned in the EDI Responsibility for that particular execution.

For outbound transactions, if the concurrent programs are for a single organization, Oracle e-Commerce Gateway will extract data for a specific operating unit. If they are for multiple organizations, then the data can be extracted for all operating units associated with your responsibility or for a specified operating unit.

For reports, since Trading Partners can be associated with operating units linked to your responsibility during the Trading Partner group setups, if the Trading Partner reports or the Transactions / Trading Partners reports are for multiple organizations, you can run the reports for all operating units associated with your responsibility or for a specified operating unit. If the reports are for a single organization, then the reports can be run for a specified operating unit.

If the transaction interface file contains transactions associated with several organizations, the transactions for the other organizations not defined in the current process's EDI Responsibility will not successfully find the Trading Partner's EDI Location Codes with the base Oracle E-Business Suite 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 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.

  2. 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 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:

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 electronic envelope. Consequently, transactions can be processed into different organizations.

The following table shows an example of transactions separated into different locations by the sending Trading Partner.

Example of Separating Transactions into Different Locations
Sending Trading Partner
(set up different Location Codes with the same physical address)		 Sending Trading Partner
Assume Items must be booked to different Organizations		 Sending Trading Partner
Send to same EDI Mailbox but different Functional Group		 Receiving
Trading Partner
(separate each location into separate files for processing in the Oracle e-Commerce Gateway)		 Receiving Trading Partner
Organization		 Note on Process:
Location Code ‘ABC-A' for
11 State St., Chicago, IL		 Enter orders for
Items A, B, C		 Mailbox 123456789;
functional group 900		 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.
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-B' has table address site ID 54321		 This address site ID has organiza-tion ‘B' 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.

The following table shows a sample of transactions separated into different electronic envelopes or functional groups by the sending Trading Partner.

Example of Separating Transactions into Different Electronic Envelopes or Functional Groups
Sending Trading Partner Sending EDI Translator:
Electronic Envelope (X12 ISA or UN/EDIFACT UNB)		 Sending EDI Translator:
Functional Group (X12 GS or UN/EDIFACT UNG)		 Receiving EDI Translator
Transaction with Location
‘ABC-A' code in their application		 123456789 900 Writes the data from this functional
group to file for Organization ‘A' processing
Transaction with Location
‘ABC-B' code in their application		 123456789 911 Writes the data from this functional
group to file for Organization ‘B' processing

Organizations in Oracle E-Business Suite Application Open Interface Tables

Even if transactions across all organizations could be loaded into the Oracle E-Business Suite 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 E-Business Suite product for their specific processing rules.

Trading Partner Windows

The Trading Partner windows are discussed below. Read the preceding section on Trading Partner detail.

Refer to the Oracle e-Commerce Gateway User‘s Guide and Set Up Trading Partners 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. A Trading Partner Group may be a supplier or customer name, or any entity that you choose.

Since Trading Partner Groups can be associated with operating units linked to your responsibility to support a multiple-organization environment, once an operating unit is associated with a Trading Partner Group, all Trading Partners within the group are all assigned to the same operating unit. When an operating unit is added to a Trading Partner Group, the associated organization ID is also added to the group.

Trading Partner Naming Convention

Using a naming convention for your Trading Partners is recommended for easy recognition. The three components in the following table are recommended. The combination of codes must be unique. Note that a delimiter between fields improves readability.

A naming convention also facilitates custom code to generate Partner names from the base Oracle E-Business Suite application for initialization of the Trading Partner tables or during updates after implementation.

Trading Partner Naming Convention Recommended Components
Component Description Sample Note
Organization Organization Code A  
Trading Partnership Trading Partner ACME  
Trading Partner Site Address Site Code INDY This may be a site or more refined descriptor
Description Free window text that describes the components above. Other descriptive data can be added A, Acme, Indy, 45 Meridian  

Example: A-ACME-INDY for A, Acme, Indy, 45 Meridian

The following table lists examples of trading partner names using the prefix and suffix conventions, and shows how the lists would be sorted:

Examples of Trading Partner Names Using Prefix and Suffix Conventions
Prefix Organization on Partner Name Suffix Organization on Partner Name
A-Acme-SJ Acme-Atl-B
A-Beta-Chic Acme-Bos-C
B-Acme-Atl Acme-SJ-A
B-Beta-Indy Beta-Atl-B
C-Acme-Bos Beta-Chic-A
C-Beta-Atl Beta-Indy-B
Result:
Listed by Organization		 Result:
Listed by Partner name

Trading Partner Lists

All Trading Partners, regardless of organization (in a multiple-organization 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 organization context associated with the EDI Responsibility.

Multiple-Organization 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 online.

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 E-Business Suite 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 E-Business Suite 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 application.

In a multiple-organization environment, only those customer addresses defined to the operating unit for the current EDI responsibility are presented for selection.

Multiple-Organization Note: The list of values of Trading Partner addresses in the Assignment tab list only those addresses associated with the assigned operating unit.

When multiple operating units are associated with your responsibility, if you want to associate a different set of addresses for the same Trading Partner group and same Trading Partner, then you have to reselect the operating unit in the Trading Partner Groups form and then change the setup for the underlying Trading Partners. The operating unit is relevant to the underlying addresses only and not to the Trading Partner groups or Trading Partner headers.

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 Partner's EDI Coordinator's 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 Partner's EDI Coordinator's contact data. This data is for reference only. It is not used by Oracle e-Commerce Gateway.

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: