Search Results data_range_hi

Overview

XDP_PARAMETER_POOL_VL is an APPS-owned view in the Oracle E-Business Suite XDP (Provisioning) product module. It exposes the set of parameter pool values that drive service provisioning and order fulfillment configuration, presenting each pool entry as a readable lookup record with an associated display name, meaning, and date-range validity. The "_VL" suffix indicates a value-level (translated/validity-filtered) view, meaning it is intended to return only descriptive, user-facing attributes rather than the full transactional payload of the underlying entity.

Functionally, the view flattens the lookup-driven configuration of extend attribute pools — the containers that group flexible attributes used during provisioning — into a single queryable row per parameter. Because it preselects a specific lookup type and projects the standard FND lookup semantics (meaning, enabled flag, active dates), the view supports reporting, validation, and integration without requiring consumers to embed the pool lookup type filter themselves. The ETRM description notes this view was modified to go against FND_LOOKUPS as of release 11.5.6, reflecting the migration of lookup data off legacy seeded tables in favor of the central FND lookup repository.

Underlying Base Objects

Per the documented ETRM metadata for release 12.2.2, the view is defined over a single referenced base object: CSI_LOOKUPS, itself a view. The documented view text selects from CSI_LOOKUPS with the filter constraint LOOKUP_TYPE = 'CSI_EXTEND_ATTRIB_POOL'. This restricts output to the extend attribute pool lookup set, so all rows returned by XDP_PARAMETER_POOL_VL represent parameter pool entries rather than the broader universe of CSI lookups.

The ETRM text maps the visible columns back to the base lookup columns: ROW_ID is sourced from LKP.ROWID, PARAMETER_NAME from LOOKUP_CODE, PROTECTED_FLAG from ENABLED_FLAG, and DISPLAY_NAME from MEANING. Several positional columns in the select list are hardcoded to NULL because the lookup source does not populate them. Because the relationship is one-to-one with the filtered CSI_LOOKUPS rows, no joins or aggregations are involved, and row counts are bounded by the number of entries of type CSI_EXTEND_ATTRIB_POOL.

Key Columns

• ROW_ID — Row identifier from the underlying lookup source; useful for pseudo-keys and row-based navigation.
• PARAMETER_ID — Identifier for the parameter pool entry, exposed as a NULL placeholder in the documented select list.
• PARAMETER_NAME — The lookup code of the pool entry; this is the primary technical name used to identify a parameter.
• PROTECTED_FLAG — Derived from the lookup ENABLED_FLAG, indicating whether the entry is protected/active for use.
• DISPLAY_NAME — The lookup MEANING, providing the user-facing label for the parameter.
• DESCRIPTION — The lookup DESCRIPTION, where maintained.
• START_DATE_ACTIVE / END_DATE_ACTIVE — Effective date bounds controlling when the entry is valid for selection.
• DATA_TYPE, DATA_LENGTH, DATA_FORMAT_MASK, DATA_RANGE_LOW, DATA_RANGE_HI — Data-shaping attributes for the parameter; NULL in the documented select list where not sourced from the lookup.
• CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, LAST_UPDATE_LOGIN — Standard audit columns.

Common Use Cases and Queries

The most frequent use is validating and listing the available extend attribute pools during provisioning setup or before inserting configuration data. Because the view already filters to CSI_EXTEND_ATTRIB_POOL, queries remain simple.

• Listing currently enabled pools:
  SELECT parameter_name, display_name FROM xdp_parameter_pool_vl WHERE protected_flag = 'Y';
• Resolving a display name for a parameter code in an integration map:
  SELECT display_name FROM xdp_parameter_pool_vl WHERE parameter_name = :p_code;
• Checking effective-dated availability at a point in time:
  SELECT parameter_name FROM xdp_parameter_pool_vl WHERE TRUNC(SYSDATE) BETWEEN start_date_active AND NVL(end_date_active, SYSDATE);

Because the view is a read-only projection of lookup data, it should be treated as a reference source rather than a maintenance surface; updates belong to the underlying lookup maintenance path.