Search Results reference_9

Overview

AXBV_ACCOUNTING_ENTRY_LINES is a reporting view belonging to the AX – Global Accounting Engine product within Oracle E-Business Suite, documented in the ETRM reference for releases 12.1.1 and 12.2.2. The view exposes accounting entry lines generated by the Global Accounting Engine (also referred to as AX or the Subledger Accounting Engine foundation for EBS), providing a flattened, read-only representation of subledger journal entries and their transfer status to the General Ledger. Its principal role is to support reconciliation, audit, and third-party reporting requirements where consumers need accounting distributions at the line level without directly joining the underlying AX_SLE_HEADERS and AX_SLE_LINES tables. The view is explicitly defined as read-only ("WITH READ ONLY"), and the ETRM metadata notes it is not implemented in the database in which the documentation was captured — meaning it should be treated as a deliverable object that must be verified against the specific instance before use.

Underlying Base Objects

The view is defined over three documented base objects:

• AX_SLE_LINES (L) — the core accounting entry lines that carry entered and accounted debit/credit amounts, currency conversion details, code combination identifiers, and GL posting and balance flags.
• AX_SLE_HEADERS (H) — the header records providing journal sequence identifiers, SLE header identifiers, effective dates, period names, application and set of books context, document references, and event identifiers.
• GL_CODE_COMBINATIONS (GCC) — joined on CODE_COMBINATION_ID to supply account structure context, referenced in the view text as the key flexfield source "_KF:SQLGL:GL#:GCC".

The join conditions link lines to headers on both JOURNAL_SEQUENCE_ID and SLE_HEADER_ID, and lines to code combinations on CODE_COMBINATION_ID. The header-to-line relationship establishes the parent-child hierarchy of a subledger journal entry, while the code combination join resolves the account flexfield, including the key flexfield descriptor column exposed as "_KF:ACCOUNT".

Key Columns

• JOURNAL_SEQUENCE_ID / JOURNAL_NUMBER / LINE_NUMBER — identify each entry and its line position.
• ACCOUNTING_DATE / PERIOD_NAME — effective date and accounting period for the entry.
• "_KF:ACCOUNT" — the concatenated key flexfield account derived from GL_CODE_COMBINATIONS.
• ENTERED_DEBIT / ENTERED_CREDIT / ACCOUNTED_DEBIT / ACCOUNTED_CREDIT — entered versus accounted amounts in the transaction and functional currencies respectively.
• CURRENCY_CODE, CURRENCY_CONVERSION_DATE, CURRENCY_CONVERSION_RATE, CURRENCY_CONVERSION_TYPE_CODE — currency and conversion attributes, with line-level values derived from the header via DECODE when the line currency is null.
• TRANSFERRED_TO_GL_FLAG / INCLUDED_IN_BALANCE_FLAG — indicate GL posting (GL_POSTED_FLAG) and balance inclusion status.
• APPLICATION_ID / SET_OF_BOOKS_ID / ACCOUNT_ID — subledger application, ledger/books, and code combination identifiers.
• DOCUMENT, TRADING_PARTNER_ID, TRADING_PARTNER_SITE_ID, EVENT_ID — source document and intercompany/trading partner context.
• REFERENCE_9, REFERENCE_10, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — audit and reference columns, including the REFERENCE_10 value frequently used to link the accounting line back to its originating transaction.

Common Use Cases and Queries

Typical usages include reconciling subledger balances to GL, identifying unposted entries, and tracing transactions through REFERENCE_10. A representative query follows:

• SELECT journal_number, line_number, accounting_date, period_name, entered_debit, entered_credit, accounted_debit, accounted_credit, transferred_to_gl_flag, reference_10 FROM axbv_accounting_entry_lines WHERE period_name = :p_period AND set_of_books_id = :p_sob;
• Filter on transferred_to_gl_flag = 'N' to isolate accounting lines not yet transferred to the General Ledger.
• Join or filter on reference_10 to trace an accounting distribution to its originating subledger document for audit and support analysis.

Because the object is read-only and may not exist in every instance, implementers should confirm availability and grants in each environment before relying on it for reporting.