Search Results get_inv_spec_or_vr_id

Overview

GMD_SPEC_MATCH_GRP is the group-layer PL/SQL package within the Oracle E-Business Suite Process Manufacturing (OPM) quality module that implements specification matching logic. Its declared header, first shipped in file GMDGSPMS.pls and last revised at version 120.7 in March 2006, defines the package as AUTHID CURRENT_USER, meaning all unqualified object references resolve through the calling schema rather than the package owner. The package exists to determine which specification version applies to a given inventory, customer, supplier, WIP, resource, or location context, and to return associated test and specification identifiers.

The package's role is central to OPM quality workflows: whenever a sample is taken, a result is recorded, or an approval decision is required, the quality engine must know which specification, version, and test govern the material. GMD_SPEC_MATCH_GRP encapsulates that resolution logic so that forms, concurrent programs, and dependent packages do not embed duplicated matching rules.

Key Procedures and Functions

The ETRM metadata documents eleven callable units. They fall into three functional groupings.

• FIND_INVENTORY_SPEC, FIND_CUSTOMER_SPEC, FIND_WIP_SPEC, FIND_SUPPLIER_SPEC, FIND_LOCATION_SPEC, FIND_RESOURCE_SPEC — Single-context matchers. Each resolves the applicable specification version for its respective domain (inventory, customer, work-in-process, supplier, storage location, or resource).
• FIND_CUST_OR_INV_SPEC, FIND_WIP_OR_INV_SPEC, FIND_SUPPLIER_OR_INV_SPEC — Fallback matchers that apply a precedence rule: the domain-specific specification is evaluated first, and if none is found the logic falls back to the inventory specification.
• GET_RESULT_MATCH_FOR_SPEC and GET_INV_SPEC_OR_VR_ID — Result-oriented and identifier-oriented routines. GET_RESULT_MATCH_FOR_SPEC determines whether a recorded result conforms to its specification. GET_INV_SPEC_OR_VR_ID, the routine referenced in the originating search, returns the inventory specification identifier or the version identifier applicable to a supplied context, functioning as the primary lookup used to translate a physical inventory scenario into the corresponding specification or version record.

The package header defines two record types, INVENTORY_SPEC_REC_TYPE and CUSTOMER_SPEC_REC_TYPE, which carry matching context. Both include inventory_item_id, revision, organization_id, and subinventory. The inventory record additionally carries grade_code, parent_lot_number, lot_number, locator_id, date_effective, exact_match, and test_id. The header comments explicitly mark item_id, lot_id, orgn_code, whse_code, and location as obsolete yet retained for migration compatibility, and note that test_id is supplied only by the production team.

Tables Accessed

The package reads and writes through APPS synonyms across the OPM quality and manufacturing schema.

• Specification definition: GMD_SPECIFICATIONS_B, GMD_SPEC_TESTS_B, GMD_INVENTORY_SPEC_VRS, GMD_CUSTOMER_SPEC_VRS, GMD_SUPPLIER_SPEC_VRS, and GMD_MONITORING_SPEC_VRS hold specifications, their tests, and version history.
• Transaction context: GMD_SAMPLES, GMD_RESULTS, GMD_SAMPLE_SPEC_DISP, and GMD_QC_STATUS store samples, analytical results, specification disposition, and quality status.
• Manufacturing structures: GMD_RECIPES_B, GMD_ROUTINGS_B, GMD_OPERATIONS_B, FM_FORM_MST_B, and FM_ROUT_DTL supply recipe, routing, operation, formula, and routing-detail context needed to resolve WIP and resource specifications.

Usage Notes

The package is a group-layer API, not an end-user form. It is invoked by OPM quality forms that require specification resolution, by concurrent programs performing batch sample and result evaluation, and by nine other packages in the APPS schema. A notable historical consumer is GMDQCMJB.pls, which relies on the obsolete fields restored to the record types in the 2005 revision. Customizations calling GET_INV_SPEC_OR_VR_ID should populate the INVENTORY_SPEC_REC_TYPE through the documented attributes only and treat item_id, lot_id, orgn_code, whse_code, and location as migration-only parameters, since their replacement by inventory_item_id, organization_id, and locator_id is the supported path in release 12.1.1 and 12.2.2.