Search Results g_process_values

Overview

GMD_QC_TESTS_PUB is the public API layer for Oracle Process Manufacturing (OPM) Quality Control test definitions. It provides the supported interface through which external callers — Oracle Forms, concurrent programs, and custom extensions — create and delete QC test headers, associated test value rows, and customer-specific test assignments. In Oracle EBS 12.1.1 and 12.2.2, this package belongs to the APPS schema and is classified as a PUB API, meaning its procedures constitute the sanctioned, upgrade-safe entry points into the underlying QC test tables.

The package header comment identifies it as "the public layer for the QC TESTS API," written by H. Verdding of OPM Development (EMEA). The body declares three global Boolean flags — G_PROCESS_TESTS, G_PROCESS_VALUES, and G_PROCESS_CUSTOMERS — which control whether the value and customer detail collections are processed during a given API call. A private routine, VALIDATE_INPUT_PARAMS, sets the latter two flags by testing the row counts of the incoming test value and customer test collections; this behavior was introduced under Bug 3506233. The package also includes a call to set_user_context to establish the correct operating context, added under Bug 2711643.

Key Procedures and Functions

• CREATE_TESTS — The primary creation routine. It accepts a QC test header record, a collection of test value rows, and a collection of customer test rows, and inserts the corresponding data into the QC test tables. It follows the standard EBS API convention, exposing API version, initialization of the message list, commit control, and validation level parameters, together with an optional user name. Output parameters return the created test header record and the two detail collections. Common IN parameters also include the test header record (p_qc_tests_rec) and the two PL/SQL tables (p_qc_test_values_tbl, p_qc_cust_tests_tbl).
• DELETE_TEST_HEADERS — Removes QC test header records and, as required, their dependent test value and customer test rows. It is the deletion counterpart to CREATE_TESTS for the header-level entity.
• DELETE_TEST_VALUES — Removes individual QC test value rows belonging to a test, supporting targeted maintenance of the value detail without deleting the parent test header.
• DELETE_CUSTOMER_TESTS — Removes customer-specific test assignments, allowing a test to be disassociated from a particular customer without affecting the underlying test definition.

All four routines are documented procedures; no parameter lists are enumerated in the metadata beyond those visible in the package body excerpt.

Tables Accessed

The package reads and writes the following tables through APPS synonyms:

• GMD_QC_TESTS — The QC test header table, holding each test definition. Referenced directly by the anchored %ROWTYPE declaration and written by CREATE_TESTS; cleaned up by DELETE_TEST_HEADERS.
• GMD_QC_TEST_VALUES — Stores the individual value rows for a test. Populated by CREATE_TESTS and maintained or removed by DELETE_TEST_VALUES.
• GMD_CUSTOMER_TESTS — Maps tests to specific customers. Populated by CREATE_TESTS and removed by DELETE_CUSTOMER_TESTS.
• PLITBLM — The standard EBS message-handling table used by the API to log and retrieve messages generated during processing. The package participates in the standard message-list pattern (API version, p_init_msg_list, and related conventions), which accounts for this reference.

Usage Notes

GMD_QC_TESTS_PUB is invoked whenever QC test data must be created or removed programmatically rather than through direct table DML. Typical callers include the OPM Quality Control setup forms, concurrent programs that bulk-load or purge test definitions, and custom integrations that migrate or synchronize test data. No other documented package references this package, so it functions as a top-level public entry point rather than a shared internal utility.

Callers should observe the standard EBS API contract: pass a valid API version, control message-list initialization, and set commit behavior explicitly according to the transaction boundary required. The value and customer collections are optional; when either collection is empty, the corresponding Boolean flag is set to FALSE and that detail set is skipped, so a header-only creation is valid. Because a session user context is established internally, custom callers do not need to set the OPM context themselves. As a PUB API, it should be preferred over direct inserts or deletes against the underlying GMD tables to preserve data integrity and upgrade compatibility.