Search Results get_comp_requirements

Overview

MSC_ATP_REQ is an Oracle Advanced Supply Chain Planning / Advanced Planning Foundation package body owned by APPS. It implements the requirement-side processing logic used by the Available-to-Promise (ATP) engine to evaluate component and resource availability across a planning horizon. The package is concerned with the requirements that ATP must satisfy: material requirements derived from bills of material and CTO configurations, resource requirements drawn from routings, supplier ATP, and transport capacity ATP. Its functions resolve demand against supply, apply the infinite time fence, and populate the standard ATP output tables so downstream planning consumers can present feasible promise dates and quantities.

The header comment embedded in the source identifies the division of labour within the package: the resource-oriented functions perform the full ATP consume operation, add the infinite time fence, and populate every output table; the material-oriented functions only execute the underlying SQL, leaving the consume operation, the infinite time fence logic, and the population of the three output tables to the calling layer. This distinction is important when diagnosing why certain outputs appear populated after a resource ATP call but are completed elsewhere during material ATP processing.

Key Procedures and Functions

• GET_COMP_REQUIREMENTS — the component requirements routine the user searched for. It is the entry point through which ATP obtains the dependent demand for BOM and CTO components that must be satisfied to promise an assemble-to-order or configured item.
• GET_MATERIAL_ATP_INFO — retrieves material-level ATP information used as the supply baseline for requirement netting.
• GET_RES_REQUIREMENTS — computes resource requirements; in line with the header comment it performs atp_consume and applies the infinite time fence and output population.
• GET_SUPPLIER_ATP_INFO — obtains supplier-sourced ATP supply so that externally procured availability can participate in the promise calculation.
• GET_TRANSPORT_CAP_ATP_INFO — returns transport capacity ATP data, reflecting shipping and carriage constraints on the promise.
• CHECK_SUBSTITUTES — validates whether substitutable components may be used when the primary component cannot satisfy the requirement.
• EXTEND_ATP_COMP_TYP — extends the component-type classification used during ATP processing.
• ADD_TO_COMP_LIST — appends entries to the internal component list assembled during requirements explosion.
• INSERT_DETAILS — inserts the computed ATP detail rows into the temporary detail tables consumed by the reporting and display layer.

Supporting internal routines include Print_Dates_Qtys, a debug helper that writes ATP date and quantity arrays to the MSC_SCH_WB debug channel when the profile MSC_ATP_DEBUG is set to Y or C, and INTEGER_SCALING, which rounds scaled quantities using a scaling multiple, a rounding variance percentage, and a rounding direction.

Tables Accessed

• MRP_ATP_DETAILS_TEMP — staging of computed ATP detail rows produced by INSERT_DETAILS.
• MSC_ATP_RULES — ATP rule definitions governing which supply sources and fences apply.
• MSC_ATP_SD_DETAILS_TEMP — scheduling detail staging for ATP results.
• MSC_ATP_SUMMARY_RES, MSC_ATP_SUMMARY_SD, MSC_ATP_SUMMARY_SO, MSC_ATP_SUMMARY_SUP — summary output tables for resource, scheduling, sales order, and supplier ATP respectively.
• MSC_BOMS, MSC_BOM_COMPONENTS, MSC_BOM_TEMP, MSC_CTO_BOM — bill of material and configuration structures exploded to derive component requirements.
• MSC_BOR_REQUIREMENTS — bill of resource requirements supplying resource demand.
• MSC_COMPONENT_SUBSTITUTES — substitute component definitions evaluated by CHECK_SUBSTITUTES.
• MSC_CALENDAR_DATES — manufacturing and shipping calendars used to place dates within working time.
• MSC_DEMANDS — the demand stream against which ATP availability is consumed.

Usage Notes

MSC_ATP_REQ is not a user-facing API; it is invoked internally by the ATP processing framework, and the ETRM metadata records six other packages that reference it. In 12.1.1 and 12.2.2 it is reached through the planning and order-promising flows rather than called directly from a form. Custom code should call the supported public API layer (MRP_ATP_PUB) rather than this package body, since the parameter lists and internal staging behaviour are not a committed interface. The debug profile MSC_ATP_DEBUG=N by default; setting it to Y or C enables the diagnostic output emitted by the internal debug routines and is the standard first step when investigating unexpected component requirement results.