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

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

master: Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.

Fields

12 fields · 5 key

Table fields: position, field name, description, data type, and flags. 12 fields.
#	Field	Description	Type	Flags
1	LOOKUP_TYPE	Lookup type — the name of the code list this row belongs to	VARCHAR2	Key
2	LOOKUP_CODE	Lookup code — the stored value coded columns carry	VARCHAR2	Key
3	LANGUAGE	Language of this row's meaning and description — filter to one or decode joins multiply	VARCHAR2	Key
4	VIEW_APPLICATION_ID	Application scope of the lookup type — part of the full key	NUMBER	Key
5	SET_ID	Reference data set striping — part of the full key; a Fusion addition EBS didn't have	NUMBER	Key
6	MEANING	The short display label the code decodes to	VARCHAR2
7	DESCRIPTION	Longer description of the code	VARCHAR2
8	SOURCE_LANG	The language this row's text was translated from	VARCHAR2
9	ENABLED_FLAG	Whether the code is active	VARCHAR2
10	START_DATE_ACTIVE	Effectivity start date	DATE
11	END_DATE_ACTIVE	Effectivity end date	DATE
12	TAG	Free-form grouping tag some lookup types use to sub-classify codes	VARCHAR2

Field provenance: hand-curated. 5 key fields.

Boilerplate SQL

Starting point for reading the BICC-landed copy of FND_LOOKUP_VALUESon 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

CatalogSchemaLanguage codeLookup typeLookup codewatermark

Include optional filters (3)

-- ============================================================
-- 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.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>'  -- the column incremental BICC extracts key on
ORDER BY t.LOOKUP_TYPE;

6 parameters not filled: <catalog>, <schema>, <language>, <LOOKUP_TYPE>, <LOOKUP_CODE>, <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.

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 Foundationtables →