Overview of Trading Partners (Oracle EDI Gateway Help)


	Previous	Next		Contents	Index	Navigation	Glossary	Library

Overview of Trading Partners

The term "trading partner" is used differently in the context of EDI translators than in the context of the EDI Gateway.

For EDI translators, the purpose of trading partner data is to:

identify sending and receiving electronic mailbox addresses

identify the communication medium (such as network or direct connection)

enable specific transactions by trading partner

For the Oracle EDI Gateway, the purpose of trading partner data is to:

cross-reference a particular address location in Oracle Applications to the location code defined for the trading partner for that address

link the EDI translator trading partner identifier to the EDI Gateway trading partner for the primary business address entity in the transaction

enable specific transactions for the EDI Gateway trading partner

In the EDI Gateway, the trading partner is defined as any address in Oracle Applications. This allows the conversion of location codes between the sender's defined code in their application to the receiver's defined code in their Oracle Application and vice versa. The translator code definition in the EDI Gateway identifies the trading partner setup code as defined in the EDI translator.

For example, assume the trading partner defined the address code as AL-012. However, the same physical address was defined as 1234 in Oracle Applications. Defining the trading partner location in the appropriate Oracle application ensures that the code AL-012 is returned in transactions.

When defining trading partner data in the EDI Gateway, transactions must be enabled for the trading partner in order for data to be imported or extracted and written to the data file.

Inbound Transactions

The primary trading partner location is the location in the transaction detail records that is reviewed in the EDI Gateway to determine the key business entity that has ownership of this transaction in the Oracle Application. This entity is at the address or site level in the transaction. The higher level customer or supplier definition (without addresses) is determined by the primary site entity found within the transaction.

The EDI translator writes a trading partner code for the record 0010 control record but it is not reviewed by the EDI Gateway. The detail location codes extracted from N104 and NAD records are reviewed within the EDI Gateway to determine the primary entity as needed by the Oracle application.

Outbound Transactions

The primary trading partner location is the address location reviewed within the transaction to determine the trading partner code for the record 0010 control record. This is the coded that links the transaction to the trading partner definition in the EDI translator.

Document Direction ASC X12 EDIFACT Content Primary Trading Partner Location

INI Inbound 810 INVOIC Invoice SUPPLIER SITE

CATI Inbound 832 PRICAT Price / Sales Catalog SUPPLIER SITE

RRQI Inbound 843 QUOTES Response to Request for Quotation SUPPLIER SITE

POI Inbound 850 ORDERS Purchase Orders SHIP TO

ANSI Inbound 856 DESADV Ship Notice / Manifest SUPPLIER SITE

SBNI Inbound 857 n/a Shipment and Billing Notice SHIP TO

INO Outbound 810 INVOIC Invoice BILL TO

PYO Outbound 820 REMADV / PAYORD Payment Order / Remittance Advice PAYING BANK BRANCH

SPSO Outbound 830 DELFOR Planning Schedule SUPPLIER SITE

POO Outbound 850 ORDERS Purchase Orders SUPPLIER SITE

POCO Outbound 860 ORDCHG Purchase Order Change SUPPLIER SITE

SSSO Outbound 862 DELJIT Shipping Schedule SUPPLIER SITE

Table 1 - 2.

Document	Direction	ASC X12	EDIFACT	Content	Primary Trading Partner Location
INI	Inbound	810	INVOIC	Invoice	SUPPLIER SITE
CATI	Inbound	832	PRICAT	Price / Sales Catalog	SUPPLIER SITE
RRQI	Inbound	843	QUOTES	Response to Request for Quotation	SUPPLIER SITE
POI	Inbound	850	ORDERS	Purchase Orders	SHIP TO
ANSI	Inbound	856	DESADV	Ship Notice / Manifest	SUPPLIER SITE
SBNI	Inbound	857	n/a	Shipment and Billing Notice	SHIP TO
INO	Outbound	810	INVOIC	Invoice	BILL TO
PYO	Outbound	820	REMADV / PAYORD	Payment Order / Remittance Advice	PAYING BANK BRANCH
SPSO	Outbound	830	DELFOR	Planning Schedule	SUPPLIER SITE
POO	Outbound	850	ORDERS	Purchase Orders	SUPPLIER SITE
POCO	Outbound	860	ORDCHG	Purchase Order Change	SUPPLIER SITE
SSSO	Outbound	862	DELJIT	Shipping Schedule	SUPPLIER SITE
Table 1 - 2.

