Search Results reserve_level




Overview
Explore in AI Chat

Overview

MTL_DEMAND_INTERFACE is an Inventory (INV) module table owned by the INV schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Per the ETRM repository, its documented purpose is "temporary demand storage for the transaction processor." It functions as a staging and work table that receives demand records from external sources—sales orders, WIP, and other feeders—so that the inventory transaction processor can validate, reserve, and ultimately transfer those rows into the permanent MTL_DEMAND table. It is not a transactional master; it is a transient holding area whose rows carry status flags (PROCESS_FLAG, LOCK_FLAG, ERROR_CODE) that govern the lifecycle of each interface record.

The heuristic Data Vault classification mined from the foreign key structure is link. This suggests the table is best modeled as a relationship entity connecting demands to items, organizations, subinventories, locators, lots, revisions, ATP rules, and departments, rather than as a standalone hub or a descriptive satellite. The 224 documented columns support this reading: most are either foreign-key references or short-lived processing attributes.

Key Information Stored

Among the 224 columns, the following are the most operationally significant. The composite identifiers ORGANIZATION_ID, INVENTORY_ITEM_ID, DEMAND_SOURCE_TYPE, DEMAND_SOURCE_HEADER_ID, DEMAND_SOURCE_LINE, and DEMAND_SOURCE_DELIVERY together constitute the business-key candidates that identify a demand row to the processor. DEMAND_ID is the FK to MTL_DEMAND and represents the assigned surrogate reference once the row is committed. DEMAND_SOURCE_TYPE distinguishes the originating system, while REQUIREMENT_DATE, LINE_ITEM_QUANTITY, and LINE_ITEM_UNIT_OF_MEASURE carry the demand itself.

Processing control columns include PROCESS_FLAG, LOCK_FLAG, ACTION_CODE, TRANSACTION_MODE, ATP_CHECK, VALIDATE_ROWS, DETAIL_RESERVE_FLAG, RESERVE_LEVEL, CHECK_ATR, and SINGLE_LOT_FLAG. These flags direct validation and reservation behavior. Error handling is captured by ERROR_CODE and ERR_EXPLANATION.

Location and lot attributes include REVISION, LOT_NUMBER, SERIAL_NUMBER, SUBINVENTORY, and LOCATOR_ID, with the OLD_* columns preserving pre-change values for the processor. ATP-relevant fields include ATP_RULE_ID, REQUEST_ATP_DATE, EARLIEST_ATP_DATE, GROUP_AVAILABLE_DATE, ACCUMULATION_WINDOW, ATP_LEAD_TIME, and INFINITE_TIME_FENCE_DATE. Audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and the standard ATTRIBUTE1–15, C_COLUMN1–8, N_COLUMN1–5, D_COLUMN1–5 flex fields complete the structure.

Common Use Cases and Queries

The most common operational use is diagnosing why a sales order or WIP demand failed to reach MTL_DEMAND. Querying rows where PROCESS_FLAG is not complete or where ERROR_CODE is populated reveals the failure reason via ERR_EXPLANATION.

  • Stuck demand diagnosis: SELECT DEMAND_SOURCE_TYPE, DEMAND_SOURCE_HEADER_ID, DEMAND_SOURCE_LINE, INVENTORY_ITEM_ID, PROCESS_FLAG, ERROR_CODE, ERR_EXPLANATION FROM MTL_DEMAND_INTERFACE WHERE ORGANIZATION_ID = :org_id AND PROCESS_FLAG = 'N';
  • Reservation audit: Join to MTL_DEMAND on DEMAND_ID to reconcile reserved quantities with LINE_ITEM_RESERVATION_QTY and RESERVATION_QUANTITY.
  • Open demand reporting: Filter by REQUIREMENT_DATE and INVENTORY_ITEM_ID to project upcoming demand before it is committed.
  • Error trending: Aggregate by ERROR_CODE to identify systematic interface failures.

Because the table is staging data, rows are typically purged after successful processing; reports should always constrain by ORGANIZATION_ID and PROCESS_FLAG to avoid reading stale or partially processed rows.

Related Objects

MTL_DEMAND_INTERFACE is tightly integrated with the following documented referents:

The transaction processor (INV_TXN_MANAGER / inventory transaction APIs) consumes this table, converting valid rows into MTL_DEMAND and reservation records, making it the principal dependency in the demand-loading pipeline.