Search Results order_origination

Overview

ICX_MRP_FORECAST_UPDATES_V is an APPS-owned database view in Oracle E-Business Suite (validated in 12.1.1 and 12.2.2) that belongs to the ICX – Oracle iProcurement product family. Its documented description is "Forecast Consumptions View." The view exposes the row-level detail of forecast consumption transactions generated by Oracle MRP against sales order demand, while enriching each record with identifying attributes from the associated sales order. In effect, it presents the transactional history of how planning forecasts were consumed or updated in response to sales order activity.

In EBS reporting and integration terms, the view functions as a read-only reporting surface. iProcurement and planning-related components consume forecast consumption data to reconcile planned demand against actual booked sales orders. Because the view already joins the raw consumption table to the sales order master, external reports, concurrent programs, and interfaces can retrieve human-readable order identifiers without replicating the join logic themselves. The user search term "update_sales_order" corresponds directly to the UPDATE_SALES_ORDER column, which is the foreign key linking each forecast consumption record to its originating sales order.

Underlying Base Objects

The view is defined over two documented base objects, both referenced through APPS synonyms:

• MRP_FORECAST_UPDATES (SYNONYM) – the primary transactional table. It stores one row per forecast update or consumption event, aliased as MFU in the view text.
• MTL_SALES_ORDERS (SYNONYM) – the sales order header source, aliased as MSO, supplying the segment-based order identifiers.

The join condition is MSO.SALES_ORDER_ID = MFU.UPDATE_SALES_ORDER. This is an equi-join between the forecast update record and its sales order header, meaning that rows in MRP_FORECAST_UPDATES referencing a sales order present in MTL_SALES_ORDERS will be returned. The view exposes MFU.ROWID as ROW_ID and carries the standard EBS WHO columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN) for auditing.

Key Columns

• ROW_ID – the ROWID of the underlying MRP_FORECAST_UPDATES row; useful for uniquely identifying a transaction.
• TRANSACTION_ID – surrogate identifier of the forecast update transaction.
• INVENTORY_ITEM_ID / ORGANIZATION_ID – the item and inventory organization context for the forecast consumption.
• FORECAST_DESIGNATOR – identifies the forecast set consumed by the transaction.
• UPDATE_SALES_ORDER – foreign key to the sales order header; the column matching the "update_sales_order" search.
• SALES_ORDER_SCHEDULE_DATE – the scheduled date of the sales order line driving the update.
• FORECAST_UPDATE_DATE – the date on which the forecast was updated or consumed.
• SALES_ORDER_QUANTITY / UPDATE_QUANTITY – ordered quantity and the quantity applied to the forecast.
• DEMAND_CLASS – the demand class associated with the consumption.
• CUSTOMER_ID, SHIP_ID, BILL_ID – customer and ship-to/bill-to references.
• LINE_NUM – the sales order line number.
• ORDER_NUMBER, ORDER_TYPE, ORDER_ORIGINATION – derived from MTL_SALES_ORDERS segments SEGMENT1, SEGMENT2, and SEGMENT3 respectively.

Common Use Cases and Queries

Typical scenarios include reconciling forecast consumption against booked orders, auditing which sales orders drove forecast updates, and feeding planning reports with readable order numbers.

Retrieve all forecast updates for a specific sales order:

SELECT order_number, line_num, inventory_item_id,
       forecast_designator, forecast_update_date,
       sales_order_quantity, update_quantity
FROM   apps.icx_mrp_forecast_updates_v
WHERE  update_sales_order = :sales_order_id;

Summarize consumption by item and organization within a date range:

SELECT inventory_item_id, organization_id,
       SUM(update_quantity) consumed_qty
FROM   apps.icx_mrp_forecast_updates_v
WHERE  forecast_update_date BETWEEN :start_date AND :end_date
GROUP  BY inventory_item_id, organization_id;

Because the view joins at header level, it should be used for reporting rather than transactional updates; the WHO columns and ROW_ID support auditing and downstream integration extraction.