Search Results mrp_bis_forecast_set_v




Overview
Explore in AI Chat

Overview

MRP_BIS_FORECAST_SET_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the MRP (Master Scheduling/MRP) product family. It is an aggregation layer within the Business Intelligence System (BIS) reporting model for forecasting, presenting forecast versus actual order performance summarized at the forecast set, forecast designator, and organization level. The view condenses transactional trend-level detail from its underlying trend view into consolidated quantities, amounts, and a computed forecast error, making it suitable for management-level accuracy reporting rather than raw data extraction.

The object carries a status of VALID in ETRM 12.2.2 and exists identically in 12.1.1 and 12.2.2, as it is a database view defined in the APPS schema rather than a form-driven or OAF-based object. Because it is a view, it holds no data of its own and imposes no additional storage; all values are derived at query time from its base objects. Its documented description mirrors the product classification (MRP - Master Scheduling/MRP) and does not enumerate business narrative detail, so functional interpretation relies primarily on the view definition and column metadata.

Underlying Base Objects

The view is defined exclusively over two documented base objects:

  • MRP_BIS_FORECAST_TREND_V (VIEW) — the primary source, supplying forecast and order quantity and amount measures at a finer granularity.
  • MRP_GET_BIS_VALUES (PACKAGE) — a PL/SQL package invoked within the SELECT list to compute the forecast error value via the FORECAST_ERROR function.

Structurally, MRP_BIS_FORECAST_SET_V groups rows from MRP_BIS_FORECAST_TREND_V by FORECAST_SET, ORGANIZATION_ID, and FORECAST_DESIGNATOR, then applies SUM aggregation to the quantity and amount columns. The FORECAST_ERROR column is not a simple sum: it is computed as ABS(MRP_GET_BIS_VALUES.FORECAST_ERROR(SUM(FORECAST_AMOUNT), SUM(ORDER_AMOUNT))), meaning the packaged function receives the already-aggregated totals. This dependency means the view cannot be queried successfully if the package is invalid or lacks EXECUTE privilege for the calling user.

Key Columns

  • FORECAST_SET — the forecast set identifier; part of the grouping key and the primary organizational unit for forecast reporting.
  • FORECAST_DESIGNATOR — the forecast designator within the set; also part of the grouping key.
  • ORGANIZATION_ID — the inventory organization; forecasts are segregated by organization in the aggregation.
  • FORECAST_QUANTITY — summed forecast quantity across the trend rows.
  • ORDER_QUANTITY — summed actual order quantity, used for consumption comparison against forecast.
  • FORECAST_AMOUNT — summed forecast value in currency terms.
  • ORDER_AMOUNT — summed actual order value in currency terms.
  • FORECAST_ERROR — the absolute deviation between forecast and order amounts, computed by MRP_GET_BIS_VALUES.FORECAST_ERROR; a lower value indicates closer forecast accuracy.

Common Use Cases and Queries

Typical usage centers on forecast accuracy scorecards, forecast consumption analysis, and BIS-style trend reporting. A standard query retrieves accuracy metrics for a specific organization and forecast set:

  • SELECT forecast_set, forecast_designator, organization_id, forecast_quantity, order_quantity, forecast_amount, order_amount, forecast_error FROM apps.mrp_bis_forecast_set_v WHERE organization_id = :org_id AND forecast_set = :set_name ORDER BY forecast_error DESC;
  • Ranking designators by error: SELECT forecast_designator, forecast_error FROM apps.mrp_bis_forecast_set_v WHERE organization_id = :org_id AND forecast_error > 0 ORDER BY forecast_error DESC;
  • Comparing aggregate forecast versus order amounts: SELECT forecast_set, SUM(forecast_amount) fcst_amt, SUM(order_amount) ord_amt FROM apps.mrp_bis_forecast_set_v GROUP BY forecast_set;

Because the view invokes MRP_GET_BIS_VALUES, large scans can be expensive; filtering by ORGANIZATION_ID and FORECAST_SET before aggregation is advisable. Reports should also account for the possibility of NULL error values where the packaged function returns no result for zero-amount groups.