Results for “pa_rep_year_pa_v”

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

Overview

PA_REP_YEAR_PA_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the Projects (PA) product family. Its documented purpose is concise and specific: it returns the set of Projects accounting year numbers (period years) that are valid for a given Oracle EBS implementation, tagged with the corresponding operating unit (ORG_ID). Rather than storing data of its own, the view derives its result set dynamically by joining the period calendar definition that controls Projects periods to the GL period calendar, so that only years actually enabled for Projects reporting are exposed.

Because Projects reporting — including expenditure, billing, and revenue reporting, and the standard PA reporting extract programs — operates within a defined period calendar and period type (typically the PA period type such as "PA Month" or a similar Projects-specific type), reporting components frequently need to populate a list of available reporting years. PA_REP_YEAR_PA_V serves that need. It is a read-only, DISTINCT-set view, and as such it behaves as a lightweight lookup for forms, concurrent program parameters, and ad hoc reporting queries that must present or filter on Projects year values. Being a view rather than a table, it carries no maintenance burden, no concurrent program to refresh it, and no data of its own to reconcile.

Underlying Base Objects

The documented ETRM metadata for this view identifies it as defined over the following referencing objects:

• PA_IMPLEMENTATIONS (referenced as a synonym in APPS) — the Projects implementation/operating unit setup table. It supplies the PERIOD_SET_NAME, PA_PERIOD_TYPE, and ORG_ID values that anchor the calendar used by each Projects implementation.
• GL_PERIODS (referenced as a synonym in APPS) — the General Ledger period definitions table. It supplies the PERIOD_YEAR values associated with each period set and period type.

The view text joins these two objects on the pair PERIOD_SET_NAME and PERIOD_TYPE, meaning the GL calendar definition must match the Projects implementation's period set name and Projects period type before a year is returned. This join is what constrains the output to years that are genuinely available in the Projects calendar for the implementation, rather than every year defined anywhere in General Ledger. The ORG_ID is projected from PA_IMPLEMENTATIONS, so the view is inherently operating-unit aware; in a multi-org environment, the same period year may legitimately appear once per operating unit.

The use of SELECT DISTINCT ensures each unique combination of PERIOD_YEAR and ORG_ID appears only once, which is important because GL_PERIODS contains many rows per year (one per accounting period) and the join would otherwise produce duplicates.

Key Columns

The view exposes a deliberately small column list, consistent with its role as a year lookup:

• PERIOD_YEAR — the Projects accounting year number (for example, 2024, 2025). This is the reporting year value presented to users or used to filter Projects reporting queries.
• ORG_ID — the operating unit identifier of the Projects implementation from which the year is derived. It allows callers to restrict the year list to the operating unit they are reporting against.

No other columns are documented. There is no period name, no start or end date, and no implementation identifier beyond ORG_ID. Consumers that require period-level detail, period names, or date ranges must join this view back to GL_PERIODS or to the Projects period tables on PERIOD_YEAR (and ORG_ID), because the view intentionally abstracts away everything except the year and its owning operating unit.

Common Use Cases and Queries

The primary use case is populating a year list — for example, a parameter list of values on a Projects report, or a validation query confirming that a requested reporting year exists for an operating unit before a report is submitted. A second common use is ad hoc reporting, where a query must iterate or filter across the years configured for Projects without hard-coding values.

Typical queries include:

• Retrieve all Projects reporting years for the current operating unit:
  SELECT period_year FROM apps.pa_rep_year_pa_v WHERE org_id = :org_id ORDER BY period_year;
• Retrieve the distinct years available across all Projects implementations (useful for cross-org reporting catalogs):
  SELECT DISTINCT period_year FROM apps.pa_rep_year_pa_v ORDER BY period_year DESC;
• Validate a user-entered year against the view before processing:
  SELECT COUNT(*) FROM apps.pa_rep_year_pa_v WHERE period_year = :entered_year AND org_id = :org_id;

Because the view reads PA_IMPLEMENTATIONS and GL_PERIODS — both setup/definition tables — it is inexpensive to query and safe to embed in reporting logic and concurrent program parameter validation. Users searching for "pa_rep_year_pa_v" are typically seeking exactly this: a supported, documented way to enumerate the Projects reporting years available to an operating unit without querying GL_PERIODS directly.