REUSE_ALV_FIELDCATALOG_MERGE — Building an ALV field catalog from a DDIC structure
REUSE_ALV_FIELDCATALOG_MERGE builds an ALV field catalog table by reading the DDIC metadata of an internal table or structure and merging it with any field catalog entries already supplied. It is part of the classic reuse ALV function group, released for customer use, and typically called before REUSE_ALV_GRID_DISPLAY or REUSE_ALV_LIST_DISPLAY so the developer does not have to build every column entry by hand.
This page covers what REUSE_ALV_FIELDCATALOG_MERGE actually populates versus what it leaves for the developer to set manually, the two exceptions it raises and what silently ignoring them does to the downstream ALV call, and the practical mistakes that produce an empty or malformed field catalog. It also addresses where this function module sits relative to modern ALV approaches on S/4HANA.
Published 16 Sept 2026· 1,079 words
What it does
REUSE_ALV_FIELDCATALOG_MERGE reads the ABAP Dictionary metadata of a named internal table or structure and generates a field catalog entry for every component, filling in field name, data element short/medium/long texts, data type, length, and reference table/field for value help and F4. If a field catalog is already passed in via the changing parameter, its entries are merged rather than overwritten, so manual settings such as column position, output length override, or key flag survive the call. It is part of the reuse ALV function group and is released for customer use, which is why it appears in a large share of custom classic ALV reports as the standard way to avoid hand-building a field catalog entry by entry.
Parameters
- I_PROGRAM_NAME (importing, required) - the calling program name, normally sy-repid, used to resolve local type and include definitions
- I_INTERNAL_TABNAME (importing) - name, as a character string, of the internal table whose row type should be read; this is the most commonly used input
- I_STRUCTURE_NAME (importing) - name of a DDIC structure to use instead of an internal table when there is no working table available at the point of the call
- I_INCLNAME (importing) - the include or program name where a locally defined type used by the internal table is declared; needed when the table type is not a pure DDIC structure
- I_CLIENT_NEVER_DISPLAY (importing, optional) - flag to suppress a client/mandt field from the generated catalog so it never appears as a column
- CT_FIELDCAT (changing, required) - table of field catalog structure entries; passed in possibly pre-populated and returned merged with the DDIC-derived entries
Exceptions
- INCONSISTENT_INTERFACE - the combination of import parameters does not let the function module resolve a structure; typically neither I_INTERNAL_TABNAME nor I_STRUCTURE_NAME point to anything the ABAP runtime can find, or the two are mutually contradictory. If this is caught and ignored, CT_FIELDCAT comes back unchanged, and the field catalog handed to REUSE_ALV_GRID_DISPLAY may be empty, producing either a blank grid or a dump deep inside the ALV framework that is much harder to trace back to the real cause
- PROGRAM_ERROR - the named table, structure, or include could not be found or read, usually because the name passed in I_INTERNAL_TABNAME is misspelled, refers to a table that only exists as a local variable name and not a resolvable type, or I_INCLNAME was omitted when it was required. Swallowing this exception with a blanket OTHERS produces the same silent empty-catalog symptom as above, with no indication in the short dump of which parameter was wrong
How to call it safely
Declare a field catalog table of the classic ALV field catalog line type, call the function module with I_PROGRAM_NAME set to sy-repid and I_INTERNAL_TABNAME set to the character-string name of the working internal table, and pass I_INCLNAME when the table's row type is defined locally rather than as a DDIC structure. Trap both exceptions explicitly rather than using a bare OTHERS, and after the call check that CT_FIELDCAT is not empty and that the field count matches the number of components in the source structure before passing it into REUSE_ALV_GRID_DISPLAY. Any column-level customization - hidden fields, currency or quantity reference fields, sort key, or a fixed column sequence - must be applied to CT_FIELDCAT after this call, since the merge only fills in what DDIC already knows.
ECC vs S/4HANA
REUSE_ALV_FIELDCATALOG_MERGE is part of the classic ALV function group and continues to work unchanged on S/4HANA; it has not been withdrawn. It is not, however, the direction SAP points new development toward: object-oriented ALV via CL_SALV_TABLE builds its own field catalog automatically from the internal table type and is the preferred approach for new reports, and Fiori list reports or RAP-based UIs replace ALV entirely for new user-facing development. Under clean-core guidance this function module is acceptable in existing custom reports but is not the recommended starting point for new on-stack or side-by-side extensions.
Common pitfalls
- Passing the internal table name as a variable reference instead of a literal character string in I_INTERNAL_TABNAME; the parameter expects the name as text, and a typo or wrong case causes PROGRAM_ERROR that is easy to miss if exceptions are not checked
- Omitting I_INCLNAME when the internal table's line type is declared in a local TYPES statement rather than a DDIC structure; the function module cannot resolve the type and returns an empty catalog without an obvious runtime error
- Using OTHERS = 0 or ignoring sy-subrc after the call, which lets an empty or partial field catalog reach REUSE_ALV_GRID_DISPLAY, where the resulting dump or blank output gives no clue that the actual failure happened earlier
- Assuming the merge sets display attributes such as column width, currency/quantity reference field, or sort order; it only derives what the DDIC data element already carries, so reports that need custom headings or hidden technical fields still require a manual loop over CT_FIELDCAT after the call
- Calling the function module a second time on the same CT_FIELDCAT expecting it to reset previous manual changes; because it merges rather than replaces, stale manual edits from an earlier call can persist unexpectedly
Whose problem this is
This is squarely an ABAP development concern. Whoever owns the custom report or program that calls it is responsible for correct parameters and for handling both exceptions. There is no functional-module or Basis configuration involved; a functional consultant seeing an empty or malformed ALV column list should route the issue straight back to the report's developer rather than looking for a customizing cause.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/reuse-alv-fieldcatalog-mergeERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.