MRP_FORECAST_DATES
Schema: MRPtransactionPer inventory orgThe forecast fact — one row per forecast entry per item, org, forecast name, and date, carrying both the entered quantity and the post-consumption remainder
A single row spans MANY buckets when RATE_END_DATE is set — expand before summing; and CURRENT_FORECAST_QUANTITY is post-consumption, so summing ORIGINAL double-counts demand already consumed by sales orders
Original minus current is what sales orders consumed. Bucket types are daily, weekly, and periodic — the bucket decides which dates are legal.
What the badges mean
- master
- Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or an APPS-schema view.
Fields
15 fields · 1 key
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | TRANSACTION_ID | Surrogate key of the forecast entry | NUMBER | Key |
| 2 | INVENTORY_ITEM_ID | The forecast item | NUMBER | |
| 3 | ORGANIZATION_ID | Inventory organization | NUMBER | |
| 4 | FORECAST_DESIGNATOR | The forecast the entry belongs to — joins with the org | VARCHAR2 | |
| 5 | FORECAST_DATE | The bucket date — the analysis date | DATE | Filter date |
| 6 | RATE_END_DATE | NULL for a single bucket — when set, the row SPANS buckets from the forecast date to here; expand before summing | DATE | |
| 7 | BUCKET_TYPE | Daily, weekly, or periodic bucket | NUMBER | |
| 8 | ORIGINAL_FORECAST_QUANTITY | The entered quantity, before consumption | NUMBER | |
| 9 | CURRENT_FORECAST_QUANTITY | The post-consumption remainder — original minus current is what sales orders consumed | NUMBER | |
| 10 | CONFIDENCE_PERCENTAGE | Confidence attached to the entry | NUMBER | |
| 11 | ORIGINATION_TYPE | How the entry was created — manual, load, copy…; numeric, undecoded | NUMBER | |
| 12 | SOURCE_FORECAST_DESIGNATOR | The forecast this entry was copied/loaded from | VARCHAR2 | |
| 13 | SOURCE_ORGANIZATION_ID | Source org of a copied entry | NUMBER | |
| 14 | END_ITEM_ID | The planning-bill parent this entry was exploded from | NUMBER | |
| 15 | FORECAST_RULE_ID | The forecast rule that generated statistical entries | NUMBER |
Field provenance: hand-curated. 1 key field.
Boilerplate SQL
Starting point for reading MRP_FORECAST_DATESon Databricks — real DATE columns need no conversion, and the org anchor and the LAST_UPDATE_DATE watermark are already in place. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.
-- ============================================================
-- Table : MRP_FORECAST_DATES — The forecast fact — one row per forecast entry per item, org, forecast name, and date, carrying both the entered quantity and the post-consumption remainder
-- Purpose: Column-selected read of MRP_FORECAST_DATES — auto-generated from field metadata
-- Grain : One row per inventory org (ORGANIZATION_ID) + TRANSACTION_ID
-- Caution: A single row spans MANY buckets when RATE_END_DATE is set — expand before summing; and CURRENT_FORECAST_QUANTITY is post-consumption, so summing ORIGINAL double-counts demand already consumed by sales orders
-- Notes : Auto-generated skeleton for Oracle EBS R12 data landed in your lakehouse. Dates are real DATE/TIMESTAMP columns — no conversion needed. WHO audit columns omitted (see the quirks guide); the optional LAST_UPDATE_DATE watermark filter supports incremental extracts.
-- ============================================================
SELECT
t.TRANSACTION_ID AS "Surrogate key of the forecast entry",
t.INVENTORY_ITEM_ID AS "The forecast item",
t.ORGANIZATION_ID AS "Inventory organization",
t.FORECAST_DESIGNATOR AS "The forecast the entry belongs to — joins with the org",
t.FORECAST_DATE AS "The bucket date — the analysis date",
t.RATE_END_DATE AS "NULL for a single bucket — when set, the row SPANS buckets from the forecast date to here; expand before summing",
t.BUCKET_TYPE AS "Daily, weekly, or periodic bucket",
t.ORIGINAL_FORECAST_QUANTITY AS "The entered quantity, before consumption",
t.CURRENT_FORECAST_QUANTITY AS "The post-consumption remainder — original minus current is what sales orders consumed",
t.CONFIDENCE_PERCENTAGE AS "Confidence attached to the entry",
t.ORIGINATION_TYPE AS "How the entry was created — manual, load, copy…; numeric, undecoded",
t.SOURCE_FORECAST_DESIGNATOR AS "The forecast this entry was copied/loaded from",
t.SOURCE_ORGANIZATION_ID AS "Source org of a copied entry",
t.END_ITEM_ID AS "The planning-bill parent this entry was exploded from",
t.FORECAST_RULE_ID AS "The forecast rule that generated statistical entries"
FROM <catalog>.<schema>.MRP_FORECAST_DATES t
WHERE
t.ORGANIZATION_ID = <inventory_org_id> -- inventory org, NOT the operating unit — see quirks guide #two-orgs
-- AND t.TRANSACTION_ID = <TRANSACTION_ID>
-- AND t.FORECAST_DATE >= DATE '<DATE_FROM>'
-- AND t.FORECAST_DATE <= DATE '<DATE_TO>'
-- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>' -- WHO watermark, bulk-stamped by batch jobs; see quirks guide #who-columns
ORDER BY t.TRANSACTION_ID;7 parameters not filled: <catalog>, <schema>, <inventory_org_id>, <TRANSACTION_ID>, <DATE_FROM>, <DATE_TO>, <watermark>
Relationships
1-hop neighbors — click a table to navigate there. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.
Join details
ON MRP_FORECAST_DATES.FORECAST_DESIGNATOR = MRP_FORECAST_DESIGNATORS.FORECAST_DESIGNATOR AND MRP_FORECAST_DATES.ORGANIZATION_ID = MRP_FORECAST_DESIGNATORS.ORGANIZATION_IDON MRP_FORECAST_DATES.INVENTORY_ITEM_ID = MTL_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID AND MRP_FORECAST_DATES.ORGANIZATION_ID = MTL_SYSTEM_ITEMS_B.ORGANIZATION_IDON MRP_SCHEDULE_DATES.FORECAST_ID = MRP_FORECAST_DATES.TRANSACTION_ID AND MRP_SCHEDULE_DATES.ORGANIZATION_ID = MRP_FORECAST_DATES.ORGANIZATION_ID