Search Results pa_report_util




Overview
Explore in AI Chat

Overview

PA_REPORT_UTIL is a utility PL/SQL package owned by the APPS schema in Oracle E-Business Suite Projects (PA). As its name implies, it provides shared helper logic consumed by the reporting layer of the Projects application rather than serving as a public business API. Its API classification in the ETRM repository is UTIL, confirming that it exists to support other programs — principally concurrent report submissions and their associated parameter validation — rather than to perform transactional updates on project data. The package and its body are both documented as VALID in the ETRM 12.2.2 reference, and the same object is present in 12.1.1.

The dominant theme of the package is resolution of default values and validation of report parameters. Project reporting in EBS relies heavily on profile options, GL period calendars, and implementation-level settings to drive utilization and related reports. PA_REPORT_UTIL centralizes the retrieval of those values so that individual report programs do not each re-implement the same lookups.

Key Procedures and Functions

  • GET_DEFAULT_VAL — Returns a default value for a report parameter, typically derived from a profile option or implementation setting, so that concurrent program parameters can be pre-populated when the user opens the submission form.
  • GET_DEFAULT_PERIOD_VAL — Resolves the default accounting period for a report, based on the GL period calendar and open/closed period status, allowing utilization-style reports to default to a sensible reporting period.
  • VALIDATE_U1 — Performs validation logic associated with a specific report parameter (the "U1" designation indicates a positional parameter slot). It confirms that the value supplied by the user is acceptable before the concurrent request is submitted.
  • VALIDATE_U2 — A parallel validation routine for a second parameter slot, following the same pattern as VALIDATE_U1.
  • GET_GE_FLAG — Retrieves a flag value, generally used to determine whether a particular reporting behavior or inclusion rule should be applied. The "GE" naming suggests a general or global enablement indicator.

These five routines constitute the entire documented surface of the package. No parameter lists are published in the metadata and should not be assumed; callers should reference the package specification directly.

Tables Accessed

The package reads from the following tables through APPS synonyms:

  • FND_PROFILE_OPTIONS_TL and FND_USER — source profile option definitions and user context, used by GET_DEFAULT_VAL to derive defaults.
  • GL_PERIODS and GL_PERIOD_STATUSES — General Ledger calendar and period state, used by GET_DEFAULT_PERIOD_VAL to choose a valid default period.
  • PA_IMPLEMENTATIONS — Projects implementation configuration, supplying organization-level defaults.
  • PA_RESOURCES_DENORM — the denormalized resource table, referenced in the context of utilization-related parameter resolution.
  • PA_UTILIZATION_OPTIONS — utilization reporting setup, which determines applicable defaults and flags such as those returned by GET_GE_FLAG.

The package is read-only with respect to these objects; no inserts, updates, or deletes are documented.

Usage Notes

PA_REPORT_UTIL is invoked indirectly. Its routines are called from the Projects reporting forms and concurrent program parameter validation logic whenever a utilization or project report is submitted. Custom code that needs to reproduce EBS-standard report defaults — for example, an extension that programmatically submits a Projects concurrent request — can call these functions to obtain the same default period, default value, or validation outcome that the standard form would produce.

The ETRM metadata records zero packages referencing PA_REPORT_UTIL, meaning it is not part of a documented dependency chain among other packages; its consumers are forms and concurrent programs rather than other PL/SQL packages. Because it is an internal utility rather than a certified public API, Oracle does not guarantee signature stability across patches, and any custom dependency on it should be treated as a risk to be re-verified after upgrades between 12.1.1 and 12.2.2.