Search Results gl_je_segment_values_u1




Overview
Explore in AI Chat

Overview

GL.GL_JE_SEGMENT_VALUES is a transactional table in the Oracle E-Business Suite General Ledger schema that stores the balancing and management segment values associated with each journal entry. In an Oracle EBS 12.1.1 or 12.2.2 environment, this table captures a denormalized, query-optimized projection of segment information tied to a specific journal header. Rather than requiring consumers to re-derive balancing segment values from the chart of accounts combination (CODE_COMBINATION_ID), the application records them explicitly here at posting time, keyed by journal entry.

The table carries a one-to-many relationship against GL.GL_JE_HEADERS, meaning a single journal entry can have multiple rows — one per segment value across the relevant balancing and management segment types. From a Data Vault modeling perspective, the mined metadata classifies this object as satellite-leaning. It is not a hub (no independent business entity is born here) and not a true link (no many-to-many resolution between hubs); instead it behaves as a descriptive, keyed satellite attached to the journal header hub, storing attributes that vary by journal entry and segment type.

Key Information Stored

The table consists of eight documented columns. The three business-key columns form both the primary key (GL_JE_SEGMENT_VALUES_PK) and the sole unique index (GL_JE_SEGMENT_VALUES_U1), which the user searched for. These are:

  • JE_HEADER_ID — NUMBER(15), mandatory; the foreign key to GL_JE_HEADERS.JE_HEADER_ID identifying the parent journal entry.
  • SEGMENT_TYPE_CODE — VARCHAR2; indicates whether the stored value is for a balancing segment or a management segment.
  • SEGMENT_VALUE — VARCHAR2(30); the actual segment value string (for example, a balancing segment such as a company or fund code).

Because the three business attributes together are unique, there is no separate surrogate system-generated key; the composite of header ID, segment type, and segment value acts as the identifying key. The remaining five columns are standard Who audit columns maintained by the EBS framework on all transactional tables: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN. These support audit trails, row-level provenance, and incremental extraction patterns in ETL processes.

Common Use Cases and Queries

The most frequent reporting need is retrieving all segment values for a given journal entry. The canonical query, matching the documented ETRM query text, is:

  • SELECT JE_HEADER_ID, SEGMENT_TYPE_CODE, SEGMENT_VALUE, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN FROM GL.GL_JE_SEGMENT_VALUES;
  • Filtering by header: ... WHERE JE_HEADER_ID = :p_header_id; to list balancing versus management segments for a single journal.
  • Filtering by type: ... WHERE SEGMENT_TYPE_CODE = 'B' ; to isolate balancing segment values, useful for entity-level rollups or intercompany reconciliations.

Typical scenarios include period-close validation (confirming each journal resolves to the expected balancing segment), audit and SOX sampling (tracing which segment values a posted entry touched), management segment reporting, and building extract feeds into a data warehouse where segment values are needed at the journal grain without re-joining the full account combination table.

Related Objects

The dominant relationship is the foreign key to the journal header. The most significant related objects are:

  • GL.GL_JE_HEADERS — parent table; join on JE_HEADER_ID.
  • GL.GL_JE_LINES — sibling child of the header holding debit/credit amounts, joined via JE_HEADER_ID.
  • GL.GL_JE_BATCHES — batch grouping reached through GL_JE_HEADERS.JE_BATCH_ID.
  • GL.GL_CODE_COMBINATIONS — referenced indirectly through the lines/header to resolve full account combinations.
  • GL_JE_SEGMENT_VALUES APPS synonym/view — the application-facing access layer over this table, listed as a dependent.

Because the ETRM metadata states the table references no other database object besides the header FK, its dependency footprint is deliberately narrow, reinforcing its role as a satellite lookup keyed to GL_JE_HEADERS.