Search Results check_delete_lifecycle_ok

Overview

EGO_LIFECYCLE_ADMIN_PUB is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite. It provides the administrative interface through which the Product Information Management (PIM) / Item Lifecycle Management infrastructure validates and executes the deletion of lifecycle definitions, lifecycle phases, and phase codes. The package is declared with AUTHID CURRENT_USER, meaning its SQL executes under the privileges of the calling schema rather than the definer, and it follows the standard EBS PL/SQL API convention of exposing an p_api_version parameter, an p_init_msg_list flag defaulting to fnd_api.g_FALSE, and the standard x_return_status, x_errorcode, x_msg_count, and x_msg_data output parameters for error handling through FND_MSG_PUB.

Its central purpose is defensive administration: before any destructive operation against a lifecycle or phase, the package determines whether the object is referenced by items or revisions, and reports back a simple delete-OK indicator. This prevents orphaned lifecycle assignments in the item master and preserves referential integrity between the lifecycle configuration tables and the item records that consume them.

Key Procedures and Functions

• Check_Delete_Lifecycle_OK — Given a lifecycle identifier, determines whether the specified lifecycle may be safely deleted and returns the result in x_delete_ok. It is the reference-checking counterpart to the phase-level check.
• Check_Delete_Phase_OK — Given a phase identifier, determines whether the referenced lifecycle phase can be removed. This is the procedure most commonly targeted by the search term check_delete_phase_ok; it is a read-only validation call that returns a Y/N style indicator plus API status, error code, and message data. Callers invoke it prior to attempting Process_Phase_Delete so that user-facing forms can block deletion with a meaningful message instead of raising a database error.
• Process_Phase_Delete — Performs the actual deletion of a single phase, identified by p_phase_id, with an optional p_commit flag controlling transactional commit behavior.
• Process_Phase_Code_Delete — Deletes a phase by its phase code rather than its internal identifier, providing a code-driven variant of the phase deletion operation and again exposing the p_commit flag.
• Delete_Stale_Data_For_Lc — Cleans up residual or orphaned configuration data associated with a lifecycle, typically invoked after the primary lifecycle or phase objects have been removed so that dependent status and policy rows do not remain stranded.

Tables Accessed

• PA_PROJ_ELEMENTS — The source of the phase and lifecycle identifiers. Notably, p_lifecycle_id and p_phase_id are both typed as PA_PROJ_ELEMENTS.PROJ_ELEMENT_ID%TYPE, confirming that lifecycle phases are modeled as project elements.
• EGO_LCPHASE_ITEM_STATUS, EGO_LCPHASE_POLICY, and EGO_OBJ_TYPE_LIFECYCLES — The EGO lifecycle configuration tables that define phase policy, assign item statuses to phases, and link object types to lifecycles. These are the primary dependency sources consulted by the check procedures and cleaned by the stale-data routine.
• MTL_SYSTEM_ITEMS_B, MTL_ITEM_REVISIONS_B, and MTL_PENDING_ITEM_STATUS — Item master, revision, and pending status tables used to detect whether items or revisions are currently associated with the lifecycle or phase. Any match effectively blocks deletion.
• DUAL — Used for trivial single-row selection and API bookkeeping.

Usage Notes

This package is normally invoked indirectly. The Lifecycle Management setup forms and related concurrent programs in the PIM module call Check_Delete_Phase_OK and Check_Delete_Lifecycle_OK to validate a delete request before presenting confirmation or performing the deletion through the corresponding Process_* procedures. Custom integrations should follow the same pattern: call the check procedure first, inspect x_delete_ok and x_return_status, and only proceed when the check returns success. Because the package is classified as PUB and AUTHID CURRENT_USER, it is supported for direct call from custom code, and callers must supply a valid API version and be prepared to read FND message stack entries when x_msg_count exceeds zero. The package is referenced by one other package in the ETRM metadata, indicating limited internal reuse.