Search Results actual_shipment_date




Overview
Explore in AI Chat

Overview

APPS.RLM_OE_ORDER_LINES_V is a reporting view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the Oracle Release Management (RLM) product family and exposes aggregated order line demand and shipment data drawn from Oracle Order Management. The view is designed to present order line information at a summarized level, keyed predominantly by organization, item, and date, rather than at the individual order line identifier level. Its central purpose is to support planning, shipping authorization, and demand-bucket analysis, providing a consolidated picture of ordered, shipped, open, and tolerance quantities.

The view's name, combined with the presence of SHIP_FROM_ORG_ID and SHIP_TO_ORG_ID, indicates that it is used to report against shipping organizations and their associated demand. In an integrated EBS environment this view can serve as a data source for downstream reporting, order visibility, and supplier or customer collaboration processes where aggregated shipping demand must be evaluated by warehouse and item.

Underlying Base Objects

The ETRM documentation identifies two referenced base objects for this view:

  • OE_ORDER_LINES_ALL (SYNONYM): The primary transactional source. The view's inline query filters this table on item_identifier_type = 'CUST', shippable_flag = 'Y', and line_category_code <> 'RETURN', thereby restricting output to customer-identified, shippable sales order lines and excluding returns.
  • INV_CONVERT (PACKAGE): Referenced via INV_CONVERT.INV_UM_CONVERT to convert shipped quantities between the shipping unit of measure and the order unit of measure, ensuring quantity columns are expressed on a consistent UOM basis.

The view is constructed as a UNION ALL of two aggregating queries. The first query captures ordered quantities and open quantities keyed on trunc(schedule_ship_date); the second captures shipped quantities keyed on trunc(actual_shipment_date). Both are grouped by shipping organizations, items, date, and related attributes, then combined and re-aggregated in the outer query using DECODE flags ('O' for ordered/open, 'S' for shipped).

Key Columns

  • SHIP_FROM_ORG_ID: The shipping (warehouse) organization from which goods are dispatched. This is the column most commonly used to filter and group demand by fulfillment location.
  • SHIP_TO_ORG_ID: The destination organization for the shipment.
  • CUSTOMER_ITEM_ID / INVENTORY_ITEM_ID: The ordered item identifier and its corresponding inventory item identifier.
  • EVENT_DATE: A truncated date representing either the scheduled ship date (for ordered quantities) or the actual shipment date (for shipped quantities).
  • AUTHORIZED_TO_SHIP_FLAG: Encoded as 1 for 'Y' and 2 for 'N', indicating whether the line is authorized to ship.
  • DEMAND_BUCKET_TYPE_CODE / UOM_CODE: Demand classification and unit of measure context.
  • ORDERED_QTY, SHIPPED_QTY, OPEN_QTY: Aggregated quantity measures derived from the 'O' and 'S' flags.
  • TOLERANCE_QTY: The over/under-shipment tolerance computed from the difference between scheduled and actual shipment dates and UOM conversions.
  • ORG_ID: The operating unit identifier, supporting multi-org data segregation.

Common Use Cases and Queries

A primary use case is evaluating shipping demand and open quantities for a specific warehouse, which explains the frequent search on SHIP_FROM_ORG_ID. A representative query follows:

  • SELECT ship_from_org_id, inventory_item_id, event_date, ordered_qty, shipped_qty, open_qty FROM apps.rlm_oe_order_lines_v WHERE ship_from_org_id = :org_id AND event_date BETWEEN :start_date AND :end_date ORDER BY event_date;
  • Filtering by authorized_to_ship_flag = 1 isolates lines cleared for shipment.
  • Grouping by demand_bucket_type_code supports demand-bucket reporting and planning analysis.
  • Joining to item and organization master views enriches output with descriptions for reporting layers.

Because the view pre-aggregates quantities, it is well suited to summary dashboards and integration extracts rather than line-level transactional reconciliation.