SAP tableObjectDD07TModuleABAP

DD07T table — Domain Fixed Values Text Table

DD07T stores the language-dependent short text for each fixed value defined on a domain in the ABAP Dictionary. Every row pairs a domain, a fixed value, and a language with the description that shows up in dropdowns, value help, and check table displays. Without a matching row, the fixed value still works technically but shows blank or the raw code instead of a readable label.

This page covers DD07T, the table holding the descriptive texts for domain fixed values in the ABAP Dictionary, distinguishing it from DD07L which holds the actual value ranges. It focuses on the join pattern back to fields and domains, the language pitfalls that cause blank dropdown texts, and how this behaves unchanged in S/4HANA.

Published 15 Sept 2026· 1,027 words

What it stores

One row represents the text, in one language, for one fixed value of one domain. Domains in the ABAP Dictionary can carry a list of fixed values (a value range restriction), for example a domain for order status carrying values 'A', 'B', 'C'. DD07L holds the actual value or value range for each entry. DD07T holds only the accompanying description, split out by language, because SAP dictionary objects separate the technical definition from its translated text. When a screen field built on that domain offers an F4 dropdown, the values come from DD07L and the labels shown next to them come from DD07T, filtered to the logon language. If a fixed value exists in DD07L but has no corresponding DD07T row in the user's language, the dropdown shows the raw value with no description, or falls back to another language if one is maintained.

Key fields

  • DOMNAME - name of the domain the fixed value belongs to, links back to the domain definition and to DD07L
  • VALPOS - sequential position number of the fixed value within the domain, ties the text row to the exact entry in DD07L
  • DDLANGUAGE - language key for this text, one row per fixed value per language maintained
  • DOMVALUE_L - the fixed value itself (the low value of the entry), repeated here from DD07L for readability
  • DDTEXT - the short descriptive text shown in dropdowns and F4 help for this value in this language

How it joins the data model

  • DD07T-DOMNAME = DD03L-DOMNAME, finds every table field that uses a given domain, then the fixed value texts that apply to it
  • DD02L-TABNAME = DD03L-TABNAME, chains from a table name down through its fields to the domains and their fixed values
  • T002-SPRAS = DD07T-DDLANGUAGE, resolves the language key to a readable language description when reporting on translation coverage
  • DD07T-DOMNAME + DOMVALUE_L = DD07L-DOMNAME + DOMVALUE_L, the underlying join that pairs a value with its text, usually handled by the dictionary APIs rather than written by hand

How to read it safely

DD07T has no client field, it is cross-client dictionary data, same content in every client of the system. Selectivity comes from DOMNAME and DDLANGUAGE together; querying by DOMNAME alone across all languages returns duplicates that look like inconsistent data but are just the translated variants. Restrict to a single language before comparing texts, and remember that the logon language of whoever reported the issue is the one that matters, not English. Do not query this table directly in application logic; use the dictionary text lookup function modules or the domain value help APIs, because direct table reads bypass buffer handling and fallback language logic that the standard dictionary access already provides.

How to prove it in the data

Symptom: a dropdown on a custom screen shows the technical code instead of a description for users in a specific language. Select DD07T where DOMNAME equals the domain assigned to the field (found via DD03L) and DDLANGUAGE equals the user's logon language. If no row comes back, the text was never translated into that language, confirming the gap. If a row exists but DDTEXT is blank, the value was added to DD07L without ever entering a text, which is a data entry gap in domain maintenance, not a program bug.

ECC vs S/4HANA

DD07T is unchanged in S/4HANA. Domains and their fixed values remain a core ABAP Dictionary concept and this table continues to carry the translated texts exactly as in ECC. There is no compatibility view replacing it because it is dictionary metadata, not application master data, and dictionary metadata tables were not part of the S/4HANA simplification of finance and logistics tables.

Common pitfalls

  • Treating a missing dropdown text as an application bug when it is a missing translation row in DD07T for that language, fixable in domain maintenance rather than in code
  • Assuming DD07T holds the valid value list; it only holds the text, DD07L holds the actual values and DD07T rows with no matching DD07L entry are orphaned leftovers from a value that was later removed from the domain
  • Comparing DD07T rows across languages and calling it inconsistent master data, when it is simply partial translation coverage, which is normal and does not indicate corruption
  • Editing DD07T directly through a table maintenance transaction instead of through domain maintenance, which can desynchronize VALPOS numbering from DD07L and break the F4 help silently
  • Forgetting that fixed values and their texts are dictionary objects transported with the domain; a fixed value added in a sandbox and tested there will not appear in dropdowns downstream until the domain change is transported end to end
  • Assuming a blank DDTEXT will fall back cleanly to the original language text in every custom program; that fallback is provided by the standard dictionary access routines, not automatically by a raw select against DD07T

Whose problem this is

This is an ABAP development question, not a functional configuration question. Domain and fixed value maintenance belongs to whoever owns the data element or domain in the development team, usually the technical lead on a custom development object or the SAP Basis or development team for standard SAP domains, since standard domain texts should never be modified directly.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tables/dd07tERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.