Search Results item_location_control_code




Overview
Explore in AI Chat

Overview

MTL_DEMAND_V is a read-only reporting view owned by the APPS schema in Oracle E-Business Suite, defined in the Inventory (INV) product. The ETRM metadata flags its documented description as "10SC ONLY," indicating that the view was authored for a specific release or localization context rather than as a general-purpose interface. Its role is to expose reserved demand records from MTL_DEMAND and enrich them with descriptive item attributes from the item key flexfield view, so that downstream reports and integrations can present demand detail without separate joins. The view returns only a filtered subset of demand: rows must carry a RESERVATION_TYPE of 2 and a non-null PARENT_DEMAND_ID, and the outstanding primary-unit-of-measure quantity must exceed zero. It is therefore a child-demand (component-level) view rather than a complete picture of all demand in the system.

Underlying Base Objects

The view text joins two base objects, both documented as synonyms: MTL_DEMAND, the transaction table that stores demand, reservation, and supply records in the Inventory module, and MTL_SYSTEM_ITEMS_KFV, the key flexfield view over MTL_SYSTEM_ITEMS that supplies concatenated item segments and descriptive attributes. The join is performed on both INVENTORY_ITEM_ID and ORGANIZATION_ID, ensuring item attributes are resolved in the correct inventory organization. The filter conditions restrict output to reserved demand rows that have a parent demand record and still carry a remaining quantity, which effectively selects unfulfilled component demand generated beneath a parent (for example, demand created for a configured or bill-of-material parent item). Because MTL_DEMAND is one of the highest-volume tables in the INV schema, the view's selective predicates are significant for performance.

Key Columns

Identification columns include ROW_ID (the MTL_DEMAND row identifier), DEMAND_ID, ORGANIZATION_ID, and INVENTORY_ITEM_ID. Item context is provided by ITEM (padded concatenated segments), ITEM_DESCRIPTION, PRIMARY_UOM, REVISION_CONTROL, LOT_CONTROL, ITEM_LOCATION_CONTROL_CODE, and SHELF_LIFE_CODE. Demand origin is described by DEMAND_SOURCE_TYPE, DEMAND_SOURCE_HEADER_ID, DEMAND_SOURCE_LINE, DEMAND_SOURCE_NAME, and PARENT_DEMAND_ID. Quantity columns are ORIG_LINE_QTY (line item quantity), PUOM_ORIG_RSV_QTY (primary UOM quantity reserved), PUOM_ISSUED_QTY (completed quantity), and PUOM_REMAINING_QTY, the arithmetic difference between reserved and completed quantities. Planning and fulfillment detail is carried by REQ_DATE, REVISION, LOT_NUMBER, SUBINVENTORY, LOCATOR_ID, and USER_LINE_NUM. Standard audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and fifteen descriptive flexfield attributes (ATTRIBUTE_CATEGORY through ATTRIBUTE15) are also exposed.

Common Use Cases and Queries

Typical uses include open component-demand reporting, backorder and shortage analysis, and feeding custom integrations that require item descriptive context alongside demand quantities. The SHELF_LIFE_CODE column in particular supports shelf-life reporting, since it is not stored on MTL_DEMAND itself and must be retrieved from the item definition.

  • List outstanding reserved demand for a given organization: SELECT demand_id, item, puom_remaining_qty, req_date FROM mtl_demand_v WHERE organization_id = :org_id ORDER BY req_date;
  • Identify shelf-life-controlled items with unfulfilled demand: SELECT item, item_description, lot_number, subinventory, puom_remaining_qty FROM mtl_demand_v WHERE shelf_life_code = 1;
  • Trace component demand to its parent: SELECT d.demand_id, d.parent_demand_id, d.item, d.puom_orig_rsv_qty, d.puom_issued_qty FROM mtl_demand_v d WHERE d.parent_demand_id = :parent_id;
  • Summarize residual demand by item and subinventory: SELECT item, subinventory, SUM(puom_remaining_qty) remaining FROM mtl_demand_v GROUP BY item, subinventory;

Because the view is documented as "10SC ONLY" and is defined over high-volume demand data, consumers should confirm its validity in their specific 12.1.1 or 12.2.2 environment and evaluate the execution plan before using it in high-frequency or bulk reporting.