Search Results order_line

Overview

The WIP_COMP_SALES_ORDERS_VAL_V view is a Work in Process (WIP) inquiry construct owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to present sales orders that are eligible to satisfy work order completion transactions — that is, the demand-side reservations that a discrete job or repetitive schedule can consume when finished goods are received into inventory. The view is a validation and reporting layer rather than a transactional table; it exposes a read-only projection of outstanding sales order demand so that completion, pick-release, and shipping logic can identify the correct order line, delivery, and quantity to associate with a produced item.

The trailing _VAL_V suffix indicates a validation view. Such views are typically consumed by concurrent programs, Oracle Forms LOV queries, and open interfaces that must confirm a selected sales order line is a legitimate target for the operation at hand. Because the view filters aggressively, callers receive only rows that represent live, reservable demand against which a completion can legitimately be booked.

Underlying Base Objects

The view is defined exclusively over MTL_DEMAND, referenced in the APPS schema through a synonym. MTL_DEMAND is the core supply/demand matching table in Oracle Inventory, storing both supplies (for example, work order completions) and demands (for example, sales order shipments). The view applies a fixed WHERE clause that constrains the rows to a single semantic category:

• DEMAND_SOURCE_TYPE = 2 — the demand originates from a sales order.
• SUPPLY_SOURCE_TYPE = 5 — the corresponding supply is a work in process completion.
• RESERVATION_TYPE = 3 — the reservation is of the type generated for sales order issue against WIP supply.
• ROW_STATUS_FLAG = 1 — only active, non-deleted demand rows are returned.
• PRIMARY_UOM_QUANTITY > 0 — rows with a fully consumed or zero quantity are excluded.

Consequently, the view behaves as a purpose-built slice of MTL_DEMAND and inherits its keys, including ORGANIZATION_ID, INVENTORY_ITEM_ID, and the supply/demand header identifiers.

Key Columns

The column list maps MTL_DEMAND attributes to business-friendly aliases:

• ORGANIZATION_ID — inventory organization in which the demand and completion coexist.
• INVENTORY_ITEM_ID and REVISION — the item and revision being produced and reserved.
• WIP_ENTITY_ID — the work order or repetitive schedule supplying the quantity, sourced from SUPPLY_SOURCE_HEADER_ID.
• DEMAND_SOURCE_HEADER_ID and DEMAND_SOURCE_LINE — the sales order header and line identifying the customer demand.
• ORDER_LINE — the user-visible order line number, derived from USER_LINE_NUM; this is the column most frequently used to reconcile the view back to Order Management.
• DEMAND_SOURCE_DELIVERY and SHIPMENT — the delivery and shipment identifiers, the latter aliased from USER_DELIVERY.
• REQUEST_DATE — the requirement date, aliased from REQUIREMENT_DATE, indicating when the demand must be satisfied.
• QUANTITY — the reserved amount in the primary unit of measure.
• SUBINVENTORY — the subinventory from which the completion quantity is intended to be issued.

Common Use Cases and Queries

Typical uses include validating sales order demand during work order completion, driving lot/serial assignment for make-to-order items, and reconciling open WIP supply against shipping commitments. A representative query retrieving demand for a specific item and organization is shown below:

SELECT order_line, demand_source_header_id, shipment,
       request_date, quantity, subinventory
FROM   apps.wip_comp_sales_orders_val_v
WHERE  organization_id = :org_id
AND    inventory_item_id = :item_id
ORDER BY request_date;

Reporting users frequently join through ORDER_LINE to OE_ORDER_LINES_ALL or DOO_ORDER_LINES_ALL to obtain the ordered item, ordered quantity, and customer, and through WIP_ENTITY_ID to WIP_ENTITIES to obtain the job or schedule name. Because the view already enforces the sales-order-to-WIP-completion relationship and excludes closed or zero-quantity rows, it is preferred over querying MTL_DEMAND directly when only valid completion targets are required.