Results for “iby_fndcpt_tx_operations”

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

Overview

IBY_FNDCPT_TX_OPERATIONS is a Payments (IBY) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores transaction-level extension records associated with payment transactions. The name derives from the Funds Capture (FNDCPT) payment instrument processing framework, and the table functions as the persistence point for operational extensions or attribute overlays attached to individual transactions. It allows the payments engine to record auxiliary or supplementary data against a transaction without altering the core transaction record itself.

The table resides in the IBY schema and is documented as VALID in ETRM 12.2.2. Its physical schema contains eight documented columns. The primary key is defined by the unique constraint IBY_FNDCPT_TX_OPERATIONS_UK, which spans TRXN_EXTENSION_ID and TRANSACTIONID. A foreign key relationship ties the table to itself on the TRXN_EXTENSION_ID column, indicating a hierarchical or reference relationship within the same object.

From a Data Vault modeling perspective, the metadata heuristic classifies this object as satellite-leaning. This suggests that IBY_FNDCPT_TX_OPERATIONS behaves primarily as a descriptive extension of a parent transaction entity, carrying attributes that qualify or elaborate upon the transaction rather than defining new business relationships. Modelers should treat the composite of TRXN_EXTENSION_ID and TRANSACTIONID as the grain of the satellite.

Key Information Stored

The table contains eight documented columns. The two business-meaningful key columns form the unique constraint and therefore serve as the compound business key:

• TRXN_EXTENSION_ID — Identifies the extension record associated with a transaction. It is the first component of the primary key and participates in the self-referencing foreign key, indicating that extension records may be organized in a parent-child or reference structure.
• TRANSACTIONID — Identifies the payment transaction to which the extension applies. It is the second component of the primary key and provides the association back to the transaction population.

The remaining documented columns are standard Oracle EBS audit and concurrency attributes, not business keys:

• CREATED_BY, CREATION_DATE — Who created the extension row and when.
• LAST_UPDATED_BY, LAST_UPDATE_DATE — Who last modified the row and when.
• LAST_UPDATE_LOGIN — The login session associated with the most recent update.
• OBJECT_VERSION_NUMBER — Optimistic locking token used by the Oracle EBS framework to detect concurrent updates.

The documented metadata does not expose a separate surrogate primary key column; the unique constraint is composed of natural identifiers, so TRXN_EXTENSION_ID and TRANSACTIONID together function as both the business key and the enforced uniqueness mechanism.

Common Use Cases and Queries

The principal use case is retrieval of all extension records for a given payment transaction. A typical query joins the extension table to the transaction parent on TRANSACTIONID:

• Enumerate extensions for a transaction: SELECT trxn_extension_id, transactionid, creation_date FROM iby.iby_fndcpt_tx_operations WHERE transactionid = :transaction_id;
• Resolve a specific extension: filter jointly on both primary key columns to return exactly one row.
• Audit reporting: select CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and LAST_UPDATE_DATE to track modification history for compliance or reconciliation reporting.
• Concurrency troubleshooting: inspect OBJECT_VERSION_NUMBER where update conflicts occur.

Because the table is satellite-leaning, reporting solutions commonly treat it as a descriptive sub-entity of transaction reporting, joining it to core transaction tables to enrich operational detail.

Related Objects

The documented FK structure shows a self-referencing relationship on TRXN_EXTENSION_ID, which means the table participates in an internal hierarchy. The most significant dependent and related objects are:

• IBY_FNDCPT_TX_OPERATIONS (self) — Join alias pairing the table to itself on TRXN_EXTENSION_ID to resolve parent-child extension relationships.
• IBY_FNDCPT_TX_OPERATIONS_UK — The unique constraint enforcing the composite key; used by the optimizer for unique lookups.
• IBY payment transaction objects — Parent transaction entities referenced through TRANSACTIONID; joined to expand extension data with core transaction attributes.
• IBY Funds Capture APIs — Application-layer services that create and consume transaction extension records during payment processing.
• IBY audit views — Reporting views that project the standard WHO columns for operational monitoring.

Because the documented metadata is limited, additional relationships beyond the self-referencing foreign key should be verified against the specific EBS point release before being relied upon in production integrations.