Each trading partner is assigned a primary address to associate with the transaction, such as bill-to address for outbound invoices or ship-to address for inbound purchase orders.

If a trading partner is both a customer and a supplier, Oracle recommends that you define the partner twice, once as a customer and once as a supplier. For each, enter a note in the trading partner description field to indicate whether it is the customer or supplier definition.

You must define a trading partner header for every location code found in the transaction. For example, an outbound invoice may have a remit-to location and a ship-to location. Both locations must be defined as trading partners in the EDI Gateway to define the external location code to appear in transactions.

Test / Production Transaction Status

Each application open interface has its own processing rules for validating EDI inbound transactions, including those marked as test transactions. The test / production status code is found on the control record (0010) in the data file. The status code is set by the EDI translator for inbound transactions. For outbound transactions, the status code is set by the EDI Gateway.

Some open interface programs include a test / production status code as one of the parameters entered when you launch the Standard Request. This status code may override the test / production status code found in the control record (0010) for each transaction.

Note: The test / production status code may be presented differently for various reasons. For example, T for Test, P for Production, or Y for Yes.

If the application open interface table has a test / production status code, the following may happen:

the test / production status code is passed from the control record of each transaction to the open interface table without being overridden by the Standard Request Submission or the open interface.

the test /production status code is passed from the control record but overridden by the test / production code from the Standard Request Submission parameters

the test / production status code is ignored by the application open interface and is determined from the Standard Request Submission parameters.

For further information, refer to the Oracle Manufacturing and Distribution Open Interfaces Manual, Release 11 or the Oracle Financials Open Interfaces Manual, Release 11.

EDI in a Multi-Organization Environment

A separate EDI responsibility must be defined for each organization that processes EDI transactions. Therefore, you must run EDI transactions separately by organization.

Note: Some outbound transactions may operate on all organizations. However, you must still define a separate responsibility for each organization.

For outbound transactions, you extract data for the organization assigned to the current responsibility. So, if you intend to extract data from multiple organizations, you must do so from separate responsibilities.

For inbound transactions, the EDI translator, another process, or the trading partner sending the data file must separate the transactions by organization before the EDI Gateway imports the data. In other words, each data file sent by a trading partner should contain only those transactions into the specific organization.

If you intend to extract data from multiple organizations, you must switch to Transactions associated with other organizations will not successfully cross-reference the trading partner's location codes. The EDI Gateway associates the organization defined in the EDI Gateway responsibility with each primary trading partner location during the location cross reference. If the responsibility has organization A, but all the trading partner primary locations in the transactions are defined to organization B in the Oracle Application, the location codes cross reference process cannot find the location in the Oracle Application. The EDI Gateway reads only trading partner locations for the specified organization.

Attention: During code conversion, the organization defined in the EDI responsibility is assigned to the trading partner primary location. If that organization is not correct for the location, the application open interface rejects the transaction during validation. Review the error report or on-line error handling procedure for the specific application.

Separate Transactions by Location

EDI translators can separate transactions into different data files. Transactions can be segregated into:

different trading partner electronic envelopes

different functional groups within the same electronic envelope

different mailboxes.

One solution is to have your trading partner separate the transactions in separate address locations that mirror your different organizations. 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. They can define unique address site / location codes in their application even those codes have the same physical address. The EDI translator can then separate the transactions to different electronic envelopes or functional groups within envelopes. The transactions can then be processed separately into different organizations.

