Search Results gl_iea_transactions_u1

Overview

GL.GL_IEA_TRANSACTIONS is the header table for Oracle General Ledger's Intercompany and Intracompany Balancing (IEA) engine in Oracle E-Business Suite 12.1.1 and 12.2.2. Each row represents a single intercompany transaction generated or submitted between two subsidiaries defined in GL_IEA_SUBSIDIARIES, together with the clearing accounts and accounting periods required to balance the sending and receiving sides of the entry. The table stores both the transaction definition and the state of the balancing process, including transfer flags, transfer statuses, running debit/credit totals, and conversion rates, so that the IEA programs can determine which side of the transaction has been posted and which remains to be accounted.

Because the table is referenced by GL_IEA_TRANSACTION_LINES via TRANSACTION_ID, and because it carries independent descriptive attributes (currency, dates, description, attributes, running totals), the metadata's heuristic Data Vault classification of satellite-leaning is reasonable. The TRANSACTION_ID surrogate key behaves as a hub-style identifier, while the operational status, transfer, and totals columns represent mutable descriptive state. Consumers should note the Oracle Internal Use Only warning: direct DML against this table is not supported, and all access should be routed through standard Oracle EBS programs and concurrent requests.

Key Information Stored

The primary key is TRANSACTION_ID, a NUMBER(15) labeled as the intercompany transaction defining column and enforced by the unique index GL_IEA_TRANSACTIONS_U1 — the index the user referenced in the search string. A second unique index, GL_IEA_TRANSACTIONS_U2, enforces TRANSACTION_NUMBER as an alternate business key. The most operationally significant columns are:

• TRANSACTION_TYPE_ID — foreign key to GL_IEA_TRANSACTION_TYPES, identifying the balancing rule set applied.
• SENDING_SUBSIDIARY_ID / RECEIVING_SUBSIDIARY_ID — foreign keys to GL_IEA_SUBSIDIARIES defining the two parties.
• STATUS — the transaction's lifecycle state; central to the GL_IEA_TRANSACTIONS_N1 and N2 composite indexes.
• SENDER_CLEARING_CCID / RECEIVER_CLEARING_CCID — code combination IDs identifying the clearing accounts on each side.
• GL_DATE, ENTERED_DATE, APPROVED_DATE — accounting, submission, and approval dates.
• SENDER_TRANSFER_FLAG / RECEIVER_TRANSFER_FLAG and SENDER_TRANSFER_STATUS / RECEIVER_TRANSFER_STATUS — control whether each side has been transferred to its period.
• SENDER_PERIOD_NAME / RECEIVER_PERIOD_NAME — the accounting periods to which each side posts.
• SENDER_RUNNING_TOTAL_DR / CR and RECEIVER_RUNNING_TOTAL_DR / CR — accumulated control totals used for balancing checks.
• SENDER_CONVERSION_RATE / RECEIVER_CONVERSION_RATE — rates applied to translate between transaction and functional currency.
• CURRENCY_CODE — transaction currency, validated against FND_CURRENCIES.
• FROM_RECURRING_TRANSACTION_ID and REVERSE_TRANSACTION_ID — links to recurring definitions and to the reversed transaction respectively.

The 116-column definition also includes 30 SENDER_SEGMENTn and 30 RECEIVER_SEGMENTn columns that materialize the account segments for each side, plus standard Who columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and 15 generic ATTRIBUTEn columns.

Common Use Cases and Queries

Typical reporting requirements include identifying transactions awaiting transfer, reconciling clearing account balances, and tracing recurring or reversed entries. A representative pattern joins the transaction to its lines and subsidiaries:

SELECT t.transaction_id,
       t.transaction_number,
       t.status,
       t.sender_period_name,
       t.receiver_period_name,
       t.sender_running_total_dr,
       t.sender_running_total_cr
FROM   gl_iea_transactions t
WHERE  t.status               = 'S'
AND    t.sender_transfer_flag = 'N'
AND    t.sender_period_name   = :period;

Because GL_IEA_TRANSACTIONS_N1 covers SENDING_SUBSIDIARY_ID, STATUS, SENDER_TRANSFER_FLAG, SENDER_PERIOD_NAME and SENDER_CLEARING_CCID, queries filtered on those columns are index-driven; the mirrored N2 serves the receiver side. Tracing a reversal uses the self-referencing REVERSE_TRANSACTION_ID:

SELECT orig.transaction_number, rev.transaction_number AS reversal_number
FROM   gl_iea_transactions orig, gl_iea_transactions rev
WHERE  rev.reverse_transaction_id = orig.transaction_id;

Reconciliation reports frequently aggregate the sender and receiver running totals by clearing CCID and accounting period to verify that debits equal credits before period close.

Related Objects

• GL.GL_IEA_TRANSACTION_LINES — child table linked on TRANSACTION_ID; holds the individual accounting lines that make up each intercompany entry.
• GL.GL_IEA_SUBSIDIARIES — parent of SENDING_SUBSIDIARY_ID and RECEIVING_SUBSIDIARY_ID.
• GL.GL_IEA_TRANSACTION_TYPES — parent of TRANSACTION_TYPE_ID, supplying the balancing and clearing rules.
• GL.GL_IEA_RECUR_TRANSACTIONS — parent referenced by FROM_RECURRING_TRANSACTION_ID for recurring intercompany definitions.
• GL.GL_IEA_TRANSACTIONS — self-referencing parent through REVERSE_TRANSACTION_ID.
• GL.GL_CODE_COMBINATIONS — source of the sender and receiver clearing account combinations (SENDER_CLEARING_CCID, RECEIVER_CLEARING_CCID).
• FND.FND_CURRENCIES — validates CURRENCY_CODE and supplies currency attributes.

Maintenance of these records is performed by the IEA balancing and transfer concurrent programs rather than by direct SQL, and any custom reporting should treat the table as read-only.