Search Results populate_config

Overview

CTO_UPDATE_CONFIGS_PK is an Oracle EBS PL/SQL package owned by the APPS schema that supports the Configure-to-Order (CTO) model within Oracle Bills of Material and Oracle Order Management. Its principal business function is to maintain, populate, and refresh the configuration data associated with ATO (Assemble-to-Order) and CTO order lines. When a customer orders a configured item, the order line spawns a hierarchy of configuration records that must be kept synchronized with the parent sales order line, the WIP supply context, planning attributes, and the Bill of Material configuration structure. This package centralizes that synchronization logic. In the 12.1.1 and 12.2.2 releases it remains classified as a VALID, internally managed object (API classification OTHER), meaning it is not a published public API but is instead invoked by Oracle's own CTO processing forms, concurrent programs, and dependent packages. It references BOM_CTO_ORDER_LINES and FND_PROFILE among its declared dependencies, confirming its tight coupling to CTO order-line storage and profile-option-driven behavior.

Key Procedures and Functions

The package exposes fourteen documented procedures and functions, each addressing a discrete aspect of configuration maintenance:

• UPDATE_CONFIGS — the primary entry point that drives the configuration update cycle across affected order lines.
• POPULATE_ALL_MODELS — populates configuration data across all applicable models in scope.
• POPULATE_CAT_MODELS — restricts population logic to models within a specified category range.
• POPULATE_CONFIG — seeds the core configuration records for a given context.
• POPULATE_BCOLU_FROM_BAC — populates BOM_CTO_ORDER_LINES_UPG (BCOLU) records from BOM_ATO_CONFIGURATIONS source data.
• POPULATE_CHILD_CONFIG — establishes child configuration rows beneath a parent configuration.
• POPULATE_LINK_TO_LINE_ID — links configuration records back to their originating order line identifier.
• POPULATE_PLAN_LEVEL — derives and sets the planning level attribute for configuration records.
• POPULATE_WIP_SUPPLY_TYPE — assigns the WIP supply type needed for manufacturing execution.
• POPULATE_PARENT_ATO — identifies and populates the parent ATO item relationship.
• CONTIGUOUS_TO_SPARSE_BCOL — converts contiguous BOM_CTO_ORDER_LINES numbering into sparse numbering.
• WRITETOLOG — writes diagnostic output to the CTO debug log.
• WRITE_CONFIG_STATUS — records the current configuration status.
• UPDATE_ATP_ATTRIBUTES — refreshes Available-to-Promise attributes on configuration records.

Tables Accessed

The package reads and writes through APPS synonyms, touching the central CTO and order management tables. BOM_CTO_ORDER_LINES and its variants BOM_CTO_ORDER_LINES_S1 and BOM_CTO_ORDER_LINES_UPG store the CTO order-line configuration hierarchy and upgrade staging data. BOM_ATO_CONFIGURATIONS holds the master ATO configuration definitions. OE_ORDER_HEADERS_ALL and OE_ORDER_LINES_ALL provide the sales order header and line context. MTL_SYSTEM_ITEMS, MTL_SYSTEM_ITEMS_B, and MTL_SYSTEM_ITEMS_KFV supply item master attributes, while MTL_ITEM_CATEGORIES is used for category-based model selection (supporting POPULATE_CAT_MODELS). MRP_ASSIGNMENT_SETS, MRP_ASSIGNMENT_SETS_S, and MRP_SR_ASSIGNMENTS are consulted for planning-level and sourcing assignment logic. DUAL is used for scalar queries.

Usage Notes

Because this package is classified as OTHER rather than a published API, it should not be called directly from customer extensions without Oracle's guidance. It is typically invoked indirectly by CTO processing forms in Oracle Order Management, by concurrent programs that refresh or upgrade CTO configurations, and by other Oracle packages — the metadata notes it is referenced by exactly one other package. During configuration creation, model selection, or order-line changes, Oracle's CTO forms and workflows call UPDATE_CONFIGS and its POPULATE_* helpers to keep BOM_CTO_ORDER_LINES synchronized with the order and configuration masters. In 12.1.1 and 12.2.2 the object resides in the APPS schema and remains VALID. Custom code should treat it as subject to change between releases and rely instead on supported public APIs where available, reserving direct invocation for Oracle-directed diagnostics or patching scenarios.