Search Results qp_price_req_sources




Overview
Explore in AI Chat

Overview

QP_PRICE_REQ_SOURCES is a table owned by the QP schema within the Oracle Advanced Pricing module. It is documented in ETRM 12.2.2 with 24 physical columns and a status of VALID. The table stores the mapping between Pricing Request Types and Source Systems, establishing which external or internal source systems are authorized to submit requests of a given pricing request type into the Advanced Pricing engine. This mapping is foundational to cross-system pricing integration, allowing Oracle EBS to validate, route, and process inbound pricing requests originating from heterogeneous source applications.

From a Data Vault modeling perspective, the metadata classifies this object heuristically as standalone, meaning it does not participate in foreign key relationships with other tables in the documented schema and therefore does not function as a hub, link, or satellite. This classification suggests that QP_PRICE_REQ_SOURCES is best treated as an independent reference or configuration table rather than a transactional entity embedded in a broader dimensional network.

Key Information Stored

The table carries a composite primary key, QP_PRICE_REQ_SOURCES_PK, defined over REQUEST_TYPE_CODE and SOURCE_SYSTEM_CODE. These two columns are also the documented business-key candidates captured by the unique index of the same name, reinforcing that the pairing of a pricing request type with a permitted source system is the natural grain of the table. REQUEST_TYPE_CODE identifies the classification of pricing request being submitted, while SOURCE_SYSTEM_CODE identifies the originating system. Together they express the valid mapping configuration.

The remaining columns fall into two groups. First, standard Oracle EBS audit and control columns are present: SEEDED_FLAG (indicating whether the row is delivered as Oracle seed data and therefore not user-modifiable), CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN. These support change tracking and identify whether a mapping is a base Oracle delivery or a customer-defined extension. Second, the table includes the standard DFF-enabled attribute block: CONTEXT plus ATTRIBUTE1 through ATTRIBUTE15. These flexfield columns permit customers to capture additional, site-specific metadata about each request type and source system pairing without modifying the underlying schema.

Common Use Cases and Queries

Administrators and integration developers consult this table to determine which source systems are permitted to send requests for a given pricing request type. A typical validation query checks whether an inbound combination is defined and whether it is seeded:

  • SELECT request_type_code, source_system_code, seeded_flag FROM qp.qp_price_req_sources WHERE request_type_code = :p_request_type; — lists all source systems authorized for a request type.
  • SELECT request_type_code, source_system_code FROM qp.qp_price_req_sources WHERE seeded_flag = 'N'; — identifies customer-defined mappings versus Oracle seed rows.
  • Audit reporting on CREATED_BY and LAST_UPDATE_DATE to trace who configured a mapping and when.
  • Flexfield extraction using CONTEXT and the ATTRIBUTE columns for extended reporting on integration metadata.

These queries are commonly embedded in integration middleware, concurrent program validations, and pre-load checks before pricing requests are processed.

Related Objects

Because the documented metadata classifies QP_PRICE_REQ_SOURCES as standalone with no foreign keys, precise join columns to sibling tables are not asserted here. The most closely associated objects are those that reference the same REQUEST_TYPE_CODE business concept and the Advanced Pricing integration infrastructure, including QP_PRICE_REQUEST_TYPES (parent of request type definitions), QP_SOURCE_SYSTEMS (catalog of source systems), QP_PRICE_REQUESTS and QP_PRICE_REQUEST_HEADERS (transactional request records), and the Advanced Pricing public APIs such as QP_PREQ_GRP and the pricing request concurrent programs that validate inbound mappings against this configuration table. Analysts should confirm actual join columns against the installed 12.1.1 or 12.2.2 data dictionary before relying on any undocumented relationship.