Skip to Content

2 Listbox dependent and other fields are mandatory in modulepool

I have created a screen in which there are 2 list box and some input/output fields.

Listbox 2 value will come from listbox 1 value selection and other fields are mandatory.

I am able to populate the values in listbox 2 by triggering Function code in Listbox 1 value selection. But if I am making other remaining fields as mandatory then Listbox2 values are not coming and Automatic field check getting triggered.

If I am making input/output fields as mandatory then I am not able populate values in Listbox2 and if I am populating values in Listbox2 using event of Listbox1 then I have make other remaining fields as non mandatory.

I want both listbox values and other fields as mandatory.


problem.png (179.8 kB)
Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    Jul 07, 2017 at 09:25 AM

    Thanks everyone,

    I solved it by
    Chain ..... Endchain and check the code at the time of saving.

    This If condition of sy-ucomm works for me.

     module check_filled.
      IF SY-UCOMM = 'FC_OK'.
    Add comment
    10|10000 characters needed characters exceeded

  • Jul 07, 2017 at 06:58 AM


    When you have an interactive screen in the same way that you have then the use of mandatory fields interrupts the flow of the users work because whenever you get a PAI you get the various error messages. Because of this, I never use mandatory fields any more but rather do all the checking myself. This can be made considerably easier by defining a macro just to check whether a field is initial or not which you then put in your PAI processing and ONLY check when the user goes online (ie sy-ucomm = ONLI) or has pressed another button specific to your program that will result in the program processing.

    Because of this I have developed a set of macros that are used specifically for screens which handle things like the placement of objects ( check boxes to the right or left), status icons on screens, description fields that automatically update so on and so forth. You will find that you will keep having to code stuff that is similar over and over again in screen handling so why not start building yourself a library of useful macros for report screens.

    For example,

    Begin_Of_Nested_SubScreen 3000 1.
          Begin_Of_Block TRA.
                Parameter_With_Listbox: 1 20 Text-TW1 Wash  Tw_File_Type    TRA WASH.
                Standard_Par:           1 20 Text-TW2 StDat Tw_Start_Date   TRA BU_DATE_CHAR,
                                        1 20 Text-TW3 StZet Tw_Start_Time   TRA SRM_F4_UZEIT,
                                        1 20 Text-TW4 FiDat Tw_Finish_Date  TRA BU_DATE_CHAR,
                                        1 20 Text-TW5 FiZet Tw_Finish_Time  TRA SRM_F4_UZEIT.
                Parameter_With_Listbox: 1 20 Text-TW6 PType Tw_Program_Type TRA PTYPE.
                Input_Line:             RF1 Tw_Rdr RfId_Reader d_Tw_Rdr     TRA,
                                        Tw7 TagId  Tw_Rfid_Tag d_TagId      TRA.
                      Selection-Screen Comment 1(20) Text-Tw8 For Field p_Temp Modif Id TRA.
                      Parameters: p_Temp Type Tw_Wash_Temp                     Modif Id TRA.
                      Selection-Screen Comment 30(20) Text-Tw9 For Field p_UoM Modif Id TRA.
                      Parameters: p_UoM  Type Tw_Wash_UoM                      Matchcode Object OUMT
                                                                               Modif Id TRA.
                Input_Line:             TWA ErCde Tw_Error_Code d_ErCde        TRA.
                Begin_Of_Block TIA.
                      Select-Options s_Inact For g_Inactive Modif Id TRA.
                End_Of_Block TIA.
          End_Of_Block TRA.
    End_Of_SubScreen 3000.

    This defines a subscreen on a report parameter screen with blocks, standard parameters with description fields for the values, list boxes etc etc.

    At Selection-Screen On p_IntNme.
          If p_IntNme Is Initial.
             Message E053.

    The code above shows the validation of one of the parameters. And this is what i am talking about - only do your checks when the user is about to go online (If you are wondering about the phrase 'Go Online' and why that particular ok code is ONLI then go back to SAP's roots on the IBM Mainframes....)

    The macro IF_ONLINE is as follows:

    Define If_OnLine.
              If SSCRFields-UComm = 'ONLI'
                 or SSCRFields-UComm = 'PRIN'
                    Or SSCRFields-UComm = 'SJOB'.

    So this only carries out any validation when the user is requesting the report and not when they are filling in the screen and moving from field to field.

    As an example of one of the input screen macros would be:

    Define Parameter_With_ListBox.
                 Selection-Screen Comment &1(&2) &3 For Field p_&4 Modif Id &6.
                 Parameters p_&4 Type &5                           As ListBox Visible Length 30
                                                                   User-Command &7
                                                                   Modif Id &6.
                 Selection-Screen Comment 70(30) d_&4 For Field p_&4 Modif Id &6.
    Add comment
    10|10000 characters needed characters exceeded

    • In a module pool you have the FIELDS command which causes a field transport. This applies to a single field and if you look at the ABAP Help (place cursor on a command and press F1) you will see all of this. So in your PAI for a single field you would use something like:

      Field gs_Display-Reason
            Module Check_Skip_Reason_0100.
      Module Exit_Command_0100 At Exit-Command.
      Module User_Command_0100.

      This transports field Reason and then for that field if an error is displayed that field will be coloured yellow and ready for input whilst all other fields would be grey.

      The other Modules are called if teh user command is flagged as an exit command, or is called regardless.

      If you have a series of fields that you require to be all available for input you would use a CHAIN statement:

            Fields: gs_Display-Reason,
            Module Check_Skip_Reason_0100.
      Module Exit_Command_0100 At Exit-Command.
      Module User_Command_0100.

      This would then make the fields listed between Chain and EndChain available for input if an error is displayed.

      However, you can also only call these things under specific circumstances using an extention to the Module statement. Again, these are described in the documentation:

      Module Check_Skip_reason_0100 On Input 
                                    On Request 
                                    On *-Input 
                                    On Chain-Input
                                    On Chain-Request

      The main difference is that On Input calls the module when there is input in the field and On-Request calls the module when there is changed input in the field. Obviously CHAIN- is used inside a chain block.

      These modules that are mentioned are defined in a module pool.

      Although you can have other statements inside a module, SAP strongly recommends that only a perform statement is used:

      *&      Module  CHECK_SKIP_REASON_0100  INPUT
      *       text    If the OK code is the skip button then this field must
      *               be populated.
      Module CHECK_SKIP_REASON_0100 Input.
             Perform Check_Skip_Reason Using gs_Display-Ok_Code

      Also Note that I am passing the global fields as parameters to the routine rather than accessing them directly in the routine.

      In the routine you would then check the OK code, and if it is one of the online codes mentioned above you would then test for initial (if the field is mandatory) and then any other errors with the field otherwise, issuing the relevant E type error message.

  • Jul 06, 2017 at 08:56 PM

    Dynpros have some limits. You reached one. You must find a compromise. All mandatory fields must be entered before function codes can be processed, so you must wait before defining the values of the second listbox. Or you can make your own mandatory checks in full ABAP and keep the dynpro fields optional.

    Add comment
    10|10000 characters needed characters exceeded

    • I tried to validate at the time of saving in PAI but if I am giving error then fields are greying out and if I am not giving error then data get saved.

      Please suggest how can I check at ABAP level, where can I code for that (fields are filled) validation.


  • Jul 07, 2017 at 02:07 AM


    Any user defined function code will be taken as an input and hence it will trigger PAI. And it will check the mandatory fields. The better thing you can do is make the mandatory fields as 'recomended' i.e. screen-required = 2. So the mandatory mark will be shown for the field. At the final execution check for those fields to be filled.



    Add comment
    10|10000 characters needed characters exceeded

    • But if you use chain endchain, once after you enter the mandatory field, it will auto fill the list box 2. When an error or warning is triggered, you cannot get the field values which are processed after PAI.

      I know this is not an effective idea, but sharing my thought on this!

      If you want to do both at same time, i.e. informing user as the field is mandatory and auto filling the listbox, you make the message as information message, but show it as an error to the user. So that he can fill all the remaining fields. But make sure it's filled before your final execution(here it's F_SAVE)

        MODULE status_0500.
       FIELD v_rdtype MODULE auto_fill_fd ON REQUEST.
          FIELD v_vbukr.
          FIELD v_proj.
          MODULE validate.
        MODULE user_command_0500.
      MODULE status_0500 OUTPUT.
      *  SET TITLEBAR 'xxx'.
          IF screen-name = 'V_VBUKR'.
            screen-required = '2'.
            MODIFY SCREEN.
        IF v_flag = 'X'.
      ENDMODULE.                 " STATUS_0500  OUTPUT
      *&      Module  USER_COMMAND_0500  INPUT
      *       text
      MODULE user_command_0500 INPUT.
        IF sy-ucomm = 'F_SAVE'.
          IF v_vbukr IS INITIAL.
            MESSAGE 'ENTER C.CODE' TYPE 'E'.
            MESSAGE 'SAVED' TYPE 'S'.
      ENDMODULE.                 " USER_COMMAND_0500  INPUT
      *&      Module  AUTO_FILL_FD  INPUT
      *       text
      MODULE auto_fill_fd INPUT.
        ok_code = sy-ucomm.
        IF ok_code = 'F_CODE'.
          IF NOT v_rdtype IS INITIAL.
            CASE v_rdtype.
              WHEN 'C'.
                v_fdtype = 'SFCPCI'.
              WHEN 'D'.
                v_fdtype = 'SFCPDE'.
              WHEN 'M'.
                v_fdtype = 'SFCPTA'.
      ENDMODULE.                 " AUTO_FILL_FD  INPUT
      *&      Module  VALIDATE  INPUT
      *       text
      MODULE validate INPUT.
        CLEAR v_flag.
        IF v_vbukr IS INITIAL.
          v_flag = 'X'.