Search Results cst_xla_oe_order_lines_ref_v




Overview

The view CST_XLA_OE_ORDER_LINES_REF_V is an Oracle E-Business Suite database object owned by the APPS schema. It is classified under the BOM (Bills of Material) product family within the ETRM reference set and carries a status of VALID. Its purpose is narrow and clearly defined: to expose a minimal projection of sales order line identity from the Order Management data model for consumption by Oracle Subledger Accounting (XLA) and Cost Management (CST) reference processing.

The naming convention is significant. The prefix CST_XLA indicates that the view is part of the interface surface used by Subledger Accounting when sourcing transaction references from Cost Management, while the _REF_V suffix signals that it is a reference view rather than a transactional or balancing view. Such reference views are typically joined into larger accounting extraction queries to resolve surrogate identifiers into human-readable numbering, or to validate that an order line exists before an accounting entry is created against it. The view does not perform any costing, valuation, or journal creation logic itself; it simply provides a stable, denormalized lookup of sales order line identity.

Underlying Base Objects

According to the documented view text, the definition is a direct, single-table projection:

The only referenced base object is OE_ORDER_LINES_ALL, which is itself a synonym resolved at runtime to the Order Management order lines entity. This is the canonical source of sales order line records in EBS, holding one row per order line across all order types. Because the view selects solely from this table with no joins, filters, or aggregations, it is structurally simple and performs efficiently. No WHERE clause is applied, meaning the view returns every row present in the base table, including lines for all order categories and statuses. There is no dependency on any other BOM, WIP, or CST object, and the view does not inherit the security or organization filters sometimes applied elsewhere in the Order Management model.

Key Columns

The view exposes exactly two columns, both derived as aliases of their source equivalents in OE_ORDER_LINES_ALL:

  • SALES_ORDER_LINE_ID — Maps to LINE_ID from the base table. This is the surrogate primary key of the order line, a system-generated unique identifier used in foreign key relationships throughout Order Management and downstream accounting tables. It is the value typically stored on cost and accounting records to point back to the originating line.
  • SALES_ORDER_LINE_NUMBER — Maps to LINE_NUMBER from the base table. This is the user-visible line number within the sales order, the value displayed on the order entry form and on printed order documentation. It is meaningful only in combination with the parent order header.

Notably, the view does not expose the order header identifier, ordered item, quantity, or pricing attributes. Any query requiring those values must join back to OE_ORDER_LINES_ALL or to OE_ORDER_HEADERS_ALL using the header identifier present in the base table.

Common Use Cases and Queries

This view is most commonly accessed by developers tracing how Subledger Accounting resolves a sales order line during Cost Management extraction, or by support analysts validating reference data returned to the Create Accounting process. A typical query listing order line references is:

  • SELECT sales_order_line_id, sales_order_line_number FROM cst_xla_oe_order_lines_ref_v;
  • SELECT sales_order_line_id, sales_order_line_number FROM cst_xla_oe_order_lines_ref_v WHERE sales_order_line_id = :line_id;

Because the view is unfiltered, production queries should always restrict results by identifier or join to a driving accounting table rather than scanning the full set. A more practical pattern joins the view to an XLA or CST transaction table to translate stored line identifiers into display numbers for reporting. Given its two-column scope, the view should be regarded strictly as a reference aid; volume analysis, costing, and order detail reporting must draw on the base tables directly.