Results for “lifecycle_tracking”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPS.ENG_LIFECYCLE_USER_PUB is a public PL/SQL package belonging to the Oracle Engineering (ENG) application module. Its purpose is to expose validation services that determine whether engineering-related entities — specifically projects and tasks — may be safely deleted without violating existing Engineering Change Order (ECO) associations. This package sits in the Engineering Lifecycle family of APIs that support the Engineering Change Management (ECM) business flow. The package is classified as PUBLIC in the ETRM registry, meaning Oracle supports its direct invocation from customer-written code, and it is referenced by one other package within the E-Business Suite.

The package declares several package-level constants that illustrate its design. It maintains a package name constant (g_pkg_name), captures session context through FND_GLOBAL.User_Id and FND_GLOBAL.Login_Id, and defines custom exceptions for validation and sequencing errors. It also declares application constants for the engineering item-project association type, lifecycle tracking codes, and the PROMOTE and DEMOTE lifecycle actions, which indicate the broader engineering lifecycle context this package operates within. A header comment indicates the source was created in early 2003 and marked noship, consistent with a patch-level build.

Key Procedures and Functions

ETRM documents two public procedures in this package:

• CHECK_DELETE_PROJECT_OK — Validates whether a given project may be deleted. The procedure accepts an API version, a project identifier drawn from PA_PROJECTS.PROJECT_ID, an initialization flag (p_init_msg_list), and returns an output flag (x_delete_ok) together with the standard FND_API return status, error code, message count, and message data. The body begins with the standard FND_API.Compatible_API_Call version check, raising FND_API.G_EXC_UNEXPECTED_ERROR if incompatible, then initializes the message list when requested.
• CHECK_DELETE_TASK_OK — The parallel validation procedure for tasks, applying the same API conventions to PA_TASKS.

The user search term "check_delete_project_ok" maps directly to the first procedure described above. Both procedures follow the standard Oracle public API pattern: compatibility validation, message list initialization, business rule evaluation, and structured return status.

Tables Accessed

The package references four objects through APPS synonyms:

• ENG_ENGINEERING_CHANGES — The primary validation target. The cursor check_project_used tests for the existence of any engineering change whose PROJECT_ID matches the project being evaluated. If such a row exists, the project is in use and cannot be deleted.
• PA_PROJECTS — Supplies the authoritative project identifier used as the input parameter for the project-level check.
• PA_TASKS — Supplies the task identifier for the task-level deletion check.
• DUAL — Used in the existence-based cursor to return the single-character flag. The cursor is written as SELECT 'y' FROM dual WHERE EXISTS (...), so the presence or absence of the result row drives the decision.

The read pattern is strictly validation-oriented: the package does not modify data, it interrogates existing lifecycle associations to determine whether a deletion is permissible.

Usage Notes

Because this package is classified as PUBLIC, it may be called from custom forms, concurrent programs, or integration code that must verify deletion eligibility before removing engineering-linked projects or tasks. Typical invocation would occur before a delete or cleanup operation, with the caller inspecting x_delete_ok and the FND_API return status to decide whether to proceed. Developers integrating with this API should honor the standard FND message-list contract by calling FND_MSG_PUB.Count_And_Get or the appropriate message retrieval routine when x_return_status is not FND_API.G_RET_STS_SUCCESS. The API version constant is 1.0; callers passing an incompatible version will receive an unexpected-error condition rather than a graceful business message. Since the package queries engineering change data, callers in a multi-org or multi-project context should ensure the correct operating unit and security profile are set before invocation.

Given the package's narrow scope — a read-only validity check backed by an existence cursor — it is best understood as a guard routine rather than a full lifecycle engine. Its PROMOTE, DEMOTE, and lifecycle-tracking constants suggest it was designed to sit alongside more extensive lifecycle APIs that handle the state transitions themselves.