Search Results p_report_id

Overview

QPR_REPORT_ENTITIES_PVT is a private (PVT) PL/SQL package body owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Oracle Quality and Product Repository reporting subsystem (the QPR module) and encapsulates the deletion logic for report entity definitions stored in the QPR reporting tables. The package serves a narrower, internal role than a public API: it is classified as PVT because its procedures are intended to be consumed by other QPR packages and internal processing rather than called directly by external integrations. Its principal business function is to provide safe, ordered removal of report headers, report lines, and relationships between related reports, so that orphaned child rows are not left behind when a report definition is discarded. Return status is communicated through the standard FND_API return status convention, allowing callers to detect success or error without relying on unhandled exceptions.

Key Procedures and Functions

The package exposes four documented procedures, all oriented around deletion of report entities keyed by the report header identifier that the user searched for, p_report_id.

• DELETE_REPORT_HEADER — Deletes a single report header record from the header tables. It accepts the report header identifier as input (p_report_id) and returns the standard FND_API return status. Its documented scope is limited to the header itself, making it the lowest-level deletion primitive in the package.
• DELETE_REPORT — Deletes a report header together with its report lines and related report relationships for a given report identifier. It internally iterates the report lines associated with the header and invokes related-report cleanup, providing a full logical deletion of one report definition.
• DELETE_RELATED_REPORTS — Removes the relationship records that associate a report with other reports. It is invoked by DELETE_REPORT as part of the broader deletion sequence and addresses the relations table directly.
• DELETE_REPORTS — Provides deletion across multiple reports, extending the single-report logic to a set of report entities. It is the highest-level entry point among the four documented procedures.

Tables Accessed

The package operates against four QPR tables, reached through APPS synonyms:

• QPR_REPORT_HDRS_B — the base (non-translated) report header table, from which header rows are deleted.
• QPR_REPORT_HDRS_TL — the translated report header table, deleted for the same report header identifier to keep header data and its translations consistent.
• QPR_REPORT_LINES — the report line table. Rows are identified by REPORT_HEADER_ID and are removed when a full report is deleted rather than just its header.
• QPR_REPORT_RELNS — the report relations table, holding links between related reports, cleared by DELETE_RELATED_REPORTS.

The paired deletion of the _B and _TL header tables reflects standard Oracle EBS multilingual design: every header delete must remove the base row and all corresponding translation rows to avoid integrity errors.

Usage Notes

Because the package body is flagged PVT, it is normally called from other QPR PL/SQL packages rather than from user-facing code. The metadata records that it is referenced by one other package, indicating its role as an internal helper within the QPR reporting stack. Typical invocation paths include Oracle Forms-based report definition maintenance screens, where a user deleting a report triggers the underlying deletion procedures, and concurrent programs or internal batch cleanup routines that must purge obsolete report definitions. Custom code should invoke DELETE_REPORT or DELETE_REPORTS rather than DELETE_REPORT_HEADER, since the header-level procedure does not clear lines or relations and can leave inconsistent data. Callers must always inspect the returned x_return_status for FND_API.G_RET_STS_SUCCESS or G_RET_STS_ERROR, and should execute the procedures within a controlled transaction so that partial deletions can be rolled back. When passing p_report_id, the value must correspond to an existing REPORT_HEADER_ID; no validation of existence is guaranteed by the deletion statements themselves.