Search Results cf_report_nameformula

Overview

The APPS.GMD_QCRCOA03_XMLP_PKG package is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. Its name follows the standard Oracle XML Publisher (BI Publisher) concurrent program package naming convention: the _XMLP_PKG suffix identifies the package body that supplies report-level data functions, formulas, and formatting flags to a concurrent program whose output is rendered against an XML Publisher data template.

The GMD_QCRCOA03 prefix places the object within the Oracle Process Manufacturing (OPM) Quality Management module. The embedded token QCRCOA corresponds to a Certificate of Analysis (COA) report for quality results, and the associated tables enumerated below (GMD_COA_HEADERS, GMD_COA_DETAILS, and the COA text tables) confirm that this package drives the extraction of Certificate of Analysis data — specifications, headers, detail results, and associated descriptive text — for printed or published COA output.

In the ETRM metadata the object is classified with an API classification of OTHER, indicating it is not a public, supported integration API but an internal report-support package. Its status is VALID, and dependency information shows only a reference to the SYS STANDARD package and to itself, as is typical of generated XML Publisher packages.

Key Procedures and Functions

Seven documented procedures and functions are exposed by this package. Their purposes, consistent with the XML Publisher report-support pattern, are as follows:

• CF_REPORT_NAMEFORMULA — A formula function returning the report name used by the concurrent program and its XML Publisher template, typically supplying the display title for the report header and file naming.
• QCRCOA01_HEADER — The primary data function for the report, responsible for assembling the header-level query that extracts COA header and specification data for the report's outer grouping.
• BEFOREREPORT — The standard XML Publisher trigger executed before the report is generated; used to initialize package state, session values, or report parameters prior to data extraction.
• BEFOREPFORM — The pre-format trigger fired before the report layout is applied, used to prepare formatting-level variables and flags.
• AFTERPFORM — The post-format trigger, executed after report formatting to reset or finalize formatting-level state.
• AFTERREPORT — The standard post-report trigger, executed after report completion, used to clean up temporaries and release package-level values.
• PRINT_TEXT_FLAG_P — A flag indicator controlling whether associated COA descriptive text (from the text tables) is printed on the report output.

Tables Accessed

The package reads from the following tables through APPS synonyms, which constitute the COA data model in OPM Quality:

• GMD_COA_HEADERS — The COA header records, providing the top-level certificate identity and specification linkage.
• GMD_COA_DETAILS — The line-level COA results, supplying individual quality result rows shown beneath each header.
• GMD_COA_SPEC_HDR_TEXT — Header-level specification text attached to the COA specification.
• GMD_COA_SPEC_TEXT — Specification-level descriptive text.
• GMD_COA_RSLT_TEXT — Result-level text annotations associated with individual COA detail results.

Together these tables support extraction of the full certificate content — header, specification, results, and narrative text.

Usage Notes

This package is invoked indirectly through the concurrent program associated with the Certificate of Analysis report rather than by direct call. Oracle EBS 12.1.1 and 12.2.2 both execute such report-support packages in the context of an XML Publisher concurrent program: the report definition invokes the data function (QCRCOA01_HEADER) to produce the XML data source, and the other routines provide triggers, formulas, and flags consumed during formatting and printing.

Because the package is classified as OTHER and referenced by no other packages, it should be regarded as internal to the standard report and not as an extension point. Customizations should be limited to report templates, parameters, and concurrent program configuration rather than direct modification of the package. Any client extension should be performed through supported personalization or template layering to preserve upgrade integrity.