Search Results partial_shipments_allowed

Overview

ASO_I_OE_ORDER_HEADERS_V is an APPS-owned database view in Oracle E-Business Suite, assigned to the ASO - Order Capture product family. According to Oracle's documented metadata, the view "includes all columns from the Oracle Order Management tables and is currently used by Oracle Sales Compensation only." This statement of scope is significant: although the view exposes the full header structure of Order Management order headers, its intended consumer within the E-Business Suite application itself is limited to Sales Compensation processing. In practice, the view is a pass-through projection over the order header data model, and it is most commonly encountered by developers and analysts as an integration and reporting access point for order header data rather than as a functional business object in its own right.

In EBS 12.1.1 and 12.2.2 the object retains a VALID status and the same owner (APPS) in the ETRM repository. Because Order Management in 12.2.x continues to store order headers in OE_ORDER_HEADERS, the view's column set remains aligned with the 11i and 12.1 lineage of that table, which means the view is stable across the 12.1.1 and 12.2.2 releases for the columns it exposes.

Underlying Base Objects

The ETRM metadata documents a single referenced base object: OE_ORDER_HEADERS, accessed through a synonym. The view text confirms this relationship, since the projection consists entirely of columns that are native to the Order Management order headers entity — HEADER_ID, ORG_ID, ORDER_TYPE_ID, ORDER_NUMBER, the sold-to/ship-to/invoice-to organization and contact identifiers, and the standard WHO audit columns. There is no join, aggregation, or filter expression documented in the view definition, so the view behaves as a column-list projection rather than as a transformed or denormalized data set.

Two consequences follow. First, the row grain of the view is identical to OE_ORDER_HEADERS: one row per order header record, keyed by HEADER_ID. Second, any data visible in the view is a direct reflection of the underlying header table at query time; no additional business logic is applied. Because the view is owned by APPS and built on a synonym, grants and synonyms determine visibility for custom reporting users, and the ordering of columns in a SELECT * will follow the view definition rather than the base table definition.

Key Columns

• HEADER_ID — Primary identifier of the order header; the join key to OE_ORDER_LINES_ALL and other order entities.
• ORG_ID — Operating unit identifier, essential for multi-org reporting and for applying the correct MO security profile.
• ORDER_NUMBER, ORDER_TYPE_ID, ORDER_SOURCE_ID — Human-readable order number and the classification of the order type and source.
• ORDERED_DATE, REQUEST_DATE, PRICING_DATE — Transaction dates used for period and trend reporting; ORDERED_DATE is the most frequently used in Sales Compensation and booking analyses.
• SOLD_TO_ORG_ID, SHIP_TO_ORG_ID, INVOICE_TO_ORG_ID, DELIVER_TO_ORG_ID — Party/organization identifiers for the various order roles, together with the corresponding contact ID columns.
• TRANSACTIONAL_CURR_CODE, CONVERSION_RATE, CONVERSION_TYPE_CODE — Currency and conversion information for value-based reporting.
• ATTRIBUTE1 through ATTRIBUTE15 — The descriptive flexfield (DFF) segment columns. A user searching for "tp_attribute1" is generally looking for a descriptive flexfield segment whose underlying column is one of these ATTRIBUTE columns on the order header.
• GLOBAL_ATTRIBUTE_CATEGORY and GLOBAL_ATTRIBUTE1 through GLOBAL_ATTRIBUTE15+ — Additional flexfield storage exposed by the view.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, PROGRAM_ID, REQUEST_ID — Standard WHO and concurrent program audit columns supporting lineage and change tracking.

Common Use Cases and Queries

The principal use case is Sales Compensation extraction and order header reporting where a read-only projection of OE_ORDER_HEADERS is required without exposing the base table directly. Typical queries retrieve order headers for a given operating unit and date range, or join to lines to build booking and revenue extracts.

• Header extract by operating unit and date:

SELECT header_id, order_number, org_id, ordered_date,
       sold_to_org_id, transactional_curr_code
FROM   apps.aso_i_oe_order_headers_v
WHERE  org_id = :p_org_id
AND    ordered_date >= :p_from_date;

• Descriptive flexfield inquiry (the "tp_attribute1" scenario). DFF segments are surfaced through the ATTRIBUTE columns, whose meaning depends on the context/segment mapping in the flexfield definition. A common diagnostic query inspects the raw segment values:

SELECT order_number, context, attribute1, attribute2, attribute3
FROM   apps.aso_i_oe_order_headers_v
WHERE  attribute1 IS NOT NULL
AND    org_id = :p_org_id;

• Join to order lines for a line-level extract:

SELECT h.order_number, l.line_number, l.ordered_quantity
FROM   apps.aso_i_oe_order_headers_v h,
       apps.oe_order_lines_all l
WHERE  h.header_id = l.header_id;

Because the view is documented as a straight projection of OE_ORDER_HEADERS, queries against it can generally be rewritten against the base table with equivalent results. Reporting users should confirm the specific DFF context and segment mapping before interpreting any ATTRIBUTE column, since the same column carries different meanings across flexfield contexts.