Skip to main content

Chapter 1: User Input and Screen Logic

Welcome to the PDC project tutorial! We're starting at the very beginning: the first screen a user sees. Think of it as the friendly receptionist for our program. Its job is to greet the user and gather all the necessary information before the real work begins.

The Problem: A Cluttered Desk​

Imagine you have a single paper form for two different tasks: processing a customer payment and a vendor payment. For customers, you need their "Customer ID," but for vendors, you need a "Vendor ID." If you put both fields on the same form, it gets messy. Users might get confused and fill in the wrong one.

Our goal is to create a "smart form" that adapts to the user's needs. If they say they're working with a customer, we'll only show them the customer-related fields. If they choose a vendor, the screen will magically switch to show only the vendor fields. This is what we call User Input and Screen Logic.

Building Our Smart Form​

In the world of ABAP (the programming language for SAP), this initial form is called a "Selection Screen." Let's see how we build ours.

Step 1: Defining the Choices​

First, we need to give the user a way to tell us what they want to do. The perfect tool for an "either/or" choice is a set of radio buttons.

We define two radio buttons, one for "Customer" and one for "Vendor," in the ZRE_FI_NOTED_ITEMS_POST_DECL.abap file.

* File: ZRE_FI_NOTED_ITEMS_POST_DECL.abap

PARAMETERS: rb_c RADIOBUTTON GROUP rb1 DEFAULT 'X' USER-COMMAND rb.
SELECTION-SCREEN COMMENT (10) TEXT-r01 FOR FIELD rb_c. " 'Customer'
PARAMETERS: rb_v RADIOBUTTON GROUP rb1.
SELECTION-SCREEN COMMENT (10) TEXT-r02 FOR FIELD rb_v. " 'Vendor'
  • PARAMETERS: rb_c RADIOBUTTON GROUP rb1 creates a radio button named rb_c. The GROUP rb1 part is important—it links rb_c and rb_v together, ensuring only one can be selected at a time.
  • DEFAULT 'X' makes the "Customer" option selected by default when the program starts.

Step 2: Creating the Fields and Giving Them a "Group Name"​

Next, we define the input fields for the Customer Number and Vendor Number. The magic trick here is giving each field a special identifier called a MODIF ID. Think of this as a group name. We'll put the customer field in the "cus" group and the vendor field in the "ven" group.

* File: ZRE_FI_NOTED_ITEMS_POST_DECL.abap

SELECT-OPTIONS: s_kunnr FOR kna1-kunnr MODIF ID cus,
                s_lifnr FOR lfa1-lifnr MODIF ID ven.
  • SELECT-OPTIONS creates input fields that can accept single values or ranges of values (like customers 100 to 200).
  • MODIF ID cus assigns the "Customer No." field (s_kunnr) to the group named cus.
  • MODIF ID ven assigns the "Vendor No." field (s_lifnr) to the group named ven.

Now our screen has all the pieces, but it doesn't know how to be "smart" yet. It will still show both fields at the same time.

Step 3: Adding the "Brain" to the Screen​

To make the screen dynamic, we need to add logic that runs just before the screen is shown to the user. ABAP has a special event for this called AT SELECTION-SCREEN OUTPUT.

Inside this event, we'll write code to loop through every single element on the screen and decide whether to show it or hide it.

This logic lives in our main program file, ZRE_FI_NOTED_ITEMS_POSTING.abap.

* File: ZRE_FI_NOTED_ITEMS_POSTING.abap

AT SELECTION-SCREEN OUTPUT.

  LOOP AT SCREEN.
    " This code loops through every item on the screen
    " (buttons, fields, labels, etc.)
  ENDLOOP.

This LOOP AT SCREEN is like an inspector checking every item on an assembly line. For each item, we can check its properties and change them.

The Customer Logic​

Inside the loop, we first check if an item belongs to our "cus" group. If it does, we then check if the "Customer" radio button is ticked.

