Search Results bom_cto_order_demand_s1

Overview

APPS.CTO_ATP_INTERFACE_PK is the Configure-to-Order (CTO) availability-to-promise interface package in Oracle E-Business Suite. It bridges Oracle Advanced Supply Chain Planning (ASCP) and Global Order Promising (GOP) ATP processing with the CTO model and option structure defined in Oracle Bills of Material. During order entry and scheduling, Oracle Order Management must determine whether a configured model—an assemble-to-order parent plus its mandatory and optional components—can be promised on a given date. Standard ATP logic operates on discrete items and does not natively explode a model configuration into its bill of material. This package performs that translation: it constructs an ATP BOM representation of the configuration, registers it with the ATP engine, and generates the demand records that the planning and promising engines subsequently schedule.

The package status is VALID and it is owned by APPS. It is classified as an OTHER API rather than a public Open Interface, indicating it is intended primarily for internal consumption by EBS CTO/ATP flows. It is not referenced by any other database object, so its callers are application-tier code and workflow rather than dependent PL/SQL units.

Key Procedures and Functions

• CREATE_ATP_BOM — Builds the ATP-visible bill of material for a configured CTO model, translating the configuration into the component structure the ATP engine requires for lead-time and availability calculations.
• EXTEND_ATP_BOM — Extends or augments an existing ATP BOM definition, typically when additional optional items or change orders alter a previously created configuration.
• POPULATE_MANDATORY_COMPONENTS — Identifies and inserts the mandatory components associated with the model so that they are included in the ATP BOM without explicit user selection.
• GET_ATP_BOM — Retrieves the ATP BOM structure already created for a configuration, used by downstream ATP and callback processing.
• GET_MODEL_SOURCING_ORG — Determines the sourcing organization for the model, applying sourcing rules and assignment sets so the correct inventory organization is used for ATP checks.
• CREATE_CTO_MODEL_DEMAND — Creates the model-level demand record consumed by ATP and planning, establishing the top-level requirement for the configuration.
• CREATE_CTO_ITEM_DEMAND — Creates item-level demand records for the individual configured components, enabling ATP to schedule and promise each element.

Tables Accessed

The package reads Oracle Bills of Material structures through BOM_BILL_OF_MATERIALS and BOM_INVENTORY_COMPONENTS, and reads the ATP-facing demand entities BOM_CTO_ORDER_DEMAND and its sequence BOM_CTO_ORDER_DEMAND_S1. BOM_CALENDAR_DATES supplies manufacturing calendar information used in date calculations. Order context is obtained from OE_ORDER_LINES and OE_ORDER_LINES_ALL, with organization and item validation through MTL_PARAMETERS and MTL_SYSTEM_ITEMS, and defaulting behavior from OE_SYSTEM_PARAMETERS_ALL. Sourcing is resolved via MRP_SOURCES_V, MRP_ASSIGNMENT_SETS, and MRP_AP_APPS_INSTANCES. ATP requests and results pass through CZ_ATP_REQUESTS, MRP_ATP_DETAILS_TEMP, and the MRP_ATP_PUB/MRP_ATP_PVT/MSC_SATP_FUNC APIs. PLITBLM is the standard EBS PL/SQL index-by table type used for internal collections.

Usage Notes

CTO_ATP_INTERFACE_PK is invoked indirectly during order entry, order import, and scheduling when a configured item requires an ATP check. The ATP engine calls back into CTO logic through CZ_ATP_CALLBACK_UTIL and CTO_WORKFLOW, which in turn drive BOM creation and demand generation. Errors are reported using FND_MSG_PUB and FND_API conventions, and debug output may be produced through OE_DEBUG_PUB. Because the package is classified OTHER and is not referenced by other database objects, custom code should treat it as an internal implementation detail and prefer supported ATP or CTO public APIs where available. In 12.1.1 and 12.2.2 the behavior is consistent with GOP/ASCP scheduling, with the online ATP path and the planning collections path both relying on the same BOM_CTO_ORDER_DEMAND records created here.