Search Results populate_transfer

Overview

APPS.GMD_RESULT_TRANSFER_GRP is a valid PL/SQL package in the Oracle E-Business Suite Process Manufacturing (OPM) Quality module. Its classification as a "GRP" (group) package indicates that it groups a set of related operations rather than exposing a single business API. The package addresses the transfer of quality results between the various quality entities managed by OPM — most notably the movement of results from individual specification tests and samples into composite results, and the propagation of those composite results to the appropriate destinations. In practical terms, it supports the laboratory and quality-control workflow in which test outcomes recorded against samples are evaluated, consolidated, and used to update composite specifications, events, and related quality records.

The package operates within the APPS schema and depends only on the SYS.STANDARD package, confirming that it is self-contained PL/SQL with no external library dependencies beyond the Oracle-supplied STANDARD package. No other application packages reference GMD_RESULT_TRANSFER_GRP, so it is typically invoked directly by application forms, concurrent programs, or custom extensions rather than being called from within another packaged API.

Key Procedures and Functions

The ETRM metadata documents four procedures or functions within this group package. Their names indicate their roles in the result-transfer lifecycle:

• POPULATE_TRANSFER — Prepares the set of records that will participate in a result transfer. This typically involves selecting the relevant specification tests, samples, or composite results and staging them into the global temporary table GMD_RESULT_TRANSFER_GT so that subsequent processing can operate on a well-defined working set.
• DO_TRANSFER — Performs the substantive result-transfer action. It consumes the staged data and applies the resulting quality values to the target records, such as updating results, composite results, or associated specifications.
• COPY_PREVIOUS_COMPOSITE_RESULT — Copies a previously calculated or stored composite result, enabling reuse of an existing composite value rather than recalculating it, which is common when a composite specification is unchanged between sampling events.
• DELETE_SINGLE_COMPOSITE — Removes a single composite result, providing a controlled deletion path that maintains referential integrity across the composite result and its associated records.

The actual parameter lists are not published in the available metadata and should be confirmed against the package specification in the database prior to direct invocation.

Tables Accessed

The package reads from and writes to a broad set of tables using APPS synonyms, all owned by the OPM Quality schema family. The temporary table GMD_RESULT_TRANSFER_GT serves as the staging area for the transfer operation. The primary quality data tables are GMD_RESULTS, GMD_SPEC_RESULTS, and GMD_COMPOSITE_RESULTS, together with GMD_COMPOSITE_RESULT_ASSOC which links composite results to their component results. Specification and dispatch information is drawn from GMD_COMPOSITE_SPEC_DISP, GMD_EVENT_SPEC_DISP, and GMD_SAMPLE_SPEC_DISP. Sample and event context comes from GMD_SAMPLES and GMD_SAMPLING_EVENTS. Test definitions are held in GMD_QC_TESTS and GMD_QC_TESTS_B, with GMD_QUALITY_CONFIG providing module configuration. GMD_SPEC_TESTS and GMD_QC_UPDATE_INST_ID_S complete the set. The 1.2.2 metadata lists fourteen tables, reflecting the broad reach of the transfer workflow across the OPM quality data model.

Usage Notes

Because no other package references GMD_RESULT_TRANSFER_GRP, it is invoked from the top level: from OPM Quality forms, from concurrent programs that batch-transfer results, or from custom PL/SQL extensions. The typical sequence is to call POPULATE_TRANSFER to build the working set in GMD_RESULT_TRANSFER_GT, then DO_TRANSFER to commit the transferred values, using COPY_PREVIOUS_COMPOSITE_RESULT and DELETE_SINGLE_COMPOSITE for the specific copy and delete scenarios. The package is identical in structure on EBS 12.1.1 and 12.2.2; only the hosting technology stack differs. Developers extending the result-transfer behavior should call the package as documented rather than updating the underlying tables directly, since the package encapsulates the associated integrity logic.