Search Results expected_purchase_flag




Overview
Explore in AI Chat

Overview

APPS.BIS_INTEREST_TYPES_V is a lightweight, read-only database view in the Oracle E-Business Suite (EBS) environment, deployed across both 12.1.1 and 12.2.2 release families. It presents a filtered list of interest type definitions intended specifically for selection in purchasing contexts. Rather than exposing the full catalog of interest types maintained within the application, the view restricts its output to records that satisfy two business conditions: the interest type must be flagged as applicable to expected purchases, and it must be enabled at the master level.

The view serves as a consumer-facing interface for LOV (List of Values) population, concurrent program parameter queries, and reporting logic that needs a curated list of valid interest types. Because it is defined over another view rather than base tables, it inherits the filtering applied upstream and adds its own qualification criteria. This layering keeps presentation logic separate from the underlying transactional model, a pattern consistent throughout the Oracle EBS schema.

Underlying Base Objects

The view is defined over a single referenced object, AS_INTEREST_TYPES_V, which itself is a view residing in the application schema. No base tables are documented as direct dependencies; all column references resolve through this intermediate view. The structure of BIS_INTEREST_TYPES_V is therefore entirely dependent on the column set and semantics exposed by AS_INTEREST_TYPES_V, which supplies the interest type identifier, its descriptive value or name, and the two governing control flags: EXPECTED_PURCHASE_FLAG and MASTER_ENABLED_FLAG.

The dependency chain is straightforward and adds no joins or aggregations. There is no union, no outer join, and no grouping — the view is a pure selection with projection and aliasing. This means query performance is governed almost entirely by the performance of the underlying view and the indexes on its contributing tables. Any change to AS_INTEREST_TYPES_V column names or definitions would directly break BIS_INTEREST_TYPES_V.

Key Columns

The view exposes four columns, three of which carry the interest_type_id and interest_type values in slightly different formats. The columns are:

  • ID — a VARCHAR2 representation of interest_type_id, produced by the TO_CHAR conversion in the defining query. This column is suitable for concatenation and display, and is typically used where a character-typed identifier is required.
  • VALUE — the descriptive interest type name from the underlying view, presented as the human-readable label.
  • INTEREST_TYPE_ID — the native numeric interest type identifier, retaining its original data type. This is the key column most application queries join against, and it is the value matched when users search for "interest_type_id".
  • INTEREST_TYPE — a duplicate of the descriptive name, included to support LOV frameworks that expect both an ID and a VALUE column plus a redundant descriptive attribute.

The duplication of the interest type name in both VALUE and INTEREST_TYPE is deliberate and accommodates different consumer conventions within Oracle EBS forms and concurrent managers.

Common Use Cases and Queries

The view is most commonly queried to populate selection lists and to resolve an identifier into a readable label. A typical retrieval projects the ID and VALUE columns ordered for display. Queries that need to join an interest type identifier to transactional data will use INTEREST_TYPE_ID directly, while those building concatenated strings will use the ID column.

Sample queries include selecting all enabled expected-purchase interest types, filtering by a specific interest_type_id to validate its existence in the enabled set, and joining the view to purchase requisition or purchasing document lines where the interest type is recorded. Because the filtering conditions are embedded in the view, callers do not need to reapply the expected purchase or master enabled predicates; any row returned is already qualified. Consumers should note that the view returns no rows for interest types that are disabled or not intended for expected purchases, and that the ID column is a string conversion rather than a numeric value, which affects ordering and comparison behavior in downstream SQL.