Search Results update_grade

Overview

INV_GRADE_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. Its functional purpose within Oracle Inventory is to manage lot grade assignment and grade-status transacting for lot-controlled items. Grade control is a quality-oriented capability that allows an organization to assign a quality grade (for example, a grade code representing acceptable, rejected, or quarantined material) to a lot, and to record changes to that grade over the life of the lot. The package provides the transactional logic that underpins these operations, including the maintenance of grade history records that track each change made to a lot's grade. In Oracle EBS 12.1.1 and 12.2.2, the package is a VALID database object compiled under the APPS schema and references the standard SYS PL/SQL constructs, including the STANDARD package, which is consistent with normal compiled PL/SQL units. The package is classified under the ETRM metadata as OTHER, indicating it is not one of the public, documented APIs (such as the public lot API), but rather a supporting internal package used by other Inventory components. It should therefore be treated as a private implementation package rather than a supported entry point for external integrations.

Key Procedures and Functions

The ETRM metadata documents a single public program unit within the package: UPDATE_GRADE. This procedure is responsible for changing the grade associated with a lot and for persisting the associated history. Conceptually, invoking UPDATE_GRADE applies a new grade value to an existing lot_grade association, writes a corresponding record into the lot grade history table, and uses a global temporary table to stage the grade-status events being processed within the session. Because the procedure is the only documented entry point, callers should rely on it exclusively and avoid depending on any non-documented internal routines. The metadata does not publish a parameter list, so integrators should not assume a signature; the authoritative interface should be confirmed against the actual package specification in the target environment.

Tables Accessed

The documented table references, accessed through APPS synonyms, are as follows:

• MTL_LOT_NUMBERS — the core lot master table; read to validate the lot and its associated item/organization and to identify the lot being re-graded.
• MTL_LOT_GRADE_HISTORY — the audit/history table that records each grade change applied to a lot; written by UPDATE_GRADE to preserve a traceable grade history.
• MTL_LOT_GRADE_HISTORY_S — the sequence and/or supporting structure associated with the grade history table, used to generate or retrieve the history record identifier during insertion.
• MTL_GRADE_STATUS_ERES_GTMP — a global temporary table used to stage grade-status event rows within the session, supporting the e-records/grade-status processing logic.
• DUAL — the standard single-row utility table used for constants, sequence lookups, or validation checks.

Collectively, these tables confirm that the package reads lot data, writes grade history, and stages transient grade-status event data.

Usage Notes

INV_GRADE_PKG is referenced by two other packages, including INV_LOT_API_PUB, the public lot API, and GMD_SAMPLES_GRP, which is associated with Oracle Process Manufacturing sample handling. This indicates that INV_GRADE_PKG is an internal dependency of the supported lot API rather than a direct integration point: the recommended approach for custom code is to invoke INV_LOT_API_PUB, which in turn calls INV_GRADE_PKG.UPDATE_GRADE. Grade changes are typically triggered from Inventory lot and grade maintenance forms, from the lot grade history inquiry, or from OPM sampling and quality transactions, and may also be reached through concurrent or batch processes that update lot grades. Because the package performs writes to history and staging tables, callers must ensure that concurrent grade updates against the same lot are serialized to avoid conflicting history records, and that any direct invocation (if unavoidable) is tested carefully, since the package is not published as a supported public API.