Search Results spec_rslt_upd_inst_id

Overview

The view APPS.GMD_QC_E_RESULTS_V belongs to the Oracle EBS Process Manufacturing Product Development module (product code GMD) and is a central reporting object for quality control (QC) result data. It consolidates information from the sample, result, and specification domains into a single denormalized structure, allowing concurrent programs, Oracle Reports, OAF pages, and integration extracts to retrieve QC results with all relevant context in one pass. The view is documented as VALID and owned by the APPS schema, which is the standard convention for Oracle EBS seed objects that must be accessed through a synonym with APPS as the connecting user.

The "E" prefix in the object name typically denotes an "enterprise" or extract-oriented view, and the presence of SAMPLE_ID as a leading column confirms that the view is a primary entry point for queries searching on sample_no, the user-visible sample identifier. Organizations commonly expose SAMPLE_ID to end users through sample numbering flexfields or generated sample numbers, and this view is the natural retrieval path when correlating a sample number with its associated test results and specification limits.

Underlying Base Objects

The documented base objects referenced by this view are:

• GMD_RESULTS — the primary result transaction table, aliased RSLT in the view text.
• GMD_SPEC_RESULTS — specification-level result records, providing the GSRSLT alias for update-instance tracking.
• GMD_SAMPLES — sample header information providing SAMPLE_ID.
• GMD_SPEC_TESTS — specification test definitions supplying minimum, target, and maximum values (GSTS alias).
• GMD_QC_TESTS and GMD_QC_TEST_VALUES_GRP — the test definition table and the package function GET_TEST_VALUE_DESC used to derive human-readable result meanings.
• GMD_TEST_METHODS and GMD_EVENT_SPEC_DISP — supporting reference data.
• FND_LOOKUP_VALUES_VL — used via the FLY and FLN aliases in DECODE expressions to translate Yes/No and delete-mark indicators into lookup meanings.
• MTL_PARAMETERS — supplies the laboratory organization context through LAB_ORGANIZATION_ID.

The view is defined in part over public synonyms, so its dependencies resolve to the same base tables regardless of whether the caller connects as APPS or an application user.

Key Columns

• RESULT_ID, SAMPLE_ID, TEST_ID — primary keys linking results to their sample and test definitions.
• TEST_RESULT — a DECODE that returns the correct value column (character or numeric) based on GQTS.TEST_TYPE.
• RESULT_MEANING — descriptive value derived through GMD_QC_TEST_VALUES_GRP.GET_TEST_VALUE_DESC.
• SPEC_MIN_VALUE, SPEC_TARGET_VALUE, SPEC_MAX_VALUE — specification limits decoded according to test type.
• RESULT_VALUE_NUM, RESULT_VALUE_CHAR, RESULT_DATE, TESTER, TESTER_ID, TEST_PROVIDER_ID — capture actual test execution details.
• ADDITIONAL_TEST_IND, OPTIONAL_IND, RSLT_DELETE_MARK — decoded lookup meanings driving business rules.
• CHECK_RESULT_INTERVAL, OUT_OF_SPEC_ACTION, USE_TO_CONTROL_STEP — quality action and workflow control attributes.

Common Use Cases and Queries

A frequent requirement is to retrieve all results for a given sample number. Because the view exposes SAMPLE_ID rather than a formatted sample number, the query typically joins to GMD_SAMPLES or filters by the numeric surrogate key resolved from the sample number:

• Locate every test result for a sample number, ordered by SEQ.
• Identify out-of-specification results by comparing TEST_RESULT against the decoded spec limits.
• Feed Certificate of Analysis (COA) reports using AD_HOC_PRINT_ON_COA_IND and PRINT_ON_COA_IND.
• Audit update instances using RSLT_UPD_INST_ID and SPEC_RSLT_UPD_INST_ID for interface reprocessing.

A representative query is:

SELECT r.sample_id, r.test_id, r.test_result, r.result_meaning, r.spec_min_value, r.spec_target_value, r.spec_max_value, r.result_date FROM apps.gmd_qc_e_results_v r WHERE r.sample_id = :sample_no ORDER BY r.seq;

Because the view is a database object rather than a table, it carries no indexes of its own; performance depends on the indexes of the underlying base tables and on the efficiency of the specification and lookup joins.