Search Results oebv_price_adjustments




Overview
Explore in AI Chat

Overview

OEBV_PRICE_ADJUSTMENTS is a Business Intelligence System (BIS) base business view owned by the APPS schema in Oracle E-Business Suite. It is registered in the ETRM repository with VALID status and is associated with the ONT (Order Management) product family. As its name and description indicate, the view is defined as the "Base BIS Business View for Price Adjustments," meaning it serves as a simplified, read-only reporting and integration layer over the Order Management price adjustment data model.

Price adjustments in Order Management represent discounts, surcharges, promotions, and other modifications applied automatically or manually to order headers and lines. By exposing this data through a stable view rather than the underlying transactional table, Oracle provides a controlled access point for BIS-based reporting, discoverer workbooks, and downstream integration interfaces. The view carries no business logic of its own; it is a projection of columns from the OE_PRICE_ADJUSTMENTS table and is therefore best understood as a reporting convenience object.

Underlying Base Objects

According to the documented ETRM metadata for release 12.2.2, OEBV_PRICE_ADJUSTMENTS is defined over a single referenced base object: OE_PRICE_ADJUSTMENTS, accessed through a synonym in the APPS schema. The view text confirms this relationship directly:

  • The SELECT list projects eleven columns from OE_PRICE_ADJUSTMENTS.
  • The view is created with the WITH READ ONLY clause, guaranteeing that no DML can be performed through it.
  • The APPS synonym resolves to the base table owned by the Oracle Order Management schema, so all reads ultimately hit the transactional price adjustment records.

Because there is no join, aggregation, or filter in the view definition, row counts and cardinality match OE_PRICE_ADJUSTMENTS exactly. Any change committed to the base table is immediately visible through the view, with no materialization or refresh cycle involved.

Key Columns

The columns exposed by OEBV_PRICE_ADJUSTMENTS map directly to fields in OE_PRICE_ADJUSTMENTS. The most significant are:

  • PRICE_ADJUSTMENT_ID — Primary identifier for each price adjustment record; the key used to join to adjustment-related child data.
  • AUTOMATIC_FLAG (AUTOMATICALLY_APPLIED) — Indicates whether the adjustment was applied automatically by the pricing engine or entered manually. Note the documented column label differs slightly from the underlying column name, a common characteristic of BIS views.
  • PERCENT — The percentage value of the adjustment, where the adjustment is expressed as a percentage.
  • DISCOUNT_ID and DISCOUNT_LINE_ID — References to the discount or promotion definition and its specific line that generated the adjustment.
  • HEADER_ID — The order header to which the adjustment belongs, enabling header-level analysis.
  • LINE_ID — The order line affected by the adjustment; the primary grain for line-level pricing analysis.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY — Standard audit columns supporting incremental extraction and data lineage.

Common Use Cases and Queries

Typical scenarios include auditing discount application on orders, extracting adjustment data into a data warehouse, and reconciling pricing engine output against order lines. Because the audit columns are exposed, the view is well suited to incremental ETL that filters on LAST_UPDATE_DATE.

A representative query retrieves all automatic adjustments for a given order line:

  • SELECT price_adjustment_id, line_id, percent, discount_id, discount_line_id, automatic_flag FROM oebv_price_adjustments WHERE line_id = :p_line_id AND automatic_flag = 'Y';

For incremental extraction, a query may filter on the audit timestamp:

  • SELECT price_adjustment_id, header_id, line_id, percent, last_update_date FROM oebv_price_adjustments WHERE last_update_date >= :p_since_date;

Analysts commonly join the view to OE_ORDER_HEADERS and OE_ORDER_LINES on HEADER_ID and LINE_ID respectively to attribute adjustments to customers, order types, and items. All such access remains strictly read-only, consistent with the view's WITH READ ONLY definition, and the object should be treated as a stable reporting interface across both 12.1.1 and 12.2.2 releases.