Search Results ece_tp_details_u2

Overview

EC.ECE_TP_DETAILS is a trading partner configuration table within the Oracle e-Commerce Gateway (ECE) module of Oracle E-Business Suite, present in both release 12.1.1 and 12.2.2. It stores the transaction-level processing rules that govern how a specific EDI document or document type is enabled, tested, and communicated for a given trading partner. Each row represents one EDI transaction or transaction type enabled for a trading partner, capturing the document definition, the translator code, and the operational flags that control extraction, printing, and test-versus-production behavior.

The table sits directly beneath EC.ECE_TP_HEADERS in the trading partner hierarchy. Exactly one ECE_TP_HEADERS row is associated with each ECE_TP_DETAILS row, while a single header may own many detail rows, establishing a one-to-many relationship between header and detail. From a Data Vault modeling perspective—offered here as a heuristic suggestion mined from the foreign-key structure—ECE_TP_DETAILS is satellite-leaning: it carries descriptive, attribute-rich context keyed to the ECE_TP_HEADERS parent rather than acting as an independent hub or an associative link. The singleton unique index on TP_DETAIL_ID and the composite unique index on TP_HEADER_ID, DOCUMENT_ID, and DOCUMENT_TYPE reinforce this interpretation, since the business key of a detail row is really the combination of its parent and the document it configures.

Key Information Stored

The physical schema documents 26 columns. The most significant are:

• TP_DETAIL_ID — the system-generated surrogate primary key (ECE_TP_DETAILS_PK), invisible to the user and the target of unique index ECE_TP_DETAILS_U1.
• TP_HEADER_ID — foreign key to ECE_TP_HEADERS; binds the detail row to its trading partner.
• DOCUMENT_ID and DOCUMENT_TYPE — identify the EDI document being configured. Together with TP_HEADER_ID these form the composite business-key candidate in unique index ECE_TP_DETAILS_U2.
• TRANSLATOR_CODE — the trading partner identifier as defined in the EDI translator; written to the 0010 control record of the transaction data file and used, with the location code, to resolve the unique trading partner address site.
• TEST_FLAG — the column surfaced by the "test_flag" search. Default is "production"; a value of "test" instructs the EDI translator and trading partner to treat outbound documents as test regardless of other settings. This is the primary control for segregating test traffic from live production data.
• EDI_FLAG — identifies the communication method as EDI or other; default "enabled." When "disabled," outbound transactions are not extracted by e-Commerce Gateway, though some inbound open-interface APIs may not honor it.
• PRINT_FLAG — governs whether the document is routed to print output.
• DOCUMENT_STANDARD and MAP_ID — capture the EDI standard version and the associated mapping definition used for translation.
• ORG_ID — multi-org operating unit context.
• WHO columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE record audit and concurrent-program provenance.
• ATTRIBUTE_CATEGORY plus ATTRIBUTE1 through ATTRIBUTE5 — the standard DFF flexfield segment columns for customer extensions.

Common Use Cases and Queries

Typical usage centers on enabling, disabling, or auditing trading partner document configuration. Administrators and support analysts frequently query TEST_FLAG to confirm whether a partner's document set is pointed at a test translator or a production translator, particularly after cloning or during cutover. A representative query joins the detail rows to their parent headers to produce a partner-level configuration report:

• Filter all test-configured documents: SELECT tp_detail_id, tp_header_id, document_id, document_type, test_flag FROM ec.ece_tp_details WHERE test_flag = 'test';
• Verify extraction eligibility: ... WHERE edi_flag = 'enabled' AND test_flag = 'production';
• Reconcile translator assignments by standard: group by document_standard and translator_code.
• Audit changes from a concurrent program: filter on program_id, request_id, or the last_update_date range.
• Locate configuration for a specific document type using the composite key columns tp_header_id, document_id, and document_type.

Reporting extracts commonly feed EDI operations dashboards that flag partners still marked "test" in a production environment, a frequent root cause of missing or duplicated interface data.

Related Objects

• EC.ECE_TP_HEADERS — parent table; join on ECE_TP_DETAILS.TP_HEADER_ID = ECE_TP_HEADERS.TP_HEADER_ID. This is the dominant relationship (one-to-many).
• EC.ECE_TP_LOCATION_CODE — supplies the Oracle Applications location code used with TRANSLATOR_CODE for inbound trading partner address resolution.
• EC.ECE_TP_HEADERS unique index ECE_TP_DETAILS_U2 (TP_HEADER_ID, DOCUMENT_ID, DOCUMENT_TYPE) — enforces one rule set per document per partner.
• ECE_TP_DETAILS_PK (TP_DETAIL_ID) — primary key constraint backing the surrogate identifier.
• e-Commerce Gateway concurrent programs — the extraction and inbound load programs read EDI_FLAG, TEST_FLAG, and MAP_ID to determine processing behavior.
• EC.ECE_TP_HEADERS organizational and audit columns — the ORG_ID and WHO columns align ECE_TP_DETAILS with standard multi-org and audit conventions used across ECE configuration tables.

Together these objects describe the full trading partner control model: headers define the partner, details define which documents are enabled, and the flags determine how each document is processed.