DD03L table — DD03L Table Field Catalog

One row in DD03L represents one field belonging to one table, structure, or view in the ABAP Dictionary, as delivered or as activated in the system. It records where that field sits in the structure (its position), whether it forms part of the primary key, which data element it is typed against, which domain governs its value range, and its technical length and data type. It exists purely to describe the shape of dictionary objects, not to hold any business content. When someone asks what fields a table has, what the key is, or which data element a field points to, DD03L is the authoritative source, and it is exactly what transaction SE11 displays on the Fields tab and what SE16 uses to render the selection screen and the field list of any table.

The most common join is from DD03L back to the table's own header record and forward to the human-readable text of the data element each field is typed against.

DD03L is cross-client, delivered once per system landscape rather than per client, so there is no client field to restrict on. The table is large because every active table and structure in the system contributes its full field list, so an unrestricted select is expensive and pointless. Always restrict on TABNAME first; that alone typically returns a handful of rows. Restricting on FIELDNAME alone across the whole table is a common mistake because the same field name (MATNR, BUKRS, WERKS) recurs in thousands of tables, and the result set is not what anyone actually wants. If searching by data element instead of table, restrict on ROLLNAME and expect many matches, since one data element is reused across many tables by design.

To confirm which fields make up a table's key, select DD03L where TABNAME equals the table name and KEYFLAG equals 'X', ordered by POSITION. This returns the exact key sequence used for buffering, sorting, and unique access, which is often different from the order fields appear on a screen. To confirm what data element a suspicious field is typed against, select DD03L for that TABNAME and FIELDNAME and read ROLLNAME, then look that value up in the data element's own metadata for the domain and value range.

DD03L continues to exist and function the same way on S/4HANA; it is core ABAP Dictionary infrastructure and is not tied to any particular application module that got restructured or replaced. What changed around it, not in it, is the volume and shape of business tables it now describes, since several classic tables were replaced by compatibility views over transparent database tables in S/4HANA. DD03L faithfully reflects whatever structure is currently active, whether that structure is a classic table or a CDS-based replacement, so it remains the correct place to check field-level metadata regardless of release.

Questions about what a field means or which data element governs it belong to whoever owns the ABAP Dictionary object, typically the development or data model lead for that functional area, not the functional consultant configuring the module. Disputes about a missing or unexpected field almost always trace back to a transport that has or has not been imported, which is a basis or change management question, not a DD03L data question.

DD02L is the table header DD03L rows belong to, and DD04T supplies the readable text for each field's data element. TADIR registers the table itself as a repository object with its package and original system, which matters when tracing where a field definition actually came from. Field and table structure changes are made and transported through SE11 and captured in the standard transport request tables, not written directly by any business transaction.