Results for “jai_inv_txn_ext_dtls”

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

Overview

JAI_INV_TXN_EXT_DTLS is a transactional detail table owned by the JA schema (JA - Asia/Pacific Localizations) in Oracle E-Business Suite 12.1.1 and 12.2.2. The table stores detailed information corresponding to records held in its parent table, JAI_INV_TXN_EXT_HDRS, and is used primarily by the Asia/Pacific localizations that extend standard Oracle Inventory transaction functionality. It is most commonly encountered in connection with customs, bonded warehouse, excise, and statutory reporting extensions where transaction-level serial number tracking and extension-day calculations are required. The object is reported as VALID in the ETRM repository and consists of 12 documented columns.

From a Data Vault modeling perspective, the heuristic classification of this table is satellite-leaning. This implies that JAI_INV_TXN_EXT_DTLS is best understood as descriptive detail hanging off a business key supplied by its parent, rather than as an independent hub of business entities or as a link between multiple hubs. The TRANSACTION_NAME and TRANSACTION_HEADER_ID combination serves as the recurring business key carried down from JAI_INV_TXN_EXT_HDRS.

Key Information Stored

The documented physical schema exposes 12 columns. The most significant are listed below.

• TRANSACTION_NAME — Part of the composite primary key and the foreign key column pointing back to JAI_INV_TXN_EXT_HDRS. Identifies the transaction type or extension category to which the detail line belongs.
• TRANSACTION_HEADER_ID — The second component of the foreign key to JAI_INV_TXN_EXT_HDRS and part of the composite primary key. Together with TRANSACTION_NAME it isolates the parent transaction header.
• SERIAL_NO — The third component of the composite primary key (JAI_INV_TXN_EXT_DTLS_PK). This is the attribute most frequently sought in user searches, as it provides the serial-level granularity required for localized tracking of individually identified items.
• EXTENSION_DAYS — Numeric attribute capturing the number of days by which a transaction or obligation is extended, typically used in duty-deferment and bonded-period calculations.
• STATUS — Status code reflecting the processing or approval state of the detail record.
• DUE_DATE — The date on which the obligation associated with the detail line falls due; commonly drives alerts, aging, and statutory reporting.
• CREATION_DATE, CREATED_BY — Standard audit columns recording when and by whom the row was inserted.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit columns capturing the most recent modification and the login under which it occurred.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the OAF/ADF framework to detect concurrent updates.

The surrogate primary key is JAI_INV_TXN_EXT_DTLS_PK, defined over TRANSACTION_NAME, TRANSACTION_HEADER_ID, and SERIAL_NO. No separate single-column unique index is documented, so the composite key above represents the only documented uniqueness constraint and therefore the business key for any downstream modeling.

Common Use Cases and Queries

The table is typically queried in conjunction with its header to reconstruct localized transaction details. A representative join pattern is shown below.

• Serial-level lookup: SELECT d.* FROM ja.jai_inv_txn_ext_dtls d WHERE d.serial_no = :serial_no; — retrieves every localized extension detail recorded for a given serial number.
• Header-to-detail reconstruction: SELECT h.*, d.* FROM ja.jai_inv_txn_ext_hdrs h, ja.jai_inv_txn_ext_dtls d WHERE h.transaction_name = d.transaction_name AND h.transaction_header_id = d.transaction_header_id;
• Due-date aging and statutory reporting: selecting rows where DUE_DATE falls within a reporting period, grouped by STATUS, to support bonded-warehouse or duty-deferment reporting.
• Extension analysis: aggregating EXTENSION_DAYS by transaction or customer to monitor cumulative deferment consumption.
• Audit reconciliation: comparing CREATION_DATE, LAST_UPDATE_DATE, and OBJECT_VERSION_NUMBER to detect out-of-band changes to localized transaction detail.

Reporting use cases center on serial number traceability, deferred-duty exposure, and period-end statutory extracts required by Asia/Pacific localizations.

Related Objects

• JAI_INV_TXN_EXT_HDRS — The parent header table. Joined on TRANSACTION_NAME and TRANSACTION_HEADER_ID, which form the documented foreign key.
• JAI_INV_TXN_EXT_DTLS_PK — The primary key constraint defined on TRANSACTION_NAME, TRANSACTION_HEADER_ID, and SERIAL_NO.
• JA schema localization objects — Additional JA-owned tables, concurrent programs, and reporting views that consume the header-detail pair for country-specific statutory output.
• Inventory transaction tables (for example MTL_MATERIAL_TRANSACTIONS and MTL_SERIAL_NUMBERS) — Referenced indirectly when localized details must be reconciled back to the base Inventory transaction and serial number records.

Because the ETRM metadata documents only a single foreign key, integration with standard Oracle Inventory tables should be confirmed against the specific localized implementation in use before being relied upon for reconciliation logic.