Address Site ID Retrieval

Each transaction is associated with a primary internal location address site defined in the Oracle application. That has a corresponding external location code defined by the trading partner. The external code is the location code found in the ASC X12 N1 name segment or the UN/EDIFACT NAD name and address segment. Multiple customers could use the same external location codes because the combination of their trading partner translator code (their identifier in the EDI translator) and their external location code make a unique combination in the EDI Gateway trading partner definition. This pair of codes is associated with the address site in the Oracle application.

There is a conflict when a given trading partner sends transactions with the same trading partner translator code and the same external location codes. However, some of these transactions are split across different organizations. Only one organization can be associated to a given address site.

Each EDI trading partner location code is derived from a unique address site ID defined in the Oracle application. That site ID is often written into the transaction so that the application open interface can correctly identify the correct address site for the customer, supplier, or other trading partner.

When extracting or importing transactions, only those address site IDs that belong to the organization defined for the current responsibility are retrieved. The same location codes used in other organizations are not retrieved, since the process is organization-specific.

The following table illustrates an external location code defined in multiple organizations. Assume that the trading partner used the code AB123 that is associated with two addresses in different organizations in the Oracle application:

Customer or Supplier Address Site Trading Partner Translator Code External Location Code (on N1 or NAD segment) Address Site ID Organization for the Address Site ID

ACME Inc. 123 Main, Chicago IL E1-ACME-1 + AB123 = 12345678 A

ACME. Inc. 123 Main, Chicago IL E1-ACME-2 + AB123 = 13567890 B

Table 1 - 3. Sample Trading Partner Data

Customer or Supplier	Address Site	Trading Partner Translator Code		External Location Code (on N1 or NAD segment)		Address Site ID	Organization for the Address Site ID
ACME Inc.	123 Main, Chicago IL	E1-ACME-1	+	AB123	=	12345678	A
ACME. Inc.	123 Main, Chicago IL	E1-ACME-2	+	AB123	=	13567890	B
Table 1 - 3. Sample Trading Partner Data

Note: The organization is defined in the Oracle application for this address site. This is not validated by the EDI Gateway. It may be passed to the application open interface table given the address site ID that is retrieved by the EDI Gateway.

The address site ID is assigned when you set up the trading partner and is retrieved when the EDI Gateway processes the transaction.

The EDI Gateway cross-references the trading partner external location code to the Oracle application internal location code (defined during trading partner set up) to retrieve the associated address site ID to be used bye the application open interface. For organization A, only the address site IDs defined for organization A are retrieved. Address site ID 13567890 in organization B is not referenced during execution.

Attention: If there are problems with transactions loading to the correct address site, review the organization for the address site, and check the EDI responsibility in use when loading transactions to the open interface tables.

Test and Production Environments

The following table describes four possible scenarios for inbound transactions. If you import a production transaction into either a production or test environment, or if you import a test transaction in a test environment, the open interfaces validate the data and load it into production tables.

However, you must use caution when importing a test transaction into a production environment. Otherwise, test data is imported into your production environment.

Test Transaction to Production Environment

Caution: Unless care is exercised, test transactions may be processed into production tables. You must set up test / production status codes properly in your EDI translator and enter them properly when you launch Standard Requests to ensure test data is not loaded into your production database.

If the application open interface has a test / production status code and it is set for test, validation is performed but data is not committed to the database. (To perform a complete test where data is committed to the database, you must set up a test environment with a test database.)

If the trading partner is currently in production for the particular transaction at the particular site, and you want to test a transaction for that trading partner, make sure that you set up a trading partner for the test transaction with a different translator code. All test transactions must be given a different translator code when defining trading partner data. All test / production flags are associated with the combination of the trading partner definition and the translator code. Providing different translator codes for production and test transactions ensures that the two are not confused. This is only necessary if the trading partner is mixing production and test transactions for the same locations within one translator code.