Search Results so_lines




Overview

SO_LINES is a VALID view owned by the APPS schema in Oracle E-Business Suite, published under the Order Entry (OE) product family. It exposes the line-level detail of order management transactions — the operational attribute set that describes each ordered item, its pricing, scheduling, shipping, invoicing, and service characteristics — while remaining consistent between Release 12.1.1 and 12.2.2. In EBS reporting and integration architecture, SO_LINES functions as the canonical read interface for order lines: operational reports, custom concurrent programs, OBIEE/BI Publisher extracts, and inbound or outbound interfaces query it rather than the underlying transactional base object. Because it is a database view rather than a table, it carries no physical storage of its own and inherits the security and indexing behavior of the objects beneath it. The view is listed with status VALID in the ETRM registry, confirming that its definition compiles cleanly against the shipped schema and that its columns resolve to existing underlying attributes. Its schema-level listing of columns — including LINE_ID, HEADER_ID, LINE_NUMBER, INVENTORY_ITEM_ID, ORDERED_QUANTITY, and a comprehensive set of date, pricing, and descriptive flexfield columns (ATTRIBUTE1 through ATTRIBUTE15, S10 through S30 with their associated date columns) — reflects the full width of the order line record as maintained in Order Management.

Underlying Base Objects

The documented view metadata for Release 12.2.2 records a single referenced base object: the synonym SO_LINES_ALL. In Oracle EBS, OE_ORDER_LINES_ALL is the seeded transactional table that stores order line records for all operating units, and SO_LINES_ALL is the public synonym that resolves to it. SO_LINES therefore presents the columns of SO_LINES_ALL through a fixed, published projection. This indirection is the central architectural point: application code and integrations reference SO_LINES or SO_LINES_ALL, while the actual data resides in the OE_ORDER_LINES_ALL table. Consequently, multi-organization (operating unit) filtering is not automatically applied by the view itself; the caller must restrict results through HEADER_ID, LINE_ID, or an appropriate join to the order header. The view's VALID status indicates that the projection remains aligned with the base table definition, so column names and datatypes used in custom SQL remain stable across supported 12.1.1 and 12.2.2 environments.

Key Columns

Common Use Cases and Queries

Typical scenarios include open-order line reporting, backlog and book-to-bill analysis, invoicing and revenue extracts, configured-item hierarchy reporting, and integration views for downstream fulfillment or billing systems. A straightforward extract of open lines for an order header is:

  • SELECT line_id, header_id, line_number, inventory_item_id, ordered_quantity, open_flag FROM apps.so_lines WHERE header_id = :p_header_id ORDER BY line_number;
  • SELECT l.line_id, l.line_number, l.inventory_item_id, l.ordered_quantity, l.promise_date FROM apps.so_lines l WHERE l.open_flag = 'Y' AND l.creation_date >= :p_start_date;
  • SELECT l.line_id, l.header_id, l.line_type_code, l.attribute1, l.context FROM apps.so_lines l WHERE l.line_type_code = 'CONFIG' AND l.parent_line_id IS NOT NULL;

Performance depends on restricting by indexed keys such as LINE_ID or HEADER_ID, since the view performs no filtering of its own. Where shipment schedules, order headers, or item master attributes are required, join SO_LINES to the corresponding header and schedule objects on HEADER_ID and SHIPMENT_SCHEDULE_LINE_ID respectively. Because flexfield columns are exposed directly, reporting on organization-specific order line attributes requires only the appropriate ATTRIBUTE or S-segment column together with the CONTEXT value used when the flexfield was captured. All such queries should be executed against the APPS schema owner, consistent with the object's documented ownership.