Automatically from a Dictionary Structure/Table

• The easiest way — ALV can build the field catalog from the DDIC (Data Dictionary).
• You just pass the internal table reference.
• ALV uses the metadata (field labels, data type, length) from DDIC.

Example:

CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
i_structure_name = 'SFLIGHT' " Dictionary structure/table
CHANGING
ct_fieldcat = gt_fieldcat. " Internal table for field catalog

Using Field Symbols at Runtime (Dynamic Field Catalog)

• Useful when you don’t know the structure at design time.
• You build the field catalog dynamically using field symbols and assign properties programmatically.

Example:

DATA: gt_fieldcat TYPE lvc_t_fcat,
gs_fieldcat TYPE lvc_s_fcat.

LOOP AT gt_dyn_fields ASSIGNING FIELD-SYMBOL(<fs_field>).
CLEAR gs_fieldcat.
gs_fieldcat-fieldname = <fs_field>-fieldname.
gs_fieldcat-coltext = <fs_field>-description.
APPEND gs_fieldcat TO gt_fieldcat.
ENDLOOP.

Useful for generic ALV reports where table structure is not known until runtime.

Using Class Method CL_GUI_ALV_GRID->SET_TABLE_FOR_FIRST_DISPLAY

In OO ALV, if you don’t pass a field catalog, the system can generate it automatically from the internal table’s line type.

CALL METHOD gr_alvgrid->set_table_for_first_display
EXPORTING
i_structure_name = ‘SFLIGHT’
CHANGING
it_outtab = gt_sflight
it_fieldcatalog = gt_fieldcat.

Note:

• If i_structure_name is given → system generates field cataloge.
• If not given → you can pass your own gt_fieldcat.

Using CL_SALV_TABLE (SALV Model)

• In SALV (Simple ALV), field catalog creation is implicit.
• You don’t create it manually — SALV builds it automatically from the internal table.

DATA: gr_table TYPE REF TO cl_salv_table.

cl_salv_table=>factory(
IMPORTING r_salv_table = gr_table
CHANGING t_table = gt_sflight ).

gr_table->display( ).

Note: SALV is simpler but less flexible than full OO ALV.

In real projects, most developers use REUSE_ALV_FIELDCATALOG_MERGE (for standard reports) or manual field catalog (for custom reports).