Search Results res_alloc_cum_atp




Overview

MRP_AATP_PVT is a private PL/SQL package body in the Oracle E-Business Suite Advanced Supply Chain Planning (ASCP) and Available-to-Promise (ATP) subsystem. The name derives from "Material Requirements Planning — Advanced ATP." Its role is to serve as the application-side wrapper layer for Advanced Available-to-Promise allocation processing, delegating the substantive algorithmic work to the public MSC_AATP family of packages and functions that constitute the core ASCP ATP engine.

The package is classified as PVT (private) in ETRM, indicating it is not a supported public API and is intended for internal consumption by Oracle's own ATP code paths, primarily forms and concurrent programs within the planning modules. The header comment ($Header: MRPAATPB.pls 115.28 2003/10/14) reflects that the file has remained substantially stable since the late 11i era, with only targeted modifications to accommodate ATP forward consumption changes.

A debug switch is exposed through the profile option MSC_ATP_DEBUG, which when set to 'Y' enables diagnostic tracing across the ATP routines invoked from this wrapper.

Key Procedures and Functions

The package exposes twelve documented routines, several of which are thin pass-through wrappers:

  • ATP_DEMAND_CLASS_CONSUME — Consumes ATP for a demand class, delegating to MSC_AATP_PVT equivalent logic.
  • ADD_TO_NEXT_STEAL_ATP — Accumulates ATP available for stealing into the next eligible bucket; documented as modified to route through MSC_AATP_PVT to align with post-forward-consumption semantics.
  • GET_ITEM_DEMAND_ALLOC_PERCENT — Returns the allocation percentage applicable to a specific item/demand combination, parameterised by plan, demand, assembly, source organization, inventory item, instance, origination type, record class, demand class and level.
  • GET_DC_ALLOC_PERCENT — Retrieves the allocation percentage for a given demand class against instance, inventory item, organization, department, resource, and request date.
  • GET_RES_DEMAND_ALLOC_PERCENT — The resource-oriented analogue returning demand allocation percentages.
  • ITEM_ALLOC_CUM_ATP — Computes cumulative ATP at the item level subject to allocation rules.
  • RES_ALLOC_CUM_ATP — Computes cumulative ATP at the resource level. This is the routine most directly associated with the search term "res_alloc_cum_atp" and is central to resource-constrained ATP promise calculations.
  • SUPPLIER_ALLOC_CUM_ATP — Cumulative ATP calculation constrained by supplier allocation.
  • GET_DC_INFO — Returns descriptive/structural information about a demand class.
  • VIEW_ALLOCATION — Presents current allocation state for inspection.
  • GET_HIERARCHY_DEMAND_CLASS — Resolves demand class hierarchy memberships.
  • GET_ALLOWED_STOLEN_PERCENT — Returns the percentage of ATP that may be "stolen" from other demand classes.

Tables Accessed

The ETRM extract does not enumerate directly referenced tables within this package body; the heavy lifting against ASCP planning tables (MSC_* family) is performed inside the MSC_AATP_PVT and MSC_AATP_FUNC objects invoked by these wrappers. Effectively, MRP_AATP_PVT inherits the data footprint of those routines — principally the ATP allocation, demand class, and plan data structures used by Advanced ATP. Table access via APPS synonyms is therefore indirect rather than declared locally.

Usage Notes

MRP_AATP_PVT is referenced by zero externally documented packages, confirming its private classification. It is invoked internally by Oracle ATP code paths — typically from the sales order scheduling and ATP inquiry forms, from the ATP concurrent processing flow, and from planning routines that require resource-level cumulative ATP with allocation percentages. Custom development should avoid calling this package directly; instead, use the supported MSC_AATP public interfaces or the standard ATP APIs, since signatures and behaviour in this PVT layer are subject to change without notice and the wrapper indirection (notably the l_current_atp local variable pattern) exists purely to insulate callers from ongoing internal refactoring.