Search Results eam_material_validate_pub




Overview
Explore in AI Chat

Overview

APPS.EAM_MATERIAL_VALIDATE_PUB is a public PL/SQL API package in Oracle E-Business Suite that supports Enterprise Asset Management (EAM) work order material validation. Its principal business function is to determine material availability and shortage conditions for an EAM work order before or during execution, allowing maintenance operations to assess whether required parts and components are available in the correct quantities. The specification declares the package with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking schema rather than the defining APPS schema, a characteristic common to APIs intended for controlled access through APPS synonyms and grants.

Anchored on work in process (WIP) entities that represent EAM work orders, the package provides a programmatic gateway for checking shortage status. The header comment ($Header: EAMPMTSS.pls 120.6 2012/01/27) indicates the file is maintained under the EAM material transaction/validation source stream, and the documented history records initial creation by Girish Rajan on 02-FEB-2005. The API follows Oracle's standard PLS API conventions, including FND_API-derived return status, message count, and message data parameters, which allow callers to participate in the EBS error-handling framework.

Key Procedures and Functions

The documented public interface exposes three callable elements:

  • GET_OPEN_QTY — A function that returns a numeric open quantity derived from three input quantities: required quantity, allocated quantity, and issued quantity. It is used to compute the remaining material requirement for a work order line, typically as required minus the sum of allocated and issued amounts, providing the basis for shortage evaluation.
  • CHECK_SHORTAGE — A procedure that evaluates whether a material shortage exists for a given work order. It accepts the API version, an initialization flag, and a commit flag as inputs, returns standard EBS API return status, message count, and message data, takes the WIP entity identifier and a source API name, and returns an output indicator (x_shortage_exists) reporting the shortage determination. Invocation follows the FND_API pattern for initialization, exception handling, and optional commit control.
  • ESCAPEXMLEAM — A function that returns an XML-escaped version of a supplied string. The specification notes this naming was adopted because newer PL/SQL versions treat the prior identifier ("escapeXMLEam") as a keyword (bug 9827868), so the renamed function now performs the escaping operation.

The package also declares the constant G_PKG_NAME, used for consistent error and debug message identification.

Tables Accessed

The documented tables referenced via APPS synonyms include CSI_ITEM_INSTANCES, EAM_WORK_ORDER_DETAILS, WIP_DISCRETE_JOBS, WIP_ENTITIES, and WIP_REQUIREMENT_OPERATIONS. CSI_ITEM_INSTANCES supplies item instance (serialized asset) context associated with the maintenance activity. EAM_WORK_ORDER_DETAILS provides EAM-specific work order definitions and attributes. WIP_ENTITIES and WIP_DISCRETE_JOBS identify and qualify the work order being validated within the WIP model. WIP_REQUIREMENT_OPERATIONS holds the material requirements per operation, quantities allocated, and issued transactions used by GET_OPEN_QTY and CHECK_SHORTAGE to derive open quantity and shortage status.

Usage Notes

EAM_MATERIAL_VALIDATE_PUB is classified as a public (PUB) API and is referenced by two other packages, indicating it is intended as a stable integration point rather than a private helper. It is typically invoked from EAM work order entry and maintenance execution flows — forms-based work order screens, related public APIs, and custom PL/SQL that must determine whether sufficient material exists before releasing or executing work. Because it follows FND_API conventions, callers should initialize the API, inspect x_return_status for FND_API.G_RET_STS_SUCCESS or error, and propagate x_msg_count and x_msg_data into the standard message stack. Transactions should be committed by the calling application unless the calling context explicitly requests commit through p_commit. Direct table manipulation should be avoided in favor of this validated API.