Search Results create_bom_data_ml




Overview

CTO_CONFIG_BOM_PK is a CTO (Configure-to-Order) bill of materials loader package delivered with Oracle Manufacturing and used by Oracle Order Management and Configurator to build and maintain the BOM structures that represent a configured item. It is the 11i/12.x successor to the older BOMLDCBB.pls loader, re-architected for the "CTO streamline" logic introduced for the newer order entry model. The package's stated purpose is to load the BOM tables for a configuration item: given an order line containing a configured model, it explodes model, option class, and option data, resolves the matching components, and inserts the corresponding bill, component, reference designator, substitute, and dependent elements records into the interface and base BOM tables.

The body is registered in ETRM under owner APPS with an API classification of OTHER, meaning Oracle does not publish it as a supported public API. Its header identifies the source file as CTOCBOMB.pls and records a long bug-fix history, including fixes for duplicate option-class component selection, date operations that unintentionally re-enabled disabled items or inflated component usage, correct updating of MTL_SYSTEM_ITEMS_TL descriptions, and the addition of preconfigured-BOM handling in 2001.

Key Procedures and Functions

  • CREATE_BOM_ML — performs the main BOM loading work for the configured item in a multi-lingual (ML) context, driving insertion into the bill and component interface tables.
  • CREATE_BOM_DATA_ML — the data-layer companion to CREATE_BOM_ML; it materializes the BOM data rows (bill and inventory component records) required for a configuration before/alongside the ML-dependent descriptive columns are populated. This is the object most commonly referenced when searching for BOM data creation for configuration items.
  • GET_DIT_COUNT — returns a count related to DIT (dependent/derived item or date-in-treatment) entries associated with the configuration, used to decide whether BOM data must be (re)created.
  • GET_DROPPED_COMPONENTS — retrieves components that were removed from a configuration, so that related BOM rows can be reconciled.
  • RESET_DROPPED_COMPONENTS — clears or resets the dropped-component state, typically in preparation for regenerating the bill after an option change.
  • GET_MODEL_LEAD_TIME — computes the lead time for the model, used in scheduling and supply-chain date calculations for the configured assembly.
  • INHERIT_OP_SEQ_ML — inherits operation sequence information (ML) into the configuration; the change history notes an added "Implementation_date is not null" condition to guard this logic.
  • BMLUPID_UPDATE_ITEM_DESC — updates item descriptions through the ML structure, addressing defects where MTL_SYSTEM_ITEMS_TL was not being updated with the correct description.
  • CHECK_BOM — validates the resulting or existing bill structure for the configuration.

Tables Accessed

The package reads order context from OE_ORDER_LINES and BOM_CTO_ORDER_LINES, and writes BOM structures through BOM_BILL_OF_MTLS_INTERFACE and BOM_INVENTORY_COMPS_INTERFACE (with BOM_INVENTORY_COMPONENTS_S for the base component records). Supporting reads include BOM_ALTERNATE_DESIGNATORS and BOM_REFERENCE_DESIGNATORS for designators, BOM_SUBSTITUTE_COMPONENTS for substitutes, BOM_DEPENDENT_DESC_ELEMENTS for option-dependent descriptions, BOM_EXPLOSION_TEMP for the exploded model structure, and BOM_CALENDAR_DATES for date/lead-time logic. FND_ID_FLEX_STRUCTURES is read for the item key flexfield definition, and FND_PROFILE_OPTIONS / FND_PROFILE_OPTION_VALUES / FND_USER supply profile and audit information.

Usage Notes

CTO_CONFIG_BOM_PK is invoked internally rather than directly by end users. It is referenced by seven other packages, and Oracle documentation positions it behind the standard Order Management configuration flow — the AutoCreate/Configurator path that materializes a bill for a configured model when an order line is booked or a configuration is completed. It is also used where preconfigured BOMs are created ahead of order entry. Because it is registered as an OTHER-classified API under APPS and is not a published interface, custom code should not call CREATE_BOM_ML or CREATE_BOM_DATA_ML directly; the supported route for extending configuration logic is through the documented CTO/Configurator public APIs. Diagnostic output during execution is routed through OE_DEBUG_PUB rather than FND_FILE, so tracing must be enabled at the debug level appropriate to Order Management.