Results for “requirement_date”

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

Overview

The MRP_DERIVED_SO_DEMANDS table resides in the MRP schema and belongs to the Master Scheduling/MRP product family within Oracle E-Business Suite 12.1.1 and 12.2.2. It functions as a staging and derivation area where sales order demand is transformed into a form usable by the MRP/MPS planning engine. Rather than reading sales order lines directly, the planner consumes a normalized demand record set that captures item, organization, quantity, date, and source lineage for every open sales order schedule. This decoupling allows the planning engine to operate against a consistent snapshot while shielding it from the transactional volatility of the order entry tables.

Because the table carries descriptive attributes tied to a demand transaction and a natural business key rooted in the source sales order schedule, the heuristic Data Vault classification is satellite. This classification is offered as a modeling suggestion only: the table behaves as a descriptive satellite attached to a demand hub/link keyed by the sales order schedule rather than as a standalone hub.

Key Information Stored

The table contains 17 documented columns. The most operationally significant are:

• DEMAND_ID — the surrogate identifier for a derived demand row within the planning snapshot.
• DEMAND_HEADER_ID — foreign key to RLA_DEMAND_HEADERS_ALL, providing the link back to the originating demand header.
• DEMAND_SOURCE_TYPE, DEMAND_SOURCE_LINE, DEMAND_SOURCE_DELIVERY — the business-key lineage that identifies which sales order line and delivery generated the demand.
• INVENTORY_ITEM_ID and ORGANIZATION_ID — the planning item and warehouse context for the demand.
• REQUIREMENT_DATE — the schedule date against which the planner nets demand.
• PRIMARY_UOM_QUANTITY, RESERVATION_QUANTITY, COMPLETED_QUANTITY — the demanded, reserved, and fulfilled quantities.
• RESERVATION_TYPE and DEMAND_CLASS — classification attributes that drive reservation and pegging logic.
• SUBINVENTORY — the storage location tied to the requirement.
• PARENT_DEMAND_ID — supports hierarchical pegging of dependent demands.
• SALES_CONTACT — the sales representative associated with the order.
• REFRESH_NUMBER — a snapshot/version tag identifying the planning run that produced the row.

DEMAND_ID serves as the surrogate primary key, while DEMAND_HEADER_ID plus the DEMAND_SOURCE_TYPE/LINE/DELIVERY combination forms the strongest business-key candidate.

Common Use Cases and Queries

Typical scenarios include reconciling planned sales order demand against booked orders, tracing backlog by item and organization, and diagnosing why a requirement appears (or fails to appear) during a planning run. Because rows are versioned by REFRESH_NUMBER, analysts isolate a single plan run before aggregating.

• Backlog by item and organization for the latest refresh.
• Comparing PRIMARY_UOM_QUANTITY against COMPLETED_QUANTITY to measure open demand.
• Pegging derived demand back to the originating sales order via DEMAND_HEADER_ID and DEMAND_SOURCE_LINE.

A representative query restricts to the current REFRESH_NUMBER and groups by ORGANIZATION_ID and INVENTORY_ITEM_ID, summing PRIMARY_UOM_QUANTITY while filtering on REQUIREMENT_DATE ranges. Joining to RLA_DEMAND_HEADERS_ALL via DEMAND_HEADER_ID enriches the result with header-level order context.

Related Objects

• RLA_DEMAND_HEADERS_ALL — joined on DEMAND_HEADER_ID; the authoritative demand header.
• MRP_ORGANIZATION_ITEMS — joined on INVENTORY_ITEM_ID and ORGANIZATION_ID for item master attributes.
• MRP_SYSTEM_ITEMS / MTL_SYSTEM_ITEMS_B — item descriptive data.
• MRP_FULL_PEGGING — pegging and dependency analysis across planning runs.
• MRP_GROSS_REQUIREMENTS — the downstream aggregate demand table populated during the MRP run.
• OE_ORDER_HEADERS_ALL and OE_ORDER_LINES_ALL — ultimate source order data reachable through the demand header lineage.