Search Results number_arr

Overview

The APPS.MRP_ATP_PUB package is a public PL/SQL API within Oracle E-Business Suite that provides the core programmable interface for Available-to-Promise (ATP) processing. ATP is the planning and order-promising capability that determines whether a requested quantity of an item can be delivered on a requested date, based on current supply, demand, and scheduling constraints. This package is the packaged entry point through which external callers — most notably Order Management and other scheduling components — request ATP checks against the planning data held in the Oracle Supply Chain Planning schema.

The package header (identified by the $Header: MRPEATPS.pls 120.4 banner) exposes an extensive set of collection types used to pass multi-row data into and out of the ATP engine. These types are central to the package's contract and explain why users frequently search for the internal element number_arr. Collections such as number_arr, char1_arr, char30_arr, char80_arr, char255_arr, and date_arr are declared as nested tables and used to pass bulk arrays of attributes to the ATP calculation routines without repeated single-row calls.

Of particular note is number_arr, defined as TYPE number_arr IS TABLE OF number;. It is the foundational numeric collection on which the composite ATP_Supply_Demand_Typ record is built. That record contains parallel number_arr fields — Level, Identifier, Inventory_Item_Id, Organization_Id, Resource_Id, Supplier_Id, From/To Organization and Location identifiers, Disposition_Type, Supply_Demand_Type, and related identifiers — allowing ATP supply and demand detail lines to be passed as synchronized arrays. The record also carries char30_arr and char3_arr fields such as Ship_Method and Uom.

Key Procedures and Functions

The package exposes two documented public procedures:

• CALL_ATP — The primary ATP invocation routine. It performs the available-to-promise calculation for the supplied item, organization, and demand context, returning the promise result to the caller. It is the standard entry point used by order-promising flows.
• CALL_ATP_NO_COMMIT — A variant of the ATP call that executes the same availability logic without issuing a database commit, allowing the caller to control transaction boundaries and integrate the ATP check within a larger unit of work.

Parameter lists are not reproduced here; callers should reference the package specification for exact signatures. The documented distinction between the two procedures is solely the commit behavior.

Tables Accessed

The documented table accessed through APPS synonyms is PLITBLM, the planning item/balance table used within the Oracle Planning schema. ATP processing reads planning supply and demand balances from this table to determine whether the requested quantity can be promised. The package operates against planning data rather than transactional order tables, which is why the collection-based interface is used to marshal large volumes of item and organization context efficiently.

Usage Notes

MRP_ATP_PUB is classified as a public (PUB) API, indicating it is intended for supported external invocation. It is referenced by 53 other packages, reflecting its role as a shared service in the order-to-cash and planning stack. Typical invocation points include:

• Oracle Order Management scheduling and promising logic, which calls ATP when a sales order line is scheduled.
• Other planning and scheduling packages that require ATP checks during planning runs or capacity evaluation.
• Custom code and extensions that need to validate item availability programmatically, using the number_arr-based ATP_Supply_Demand_Typ record to pass supply and demand detail.

Because CALL_ATP commits and CALL_ATP_NO_COMMIT does not, the latter is preferred when the ATP result must be part of a caller-managed transaction. Callers should treat the array-based interface as the supported integration contract and avoid modifying the underlying PLITBLM data directly.