Search Results get_computed_dates




Overview
Explore in AI Chat

Overview

APPS.BIS_PMV_TIME_LEVELS_PVT is a private PL/SQL package in the Oracle E-Business Suite Business Intelligence System (BIS) product family, associated with the Performance Management Viewer (PMV) framework. It is compiled with AUTHID CURRENT_USER and is classified as a private (PVT) API, meaning it is not exposed for direct customer invocation but is consumed internally by other BIS components. The package encapsulates the date and time-level resolution logic used by PMV-based dashboards, reports, and balanced scorecards to translate abstract "time level" and "dimension level" definitions into concrete calendar boundaries at runtime.

The core business problem it addresses is the dynamic interpretation of time comparison semantics. When a PMV region displays a metric, it must determine which time period is "current," which period is "previous," and which historical column corresponds to a user-selected comparison type (for example, period-to-date, prior period, or year-over-year). This package centralizes that calculation so that all consumers apply consistent rules across responsibilities and regions.

Key Procedures and Functions

The package exposes nine documented procedures and functions:

  • GET_PREVIOUS_TIME_LEVEL_VALUE — Resolves the time-level identifier, time-level value, and start/end dates for the period preceding the current as-of date, driven by a supplied dimension level, region code, responsibility, and time comparison type. Accepts a flag to force current-mode evaluation.
  • GET_TIME_LEVEL_INFO — Returns the time-level identifier, value, and start/end dates for the period containing the given as-of date, evaluated according to a supplied mode.
  • GET_PREVIOUS_ASOF_DATE — Computes the prior as-of date corresponding to a dimension level and time comparison type, providing the anchor date other routines use for historical lookups.
  • GET_BIS_COMMON_START_DATE — Derives the common start date shared across a BIS report or region, ensuring aligned period boundaries.
  • GET_REPORT_START_DATE — Determines the effective start date for a report execution based on its defined time parameters.
  • GET_TIME_PARAMETER_RECORD — Retrieves the stored time parameter record that governs how a given region or report interprets time.
  • GET_COMPUTED_DATES — Returns the calculated date range (start and end) resulting from the combination of time level, mode, and as-of date.
  • GET_NESTED_PATTERN — Produces the nested time pattern used to map hierarchical time levels (for example, year containing quarter containing month) into a structured sequence suitable for PMV column generation. This is the routine most commonly referenced when diagnosing how multi-level time hierarchies are rendered.
  • GET_POPLIST_DATES — Builds the list of selectable dates presented in a PMV time poplist, supporting user-driven period selection.

Tables Accessed

The package operates primarily on BIS PMV metadata rather than transactional tables. Through APPS synonyms it resolves region definitions, responsibility-to-region associations, and time parameter configuration records that store the dimension level and comparison type defaults. Because it is a private helper, its data access is read-mostly: it queries configuration and parameter records to compute dates, and returns results through OUT NOCOPY parameters rather than persisting them. The documented metadata does not enumerate the specific table names beyond the synonym references, so direct table-level dependency analysis should be performed against the deployed 12.1.1 or 12.2.2 instance.

Usage Notes

BIS_PMV_TIME_LEVELS_PVT is invoked indirectly. PMV regions, dashboard definitions, and the BIS reporting engine call into it at runtime to resolve time context before rendering columns and values. It is referenced by four other packages within the BIS schema, which is consistent with its role as a shared internal utility. Developers troubleshooting dashboard date behavior, custom PMV region extensions, or time comparison mismatches should trace upward into the calling packages rather than invoking this private package directly, since its signature and behavior are not part of the supported public API surface. The package header dates from release 12.0-era source ($Header 120.1) and remains applicable to both 12.1.1 and 12.2.2.