Search Results bom_delete_sub_entities




Overview

The BOM_DELETE_SUB_ENTITIES table is a critical supporting object within the Bills of Material (BOM) module of Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2. It functions as a staging or tracking table that holds references to specific component and operation entities slated for deletion during a bill of material revision or deletion process. Its primary role is to ensure referential integrity and manage the complex cascade of deletions required when a parent bill entity is removed or altered. The table acts as a child to the BOM_DELETE_ENTITIES table, which tracks the main bill or routing being processed, thereby enabling a structured and auditable deletion workflow within the application's data model.

Key Information Stored

The table's structure is designed to store foreign key references to the detailed entities associated with a bill. While the full column list is not detailed in the provided metadata, the documented foreign key relationships reveal its core data. The DELETE_ENTITY_SEQUENCE_ID column is the primary key and serves as the link to the parent deletion process record in BOM_DELETE_ENTITIES. The two pivotal columns are COMPONENT_SEQUENCE_ID and OPERATION_SEQUENCE_ID. These columns store the unique identifiers (SEQUENCE_ID) for individual bill components (from BOM_COMPONENTS_B) and operation sequences (from BOM_OPERATION_SEQUENCES), respectively, that have been marked for deletion. A single record in this table will typically populate one of these two ID columns, identifying a specific sub-entity to be removed.

Common Use Cases and Queries

The primary use case is the execution of a bill or routing deletion via the standard Oracle EBS forms or APIs, such as the Bill and Routing APIs. When a user initiates a deletion, the application populates this table to define the scope of the operation before performing the actual database deletions, allowing for validation and error handling. Common queries against this table are typically part of diagnostic or support scripts. For instance, to identify all components pending deletion for a specific bill, one might join through BOM_DELETE_ENTITIES. A sample diagnostic query pattern is:

  • SELECT bdse.* FROM bom_delete_sub_entities bdse JOIN bom_delete_entities bde ON bdse.delete_entity_sequence_id = bde.delete_entity_sequence_id WHERE bde.bill_sequence_id = <BILL_SEQ_ID>;

This table is not intended for direct transactional reporting but is crucial for troubleshooting failed deletion jobs or understanding the data relationships during a delete operation.

Related Objects

The BOM_DELETE_SUB_ENTITIES table has defined dependencies on several core BOM tables, as per the provided relationship data:

  • BOM_DELETE_ENTITIES: The parent table. Joined via BOM_DELETE_SUB_ENTITIES.DELETE_ENTITY_SEQUENCE_ID → BOM_DELETE_ENTITIES.DELETE_ENTITY_SEQUENCE_ID. This relationship ties sub-entities to the master deletion transaction.
  • BOM_COMPONENTS_B: The core component table. Joined via BOM_DELETE_SUB_ENTITIES.COMPONENT_SEQUENCE_ID → BOM_COMPONENTS_B.COMPONENT_SEQUENCE_ID. This identifies the specific bill component to be deleted.
  • BOM_OPERATION_SEQUENCES: The core routing operations table. Joined via BOM_DELETE_SUB_ENTITIES.OPERATION_SEQUENCE_ID → BOM_OPERATION_SEQUENCES.OPERATION_SEQUENCE_ID. This identifies the specific routing operation to be deleted.

These relationships underscore the table's role as a junction point between a deletion transaction header and the detailed manufacturing entities it affects.