Search Results quarter_num




Overview
Explore in AI Chat

Overview

PMI_GL_CALENDAR_V is an APPS-owned database view in Oracle E-Business Suite, delivered as part of the PMI (Process Manufacturing Intelligence) product family. Its documented purpose is to link the General Ledger calendar to the OPM (Oracle Process Manufacturing) company. In practice, the view presents a flattened, query-ready slice of the GL accounting calendar restricted to a specific set of books and joining that calendar to an OPM policy/company definition.

In EBS 12.1.1 and 12.2.2 the object remains a VALID view owned by APPS. Because it is a view rather than a table, no storage or index maintenance is required; performance derives entirely from the underlying GL tables. This makes it a convenient integration and reporting surface where an OPM-side query needs GL period information without re-implementing the multi-table join against GL_PERIODS, GL_SETS_OF_BOOKS, and the OPM policy master.

Functionally, the view is a bridge object: the GL calendar defines when accounting periods open and close, while the OPM company / policy master (GL_PLCY_MST) identifies which set of books an OPM company posts to. PMI_GL_CALENDAR_V resolves that relationship so that reporting and validation logic can enumerate the periods that apply to a given OPM company.

Underlying Base Objects

The documented base objects referenced by PMI_GL_CALENDAR_V are:

  • GL_PERIODS (referenced through a SYNONYM) — the GL calendar table holding one row per accounting period, including period name, period type, year, quarter, period number, and start/end dates.
  • GL_SETS_OF_BOOKS (referenced through a VIEW) — the set of books definition, providing PERIOD_SET_NAME and ACCOUNTED_PERIOD_TYPE for the ledger.
  • GL_PLCY_MST (referenced through a SYNONYM) — the OPM policy master, which carries the company code (CO_CODE) and the associated set of books name (SET_OF_BOOKS_NAME).

The join logic documented in the view text is: GL_PERIODS.PERIOD_SET_NAME = GL_SETS_OF_BOOKS.PERIOD_SET_NAME, GL_SETS_OF_BOOKS.NAME = GL_PLCY_MST.SET_OF_BOOKS_NAME, and GL_PERIODS.PERIOD_TYPE = GL_SETS_OF_BOOKS.ACCOUNTED_PERIOD_TYPE. A filter excludes adjustment periods via GL_PERIODS.ADJUSTMENT_PERIOD_FLAG <> 'Y', so only regular, non-adjustment periods are returned.

In 12.2.2, GL_SETS_OF_BOOKS is itself surfaced as a view over the ledger definitions, reflecting the multi-organization architecture of Release 12; the synonym layer allows PMI_GL_CALENDAR_V to remain stable across releases.

Key Columns

  • CO_CODE — the OPM company code carried from GL_PLCY_MST; identifies the company whose calendar is being reported.
  • PERIOD_TYPE — the accounting period type (for example, Month), inherited from GL_SETS_OF_BOOKS.ACCOUNTED_PERIOD_TYPE.
  • PERIOD_YEAR — the fiscal/accounting year of the period.
  • QUARTER_NUM — the quarter number within the year.
  • PERIOD_NUM — the sequential period number within the year.
  • PERIOD_NAME — the GL period name (for example, JAN-24); the human-readable key used throughout GL and OPM reporting.
  • START_DATE and END_DATE — the opening and closing dates of the period, used for date-range filtering and validation.

Common Use Cases and Queries

Typical scenarios include: populating period-selection lists in OPM/PMI reports, validating that a transaction date falls inside an open GL period for a given company, and reconciling OPM company calendars with their assigned set of books.

A basic query returning the calendar for one company:

  • SELECT period_name, period_year, period_num, start_date, end_date
  • FROM apps.pmi_gl_calendar_v
  • WHERE co_code = :company_code
  • ORDER BY start_date;

To determine the period covering a specific date:

  • SELECT period_name
  • FROM apps.pmi_gl_calendar_v
  • WHERE co_code = :company_code
  • AND :txn_date BETWEEN start_date AND end_date;

Because the view is not indexed, queries should filter on CO_CODE and date ranges to limit the rows scanned in GL_PERIODS. For large deployments, wrapping the view in an inline view with the company filter applied first typically yields the most predictable execution plans across both 12.1.1 and 12.2.2.