Search Results delete_object_filter

Overview

APPS.IEX_FILTER_PUB is a public PL/SQL API package within the Oracle E-Business Suite Collections (Advanced Collections / IEX) module. Its primary business function is to manage and evaluate object filters — user-defined criteria that determine which business objects (such as customers, delinquencies, or collection strategies) are included in a given scoring, scoring-engine, or collections processing run. Object filters allow application users to restrict the universe of records processed by a scoring model or strategy by defining Boolean or SQL-based selection criteria.

The package is classified as a public (PUB) API, meaning it exposes a stable, supported interface intended for invocation by other application modules, concurrent programs, and custom extensions rather than being strictly internal. It depends on the standard Oracle EBS API framework package FND_API, which supplies the standard API return-status conventions (success, error, unexpected error) and message-handling facilities. In ETRM 12.2.2 the package status is VALID and it is documented with six procedures/functions.

Key Procedures and Functions

The documented API surface consists of six entry points:

• BUILDUNIVERSE — Constructs the working "universe" of records that satisfy the active filter definition. This is the core runtime operation that establishes the population against which scoring or collections logic will operate.
• BUILDSQL — Generates the SQL statement (or SQL fragment) that implements a filter's selection criteria. This routine translates filter metadata into executable SQL, enabling the universe build to be driven dynamically.
• VALIDATE_FILTER — Validates a filter definition, confirming that the specified criteria are syntactically and structurally valid before the filter is persisted or executed.
• CREATE_OBJECT_FILTER — Creates a new object filter record, persisting the filter definition into the repository tables.
• UPDATE_OBJECT_FILTER — Modifies an existing object filter definition, allowing criteria to be revised after creation.
• DELETE_OBJECT_FILTER — Removes an object filter definition from the repository.

Together these procedures provide a complete lifecycle for filter maintenance (create, update, delete, validate) plus the execution-time functions (BUILDSQL, BUILDUNIVERSE) required to apply filters during processing.

Tables Accessed

The package accesses the following objects via APPS synonyms, as documented in the ETRM metadata:

• IEX_OBJECT_FILTERS — the primary transactional table storing object filter definitions. The create, update, delete, and validation routines read and write this table.
• IEX_OBJECT_FILTERS_S — the corresponding sequence (or secondary/translation) object associated with the filter definitions, supporting key generation and related persistence.
• DUAL — the standard Oracle single-row utility table, used for lightweight evaluations and SQL expression construction.
• PLITBLM — the PL/SQL intermediate table (index-by table) type/utility used to pass and manipulate collections of filter criteria within the package.

Usage Notes

IEX_FILTER_PUB is referenced by four other packages, notably IEX_SCOREAPI_PUB, IEX_SCORE_NEW_PVT, and IEX_SCORE_PVT, which indicates that filter management is tightly coupled to the Collections scoring engine. When a scoring model or collections strategy is executed, the scoring packages call into IEX_FILTER_PUB to build the applicable universe and generate the filtering SQL. The wrapper objects IEX_FILTER_PUB_W appear in the dependency chain, indicating that a public wrapper layer provides the callable interface for forms or external callers.

Typical invocation scenarios include the Collections setup and scoring configuration forms (where administrators define and maintain object filters), concurrent scoring programs that apply filters at runtime, and custom code that requires programmatic manipulation of filter definitions using the standard FND_API error-handling conventions. Because the package is a published API, custom integrations should call it rather than writing directly to IEX_OBJECT_FILTERS to preserve data integrity and upgrade compatibility.