Search Results check_next_approver

Overview

GMD_QM_UOM is an Oracle E-Business Suite PL/SQL package owned by APPS and classified as OTHER within the ETRM metadata registry. It belongs to the process manufacturing quality management domain, where the GMD_ prefix identifies objects associated with Oracle Quality and Oracle Process Manufacturing (OPM). The package is declared with AUTHID CURRENT_USER, meaning its database privileges are evaluated against the invoking schema rather than the package owner. This is significant in EBS environments where custom quality extensions or workflow-driven logic execute under a calling user's identity.

The package's stated purpose is event verification and approver resolution for the Quality Management workflow. It provides the server-side logic invoked when a quality-related workflow event (such as a specification change, sampling event, or test result) must be validated before it proceeds to approval routing. The primary use case associated with the user search term check_next_approver is the determination of whether an additional approver exists in a multi-step approval chain and, if so, the forwarding of the workflow item to that approver.

The package header dates to 2003 (GMDQMUMS.pls 115.0), indicating it is a mature, release-stable object carried forward through 12.1.1 and 12.2.2 without interface changes.

Key Procedures and Functions

The documented interface exposes exactly two procedures, both with identical parameter conventions: a workflow item type, item key, activity identifier, function mode, and an OUT NOCOPY result string.

• VERIFY_EVENT — Verifies a quality management event and, on successful validation, dispatches the corresponding notification. It is the entry point that confirms the event is legitimate and actionable within the quality workflow before any approval routing occurs. Its result output communicates the outcome back to the calling workflow engine.
• CHECK_NEXT_APPROVER — Checks whether a next approver exists for the current workflow item. The procedure comment states its intent plainly: "procedure to Check next approver if any." This is the procedure users reference when diagnosing stalled or misrouted quality approvals. It evaluates the approval hierarchy and reports the result through the OUT parameter, allowing the workflow to branch to the next approval activity or terminate the chain.

No functions are declared in the documented interface. Both procedures use NOCOPY for the OUT parameter, a performance optimization appropriate for VARCHAR2 results returned to a workflow background engine.

Tables Accessed

The package reaches a broad set of tables through APPS synonyms, spanning Oracle Application Object Library, process manufacturing, inventory, and purchasing. The documented references include FND_APPLICATION, FND_LOOKUP_VALUES, and FND_USER for application registration, lookup-based configuration, and approver identity resolution. Quality-specific data is drawn from GMD_EVENT_SPEC_DISP, GMD_QC_TESTS, GMD_SAMPLING_EVENTS, and GMD_SPECIFICATIONS, which supply the event, test, sampling, and specification context required by VERIFY_EVENT.

Unit-of-measure and conversion logic accesses GMD_UOM_CONVERSIONS, MTL_LOT_UOM_CLASS_CONVERSIONS, and MTL_UNITS_OF_MEASURE, reflecting the package's role in UOM-aware quality checks. Lot and item context comes from MTL_LOT_NUMBERS and MTL_SYSTEM_ITEMS_KFV, while MTL_PARAMETERS provides inventory organization defaults. Purchasing context for receiving-related quality events is supplied by PO_HEADERS_ALL and PO_LINES_ALL.

Usage Notes

GMD_QM_UOM is a workflow-support package, not a public API. It is typically invoked from Oracle Workflow function activities attached to the quality management item type, where the workflow engine supplies p_itemtype, p_itemkey, p_actid, and p_funcmode, and consumes p_resultout to determine the next transition. It is not referenced by any other documented package, confirming that its callers are workflow definitions rather than PL/SQL code.

Because the package is AUTHID CURRENT_USER, custom code invoking these procedures directly must ensure the executing schema has appropriate privileges on every underlying table. Customizations that call CHECK_NEXT_APPROVER outside of workflow should pass a valid item key and be prepared to interpret the result string, as its exact content is not part of the documented contract. Given the 2003 header and stable signature, the package can be treated as backward-compatible across 12.1.1 and 12.2.2, and any diagnostic work on stuck approvals should begin by confirming the workflow activity's function mode and the approver source data in FND_USER.