The PARAMETERS Statement in ABAP: Syntax, Options & Examples

Category
ABAP-Statements
Published
Author
Johannes

The PARAMETERS statement is an ABAP keyword that you use exclusively in the declaration part of executable programs (REPORT), function groups, or module pools. Its purpose is to define a single input field on the standard selection screen (Dynpro 1000) of the program.

Through this field, the user can enter exactly one value, which is then available in the program as a global variable with the same name as the parameter.

Important distinction from SELECT-OPTIONS:

  • PARAMETERS: For entering a single value (e.g., a customer number, a date, a plant). Creates a variable.
  • SELECT-OPTIONS: For complex selections (e.g., a range of customer numbers, multiple individual materials, exclusion of certain values). Internally creates a table (ranges table).

Syntax

PARAMETERS <param_name> { {TYPE <data_type> [LENGTH <length>] [DECIMALS <decimal_places>]} | {LIKE <data_object>} }
[DEFAULT <default_value>]
[OBLIGATORY]
[LOWER CASE]
[AS CHECKBOX [USER-COMMAND <function_code>]]
[RADIOBUTTON GROUP <group_name> [USER-COMMAND <function_code>]]
[MEMORY ID <pid>]
[NO-DISPLAY]
[VISIBLE LENGTH <visible_length>]
[MODIF ID <modification_group>]
[VALUE-REQUEST] " For custom F4 help
[HELP-REQUEST]. " For custom F1 help
" Older / Rarer additions like MATCHCODE OBJECT, AS SEARCHPATTERN etc.

Components

  • <param_name>: The name of the parameter. A global variable is created in the program under this name, and (if not NO-DISPLAY) an input field is generated on the selection screen.
  • TYPE <data_type> ... or LIKE <data_object>: (Mandatory) Defines the data type of the parameter and the associated variable.
    • TYPE: Preferred! Can be a built-in ABAP type (I, D, STRING, C, P…), a data element from the ABAP Dictionary (kunnr, matnr, werks_d…), or a local type. When referencing Dictionary types, input checks, F1 and F4 help are often automatically provided.
    • LIKE: Older syntax, refers to an already declared data object. Should be replaced by TYPE.
  • DEFAULT <default_value>: (Optional) Specifies a value to pre-fill the input field on the selection screen.
  • OBLIGATORY: (Optional) Makes the field a mandatory field. The user must enter a value before they can execute the program.
  • LOWER CASE: (Optional) Allows entering lowercase letters and prevents automatic conversion to uppercase (default behavior for many data types).
  • AS CHECKBOX: (Optional) Displays the parameter as a checkbox. The variable <param_name> should then be TYPE c LENGTH 1 ('X' = checked, ' ' = unchecked).
  • RADIOBUTTON GROUP <group_name>: (Optional) Displays the parameter as a radio button. All parameters with the same <group_name> form a group where only one option can be selected. Requires at least two radio buttons per group. <param_name> often TYPE c LENGTH 1.
  • MEMORY ID <pid>: (Optional) Links the parameter with a SAP Memory ID. The field is pre-filled with the value from SAP Memory (GET PARAMETER), if available.
  • NO-DISPLAY: (Optional) The variable <param_name> is declared, but no input field is displayed on the selection screen. Useful for “hidden” parameters that are passed via variants or SUBMIT ... WITH ....
  • VISIBLE LENGTH <visible_length>: (Optional) Controls the visible width of the input field on the screen (can be shorter than the actual field length).
  • MODIF ID <modification_group>: (Optional) Assigns the parameter to a modification group. This allows dynamic manipulation of the field (e.g., hiding, disabling) in the AT SELECTION-SCREEN OUTPUT event.

How It Works

  1. The program reads the declarations at startup.
  2. For each PARAMETERS command, a global variable is created.
  3. The system automatically generates the standard selection screen (Dynpro 1000) with the corresponding input fields (except with NO-DISPLAY).
  4. The user enters values in the fields and executes the program (F8).
  5. After processing the selection screen, the entered (or default) values are available in the global variables (<param_name>) and can be used in the further program flow (e.g., from START-OF-SELECTION).

Examples

REPORT z_parameter_demo.
" --- Declaration part ---
TABLES: spfli. " For Dictionary reference
" Simple parameter with Dictionary typing
PARAMETERS p_carrid TYPE spfli-carrid.
" Mandatory date parameter with default value (today)
PARAMETERS p_date TYPE d OBLIGATORY DEFAULT sy-datum.
" Checkbox for test run
PARAMETERS p_test AS CHECKBOX.
" Radio buttons for output mode
PARAMETERS: p_list RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND radio,
p_grid RADIOBUTTON GROUP mode.
" Parameter that is not displayed
PARAMETERS p_intern TYPE i NO-DISPLAY.
" Parameter that allows lowercase
PARAMETERS p_text TYPE c LENGTH 40 LOWER CASE.
" --- Processing logic ---
START-OF-SELECTION.
WRITE: / 'Airline:', p_carrid.
WRITE: / 'Date:', p_date.
IF p_test = 'X'.
WRITE: / 'Test run is active.'.
ELSE.
WRITE: / 'Production run.'.
ENDIF.
IF p_list = 'X'.
WRITE: / 'List output selected.'.
ELSE.
WRITE: / 'Grid output selected.'.
ENDIF.
WRITE: / 'Entered text:', p_text.
" p_intern could be used here if it was filled e.g. via SUBMIT.

Best Practices

  • PARAMETERS always belongs in the declaration part of a program.
  • Use the TYPE addition with reference to data elements or table fields from the ABAP Dictionary (SE11). This automatically gives you the correct data type, length, F1 help, F4 value help, and possibly input checks.
  • Use PARAMETERS for simple inputs where the user should only provide a single value. For more complex selections (ranges, multiple values, exclusions), SELECT-OPTIONS is intended.
  • Make fields with OBLIGATORY mandatory when input is essential for the program logic.
  • Use AS CHECKBOX and RADIOBUTTON GROUP for simple yes/no decisions or exclusive selection options.