MTL_TRANSACTION_TYPES
Schema: INVcontrolThe transaction type list — seeded and user-defined types, each mapping to the transaction action and source type that together classify material transactions
Global reference data — no org column. USER_DEFINED_FLAG separates site-defined types from seeded ones; treat user-defined type ids as configuration, not constants, across environments.
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
7 fields · 1 key
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | TRANSACTION_TYPE_ID | Transaction type id — what the material ledger carries | NUMBER | Key |
| 2 | TRANSACTION_TYPE_NAME | The type's display name | VARCHAR2 | |
| 3 | TRANSACTION_ACTION_ID | The physical action the type performs | NUMBER | MTL_TRANSACTION_ACTION |
| 4 | TRANSACTION_SOURCE_TYPE_ID | The document source type the type pairs with | NUMBER | |
| 5 | DESCRIPTION | Type description | VARCHAR2 | |
| 6 | DISABLE_DATE | When the type was disabled — NULL while active | DATE | |
| 7 | USER_DEFINED_FLAG | Site-defined vs seeded type — user-defined ids differ across environments | VARCHAR2 |
Field provenance: hand-curated. 1 key field.
Boilerplate SQL
Starting point for reading MTL_TRANSACTION_TYPESon 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 : MTL_TRANSACTION_TYPES — The transaction type list — seeded and user-defined types, each mapping to the transaction action and source type that together classify material transactions
-- Purpose: Column-selected read of MTL_TRANSACTION_TYPES — auto-generated from field metadata
-- Grain : One row per TRANSACTION_TYPE_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.TRANSACTION_TYPE_ID AS "Transaction type id — what the material ledger carries",
t.TRANSACTION_TYPE_NAME AS "The type's display name",
t.TRANSACTION_ACTION_ID AS "The physical action the type performs", -- decode t.TRANSACTION_ACTION_ID via FND_LOOKUP_VALUES (LOOKUP_TYPE = 'MTL_TRANSACTION_ACTION', LANGUAGE-filtered) — see quirks guide #lookups
t.TRANSACTION_SOURCE_TYPE_ID AS "The document source type the type pairs with",
t.DESCRIPTION AS "Type description",
t.DISABLE_DATE AS "When the type was disabled — NULL while active",
t.USER_DEFINED_FLAG AS "Site-defined vs seeded type — user-defined ids differ across environments"
FROM <catalog>.<schema>.MTL_TRANSACTION_TYPES t
WHERE
1 = 1 -- no partition column on this table; the filters below are optional
-- AND t.TRANSACTION_TYPE_ID = <TRANSACTION_TYPE_ID>
-- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>' -- WHO watermark, bulk-stamped by batch jobs; see quirks guide #who-columns
ORDER BY t.TRANSACTION_TYPE_ID;4 parameters not filled: <catalog>, <schema>, <TRANSACTION_TYPE_ID>, <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 MTL_MATERIAL_TRANSACTIONS.TRANSACTION_TYPE_ID = MTL_TRANSACTION_TYPES.TRANSACTION_TYPE_IDON MTL_TXN_REQUEST_HEADERS.TRANSACTION_TYPE_ID = MTL_TRANSACTION_TYPES.TRANSACTION_TYPE_ID