Search Results gl_je_lines_recon




Overview

The GL_JE_LINES_RECON table is a General Ledger reconciliation table in the Oracle E-Business Suite GL schema. It stores reconciliation status information for individual journal entry lines, allowing reconciliation processes to track the approval, clearing, or matching state of specific journal lines against controlling records such as bank statements or intercompany balances. It is closely coupled with GL_JE_HEADERS and GL_LEDGERS, positioning it as a subordinate detail table within the GL journal posting model.

The primary key GL_JE_LINES_RECON_PK is composed of JE_HEADER_ID and JE_LINE_NUM, and a unique index GL_JE_LINES_RECON_U1 on the same two columns acts as a documented business-key candidate. In Data Vault terms, the table's FK structure is heuristically classified as a link, suggesting a modeling approach that resolves the many-to-many or dependent relationship between journal headers/lines and ledger-level reconciliation state.

Key Information Stored

  • JE_HEADER_ID – Foreign key to GL_JE_HEADERS; identifies the parent journal entry header.
  • JE_LINE_NUM – Line number within the journal entry; together with JE_HEADER_ID forms the primary and business key.
  • LEDGER_ID – Foreign key to GL_LEDGERS; identifies the ledger context for the reconciliation record.
  • JGZZ_RECON_STATUS – Status flag describing the reconciliation state of the journal line.
  • JGZZ_RECON_DATE – Date the reconciliation status was recorded.
  • JGZZ_RECON_ID – Identifier linking the line to a specific reconciliation event or batch.
  • JGZZ_RECON_REF – Reference value (e.g., external document or reconciliation reference).
  • CREATED_BY, CREATION_DATE – Audit columns recording who created the row and when.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Audit columns tracking the most recent modification.

The JGZZ_* columns carry the substantive reconciliation payload, while the remainder are standard "WHO" audit and key columns. The surrogate-style primary key is really a composite natural/business key here rather than a synthetic sequence column.

Common Use Cases and Queries

Typical uses include identifying unreconciled journal lines, reporting reconciliation aging, and joining reconciliation state to header and ledger attributes for financial close dashboards.

  • Unreconciled lines query:
    SELECT r.JE_HEADER_ID, r.JE_LINE_NUM, r.LEDGER_ID, r.JGZZ_RECON_STATUS
    FROM GL_JE_LINES_RECON r
    WHERE r.JGZZ_RECON_STATUS <> 'RECONCILED';
  • Join to header and ledger:
    SELECT h.NAME, l.NAME, r.JGZZ_RECON_DATE
    FROM GL_JE_LINES_RECON r
    JOIN GL_JE_HEADERS h ON h.JE_HEADER_ID = r.JE_HEADER_ID
    JOIN GL_LEDGERS l ON l.LEDGER_ID = r.LEDGER_ID;
  • Aging analysis: aggregate by JGZZ_RECON_DATE to surface stale reconciliations.

Related Objects

  • GL_JE_HEADERS – join on JE_HEADER_ID; parent header of each reconciled line.
  • GL_LEDGERS – join on LEDGER_ID; ledger context.
  • GL_JE_LINES – logical counterpart holding the actual journal line amounts.
  • GL_JE_BATCHES – upstream batch grouping via headers.
  • GL_JE_SOURCES – journal source definition reachable through headers.

Because GL_JE_LINES_RECON is a reconciliation-specific structure, most reporting should join it back to GL_JE_LINES and GL_JE_HEADERS to obtain amounts, periods, and descriptions alongside reconciliation status.