Search Results trx_type_class_code




Overview
Explore in AI Chat

Overview

OKL_TRX_EXTENSION_B is the lease transactions header extension table within the Oracle Lease and Finance Management (OKL) module of Oracle E-Business Suite 12.1.1 and 12.2.2. It stores supplementary, descriptive, and denormalized attribute data associated with lease contract headers. Rather than duplicating operational contract state maintained across the core OKL transaction tables, this table acts as a wide extension surface: it records customer-facing identifiers, integration-agreement references, tax and accrual flags, and a substantial set of descriptive flexfield (DFF) columns at CUST_ATTRIBUTE1 through CUST_ATTRIBUTE15.

The table is owned by the OKL schema and is marked VALID in the ETRM dictionary, with 65 documented columns in release 12.2.2. Under a heuristic Data Vault classification mined from its foreign key structure, OKL_TRX_EXTENSION_B is best modeled as a link table. Its foreign keys resolve to master party and customer entities rather than to a strict parent-child hierarchy, which supports treating the table as a relationship connector between lease headers and the Trading Community Architecture (TCA) model. This is a modeling suggestion derived from FK topology, not a documented product declaration.

Key Information Stored

The surrogate primary key is HEADER_EXTENSION_ID, enforced by OKL_TRX_EXTENSION_B_PK. Two unique indexes define business-key candidates: OKL_TRX_EXTENSION_B_U1 on HEADER_EXTENSION_ID (redundant with the PK) and OKL_TRX_EXTENSION_B_U2 on the SOURCE_ID and SOURCE_TABLE pair, indicating that the extension row is keyed back to a source entity by a polymorphic reference.

The most operationally significant columns include:

Standard EBS audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and OBJECT_VERSION_NUMBER are present for concurrency and auditability.

Common Use Cases and Queries

Because the table carries denormalized customer and contract attributes, it is frequently joined into reporting queries that would otherwise require multiple TCA lookups. A typical pattern resolves the contract to its customer and operating unit:

  • Joining OKL_TRX_EXTENSION_B to HZ_PARTIES on PARTY_ID to retrieve party detail for a contract header.
  • Joining to HZ_CUST_ACCOUNTS on CUST_ACCOUNT_ID and to HZ_CUST_SITE_USES_ALL on CUST_SITE_USE_ID to obtain account and site-use context for billing or statements.
  • Filtering on CONTRACT_STATUS_CODE or INV_AGRMNT_STATUS_CODE to produce active-versus-terminated portfolio extracts.
  • Resolving CUST_ATTRIBUTE1 through CUST_ATTRIBUTE15 with CUST_ATTRIBUTE_CATEGORY to expose client-specific descriptive flexfield data in downstream extracts.

A representative query pattern selects the extension row by its polymorphic key — WHERE SOURCE_ID = :source_id AND SOURCE_TABLE = :source_table — which leverages the U2 index and avoids full scans. Reports on investor agreements typically use INV_AGRMNT_NUMBER, INV_AGRMNT_POOL_NUMBER, and INV_AGRMNT_SYND_CODE together to group contracts by funding structure.

Related Objects

The documented foreign keys of OKL_TRX_EXTENSION_B resolve exclusively to TCA tables, which are the most significant related objects:

  • HZ_PARTIES — joined via OKL_TRX_EXTENSION_B.PARTY_ID; supplies party-level identity for the contract holder.
  • HZ_CUST_ACCOUNTS — joined via OKL_TRX_EXTENSION_B.CUST_ACCOUNT_ID; provides the customer account record.
  • HZ_CUST_SITE_USES_ALL — joined via OKL_TRX_EXTENSION_B.CUST_SITE_USE_ID; supplies site-use context such as bill-to location.

Beyond the declared foreign keys, the SOURCE_ID and SOURCE_TABLE pair logically links each extension row to its parent lease transaction header in the core OKL transaction tables. The table is therefore consumed as an extension attribute source by OKL contract search pages, portfolio reporting, and any public API or concurrent program that reads lease header details. Implementers should treat it as a supplementary link to the OKL transaction header and to TCA, not as a transactional or history-bearing child. As with all OKL objects, referencing the table directly in custom SQL ties the customization to an internal schema whose contents are maintained by the application rather than by documented public interfaces.