Results for “start_date_active_second”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

QP_PREQ_QUAL_TMP is an APPS-owned, VALID view within the Oracle Advanced Pricing (QP) module. It is defined over the temporary staging table QP_PREQ_QUAL_TMP_T and exposes the qualifier rows that belong to the current pricing engine call. In Oracle EBS 12.1.1 and 12.2.2, the pricing engine (QP) materializes its working set of qualifier candidates into session-scoped temporary structures, and this view provides a relational, query-friendly projection of those rows filtered by the active request.

The defining characteristic of the view is its REQUEST_ID predicate: the view returns rows WHERE REQUEST_ID = NVL(SYS_CONTEXT('QP_CONTEXT', 'REQUEST_ID'), 1). This means the view is context-sensitive. When called inside a pricing engine session, the QP_CONTEXT application context supplies the current REQUEST_ID and only that call's qualifier rows are visible. Outside such a session, the NVL default of 1 is used, which typically returns no meaningful data. This design protects concurrent pricing calls from cross-contaminating one another's qualifier sets, and it also explains why ad hoc queries against this view often return nothing unless the caller deliberately sets the context.

Because the row set is transient and tied to a live pricing invocation, this view is not intended as a historical reporting source. It is an operational/debugging object used by DBAs, Oracle Support, and technical consultants to inspect the qualifier state during a pricing engine execution. The "search_ind" attribute that prompted this search appears as a column exposed by the view, reflecting whether a qualifier row participates in a search-eligible qualifier path during qualification processing.

Underlying Base Objects

The view is defined over a single documented base object: the synonym QP_PREQ_QUAL_TMP_T, which resolves to the underlying temporary table in the APPS schema that the pricing engine populates for the current call. The view text is a straightforward column projection with no joins, aggregation, or computed expressions — every column in QP_PREQ_QUAL_TMP maps directly to the identically named column in QP_PREQ_QUAL_TMP_T.

The only transformation applied by the view is the REQUEST_ID filter driven by SYS_CONTEXT('QP_CONTEXT', 'REQUEST_ID'). This makes QP_PREQ_QUAL_TMP effectively a "current call" slice of the temporary qualifier data. Because the base is a temporary structure, its content is scoped to the pricing request lifecycle: rows are populated as the engine gathers and evaluates qualifier candidates, and they are released when the request completes. The view itself holds no data and performs no DML; it is read-only.

Key Columns

The view exposes the full qualifier working set. The most relevant columns include:

• REQUEST_ID — identifies the pricing engine call; the value the view filters on via QP_CONTEXT.
• LIST_HEADER_ID / LIST_LINE_ID — the price list (qualifier) header and line that the row derives from.
• LINE_INDEX — ordering index of the qualifier line within the call.
• QUALIFIER_ATTRIBUTE_* columns (LEVEL, TYPE, CONTEXT, ATTRIBUTE, VALUE, DATATYPE, PRICING_ATTR_FLAG, OPERATOR_TYPE) — describe the qualifier attribute being evaluated, its context, comparison values, and data type.
• SETUP_VALUE_FROM / SETUP_VALUE_TO — the qualifier range values used for between/from-to matching.
• QUALIFIER_PRECEDENCE, QUALIFIER_GROUPING_NO, QUALIFIER_GROUP_CNT, HEADER_QUALS_EXIST_FLAG, NULL_GROUP_CNT, OTHER_GROUP_CNT, OTHERS_GROUP_CNT — govern qualifier grouping and precedence evaluation.
• SEARCH_IND — indicates the row's search participation/eligibility indicator within the qualifier search process.
• VALIDATED_FLAG / APPLIED_FLAG — whether the qualifier has passed validation and was applied.
• PRICING_STATUS_CODE, PRICING_PHASE_ID — the pricing phase and processing status.
• ASK_FOR_FLAG, CREATED_FROM_LIST_TYPE, LINE_TYPE_CODE, UNIQUE_KEY — qualifier origin and identity attributes.
• START_DATE_ACTIVE / END_DATE_ACTIVE and the FIRST/SECOND/H variants, with ACTIVE_DATE_FIRST_TYPE and ACTIVE_DATE_SECOND_TYPE, plus PRICING_EFFECTIVE_DATE — effective-dating controls for the qualifier.

Common Use Cases and Queries

Primary use cases are troubleshooting qualifier resolution, confirming which qualifiers were staged for a given pricing call, and validating search-indicator and grouping behavior. Because the view is REQUEST_ID-filtered via context, a direct query usually must first establish the QP_CONTEXT REQUEST_ID, or query the base table explicitly.

Query using the context value (typical inside a debugging session):

SELECT list_header_id, list_line_id, qualifier_attribute,
       qualifier_attribute_value, qualifier_precedence,
       search_ind, validated_flag, applied_flag
FROM   apps.qp_preq_qual_tmp
WHERE  request_id = &request_id;

Because the view's own predicate uses SYS_CONTEXT, a safer ad hoc pattern is to query the base synonym with an explicit REQUEST_ID, which reproduces the view while removing the context dependency:

SELECT qpt.*
FROM   apps.qp_preq_qual_tmp_t qpt
WHERE  qpt.request_id = &request_id
ORDER  BY qpt.qualifier_precedence, qpt.line_index;

To isolate search-eligible qualifiers for a request:

SELECT list_header_id, list_line_id, search_ind
FROM   apps.qp_preq_qual_tmp_t
WHERE  request_id = &request_id
AND    NVL(search_ind,'Y') = 'Y';

To inspect qualifier grouping and precedence outcomes:

SELECT qualifier_grouping_no, qualifier_precedence,
       header_quals_exist_flag, qualifier_group_cnt
FROM   apps.qp_preq_qual_tmp_t
WHERE  request_id = &request_id
ORDER  BY qualifier_grouping_no, qualifier_precedence;

In all cases the returned data is only meaningful while the associated pricing engine call is active, since the underlying temporary table content is scoped to that request. For historical or batch reporting, the persistent qualifier tables (such as QP_QUALIFIERS and related list structures) should be used instead.