Search Results ecx_transactions_b_u1

Overview

ECX.ECX_TRANSACTIONS_B is a seed data table in the Oracle E-Business Suite E-Commerce Gateway (ECX) schema. It stores the internal transaction definitions used by ETRM to identify and control the electronic business transactions that Oracle EBS can exchange with trading partners, such as purchase orders, invoices, advance ship notices, and payment remittances. Each row defines a transaction by its type, subtype, and the party type involved, and carries standard auditing columns as well as enablement and application ownership attributes.

The table resides in the APPS_TS_SEED tablespace, consistent with its role as a seeded reference table populated during product installation and patched by Oracle. It is documented as VALID in the ETRM 12.1.1 / 12.2.2 metadata and appears as a standalone object with no outgoing foreign keys to other tables. Using Data Vault modeling heuristics, the table can be treated as a hub, since its business identity is expressed through the natural keys TRANSACTION_TYPE, TRANSACTION_SUBTYPE, and PARTY_TYPE, while description and enablement attributes behave like satellite context.

Key Information Stored

The physical table contains 14 documented columns. The most significant are:

• TRANSACTION_ID — surrogate primary key, defined by the ECX_TRANSACTIONS_B_PK constraint and enforced uniquely by the ECX_TRANSACTIONS_B_U2 index (in combination with ZD_EDITION_NAME). Holds the internal transaction identifier.
• TRANSACTION_TYPE — internal transaction type; part of the business-key candidate ECX_TRANSACTIONS_B_U1.
• TRANSACTION_SUBTYPE — internal transaction subtype; also part of U1.
• PARTY_TYPE — party type associated with the transaction; completes the U1 business key.
• TRANSACTION_DESCRIPTION — descriptive text for the transaction definition, up to 256 characters.
• ENABLED — flag indicating whether the transaction definition is active.
• APPLICATION_ID — owning application, used to attribute the transaction definition to an EBS module.
• ADMIN_USER — administrative user associated with the transaction definition.
• ZD_EDITION_NAME — editioning column present in 12.2 Online Patching architecture; appended to both unique indexes.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns, with CREATED_BY and LAST_UPDATED_BY referencing FND_USER.USER_ID and LAST_UPDATE_LOGIN referencing FND_LOGINS.LOGIN_ID.

The distinction between the surrogate key (TRANSACTION_ID) and the business-key candidates (U1 on type/subtype/party type; U2 on TRANSACTION_ID and ZD_EDITION_NAME) is important when writing joins and de-duplication logic.

Common Use Cases and Queries

Typical scenarios include validating which ETRM transactions are enabled, identifying the application that owns a given transaction definition, and joining gateway configuration to transaction processing logic. A listing of enabled transactions for a party type can be produced as follows:

• SELECT TRANSACTION_ID, TRANSACTION_DESCRIPTION, TRANSACTION_TYPE, TRANSACTION_SUBTYPE FROM ECX.ECX_TRANSACTIONS_B WHERE ENABLED = 'Y' AND PARTY_TYPE = :p_party_type;
• Lookups by natural key: filter on TRANSACTION_TYPE, TRANSACTION_SUBTYPE, and PARTY_TYPE to resolve the internal TRANSACTION_ID.
• Audit and change reporting using LAST_UPDATED_BY and LAST_UPDATE_DATE, joined to FND_USER for user names.
• Application ownership reporting via APPLICATION_ID joined to FND_APPLICATION.

Related Objects

The metadata confirms the object references no other database object directly, and identifies ECX and EC as the schemas whose objects reference it. Practitioner-relevant companions include:

• ECX.ECX_TRANSACTIONS_TL — translated description table typically keyed by TRANSACTION_ID.
• FND_USER — joined on CREATED_BY / LAST_UPDATED_BY.
• FND_LOGINS — joined on LAST_UPDATE_LOGIN.
• FND_APPLICATION — joined on APPLICATION_ID to resolve the owning application.
• ECX gateway configuration tables (transaction/party mapping) whose keys reference TRANSACTION_TYPE, TRANSACTION_SUBTYPE, and PARTY_TYPE.

Because the object is standalone, join paths depend on the business keys rather than declared foreign keys; queries should therefore use the U1 and U2 index columns when correlating with dependent ECX and EC objects.