Search Results sales_order_line_number




Overview
Explore in AI Chat

Overview

The APPS.CST_XLA_OE_ORDER_LINES_REF_V view is a lightweight reference view delivered as part of the Oracle E-Business Suite Cost Management and Subledger Accounting (XLA) infrastructure. Its purpose is narrow and well defined: it exposes sales order line identifiers and their corresponding user-visible line numbers from the Order Management base table OE_ORDER_LINES_ALL, presenting them under the column aliases SALES_ORDER_LINE_ID and SALES_ORDER_LINE_NUMBER. This aliasing is significant because the view exists to support the reporting and integration needs of the Cost Management and XLA (eXtended Ledger Architecture) subledger accounting flows, where downstream objects must correlate cost and accounting entries back to specific sales order lines using a consistent, descriptive naming convention.

The object is documented in ETRM as a view owned by the APPS schema. It is referenced within the sales order costing and subledger accounting reporting context, particularly where a user or report requires the human-readable sales order line number associated with a transaction line. The view's simplicity — a single SELECT from one base table — reflects its role as a stable interface or "ref" (reference) view rather than a transformed or enriched reporting layer.

Underlying Base Objects

The view is defined over a single documented base object: OE_ORDER_LINES_ALL (referenced as a synonym). The documented view text is unambiguous:

  • SELECT LINE_ID SALES_ORDER_LINE_ID, LINE_NUMBER SALES_ORDER_LINE_NUMBER FROM OE_ORDER_LINES_ALL

OE_ORDER_LINES_ALL is the canonical Order Management table storing one row per sales order line, including pricing, quantity, fulfilment context, and line-level attributes. Because the view performs a direct, unfiltered column projection with no joins, no WHERE clause, and no aggregation, it inherits the full row population of that base table. There is consequently a one-to-one relationship between the rows returned by CST_XLA_OE_ORDER_LINES_REF_V and the sales order lines in OE_ORDER_LINES_ALL. No view-level predicates restrict scope, so partition or status filtering must be applied explicitly by the consuming query if required.

Key Columns

  • SALES_ORDER_LINE_ID — Maps to OE_ORDER_LINES_ALL.LINE_ID. This is the internal primary key (unique system-generated identifier) of the sales order line. It is the value most commonly carried as a foreign key into costing, XLA, and inventory transaction tables to establish the link between an accounting or cost event and its originating order line.
  • SALES_ORDER_LINE_NUMBER — Maps to OE_ORDER_LINES_ALL.LINE_NUMBER. This is the user-facing line number displayed on the order in the Order Management forms and in Sales Order Inquiry. It is the attribute a user searching for "sales_order_line_number" typically expects to retrieve, as it is meaningful to the business rather than to the database.

Because the view exposes only these two columns, it is intentionally minimal. Note that neither header-level context (order number, customer) nor line-level detail (item, quantity) is included; those must be sourced from other tables such as OE_ORDER_HEADERS_ALL or additional columns of OE_ORDER_LINES_ALL when needed.

Common Use Cases and Queries

The view is typically joined to cost or subledger accounting data in order to render the business line number alongside an internal line identifier. A representative query joining the view to a costing or XLA reference follows:

  • SELECT r.sales_order_line_number, r.sales_order_line_id FROM apps.cst_xla_oe_order_lines_ref_v r WHERE r.sales_order_line_id = :p_line_id;

Typical scenarios include: translating a stored LINE_ID from a cost or accounting event into the displayed sales order line number for reporting; validating that XLA accounting lines map correctly to originating order lines; and providing a user-friendly column in custom order-costing extracts. Because the view simply mirrors OE_ORDER_LINES_ALL, for requirements demanding organisation, order, or item context, developers usually join back to OE_ORDER_LINES_ALL or OE_ORDER_HEADERS_ALL rather than relying on this view alone. When joining to XLA tables, filter on the relevant APPLICATION_ID and entity identifiers, as the view itself imposes no such filtering.