Results for “application_id”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

RG_PERIOD_YEARS_V is a database view owned by the APPS schema within the Oracle E-Business Suite environment, delivered as part of the RG — Application Report Generator product family. Its ETRM documentation status is VALID, and its stated description is "10SC ONLY," indicating that the object is scoped for a specific deployment or localization context rather than being a general-purpose reporting component. As a view, it does not store data; it presents a consolidated, read-only projection of accounting period years drawn from the General Ledger period status data.

Functionally, the view answers a narrow question: which fiscal period years exist for a specified application and ledger combination. Because it collapses duplicate rows through grouping, it returns a distinct list of period years rather than the row-per-period detail found in the base table. This makes it useful as a lightweight reference or lookup source in reports, concurrent program parameters, and validation logic that must confirm the availability of a period year before further processing.

Underlying Base Objects

The view is defined over GL_PERIOD_STATUSES, referenced in the ETRM metadata as a synonym. GL_PERIOD_STATUSES is the standard General Ledger table that records open, closed, and permanently closed status for each accounting period across ledgers and applications. The view's defining text is:

• SELECT PERIOD_YEAR, APPLICATION_ID, LEDGER_ID FROM GL_PERIOD_STATUSES
• GROUP BY APPLICATION_ID, LEDGER_ID, PERIOD_YEAR
• HAVING APPLICATION_ID = 101

The HAVING clause restricting APPLICATION_ID to 101 is significant. In Oracle EBS, application identifier 101 corresponds to the General Ledger product. The filter therefore limits the result set to General Ledger period status records, excluding rows that the same table may carry for other application contexts. The GROUP BY clause on APPLICATION_ID, LEDGER_ID, and PERIOD_YEAR deduplicates the source data so that each distinct combination of ledger and period year appears exactly once, regardless of how many individual accounting periods or status changes exist beneath it.

Key Columns

• PERIOD_YEAR — The fiscal or calendar year to which the accounting period belongs. This is the primary value returned and the attribute most consumers filter or list on.
• APPLICATION_ID — The application owning the period status record. Because of the HAVING clause, values returned by this view are effectively fixed at 101 (General Ledger).
• LEDGER_ID — The identifier of the ledger (formerly set of books) for which the period year is defined. This column allows consumers to scope the result to a particular ledger.

Common Use Cases and Queries

The principal use case is enumerating available period years for a ledger to drive report parameters, validation, or dropdown-style list of values logic. A typical query retrieving all period years for a given ledger is:

• SELECT PERIOD_YEAR FROM APPS.RG_PERIOD_YEARS_V WHERE LEDGER_ID = :p_ledger_id ORDER BY PERIOD_YEAR;

A second scenario confirms whether a specific year exists before a process proceeds:

• SELECT COUNT(*) FROM APPS.RG_PERIOD_YEARS_V WHERE LEDGER_ID = :p_ledger_id AND PERIOD_YEAR = :p_year;

A third pattern joins the view to ledger or report configuration data to present a friendly year list. Because the view is confined to application 101 and aggregates away period-level detail, it should not be used where individual period names, start dates, or open/closed status are required; in those cases the base table GL_PERIOD_STATUSES should be queried directly. The view remains a compact, purpose-built reference for period-year availability within the General Ledger context.