Skip to content
Fusion Reference

FND_LOOKUP_VALUES

Product: FNDviewLanguage-stripedView

The generic lookup view — every seeded and user-defined code list (lookup type + code) with its meaning and description, one row per code per installed language; the decode target for coded columns across every module

Identity
Module: FoundationNot org-partitioned
Notes

Documented as a view (LOOKUPS schema) joining the physical FND_LOOKUP_VALUES_B and FND_LOOKUP_VALUES_TL pair — land the base pair or a lookups extract, not the view. Always filter LANGUAGE or decode joins multiply. The full base key adds VIEW_APPLICATION_ID, SET_ID (reference data sets — a Fusion addition EBS didn't have), ENTERPRISE_ID, and SANDBOX_ID; most decodes can treat LOOKUP_TYPE + LOOKUP_CODE + LANGUAGE as the working key.

What the badges mean
Product: EGP
Product: the Oracle product family that owns the object — the short code Oracle's Tables and Views documentation lists as the object owner. Fusion is SaaS, so this isn't a database schema; there's no SQL path to the tables at all (see the quirks guide).
master
Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.

Structural facts — how the table is partitioned, not a trap by itself

BU-striped (ORG_ID)
Rows are scoped to a business unit. The column is still named ORG_ID, but in Fusion it means business unit, not the EBS operating unit — treat any migrated “operating unit” filter as suspect (see the quirks guide).
Per inventory org
Rows are scoped to an inventory organization via ORGANIZATION_ID — always pair it with INVENTORY_ITEM_ID on item-level joins (see the quirks guide).
Set / ledger / named-BU striped
Some tables stripe by a named column instead of ORG_ID: reference data set (SET_ID — see the quirks guide), ledger (LEDGER_ID on the GL journal tables), or a named business-unit column (PRC_BU_ID / REQ_BU_ID in procurement). The table page’s partition line names the column, and the generated SQL anchors on it — never treat these tables as unpartitioned.
Language-striped
The table carries a LANGUAGE column (a _TL translation table or FND_LOOKUP_VALUES) — one row per language. Filter to one LANGUAGE or a join multiplies rows.

Join & extract hazards — verify before you rely on this

Date-effective
This is an _F table — one row per entity per effectivity window, with EFFECTIVE_START_DATE and EFFECTIVE_END_DATE part of the key. Join without a window filter and every fact multiplies by history (see the quirks guide).
View
This is a documented convenience view, not a physical table. Extract through the BICC data store that fronts its base objects instead of assuming the view lands as-is.
In field listings, the Key chip marks a key field — a member of the documented primary key or of a documented unique index.

Fields

12 fields · 5 key

12 fields.

Table fields: position, field name, description, data type, and flags. 12 fields.
#FieldDescriptionTypeFlags
1LOOKUP_TYPELookup type — the name of the code list this row belongs toVARCHAR2
Key
2LOOKUP_CODELookup code — the stored value coded columns carryVARCHAR2
Key
3LANGUAGELanguage of this row's meaning and description — filter to one or decode joins multiplyVARCHAR2
Key
4VIEW_APPLICATION_IDApplication scope of the lookup type — part of the full keyNUMBER
Key
5SET_IDReference data set striping — part of the full key; a Fusion addition EBS didn't haveNUMBER
Key
6MEANINGThe short display label the code decodes toVARCHAR2
7DESCRIPTIONLonger description of the codeVARCHAR2
8SOURCE_LANGThe language this row's text was translated fromVARCHAR2
9ENABLED_FLAGWhether the code is activeVARCHAR2
10START_DATE_ACTIVEEffectivity start dateDATE
11END_DATE_ACTIVEEffectivity end dateDATE
12TAGFree-form grouping tag some lookup types use to sub-classify codesVARCHAR2

Field provenance: hand-curated. 5 key fields.

Boilerplate SQL

Starting point for reading the BICC-landed copy of FND_LOOKUP_VALUES on Databricks — real DATE columns need no conversion, and the org anchor and the LAST_UPDATE_DATE watermark (the column incremental BICC extracts key on) are already in place. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.

Query parameters

7 parameters not filled: <catalog>, <schema>, <language>, <LOOKUP_TYPE>, <LOOKUP_CODE>, <SET_ID>, <watermark>

-- ============================================================
-- Table  : FND_LOOKUP_VALUES — The generic lookup view — every seeded and user-defined code list (lookup type + code) with its meaning and description, one row per code per installed language; the decode target for coded columns across every module
-- Purpose: Column-selected read of FND_LOOKUP_VALUES — auto-generated from field metadata
-- Grain  : One row per LOOKUP_TYPE + LOOKUP_CODE + VIEW_APPLICATION_ID + SET_ID
-- Notes  : Auto-generated skeleton for Oracle Fusion Cloud data landed in your lakehouse by a BICC extract — there is no SQL path to the SaaS database. Column names follow Oracle's table documentation — if your landed data still carries PVO attribute headers, map names first; see quirks #pvo-drift. 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. Documented view — land its base tables for extraction; see the table notes.
-- ============================================================
SELECT
  t.LOOKUP_TYPE AS "Lookup type — the name of the code list this row belongs to",
  t.LOOKUP_CODE AS "Lookup code — the stored value coded columns carry",
  t.LANGUAGE AS "Language of this row's meaning and description — filter to one or decode joins multiply",
  t.VIEW_APPLICATION_ID AS "Application scope of the lookup type — part of the full key",
  t.SET_ID AS "Reference data set striping — part of the full key; a Fusion addition EBS didn't have",
  t.MEANING AS "The short display label the code decodes to",
  t.DESCRIPTION AS "Longer description of the code",
  t.SOURCE_LANG AS "The language this row's text was translated from",
  t.ENABLED_FLAG AS "Whether the code is active",
  t.START_DATE_ACTIVE AS "Effectivity start date",
  t.END_DATE_ACTIVE AS "Effectivity end date",
  t.TAG AS "Free-form grouping tag some lookup types use to sub-classify codes"
FROM <catalog>.<schema>.FND_LOOKUP_VALUES t
WHERE
  t.LANGUAGE = '<language>'  -- one language or rows multiply; translations fall back to SOURCE_LANG
  -- AND t.LOOKUP_TYPE = '<LOOKUP_TYPE>'
  -- AND t.LOOKUP_CODE = '<LOOKUP_CODE>'
  -- AND t.SET_ID = <SET_ID>
  -- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>'  -- the column incremental BICC extracts key on
ORDER BY t.LOOKUP_TYPE;

Verified September 2026 · docs release 26C

Column names differ in BICC extracts — see PVO header drift.

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

  • RCV_TRANSACTIONSFND_LOOKUP_VALUESFND lookup decode · N:1
    ON RCV_TRANSACTIONS.TRANSACTION_TYPE = FND_LOOKUP_VALUES.LOOKUP_CODE AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'RCV_TRANSACTION_TYPE' AND FND_LOOKUP_VALUES.LANGUAGE = '<language>'
  • RCV_TRANSACTIONSFND_LOOKUP_VALUESFND lookup decode · N:1
    ON RCV_TRANSACTIONS.SOURCE_DOCUMENT_CODE = FND_LOOKUP_VALUES.LOOKUP_CODE AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'RCV_SOURCE_DOCUMENT_TYPE' AND FND_LOOKUP_VALUES.LANGUAGE = '<language>'
  • WIE_OPERATION_TRANSACTIONSFND_LOOKUP_VALUESFND lookup decode · N:1
    ON WIE_OPERATION_TRANSACTIONS.TRANSACTION_TYPE_CODE = FND_LOOKUP_VALUES.LOOKUP_CODE AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'ORA_WIE_OP_TRANSACTION_TYPE' AND FND_LOOKUP_VALUES.LANGUAGE = '<language>'
  • WIE_RESOURCE_TRANSACTIONSFND_LOOKUP_VALUESFND lookup decode · N:1
    ON WIE_RESOURCE_TRANSACTIONS.TRANSACTION_TYPE_CODE = FND_LOOKUP_VALUES.LOOKUP_CODE AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'ORA_WIE_TRANSACTION_TYPE' AND FND_LOOKUP_VALUES.LANGUAGE = '<language>'
  • RA_CUSTOMER_TRX_LINES_ALLFND_LOOKUP_VALUESFND lookup decode · N:1
    ON RA_CUSTOMER_TRX_LINES_ALL.LINE_TYPE = FND_LOOKUP_VALUES.LOOKUP_CODE AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'STD_LINE_TYPE' AND FND_LOOKUP_VALUES.LANGUAGE = '<language>'
  • AP_INVOICE_LINES_ALLFND_LOOKUP_VALUESFND lookup decode · N:1
    ON AP_INVOICE_LINES_ALL.LINE_TYPE_LOOKUP_CODE = FND_LOOKUP_VALUES.LOOKUP_CODE AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'INVOICE LINE TYPE' AND FND_LOOKUP_VALUES.LANGUAGE = '<language>'
  • AP_INVOICE_DISTRIBUTIONS_ALLFND_LOOKUP_VALUESFND lookup decode · N:1
    ON AP_INVOICE_DISTRIBUTIONS_ALL.LINE_TYPE_LOOKUP_CODE = FND_LOOKUP_VALUES.LOOKUP_CODE AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'INVOICE DISTRIBUTION TYPE' AND FND_LOOKUP_VALUES.LANGUAGE = '<language>'
Extraction note

FND_LOOKUP_VALUES is a documented convenience view. Extract through the BICC data store that fronts its base objects instead of assuming the view lands as-is — see the table notes for where the physical rows live.

Browse more Foundation tables

More Foundation tables

Maintained by Summit Analytics, a supply chain analytics practice. The tools and references are free — the consulting is selective.

Part of the Summit Analytics reference library.

Work with the practice

Not affiliated with or endorsed by Oracle. Oracle and Oracle Fusion Cloud Applications are registered trademarks of Oracle and/or its affiliates.