Search Results mrp_forecasts_lov_v




Overview
Explore in AI Chat

Overview

The MRP_FORECASTS_LOV_V view is an APPS-owned database object in Oracle E-Business Suite, delivered under the Master Scheduling/MRP (MRP) product family. In EBS 12.1.1 and 12.2.2, its documented purpose is to expose forecast designators and forecast sets as a List of Values (LOV) source. The _LOV_V suffix signals that the view is designed to populate an Oracle Forms list of values rather than to serve as a transactional interface. Forms that require a user to choose a forecast set, a forecast designator, or both, typically reference this view through a validation LOV.

Because forecast designators and forecast sets are closely related concepts in Oracle MRP, the view deliberately presents both in a single result set. Each row corresponds to a selectable combination, which allows a consuming form to offer a merged pick list without maintaining two separate queries. This simplifies the user interface and enforces consistent resolution of the organization context.

Underlying Base Objects

The ETRM metadata documents a single referenced base object: the synonym MRP_FORECAST_DESIGNATORS, which resolves in APPS to the underlying forecast designator table. The view definition joins this object to itself twice, using the aliases MRFDE1 and MRFDE2. The self-join is the mechanism that relates a forecast set designator to its member forecast designator within the same organization.

Internally the view is a UNION ALL of two branches. The first branch joins MRFDE1 and MRFDE2 where ORGANIZATION_ID values are equal and the FORECAST_SET of the second alias matches the FORECAST_DESIGNATOR text of the first alias. This returns designator rows that are associated with a specific forecast set. The second branch selects forecast designator records where FORECAST_SET IS NULL, supplying literal placeholders (' ', TO_CHAR(NULL), TO_DATE(NULL)) for the forecast designator, description, and disable date columns. This second branch ensures that top-level forecast sets with no subordinate designator still appear in the LOV.

Key Columns

  • FORECAST_SET_DESIGNATOR — The designator value that identifies the forecast set; this is the parent-level selector in the LOV.
  • FORECAST_SET_DESCRIPTION — Descriptive text for the forecast set, shown alongside the designator in the pick list.
  • FORECAST_SET_DISABLE_DATE — The date on which the forecast set record is disabled; used to filter out inactive sets.
  • FORECAST_SET_BUCKET_TYPE — The bucket type (for example daily, weekly, or period buckets) associated with the forecast set.
  • FORECAST_DESIGNATOR — The member forecast designator beneath the set. It is populated only in the first UNION branch; the second branch returns a single space.
  • FORECAST_DESCRIPTION — Description of the member forecast designator, or NULL where no member exists.
  • FORECAST_DISABLE_DATE — Disable date for the member forecast designator, or NULL in the set-only branch.
  • ORGANIZATION_ID — The inventory organization that owns the forecast set and designator. It provides the mandatory organizational filter in almost all LOV queries.

Common Use Cases and Queries

The principal use case is populating a Form LOV so that users can select a valid forecast set and, optionally, a subordinate forecast designator. A typical query restricts results to the current organization and omits disabled records:

  • SELECT FORECAST_SET_DESIGNATOR, FORECAST_SET_DESCRIPTION, FORECAST_DESIGNATOR, FORECAST_DESCRIPTION FROM MRP_FORECASTS_LOV_V WHERE ORGANIZATION_ID = :org_id AND (FORECAST_SET_DISABLE_DATE IS NULL OR FORECAST_SET_DISABLE_DATE > SYSDATE);
  • Filtering on FORECAST_SET_BUCKET_TYPE to limit the LOV to sets using a particular bucket configuration before selecting designators for planning reports.
  • Joining the view to custom reporting queries that resolve a stored forecast designator string back to its owning forecast set and description.

Because the view is a LOV source, it should not be treated as an authoritative transactional entity. Consumers requiring full attribute detail should query MRP_FORECAST_DESIGNATORS directly, using the view only to drive user selection and validation.