MTL_RESERVATIONS
Schema: INVtransactionPer inventory orgFirm reservations tying a demand source (a sales order line, most commonly) to a supply source (on-hand or expected supply) for an item in an org, optionally pinned down to subinventory, locator, and lot
This is the R12 reservations table. Legacy reservation rows also exist in MTL_DEMAND — don't count both.
What the badges mean
- Schema: INV
- Schema: the Oracle product schema that owns the table (INV, ONT, WSH, PO, BOM, WIP, MRP, MSC, AR, AP, GL, HR, APPLSYS) — tells you which product family the object belongs to, not who can query it.
- master
- Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or an APPS-schema view.
- OU-striped (ORG_ID)
- Rows are scoped to an operating unit. A landed extract carries every operating unit’s rows — filter or join on
ORG_ID, and don’t confuse it withORGANIZATION_ID(see the quirks guide). - Per inventory org
- Rows are scoped to an inventory organization (plant or warehouse) via
ORGANIZATION_ID— a different partition from OU-striped tables (see the quirks guide). - Language-striped
- The table carries a
LANGUAGEcolumn (a _TL translation table or FND_LOOKUP_VALUES) — one row per language. Filter to oneLANGUAGEor a join multiplies rows (see the quirks guide). - View
- This is an APPS-schema convenience view, not a physical table. Extract the base tables it joins instead — views can be slow at scale and aren't guaranteed stable across patches.
Structural facts — how the table is partitioned, not a trap by itself
Join & extract hazards — verify before you rely on this
Fields
15 fields · 1 key
15 fields.
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | RESERVATION_ID | Surrogate key of the reservation | NUMBER | Primary-key field |
| 2 | ORGANIZATION_ID | Inventory organization | NUMBER | |
| 3 | INVENTORY_ITEM_ID | Item id | NUMBER | |
| 4 | DEMAND_SOURCE_TYPE_ID | What kind of demand holds the reservation (sales order, most commonly) | NUMBER | |
| 5 | DEMAND_SOURCE_HEADER_ID | The demand document's header id — interpretation depends on the source type | NUMBER | |
| 6 | DEMAND_SOURCE_LINE_ID | The demand document's line id | NUMBER | |
| 7 | SUPPLY_SOURCE_TYPE_ID | What supplies the reservation — on-hand or an expected supply document | NUMBER | |
| 8 | SUPPLY_SOURCE_HEADER_ID | The supplying document's header id, when not against on-hand | NUMBER | |
| 9 | RESERVATION_QUANTITY | Reserved quantity in the reservation UOM | NUMBER | |
| 10 | PRIMARY_RESERVATION_QUANTITY | Reserved quantity in the item's primary UOM — the column to aggregate | NUMBER | |
| 11 | RESERVATION_UOM_CODE | The UOM the reservation was placed in | VARCHAR2 | |
| 12 | SUBINVENTORY_CODE | Subinventory the reservation is pinned to, when detailed | VARCHAR2 | |
| 13 | LOCATOR_ID | Locator the reservation is pinned to | NUMBER | |
| 14 | LOT_NUMBER | Lot the reservation is pinned to | VARCHAR2 | |
| 15 | REQUIREMENT_DATE | When the demand needs the material | DATE | The table's primary analysis date — a real DATE column, no conversion needed |
Field provenance: hand-curated. 1 key field.
Boilerplate SQL
Starting point for reading MTL_RESERVATIONS on Databricks — real DATE columns need no conversion, and the org anchor is already in place. The optional LAST_UPDATE_DATE watermark is included. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.
7 parameters not filled: <catalog>, <schema>, <inventory_org_id>, <RESERVATION_ID>, <DATE_FROM>, <DATE_TO>, <watermark>
-- ============================================================
-- Table : MTL_RESERVATIONS — Firm reservations tying a demand source (a sales order line, most commonly) to a supply source (on-hand or expected supply) for an item in an org, optionally pinned down to subinventory, locator, and lot
-- Purpose: Column-selected read of MTL_RESERVATIONS — auto-generated from field metadata
-- Grain : One row per inventory org (ORGANIZATION_ID) + RESERVATION_ID
-- 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.RESERVATION_ID AS "Surrogate key of the reservation",
t.ORGANIZATION_ID AS "Inventory organization",
t.INVENTORY_ITEM_ID AS "Item id",
t.DEMAND_SOURCE_TYPE_ID AS "What kind of demand holds the reservation (sales order, most commonly)",
t.DEMAND_SOURCE_HEADER_ID AS "The demand document's header id — interpretation depends on the source type",
t.DEMAND_SOURCE_LINE_ID AS "The demand document's line id",
t.SUPPLY_SOURCE_TYPE_ID AS "What supplies the reservation — on-hand or an expected supply document",
t.SUPPLY_SOURCE_HEADER_ID AS "The supplying document's header id, when not against on-hand",
t.RESERVATION_QUANTITY AS "Reserved quantity in the reservation UOM",
t.PRIMARY_RESERVATION_QUANTITY AS "Reserved quantity in the item's primary UOM — the column to aggregate",
t.RESERVATION_UOM_CODE AS "The UOM the reservation was placed in",
t.SUBINVENTORY_CODE AS "Subinventory the reservation is pinned to, when detailed",
t.LOCATOR_ID AS "Locator the reservation is pinned to",
t.LOT_NUMBER AS "Lot the reservation is pinned to",
t.REQUIREMENT_DATE AS "When the demand needs the material"
FROM <catalog>.<schema>.MTL_RESERVATIONS t
WHERE
t.ORGANIZATION_ID = <inventory_org_id> -- inventory org, NOT the operating unit — see quirks guide #two-orgs
-- AND t.RESERVATION_ID = <RESERVATION_ID>
-- AND t.REQUIREMENT_DATE >= DATE '<DATE_FROM>'
-- AND t.REQUIREMENT_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.RESERVATION_ID;Verified September 2026
Relationships
Diagram of 1-hop neighbors — join details below. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.
Join details
ON MTL_RESERVATIONS.INVENTORY_ITEM_ID = MTL_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID AND MTL_RESERVATIONS.ORGANIZATION_ID = MTL_SYSTEM_ITEMS_B.ORGANIZATION_IDON MTL_RESERVATIONS.ORGANIZATION_ID = MTL_PARAMETERS.ORGANIZATION_IDON MTL_RESERVATIONS.DEMAND_SOURCE_LINE_ID = OE_ORDER_LINES_ALL.LINE_ID
More Inventory tables
- MTL_SECONDARY_INVENTORIESThe subinventory master — each row a named section of stock within an organization (stores, staging, WIP, rejects) with its asset/expense nature, tracking and reservability controls, and default accounts
- MTL_SERIAL_NUMBERSThe serial number master — definition and current position (status, org, subinventory, locator, lot) of every serialized unit; a serial is unique per item, not per org
- MTL_SUPPLYThe incoming-supply picture — one row per open requisition, purchase order, or in-transit shipment element expected into an org, with the supply type migrating as the document progresses
- MTL_TRANSACTION_ACCOUNTSAccounting distributions for material transactions — the debit and credit lines behind each material transaction, valued and pointed at a GL account combination
- MTL_TRANSACTION_LOT_NUMBERSLot-level detail for material transactions — one row per lot consumed or received per material transaction, with the lot's share of the quantity
- MTL_TRANSACTION_TYPESThe transaction type list — seeded and user-defined types, each mapping to the transaction action and source type that together classify material transactions