Results for “mrp_schedule_consumptions_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The APPS.MRP_SCHEDULE_CONSUMPTIONS_V view presents consumption history for the master schedule within the Master Scheduling/MRP (MRP) product of Oracle E-Business Suite 12.1.1 and 12.2.2. It is a reporting and integration layer that denormalizes records from the MRP_SCHEDULE_CONSUMPTIONS base object and resolves the disposition of each consumption transaction into a human-readable identifier. The view is owned by the APPS schema and is marked VALID in ETRM 12.2.2.

Consumption records capture the relief of supply against demand: when a schedule entry consumes on-hand, a work order, a purchase order, a requisition, or a shipment, MRP records the transaction with a relief type and a disposition. This view exposes those movements together with the document number of the originating source, enabling planners and reporting tools to reconcile schedule consumption without joining multiple operational tables manually. The view is commonly referenced in custom concurrent programs, BI Publisher reports, and inbound/outbound interface extracts that require consumption history.

Underlying Base Objects

The view is defined over a single driving table, MRP_SCHEDULE_CONSUMPTIONS (aliased MRSC, exposed as a synonym), which supplies all transactional columns. Four outer-joined synonyms resolve the disposition identifier into a document name based on the disposition type: PO_HEADERS_ALL (purchase orders), PO_REQUISITION_HEADERS_ALL (requisitions), RCV_SHIPMENT_HEADERS (receiving shipments), and WIP_ENTITIES (work orders). All four joins are outer joins, so consumption rows are never dropped when a disposition cannot be resolved.

A final join to MFG_LOOKUPS (VIEW) resolves the DISPOSITION_TYPE code against LOOKUP_TYPE = 'MRP_RELIEF_ORIGINATION' to produce DISPOSITION_TYPE_TEXT. The DECODE on DISPOSITION_TYPE selects the appropriate document number: 1 and 9 return WIP_ENTITY_NAME, 2 and 6 return PO SEGMENT1, 5 returns requisition SEGMENT1, 7 and 8 return SHIPMENT_NUM, and 3 and 4 return NULL.

Key Columns

• ROW_ID — the ROWID of the underlying MRP_SCHEDULE_CONSUMPTIONS row.
• TRANSACTION_ID — unique identifier for the consumption transaction.
• RELIEF_TYPE — the category of relief applied to the schedule (the column most frequently searched).
• DISPOSITION_TYPE — coded value identifying the source document category.
• DISPOSITION_TYPE_TEXT — the lookup meaning for the disposition type.
• DISPOSITION_ID — the primary key of the source document.
• DISPOSITION — the resolved document number (work order, PO, requisition, or shipment).
• ORDER_DATE / ORDER_QUANTITY — date and quantity of the originating order.
• RELIEF_QUANTITY — quantity relieved from supply.
• SCHEDULE_DATE — the schedule date associated with the consumption.
• LINE_NUM — line reference on the disposition document.
• Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, PROGRAM_ID, REQUEST_ID, and related fields for change tracking and concurrent program tracing.

Common Use Cases and Queries

Typical scenarios include consumption reconciliation by relief type, tracing relief back to a work order or purchase order, and feeding planning dashboards. A representative query filters on relief type and joins schedule dates:

• SELECT transaction_id, relief_type, disposition, disposition_type_text, order_quantity, relief_quantity, schedule_date FROM apps.mrp_schedule_consumptions_v WHERE relief_type = :p_relief_type AND schedule_date BETWEEN :p_from AND :p_to;
• Aggregate relieved quantity by disposition type: SELECT disposition_type_text, SUM(relief_quantity) FROM apps.mrp_schedule_consumptions_v GROUP BY disposition_type_text;
• Trace consumption back to work orders: filter on DISPOSITION_TYPE IN (1,9) and report DISPOSITION as the WIP entity name.
• Audit extracts using REQUEST_ID and PROGRAM_ID to identify the concurrent program that created the row.

Because all lookup joins are outer joins, reports should always filter on RELIEF_TYPE explicitly to limit the result set and avoid scanning unrelated consumption history.