ABAP Dynpro Flow Logic: The FIELD Statement for Data Transport and Module Calls

Important preliminary note: The FIELD statement is not a command in normal procedural or object-oriented ABAP code (such as in a REPORT, a CLASS or a FUNCTION MODULE). Instead, FIELD is a keyword used exclusively in the flow logic of Dynpros (screens) created with the Screen Painter (Transaction SE51).

The FIELD statement in Dynpro flow logic has the following main purposes:

1. Control of data transport (PAI): In the PROCESS AFTER INPUT (PAI) event block, FIELD specifies when the content of a specific field on the screen is transported to the corresponding, identically-named global variable in the ABAP program.
2. Conditional call of modules (PAI): Also in the PAI block, FIELD controls when specific ABAP modules (MODULE ... ON INPUT or MODULE ... ON REQUEST) are called for field validation or processing.
3. Binding field help (POV, POH): In the PROCESS ON VALUE-REQUEST (POV) and PROCESS ON HELP-REQUEST (POH) event blocks, FIELD links a screen field with an ABAP module that provides F4 (value help) or F1 (field help) functionality.

Distinction from FIELD-SYMBOLS

Please don’t confuse: The FIELD statement in Dynpro flow logic has nothing to do with FIELD-SYMBOLS in ABAP code. FIELD-SYMBOLS are placeholders or pointers to memory areas in the ABAP program. The FIELD statement always refers to a specific input/output field on a screen mask.

Context

• Where: Flow logic of a Dynpro (Screen Painter, SE51)
• When: Mainly in the PROCESS AFTER INPUT (PAI) block, but also in PROCESS ON VALUE-REQUEST (POV) for F4 help and PROCESS ON HELP-REQUEST (POH) for F1 help.

Syntax and Behavior

1. In PROCESS AFTER INPUT (PAI)

Syntax:

PROCESS AFTER INPUT.
  ...
  FIELD <screen_field_name>.
  MODULE <pai_module_name> [ON INPUT | ON REQUEST].
  ...
  " Or with CHAIN for group validations:
  CHAIN.
    FIELD <field1>.
    FIELD <field2>.
    MODULE <module_for_field2> ON INPUT. " Module only for field 2
  ENDCHAIN.
  MODULE <module_for_chain> [ON CHAIN-INPUT | ON CHAIN-REQUEST]. " Module for the chain
  ...

How It Works

• Data transport: When PAI processing reaches the line FIELD <screen_field_name>., the content of this field is only transported from the screen to the identically-named global variable in the ABAP program if the user has changed the value since the last screen send (PBO).
• Module call: A directly following MODULE <pai_module_name> ON INPUT. or MODULE <pai_module_name> ON REQUEST. is only executed if the field content was transported (i.e., changed by the user).
  • ON INPUT: Call if field was ready for input and was changed.
  • ON REQUEST: Call only if field was changed AND the user triggered an action that explicitly requests PAI (e.g., Enter, Save - not just Tab).
• Order: The sequence of FIELD statements determines in what order fields are potentially transported and their modules called.
• CHAIN ... ENDCHAIN: Groups multiple FIELD statements together. A MODULE ... ON CHAIN-INPUT or ON CHAIN-REQUEST is called when at least one field within the CHAIN was changed. This is useful for validations that depend on multiple fields and for common error handling (with MESSAGE E... inside the chain, all fields in the chain remain ready for input).

2. In PROCESS ON VALUE-REQUEST (POV) for F4 Help

• Syntax:

PROCESS ON VALUE-REQUEST.
  FIELD <screen_field_name> MODULE <f4_module_name>.

How It Works: When the user positions the cursor on <screen_field_name> and presses F4, the ABAP module <f4_module_name> is called. This module is responsible for displaying the value help (e.g., by calling function modules like F4IF_INT_TABLE_VALUE_REQUEST).

3. In PROCESS ON HELP-REQUEST (POH) for F1 Help

Syntax:

PROCESS ON HELP-REQUEST.
  FIELD <screen_field_name> MODULE <f1_module_name>.

How It Works: When the user positions the cursor on <screen_field_name> and presses F1, the ABAP module <f1_module_name> is called. This module can then display context-sensitive help information (e.g., by calling HELP_OBJECT_SHOW).

Examples (Conceptual)

1. Simple PAI Validation

*&---------------------------------------------------------------------*
*& Dynpro 0100 Flow Logic
*&---------------------------------------------------------------------*
PROCESS AFTER INPUT.
*-- Read field CUSTOMER_NUMBER from screen (if changed) and validate
  FIELD CUSTOMER_NUMBER.
  MODULE VALIDATE_CUSTOMER ON INPUT.

*&---------------------------------------------------------------------*
*& Module VALIDATE_CUSTOMER INPUT
*&---------------------------------------------------------------------*
MODULE VALIDATE_CUSTOMER INPUT.
* Global variable CUSTOMER_NUMBER was filled if user made input
  IF CUSTOMER_NUMBER IS INITIAL.
    MESSAGE E001(ZMSG) WITH 'Enter customer number!'.
  ELSE.
    SELECT SINGLE KUNNR FROM KNA1 INTO CUSTOMER_NUMBER WHERE KUNNR = CUSTOMER_NUMBER.
    IF SY-SUBRC <> 0.
       MESSAGE E002(ZMSG) WITH 'Customer number does not exist'.
    ENDIF.
  ENDIF.
ENDMODULE.

2. PAI with CHAIN

PROCESS AFTER INPUT.
  CHAIN.
    FIELD FLIGHT_DATE_FROM.
    FIELD FLIGHT_DATE_TO.
    MODULE CHECK_DATE_RANGE ON CHAIN-INPUT.
  ENDCHAIN.

MODULE CHECK_DATE_RANGE INPUT.
* FLIGHT_DATE_FROM and FLIGHT_DATE_TO were filled if one was changed
  IF FLIGHT_DATE_TO < FLIGHT_DATE_FROM.
    MESSAGE E003(ZMSG) WITH 'Date To must be after Date From'.
  ENDIF.
ENDMODULE.

3. Bind F4 Help (POV)

PROCESS ON VALUE-REQUEST.
  FIELD CARRID MODULE F4_FOR_CARRID.

MODULE F4_FOR_CARRID INPUT.
* Here code to call value help for airlines (table SCARR)
* e.g., with F4IF_INT_TABLE_VALUE_REQUEST or F4IF_FIELD_VALUE_REQUEST
ENDMODULE.

Important Notes

• The FIELD statement is fundamental for controlling classic Dynpro programming.
• Understanding it is essential for working with module pool programs and classic SAP applications.
• In modern UI technologies like Web Dynpro ABAP or SAP Fiori (with SAPUI5), there is no Dynpro flow logic and therefore no FIELD statement in this form. There, data exchange and validation are implemented via other concepts like data binding and event handling.