Search Results call_atp

Overview

MRP_ATP_PUB is a public PL/SQL package body owned by the APPS schema in Oracle E-Business Suite, classified as a PUB (public) API in the ETRM documentation set. Its role is to expose available-to-promise (ATP) functionality to calling applications, most notably Oracle Order Management and other modules that must confirm whether a requested quantity of an item can be promised on a given date. The package acts as a thin public wrapper over the internal ATP processing logic implemented in the MSC_ATP_PUB and MSC_ATP_PVT packages, which reside in the Advanced Supply Chain Planning schema family. As a package body with VALID status, it is fully compiled and available for invocation in both EBS 12.1.1 and 12.2.2 environments.

The dependency listing confirms that MRP_ATP_PUB sits at the boundary between the Oracle Order Management API layer (MRP_OM_API_PK) and the supply chain ATP engine (MSC_ATP_PUB, MSC_ATP_PVT, MSC_SCH_WB). It also depends on FND_API and FND_PROFILE for the standard EBS API error-handling and profile-option infrastructure, and on the PLITBLM public package for PL/SQL table (index-by table) type definitions and utilities.

Key Procedures and Functions

The documented API surface consists of two public procedures:

• CALL_ATP — the primary entry point for performing an available-to-promise check. It accepts the caller's scheduling request attributes, delegates the calculation to the internal ATP packages, and returns the promise result to the caller. Because the procedure name carries no "_NO_COMMIT" suffix, it is the standard variant that permits the caller's transaction state to be committed as part of the ATP processing cycle.
• CALL_ATP_NO_COMMIT — functionally equivalent to CALL_ATP but executes without issuing a commit. This variant exists so that callers already operating inside an open transaction (for example, a form that must maintain rollback capability) can obtain ATP results without prematurely ending the transaction. It is the preferred entry point when ATP is invoked from interactive UI code.

Both procedures rely on the standard FND_API error-handling conventions, meaning callers should inspect the returned API status and message stack rather than relying solely on PL/SQL exceptions.

Tables Accessed

The ETRM metadata documents a single table reference for this package: PLITBLM. In practice PLITBLM is not a business data table but a public PL/SQL utility package that supplies index-by table and record type declarations used throughout the EBS code base. The substantive ATP data — item supply, demand, on-hand, and scheduled receipt information — is not read directly by MRP_ATP_PUB; it is retrieved by the underlying MSC_ATP_PUB/MSC_ATP_PVT layers, which MRP_ATP_PUB calls. This keeps the public wrapper insulated from the physical ATP schema objects.

Usage Notes

MRP_ATP_PUB is a heavily consumed API. The documented metadata shows it is referenced by 53 other database objects, reflecting its central position in order promising flows. Typical invocation scenarios include:

• Oracle Order Management — through MRP_OM_API_PK, which calls the ATP wrapper during order line scheduling and date-promise validation.
• Custom and extension code — developers building bespoke order-entry, quote, or fulfillment processes that require a programmatic ATP check should call CALL_ATP_NO_COMMIT when their transaction must remain open, and CALL_ATP when a commit is acceptable.
• Concurrent and batch processes — batch scheduling routines that evaluate large volumes of demand lines may invoke the commit-permitting variant.

Because the package is not referenced by any higher-level object within the tracked dependency set, it is treated as a leaf-level public API suitable for direct external calls. Callers should always validate FND_API return status and should never assume that a successful PL/SQL return implies a positive ATP result; the promise outcome is communicated through the API's out parameters.