* File: ZRE_FI_NOTED_ITEMS_POSTING.abap

    IF screen-group1 = 'CUS'.      " Is this part of the 'Customer' group?
      IF rb_c = abap_true.          " Is the Customer radio button checked?
        screen-active    = 1.       " Yes: Make it visible and editable.
        screen-invisible = 0.
      ELSE.                         " No:
        screen-active    = 0.       " Make it inactive and hidden.
        screen-invisible = 1.
      ENDIF.
      MODIFY SCREEN.                " Apply the changes!
      CONTINUE.                     " Move to the next screen item.
    ENDIF.
  • screen-group1 = 'CUS' is where we use the MODIF ID we set up earlier.
  • rb_c = abap_true checks if the "Customer" radio button is selected. (abap_true is just a clean way of saying 'X' or "on").
  • MODIFY SCREEN is the crucial command that tells the system to apply our changes.

The Vendor Logic​

We do the exact same thing for the "ven" group, but this time we check if the "Vendor" radio button is selected.

* File: ZRE_FI_NOTED_ITEMS_POSTING.abap

    IF screen-group1 = 'VEN'.      " Is this part of the 'Vendor' group?
      IF rb_v = abap_true.          " Is the Vendor radio button checked?
        screen-active    = 1.       " Yes: Make it visible and editable.
        screen-invisible = 0.
      ELSE.                         " No:
        screen-active    = 0.       " Make it inactive and hidden.
        screen-invisible = 1.
      ENDIF.
      MODIFY SCREEN.                " Apply the changes!
    ENDIF.

With this logic in place, our form is now smart!

  • When you click "Customer": The code runs, sees rb_c is true, shows the customer field (s_kunnr), and hides the vendor field (s_lifnr).
  • When you click "Vendor": The code runs, sees rb_v is true, shows the vendor field (s_lifnr), and hides the customer field (s_kunnr).

Under the Hood: How It All Connects​

Let's visualize the sequence of events when a user interacts with our screen.

From Input to Action​

Once the user has filled out the form and clicks the "Execute" button, we need to do two things:

  1. Validate the Input: Make sure the user didn't forget any required information. We use the AT SELECTION-SCREEN event for this. It runs after the user clicks "Execute" but before the main logic starts.

    * File: ZRE_FI_NOTED_ITEMS_POSTING.abap

    AT SELECTION-SCREEN.
      IF  sy-ucomm = 'ONLI'. " The 'Execute' button was clicked
        IF p_bukrs IS INITIAL OR s_duedt IS INITIAL.
          MESSAGE e100(zfi) WITH 'Input Comp.Code and Due Date fields'.
        ENDIF.
      ENDIF.

    This code checks that the "Company Code" and "Due Date" fields have been filled. If not, it shows an error message and stops.

  2. Start the Main Process: If all validations pass, the START-OF-SELECTION event is triggered. This is the official starting point of our program's main job. Here, we'll gather all the user's inputs and hand them over to the next part of our application, the PDC Processing Orchestrator.

    * File: ZRE_FI_NOTED_ITEMS_POSTING.abap

    START-OF-SELECTION.
      CREATE OBJECT go_data. " Prepare the orchestrator

      IF rb_c IS NOT INITIAL.
        go_data->gv_flag = 'C'.    " Tell the orchestrator we are doing 'Customer' work
      ELSE.
        go_data->gv_flag = 'V'.    " Tell the orchestrator we are doing 'Vendor' work
      ENDIF.

      go_data->main( ). " Start the main process

    Notice the gv_flag. This simple variable ('C' or 'V') carries the user's choice forward, ensuring the rest of the program knows exactly what kind of data to look for.

Conclusion​

Congratulations! You've just learned how to build a clean, intelligent, and user-friendly interface for an ABAP program. We saw how to:

  • Use radio buttons for exclusive choices.
  • Group screen fields using MODIF ID.
  • Write dynamic logic in AT SELECTION-SCREEN OUTPUT to show and hide fields.
  • Validate user input before starting the main process.

This smart "receptionist" ensures we collect the right information every time, setting the stage for a smooth and error-free operation.

Now that we have the user's criteria, our next step is to find the relevant financial data and present it in a clear, organized table. Let's move on to the next chapter and build our Interactive ALV Report.