Search Results parent_uom_code

Overview

QP_DEBUG_REQ_LINES_V is a diagnostic view owned by the APPS schema within the Oracle Advanced Pricing (QP) module. It is defined over the pricing debug request tables and exposes the set of request lines that the pricing engine evaluates during a pricing or reprice call. In Oracle EBS 12.1.1 and 12.2.2, Advanced Pricing maintains a debug repository that captures the state of the pricing engine at runtime; this view is the flattened, human-readable projection of that repository for the line-level records.

The view does not store data of its own. It presents a consolidated picture of each pricing line together with its related line index, allowing technical consultants and support analysts to reconstruct the sequence and outcome of a pricing request. Because it surfaces the hold code, hold text, pricing status, qualifier match flags, and adjustment values, it is frequently used during troubleshooting to determine why a particular line was or was not priced, and whether a hold was applied during processing.

Underlying Base Objects

The view is defined over two synonyms: QP_DEBUG_REQ_LINES and QP_DEBUG_REQ_RLTD_LINES, both resolving to their base tables in the APPS schema. The join is an outer join on the related-line table:

• QP_DEBUG_REQ_LINES (aliased A) — the driving table, holding one row per priced line, keyed by REQUEST_ID and LINE_INDEX.
• QP_DEBUG_REQ_RLTD_LINES (aliased B) — the related-line table, supplying RELATED_LINE_INDEX. The outer join condition (A.REQUEST_ID = B.REQUEST_ID (+) AND A.LINE_INDEX = B.LINE_INDEX (+)) preserves every line from A even when no related line exists, in which case NVL(B.RELATED_LINE_INDEX, A.LINE_INDEX) defaults the related index to the line's own index.

The SELECT DISTINCT clause collapses any duplication introduced by multiple related-line matches, so each request/line combination is presented once.

Key Columns

• REQUEST_ID, REQUEST_TYPE_CODE — identify the pricing debug request and its type, the primary correlation keys.
• LINE_ID, LINE_INDEX, RELATED_LINE_INDEX, LINE_TYPE_CODE — identify the line and its position, including linkage to related lines.
• PRICING_EFFECTIVE_DATE, START_DATE_ACTIVE_FIRST, ACTIVE_DATE_FIRST_TYPE, START_DATE_ACTIVE_SECOND, ACTIVE_DATE_SECOND_TYPE — the effective and active dating used to evaluate price lists and modifiers.
• LINE_QUANTITY, LINE_UOM_CODE, PRICED_QUANTITY, PRICED_UOM_CODE, UOM_QUANTITY, CURRENCY_CODE — quantity and currency context.
• UNIT_PRICE, PERCENT_PRICE, ADJUSTED_UNIT_PRICE, UPDATED_ADJUSTED_UNIT_PRICE, PARENT_PRICE, PARENT_QUANTITY, PARENT_UOM_CODE, LINE_AMOUNT, GROUP_QUANTITY, GROUP_AMOUNT — pricing and adjustment results.
• HOLD_CODE, HOLD_TEXT — the hold applied to the line, with its descriptive text; the search term "hold_code" maps directly to this column.
• PRICING_STATUS_CODE, PRICING_STATUS_TEXT, PROCESSED_FLAG, PROCESSED_CODE, PRICE_FLAG, VALIDATED_FLAG — processing outcome and status indicators.
• QUALIFIERS_EXIST_FLAG, PRIMARY_QUALIFIERS_MATCH_FLAG, PRICING_ATTRS_EXIST_FLAG — qualifier evaluation diagnostics.
• PRICE_REQUEST_CODE, PRICE_LIST_HEADER_ID, ROUNDING_FLAG, ROUNDING_FACTOR, USAGE_PRICING_TYPE, PROCESSING_ORDER.

Common Use Cases and Queries

Typical scenarios include debugging why a line was held, verifying which price list and modifiers were applied, and auditing qualifier matches. The following query isolates lines carrying a hold within a request:

• SELECT request_id, line_index, line_id, hold_code, hold_text, pricing_status_code, pricing_status_text FROM qp_debug_req_lines_v WHERE hold_code IS NOT NULL ORDER BY request_id, line_index;
• SELECT line_index, line_type_code, unit_price, adjusted_unit_price, line_amount, currency_code FROM qp_debug_req_lines_v WHERE request_id = :request_id ORDER BY processing_order;
• SELECT request_id, line_index, related_line_index, primary_qualifiers_match_flag, qualifiers_exist_flag FROM qp_debug_req_lines_v WHERE qualifiers_exist_flag = 'Y' AND primary_qualifiers_match_flag = 'N';

Because the view is read-only and diagnostic, it is well suited to ad hoc reporting and integration extracts that need to inspect pricing engine behavior without touching transactional pricing tables.