Search Results explosion_type




Overview
Explore in AI Chat

Overview

APPS.BOMDELEX is a PL/SQL package body in Oracle E-Business Suite that provides maintenance utilities for the BOM_EXPLOSIONS table, the central staging and results table used by Oracle Bills of Material explosion and implosion processing. The package addresses a specific housekeeping requirement: removing stale explosion rows that have been flagged for re-explosion. When a bill of material structure changes, EBS marks affected explosion records by setting the REXPLODE_FLAG column to 1, signalling that the cached exploded structure is no longer valid and must be regenerated. The BOMDELEX package supplies the deletion logic that purges those invalidated rows so that a subsequent explosion run can rebuild them cleanly.

The package header comment identifies the file as BOMDELEB.pls and describes its purpose as deleting records from BOM_EXPLOSIONS where the rexplode flag is set to 1. It is classified in the ETRM repository as an OTHER API rather than a formal public interface, which reflects its role as an internal utility invoked by concurrent processing logic rather than a supported integration point. The source carries a 2005 copyright and revision header, and the package remains present across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

  • DELETE_BOM_EXPLOSIONS — the principal procedure of the package. It accepts a top bill sequence identifier and an explosion type, validates that both arguments are non-null, and then iterates a cursor over BOM_EXPLOSIONS selecting rows whose TOP_BILL_SEQUENCE_ID and EXPLOSION_TYPE match the supplied values and whose REXPLODE_FLAG equals 1. Each qualifying row is deleted. The procedure declares standard concurrent-manager error handling variables and an INVALID_ARGUMENT_LIST exception, which is raised when either parameter is null. It also writes the supplied parameters to the concurrent manager log via FND_FILE.PUT_LINE for diagnostic traceability. The explosion_type parameter is the discriminator that scopes the deletion to a single explosion category, ensuring that rows belonging to other explosion runs are not affected.
  • GET_TOP_BILL — the companion function documented in the package metadata. Its role is to resolve and return the top bill identifier associated with a given bill structure, supplying the TOP_BILL_SEQUENCE_ID value that DELETE_BOM_EXPLOSIONS requires as its first argument. Together the two units form a resolve-then-purge pair.

Tables Accessed

The only documented table is BOM_EXPLOSIONS, accessed through an APPS synonym. BOM_EXPLOSIONS stores the exploded bill of material result set, including TOP_BILL_SEQUENCE_ID, BILL_SEQUENCE_ID, EXPLOSION_TYPE, SORT_ORDER and REXPLODE_FLAG. BOMDELEX reads this table through its cursor to identify rows flagged for regeneration and deletes those rows. No inserts or updates are performed by the documented logic; the package is purely a deletion utility against this single table.

Usage Notes

BOMDELEX is not referenced by any other documented package, so it is effectively a leaf utility invoked directly by concurrent programs or by the bill of material explosion processor when a re-explosion is required. Typical invocation occurs when a user or process requests that a bill structure be re-exploded, causing the existing flagged rows to be purged before the explosion engine regenerates them. Because DELETE_BOM_EXPLOSIONS follows the concurrent program interface convention — accepting ERRBUF and RETCODE as IN OUT NOCOPY parameters — it is suitable for registration as a concurrent executable.

Custom code should exercise caution when calling this package. Deletion is unconditional for rows matching the supplied top bill sequence identifier, explosion type and rexplode flag, and there is no dry-run mode. Developers integrating with BOM_EXPLOSIONS should confirm that the explosion type value passed aligns with the intended explosion category, since an incorrect value may either leave stale rows in place or, conversely, delete rows still required by an in-flight explosion run. Because the package is classified as OTHER rather than a public API, Oracle does not guarantee backward compatibility of its signature, and custom callers should validate behaviour after each upgrade.