Search Results gl_recurring_valid_periods_v




Overview
Explore in AI Chat

Overview

GL_RECURRING_VALID_PERIODS_V is a General Ledger (GL) view owned by the APPS schema in Oracle E-Business Suite. It exposes, for each recurring batch, the set of GL periods that satisfy two conditions simultaneously: the period is open or future-enterable for the owning ledger, and at least one recurring header belonging to that batch is active during the effective date range of that period. The object carries the ETRM description "10SC ONLY," indicating it is scoped to a specific localization or deployment context rather than being a general-purpose GL dictionary view.

Because the view joins period status data to recurring batch data and depends on the session date via SYSDATE, it produces a date-sensitive, ledger-aware list of periods in which recurring journal entries can legitimately be generated or reviewed. Its primary role is as a validation and reporting helper: rather than re-implementing the logic that determines whether a recurring batch has any active header for a given period, callers can select from this view directly. This makes it useful for custom concurrent programs, discoverer reports, and ad hoc SQL that must confirm which periods are valid for a recurring batch before submission.

Underlying Base Objects

The view is defined over three base objects, all referenced as APPS synonyms:

  • GL_PERIOD_STATUSES — the source of the period-level attributes. The view filters this table to APPLICATION_ID = 101 (the General Ledger application) and to periods whose CLOSING_STATUS is 'O' (Open) or 'F' (Future Enterable).
  • GL_RECURRING_BATCHES — supplies the RECURRING_BATCH_ID for each candidate row. The join is a cross-product between eligible period status rows and recurring batches, constrained by the correlated existence test below.
  • GL_RECURRING_HEADERS — used only within a correlated EXISTS subquery. For each (period, batch) candidate pair, a header is considered active when the period's effective date falls within the header's START_DATE_ACTIVE/END_DATE_ACTIVE range, with NVL defaulting those bounds to the period start and end dates respectively.

The active-date comparison uses a DECODE expression over GREATEST(SYSDATE, period_start) and LEAST(SYSDATE, period_end), which effectively clamps SYSDATE into the period window so that the current date is evaluated against the header's active range within the correct period boundary. This is the mechanism that makes the view's output change as time advances and periods open or close.

Key Columns

  • PERIOD_NAME — the accounting period name (for example, JAN-24) from GL_PERIOD_STATUSES.
  • LEDGER_ID — the ledger to which the period status applies; essential for multi-ledger reporting.
  • CLOSING_STATUS — 'O' or 'F' only, confirming the period is open or future-enterable.
  • START_DATE / END_DATE — the calendar boundaries of the period.
  • PERIOD_YEAR / PERIOD_NUM — the year and sequence number of the period, useful for ordering and comparisons.
  • RECURRING_BATCH_ID — the recurring batch identifier, linking the period back to a batch that has at least one active header overlapping it.

Common Use Cases and Queries

Typical uses include determining the valid submission periods for a recurring batch, driving period list-of-values in custom forms, and auditing which batches are active in the current period.

To list valid periods for a specific batch:

  • SELECT period_name, ledger_id, start_date, end_date, closing_status FROM apps.gl_recurring_valid_periods_v WHERE recurring_batch_id = :batch_id ORDER BY period_year, period_num;

To identify all batches valid in the current period for a ledger:

  • SELECT recurring_batch_id, period_name, closing_status FROM apps.gl_recurring_valid_periods_v WHERE ledger_id = :ledger_id AND SYSDATE BETWEEN start_date AND end_date;

Because the view already applies the open/future status filter and active-header test, these queries avoid duplicating that logic and remain consistent with the standard GL validation rules.