Search Results oe_order_lines_hist_v




Overview
Explore in AI Chat

Overview

OE_ORDER_LINES_HIST_V is an APPS-owned view within the Oracle Order Management (ONT) module that exposes order line history records. In Oracle EBS 12.1.1 and 12.2.2, order history is maintained to preserve a point-in-time snapshot of order line attributes whenever a significant change occurs — for example, when the workflow activity, line quantity, shipping destination, or fulfilment milestone advances. Rather than overwriting the live transactional row, the Order Management engine writes a versioned history row, enabling audit trails, change analysis, and historical reporting.

The view is a denormalised reporting layer over OE_ORDER_LINES_HISTORY and its associated header history, enriched with resolved master and reference data such as customer accounts, sites, locations, transaction types, price lists, payment terms, and accounting rules. Because it returns the history-keyed columns (HIST_TYPE_CODE, HIST_CREATION_DATE, HIST_CREATED_BY, HIST_COMMENTS) alongside the full line attribute set, it is well suited to integration extracts that must publish order state changes to external systems, as well as to operational dashboards that track fulfilment progress over time.

Underlying Base Objects

The view is defined primarily over OE_ORDER_LINES_HISTORY and OE_ORDER_HEADER_HISTORY, which hold the line-level and header-level historical snapshots respectively. The following documented base objects are joined to resolve descriptive and reference attributes:

These are documented as synonyms in the 12.2.2 metadata, reflecting the standard APPS synonym convention over the underlying application tables. The view therefore sits on top of the Order Management history schema and the Trading Community Architecture (TCA) model.

Key Columns

The view exposes a broad attribute set. The principal history control columns are LINE_ID, HEADER_ID, ORG_ID, HIST_TYPE_CODE, HIST_CREATION_DATE, HIST_CREATED_BY, HIST_COMMENTS, WORKFLOW_ACTIVITY_CODE, and WF_RESULT_CODE — these identify what changed, when, and by whom, and at which workflow milestone. Transactional quantity columns include ORDERED_QUANTITY, SHIPPING_QUANTITY, SHIPPED_QUANTITY, FULFILLED_QUANTITY, CANCELLED_QUANTITY, and PRICING_QUANTITY, each qualified by its UOM counterpart.

Scheduling and promise data are represented by REQUEST_DATE, PROMISE_DATE, SCHEDULE_SHIP_DATE, and SCHEDULE_ARRIVAL_DATE. The party and location columns are central to the user query of interest: SOLD_TO_ORG_ID, SHIP_TO_ORG_ID, DELIVER_TO_ORG_ID, INVOICE_TO_ORG_ID, and notably INTMED_SHIP_TO_ORG_ID, which captures the intermediate ship-to organisation (a business entity that receives goods before final delivery — commonly required for drop-ship and multi-leg supply chains). This is complemented by SHIP_TO_CONTACT_ID, DELIVER_TO_CONTACT_ID, INTMED_SHIP_TO_CONTACT_ID, and INVOICE_TO_CONTACT_ID. Note the view itself exposes the identifier columns; the associated descriptive site and location names are resolved through the HZ joins.

Common Use Cases and Queries

A frequent requirement is to retrieve order lines destined for a specific intermediate ship-to organisation, together with header context. For example:

  • SELECT lorg_id, l.header_id, l.line_id, l.ordered_item, l.shipping_quantity, l.intmed_ship_to_org_id, l.ship_to_org_id, l.hist_creation_date FROM oe_order_lines_hist_v l WHERE l.intmed_ship_to_org_id = :p_org_id ORDER BY l.hist_creation_date DESC;

  • Filtering by change type to audit quantity revisions: SELECT line_id, ordered_quantity, shipping_quantity, hist_type_code, hist_creation_date, hist_created_by FROM oe_order_lines_hist_v WHERE header_id = :p_header_id ORDER BY hist_creation_date;

  • Joining to HZ_CUST_ACCOUNTS via intmed_ship_to_org_id to obtain the intermediate ship-to account number for an integration extract.

Because the view is historical, a single LINE_ID may return multiple rows across successive history events. Queries should therefore be scoped by HEADER_ID, ORG_ID, or a date range, and consumers should expect and handle duplicate LINE_ID values. This makes the view particularly valuable for change-data-capture feeds, transit-time and milestone analytics, and reconciliation of order state between EBS and downstream logistics or warehouse systems.