Search Results qp_parameter_values




Overview
Explore in AI Chat

Overview

QP_PARAMETER_VALUES is a table owned by the QP schema within the Oracle Advanced Pricing module. It stores all seeded and user-assigned values for every parameter associated with a given request type. In the Oracle EBS pricing engine, request types drive behaviors such as price list calculation, modifier resolution, and pricing attribute derivation. Each request type exposes a set of parameters, and this table captures the concrete value assigned to each parameter at a defined level. The object is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2, with a documented physical schema of 11 columns in the 12.2.2 ETRM repository.

The heuristic Data Vault classification mined from the foreign key structure is standalone, meaning no referential dependencies to other tables were detected in the FK metadata. From a modeling perspective, this absence of declared relationships suggests treating it as an independent satellite-like structure keyed by its own surrogate identifier, while the business meaning of the row is anchored by the parameter and level combination rather than by a parent hub. This classification should be regarded as a modeling suggestion rather than a definitive architectural statement, since Advanced Pricing relies heavily on application-level (non-enforced) relationships.

Key Information Stored

The table is defined by a small but tightly constrained column set. The most significant columns are:

  • PARAMETER_VALUE_ID — the surrogate primary key, enforced by the system-generated constraint SYS_C00180318. It uniquely identifies each parameter value record.
  • PARAMETER_ID — identifies the parameter to which the stored value belongs; this is the essential business attribute linking the value back to a pricing request parameter definition.
  • LEVEL_NAME — indicates the level at which the parameter value applies, allowing the same parameter to hold different values across levels such as request type, price list, or line.
  • SEEDED_DEFAULT_VALUE — holds the Oracle-supplied default value that ships with the application, preserved independently of user changes.
  • USER_ASSIGNED_VALUE — holds the value the user has explicitly assigned, which takes precedence over the seeded default where present.
  • ZD_EDITION_NAME — the editioning column supporting Oracle EBS 12.2.2 online patching, enabling edition-specific visibility of rows.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard EBS audit columns recording who created and last modified the record and when.

Two unique indexes act as business-key candidates. QP_PARAMETER_VALUES_U1 covers (PARAMETER_VALUE_ID, ZD_EDITION_NAME), aligning the surrogate key with the editioning model. QP_PARAMETER_VALUES_U2 covers (PARAMETER_ID, LEVEL_NAME, ZD_EDITION_NAME), which is the more meaningful natural key: it enforces that a given parameter can have only one value per level within an edition.

Common Use Cases and Queries

The primary use case is diagnosing pricing behavior that depends on parameter setup. Because seeded defaults and user overrides are stored side by side, a common query compares the two to identify configurations that have been customized away from Oracle's baseline:

  • Listing overridden parameters: SELECT PARAMETER_ID, LEVEL_NAME, SEEDED_DEFAULT_VALUE, USER_ASSIGNED_VALUE FROM QP.QP_PARAMETER_VALUES WHERE USER_ASSIGNED_VALUE IS NOT NULL AND USER_ASSIGNED_VALUE <> SEEDED_DEFAULT_VALUE;
  • Retrieving the effective value for a given parameter and level, using NVL(USER_ASSIGNED_VALUE, SEEDED_DEFAULT_VALUE) to resolve precedence.
  • Auditing changes by filtering on LAST_UPDATE_DATE and LAST_UPDATED_BY to determine which user altered a parameter and when, which is useful during upgrade or regression testing.
  • Edition-scoped reporting in 12.2.2, where queries must account for ZD_EDITION_NAME to avoid returning rows from the file system edition in addition to the run edition.

These patterns support pricing setup validation, post-clone verification, and root-cause analysis when pricing results differ between environments.

Related Objects

The documented FK metadata classifies this table as standalone, so no enforced foreign keys to parent tables were captured by the ETRM miner. In practice, the following objects are the most significant application-level references:

  • QP_PARAMETERS — the parameter definition table; join on PARAMETER_ID to resolve parameter names and descriptions.
  • QP_REQUEST_TYPES — defines the pricing request types whose parameters this table populates.
  • QP_REQUEST_TYPE_PARAMS — associates request types with their allowed parameters, forming the logical parent of the values stored here.
  • QP_RL_SEARCH_REQUEST_TYPES and related pricing setup tables that consume resolved parameter values at runtime.
  • QP_PARAMETER_VALUES is accessed indirectly through Advanced Pricing setup forms and concurrent programs that read effective parameter values during price calculation.