Results for “iby_trxn_types_b”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IBY_TRXN_TYPES_B is a core setup table in the Oracle Payments (IBY) module of Oracle E-Business Suite, holding the definitions of payment processing transaction types that dependent products use when submitting payment transactions to Oracle Payments. The description available in Oracle's ETRM repository states that IBY_TRXN_TYPES stores the payment processing transaction types required by dependent products, and that the same table serves both funds disbursement and funds capture flows. In practice, this makes IBY_TRXN_TYPES_B a shared reference object: any product that hands payments to IBY — Payables, Receivables, payroll-style flows, and other calling applications — must register or reference a valid transaction type here before the engine can route and process that instruction.

From a Data Vault modeling perspective, the relationship data classifies this object as hub-leaning. That is a heuristic suggestion rather than an enforced design rule: the table supplies a stable, uniquely identified business concept (a payment processing transaction type, scoped by its calling application), which is the classic profile of a hub, with descriptive attributes that could reasonably be separated into satellites.

Key Information Stored

The table is defined with 11 documented columns in the 12.2.2 physical schema. The most significant are:

• APPLICATION_ID — identifies the calling application that owns the transaction type; part of the primary key and of the business-key unique index.
• PAY_PROC_TRXN_TYPE_CODE — the code identifying the payment processing transaction type; the second component of the primary key and of the unique index.
• PAYMENT_FLOW — indicates whether the transaction type is used for funds disbursement or funds capture, driving how the payment engine routes the transaction.
• SEEDED_FLAG — distinguishes Oracle-seeded transaction types from user- or product-defined rows.
• OBJECT_VERSION_NUMBER — the optimistic locking column used by the underlying framework to detect concurrent updates.
• ZD_EDITION_NAME — the editioning column introduced with EBS 12.2 online patching; it appears in the unique index and in the IBY_TRXN_TYPES_TL foreign key.
• Standard audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN.

The surrogate primary key is IBY_TRXN_TYPES_B_PK, defined on (APPLICATION_ID, PAY_PROC_TRXN_TYPE_CODE). The documented business-key unique index is IBY_TRXN_TYPES_B_U1, defined on (APPLICATION_ID, PAY_PROC_TRXN_TYPE_CODE, ZD_EDITION_NAME).

Common Use Cases and Queries

Typical reporting uses revolve around validating and reconciling the transaction types configured for each calling application, and around tracing which transactions resolve to which setup row.

• Listing all transaction types registered for a given product: SELECT PAY_PROC_TRXN_TYPE_CODE, PAYMENT_FLOW, SEEDED_FLAG FROM IBY.IBY_TRXN_TYPES_B WHERE APPLICATION_ID = :app_id;
• Isolating disbursement versus capture flows with WHERE PAYMENT_FLOW = :flow to confirm split between payments and receipts.
• Joining to IBY_TRXN_TYPES_TL for the translated name, and to IBY_DOCUMENTS_PAYABLE_H or IBY_DOCS_PAYABLE_ALL to reconcile documents to their transaction types.
• Identifying seeded versus custom rows via SEEDED_FLAG during upgrade or configuration audits.

Related Objects

The foreign key metadata identifies the principal dependent objects, joined on the composite of calling application and transaction type code:

• IBY_DOCS_PAYABLE_ALL — joined via CALLING_APP_ID and PAY_PROC_TRXN_TYPE_CODE.
• IBY_DOCUMENTS_PAYABLE_H — joined on the same pair.
• IBY_TRANSACTION_ERRORS — links error records back to the transaction type.
• IBY_TRXN_TYPES_TL — the translation table, joined via APPLICATION_ID and PAY_PROC_TRXN_TYPE_CODE, and also via ZD_EDITION_NAME.

These relationships confirm that IBY_TRXN_TYPES_B acts as the parent, referenced by both payable documents and error records when payments are submitted to the Oracle Payments engine.