Search Results iex_case_definitions_pvt




Overview
Explore in AI Chat

Overview

IEX_CASE_DEFINITIONS_PVT is a private PL/SQL package in the APPS schema that belongs to the Oracle E-Business Suite Collections (IEX/Advanced Collections) module. It encapsulates the core persistence logic for case definitions, the configurable templates that determine how collections cases are created, categorized, and tracked. Case definitions hold the attributes that drive the case management workflow, including status assignments, category mappings, and default ownership rules.

As an API classification of PVT (private), this package is not intended for direct invocation by external or customer code. It exposes its functionality to the public-facing layer through a controlled interface; Oracle's convention is that callers use the corresponding public package, while the private package performs the actual DML and validation. In the dependency chain shown in the ETRM metadata, IEX_CASE_DEFINITIONS_PVT relies on FND_API, the standard Oracle Application Object Library API utility package used for consistent error handling, message stacking, and the standard fnd_api.g_ret_sts_success/error return conventions. This dependency confirms that the package follows the Oracle PL/SQL API standard rather than implementing ad hoc error handling.

Key Procedures and Functions

The documented interface consists of three procedures:

  • CREATE_CASE_DEFINITIONS — Inserts a new case definition record. This routine accepts the definition attributes and persists them to the base table, establishing the template from which future collections cases are instantiated.
  • UPDATE_CASE_DEFINITIONS — Modifies an existing case definition. It applies changes to the current definition record and maintains the associated audit or history rows so that prior configurations remain traceable.
  • DELETE_CASE_DEFINITIONS — Removes a case definition. Deletion logic ordinarily performs the corresponding cleanup on dependent history and translated rows to keep the entity intact.

All three follow the same structural pattern: validate input, execute DML, propagate errors through FND_API, and return a standard status indicator. No parameter lists are documented in the ETRM metadata and none are asserted here.

Tables Accessed

The package operates against three objects resolved through APPS synonyms:

  • IEX_CASE_DEFINITIONS — The primary transactional table storing the case definition records themselves. It is the target of the create, update, and delete operations.
  • IEX_CASE_DEFINITIONS_S — The corresponding MLS/translation table holding the language-specific descriptive text for each definition. Maintaining both tables together ensures the definition remains consistent across installed languages.
  • DUAL — Used for single-row evaluations, typically sequence retrieval (definition ID generation) or validation of scalar expressions within the API logic.

Usage Notes

Because the package is private, direct calls from custom extensions are not supported and are likely to break on patching. The supported path is through the public wrapper layer: the ETRM metadata shows IEX_CASE_DEFINITIONS_PVT is referenced by IEX_API_RECORDS_PVT and IEX_CASE_UTL_PUB, and is also self-referencing. The presence of IEX_API_RECORDS_PVT in the referencing list is significant for the user who searched for "iex_api_records_pvt": that package is a consumer of this one, meaning case-definition maintenance triggered through the records API ultimately funnels into these three procedures. IEX_CASE_UTL_PUB is the utility public package that serves as the intended entry point for case-definition maintenance, and it in turn delegates to this private implementation.

In practice, invocations originate from the Advanced Collections setup and administration forms, from concurrent programs that seed or migrate case-definition configuration, and from internal APIs such as IEX_API_RECORDS_PVT. In Oracle EBS 12.1.1 and 12.2.2 the object is documented as VALID, so it is present and compiled in the APPS schema in both releases. Customization should be limited to reading the underlying tables; all writes should be routed through the public API to preserve validation, audit history, and translation integrity.