Search Results so_lookups




Overview
Explore in AI Chat

Overview

APPS.SO_SCHEDULE_DETAILS is a dated, VALID view in the Oracle E-Business Suite Order Entry (OE) module, defined in the APPS schema. It presents order line scheduling information by resolving the relationship between an order line, its child option/configuration lines, and the underlying scheduling detail rows held in SO_LINE_DETAILS. Because it joins order header and line data to item master descriptions, warehouse parameters, and lookup meanings, the view provides a denormalized, reporting-ready picture of scheduled demand that can be consumed directly by reports, concurrent programs, and integration extracts without requiring callers to reconstruct the parent/child line hierarchy themselves.

The view is especially relevant to users investigating the OPTION_LINE_NUMBER column, since that column is produced by the view rather than stored as a discrete column on a base table. It is derived using a DECODE on PARENT_LINE_ID: when a line has no parent, the value resolves to an empty string; otherwise it returns the line's LINE_NUMBER. This construct exposes the number of a modelled or configured option line, allowing a report to distinguish top-level (model) lines from their option children.

Underlying Base Objects

The documented base objects include FND_GLOBAL and FND_PROFILE (packages), MTL_PARAMETERS, MTL_SYSTEM_ITEMS_VL, SO_LINES, SO_LINE_DETAILS, SO_LOOKUPS, SO_PICKING_LINES, and SO_PICKING_LINE_DETAILS. The view text supplied in the metadata shows a UNION of at least three branches. The first branch drives off SO_LINES and SO_LINE_DETAILS, joining MTL_SYSTEM_ITEMS_VL (filtered by the profile option SO_ORGANIZATION_ID), SO_LOOKUPS for RECEIPT STATUS, and SO_LOOKUPS for SOURCE TYPE. The second branch retains SO_LINES, SO_LINE_DETAILS, and SO_LOOKUPS but adds MTL_PARAMETERS to supply the warehouse organization code, filtering for unreleased schedule rows. A further branch draws on SO_PICKING_LINES and SO_PICKING_LINE_DETAILS. The lookups are outer-joined via the (+) operator, so receipt status and source type meanings are returned where available without suppressing the row.

Key Columns

  • LINE_ID — identifier of the order line, and the correlate between the view branches.
  • OPTION_LINE_NUMBER — derived from LINE_NUMBER when PARENT_LINE_ID is populated; blank for top-level lines.
  • PARENT_LINE_ID — the parent line reference used to establish the option/configuration relationship.
  • COMPONENT_CODE / INVENTORY_ITEM_ID — the component and its item identifier.
  • QUANTITY — for the item-master branch, computed as ORDERED_QUANTITY multiplied by COMPONENT_RATIO; for the detail branch, taken directly from LD.QUANTITY.
  • RATIO — the component ratio used in quantity derivation.
  • DESCRIPTION — item description, or an assembled string of organization code, schedule date, revision, lot, and subinventory.
  • ROW_LEVEL — discriminates the item-master row (0) from schedule-detail rows (1).
  • ID_COLUMN — the LINE_ID or LINE_DETAIL_ID, depending on row level.
  • RECEIPT_STATUS / SOURCE_TYPE — lookup meanings resolved through SO_LOOKUPS.
  • END_ITEM_UNIT_NUMBER — the unit number of the end item for configured items.

Common Use Cases and Queries

Typical applications include scheduled-order reports, option/configuration line listings, and extracts that must separate model lines from their option children. The OPTION_LINE_NUMBER column is the natural filter for identifying configured options.

To list option lines for a parent:

  • SELECT option_line_number, component_code, inventory_item_id, quantity, ratio, description, receipt_status
  • FROM apps.so_schedule_details
  • WHERE parent_line_id = :parent_line_id
  • AND option_line_number IS NOT NULL
  • ORDER BY option_line_number;

To enumerate top-level lines with their option counts:

  • SELECT line_id, end_item_unit_number, source_type, COUNT(option_line_number) options
  • FROM apps.so_schedule_details
  • WHERE option_line_number IS NULL
  • GROUP BY line_id, end_item_unit_number, source_type;

Because ROW_LEVEL and the UNION branches coexist, queries should filter on ROW_LEVEL or on the relevant column locality to avoid duplicate projections. All access is read-only and governed by standard APPS schema privileges.