MTL_SERIAL_NUMBERS
Schema: INVmasterThe 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
The org column is CURRENT_ORGANIZATION_ID — where the unit sits now, an attribute rather than part of the key — so this catalog does not give the table the inventory-org anchor; filter CURRENT_ORGANIZATION_ID explicitly when you mean one org's serials.
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
10 fields · 2 key
10 fields.
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | INVENTORY_ITEM_ID | Item id — a serial is unique per item, across all orgs | NUMBER | Primary-key field |
| 2 | SERIAL_NUMBER | The serial number | VARCHAR2 | Primary-key field |
| 3 | CURRENT_ORGANIZATION_ID | Where the unit sits now — an attribute, not part of the key; filter it when you mean one org's serials | NUMBER | |
| 4 | CURRENT_STATUS | Lifecycle state — defined-not-used, in stores, issued, in transit | NUMBER | |
| 5 | CURRENT_SUBINVENTORY_CODE | The subinventory the unit currently sits in | VARCHAR2 | |
| 6 | CURRENT_LOCATOR_ID | The locator the unit currently sits in | NUMBER | |
| 7 | LOT_NUMBER | The lot the unit belongs to, for lot-and-serial items | VARCHAR2 | |
| 8 | INITIALIZATION_DATE | When the serial was first used | DATE | |
| 9 | SHIP_DATE | When the unit shipped | DATE | |
| 10 | ORIGINAL_WIP_ENTITY_ID | The job that built the unit, when WIP-sourced | NUMBER |
Field provenance: hand-curated. 2 key fields.
Boilerplate SQL
Starting point for reading MTL_SERIAL_NUMBERS 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.
5 parameters not filled: <catalog>, <schema>, <INVENTORY_ITEM_ID>, <SERIAL_NUMBER>, <watermark>
-- ============================================================
-- Table : MTL_SERIAL_NUMBERS — The 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
-- Purpose: Column-selected read of MTL_SERIAL_NUMBERS — auto-generated from field metadata
-- Grain : One row per INVENTORY_ITEM_ID + SERIAL_NUMBER
-- 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.INVENTORY_ITEM_ID AS "Item id — a serial is unique per item, across all orgs",
t.SERIAL_NUMBER AS "The serial number",
t.CURRENT_ORGANIZATION_ID AS "Where the unit sits now — an attribute, not part of the key; filter it when you mean one org's serials",
t.CURRENT_STATUS AS "Lifecycle state — defined-not-used, in stores, issued, in transit",
t.CURRENT_SUBINVENTORY_CODE AS "The subinventory the unit currently sits in",
t.CURRENT_LOCATOR_ID AS "The locator the unit currently sits in",
t.LOT_NUMBER AS "The lot the unit belongs to, for lot-and-serial items",
t.INITIALIZATION_DATE AS "When the serial was first used",
t.SHIP_DATE AS "When the unit shipped",
t.ORIGINAL_WIP_ENTITY_ID AS "The job that built the unit, when WIP-sourced"
FROM <catalog>.<schema>.MTL_SERIAL_NUMBERS t
WHERE
1 = 1 -- no partition column on this table; the filters below are optional
-- AND t.INVENTORY_ITEM_ID = <INVENTORY_ITEM_ID>
-- AND t.SERIAL_NUMBER = '<SERIAL_NUMBER>'
-- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>' -- WHO watermark, bulk-stamped by batch jobs; see quirks guide #who-columns
ORDER BY t.INVENTORY_ITEM_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_SERIAL_NUMBERS.INVENTORY_ITEM_ID = MTL_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID AND MTL_SERIAL_NUMBERS.CURRENT_ORGANIZATION_ID = MTL_SYSTEM_ITEMS_B.ORGANIZATION_IDON MTL_SERIAL_NUMBERS.LOT_NUMBER = MTL_LOT_NUMBERS.LOT_NUMBER AND MTL_SERIAL_NUMBERS.INVENTORY_ITEM_ID = MTL_LOT_NUMBERS.INVENTORY_ITEM_ID AND MTL_SERIAL_NUMBERS.CURRENT_ORGANIZATION_ID = MTL_LOT_NUMBERS.ORGANIZATION_ID
More Inventory tables
- 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
- MTL_TXN_REQUEST_HEADERSMove order headers — the user-visible move order number, type, status, and required date for requests to move material within an organization
- MTL_TXN_REQUEST_LINESMove order lines — each row requests moving a quantity of an item from a source to a destination subinventory, individually statused, allocated (quantity detailed), and transacted (quantity delivered)