Search Results bom_delete_status_type




Overview
Explore in AI Chat

Overview

APPS.BOM_DELETE_SUB_ENTITIES_V is a reporting and inquiry view in Oracle E-Business Suite that exposes the contents of the BOM_DELETE_SUB_ENTITIES table. The base table stores the individual sub-entities — component assignments, operation references, and related effectivity records — that are scheduled for removal when a bill of materials is processed through the BOM deletion programs. Rather than requiring callers to join the underlying table to the manufacturing lookup set, the view performs that decode internally and presents a human-readable delete status alongside the raw code value.

The view is owned by APPS and is defined in both Oracle EBS 12.1.1 and 12.2.2. It is a read-oriented object: the view is not intended to be inserted into or updated directly, since it derives its DELETE_STATUS column from a lookup meaning and its ROW_ID column from the underlying table's ROWID pseudo-column.

Underlying Base Objects

The view is defined as a join between two documented base objects:

  • BOM_DELETE_SUB_ENTITIES (SYNONYM) — the primary object, aliased as BDSE. It supplies every column except the decoded delete status. The synonym resolves to the base deletion sub-entity table in the BOM schema.
  • MFG_LOOKUPS (VIEW) — aliased as ML. It provides the lookup meaning that decodes the delete status code. The join is constrained with ML.LOOKUP_TYPE = 'BOM_DELETE_STATUS_TYPE'.

The join predicate is written as BDSE.DELETE_STATUS_TYPE (+) = ML.LOOKUP_CODE, an outer join on the BOM_DELETE_SUB_ENTITIES side. This means rows in the deletion sub-entity table whose DELETE_STATUS_TYPE does not resolve to a value in the BOM_DELETE_STATUS_TYPE lookup set are still returned, with a null DELETE_STATUS. Because MFG_LOOKUPS is itself a view over the FND_LOOKUP_VALUES family of tables, the effective lineage of BOM_DELETE_SUB_ENTITIES_V reaches into the application lookup infrastructure.

Key Columns

Common Use Cases and Queries

The view is typically queried to audit or troubleshoot BOM deletion activity, to confirm which components were removed, and to reconcile deletion requests against their concurrent program identifiers. A representative query follows:

SELECT delete_entity_sequence_id,
       component_sequence_id,
       item_num,
       delete_status,
       delete_date,
       request_id
FROM   apps.bom_delete_sub_entities_v
WHERE  delete_status = 'Deleted'
ORDER  BY delete_date DESC;

Because DELETE_STATUS_TYPE is decoded, analysts can group and count deletions by status without a separate lookup join:

SELECT delete_status, COUNT(*)
FROM   apps.bom_delete_sub_entities_v
GROUP  BY delete_status;

Reports reconciling deletion batches by concurrent request use the REQUEST_ID and PROGRAM_ID columns, while component-level investigations join COMPONENT_ITEM_ID or ITEM_NUM back to the item master. In all cases the view should be treated as read-only, populated by the BOM deletion concurrent processes rather than by direct DML.