Search Results inv_already_exists

Overview

ENG_ECO_PRIOR_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite (12.1.1 and 12.2.2). Its business function is to support validation logic for engineering change order (ECO) priority codes used by Oracle Engineering. Priority codes are user-defined classifications that rank or sequence engineering changes, and the package enforces the two integrity rules that govern these codes: uniqueness within an organization and prevention of deletion while a priority code is still referenced by an engineering change.

The header revision visible in the source ($Header: engpecpb.pls 115.2 2003/02/07) indicates this is a long-standing, stable component of the Oracle Engineering module. Its only documented procedure set is a pair of validation routines that raise standard Oracle Forms error messages via FND_MESSAGE and APP_EXCEPTION, making the package suitable for direct invocation from the Oracle Forms-based Engineering Change Order window. The API classification in the ETRM metadata is OTHER, reflecting that this is a supporting validation package rather than a public, fully documented business API.

Key Procedures and Functions

Two procedures are documented. Their parameters are not described here, and no additional interfaces should be assumed.

• CHECK_UNIQUE — Verifies that a given engineering change priority code does not already exist for the specified organization. Internally it queries ENG_CHANGE_PRIORITIES using a NOT EXISTS pattern; if a matching row is found, the select raises NO_DATA_FOUND, and the exception handler calls FND_MESSAGE.SET_NAME('INV', 'INV_ALREADY_EXISTS'), sets the offending code as the message token, and raises the exception through APP_EXCEPTION.RAISE_EXCEPTION. This ensures that priority codes remain unique per organization.
• CHECK_REFERENCES — Validates that a priority code is not currently assigned to any engineering change before allowing deletion. It queries ENG_ENGINEERING_CHANGES with the same NOT EXISTS pattern, filtered by organization and priority code. When referenced rows are found, it raises NO_DATA_FOUND and the handler sets FND_MESSAGE.SET_NAME('ENG', 'ENG_CANNOT_DELETE_USED'), sets the ENTITY token to 'PRIORITY', and raises via APP_EXCEPTION.RAISE_EXCEPTION. This enforces referential integrity at the application level, protecting records that active engineering changes depend upon.

Tables Accessed

• ENG_CHANGE_PRIORITIES — Read by CHECK_UNIQUE to confirm whether a priority code already exists for an organization. Identified by ENG_CHANGE_PRIORITY_CODE and ORGANIZATION_ID.
• ENG_ENGINEERING_CHANGES — Read by CHECK_REFERENCES to detect engineering changes assigned to the priority code via ORGANIZATION_ID and PRIORITY_CODE.
• DUAL — Used as the driving table for the NOT EXISTS constructs, allowing the existence check to be expressed as a single-row query that raises NO_DATA_FOUND as a control-flow signal.

These tables are referenced through APPS synonyms, consistent with the package residing in the APPS schema. No inserts, updates, or deletes are performed by the documented procedures; the package is read-only with respect to the data model, and it relies on the database or the calling form to perform actual DML.

Usage Notes

ENG_ECO_PRIOR_PKG is typically invoked from Oracle Engineering's setup and maintenance forms when a user creates, updates, or deletes an ECO priority code. Before a new code is committed, the form calls CHECK_UNIQUE to prevent duplicates within the organization; before a deletion is accepted, it calls CHECK_REFERENCES to block removal of codes still in use. The ETRM metadata indicates that the package is referenced by zero other packages, meaning it is a leaf-level validation utility rather than a dependency of broader APIs.

Because the procedures are not part of a formally versioned public API, custom code should generally avoid depending on them for new integrations; instead, equivalent validation can be applied in custom concurrent programs or interfaces. Where reuse is required, callers must honor the package's exception convention — errors are communicated as raised APP_EXCEPTION exceptions carrying FND message names and tokens, not as return codes — so calling code must include a handler that recognizes these messages. The behavior is consistent across 12.1.1 and 12.2.2, since the package operates solely on Oracle Engineering base tables and standard FND messaging utilities that are unchanged between releases.