Skip to main content

Chapter 2: Interactive ALV Report

In the previous chapter, we built a smart "receptionist"—a screen that cleverly adapts to the user's needs to gather the right information. Now that our program knows what to look for (e.g., noted items for a specific customer due in the next month), its next job is to find that data and present it to the user.

The Problem: A Lifeless Data Dump​

Imagine our program finds 50 relevant financial items and just prints them out as a plain, static list. What if the user only wants to process 10 of them? How can they select them? What if they want to sort the list by amount? A static list is like a printed report—you can look at it, but you can't do anything with it.

We need something much better. We need a workspace that's alive, responsive, and powerful. We need an Interactive ALV Report.

The Solution: A Built-in Spreadsheet​

Think of an ALV (ABAP List Viewer) as a powerful spreadsheet, like Excel, built directly into our application. It's not just a table; it's a dynamic grid where the user can:

  • Select specific rows using checkboxes.
  • Sort and filter data on the fly.
  • Click buttons like "Post" to trigger actions on the selected items.
  • Click links within the data to drill down into more details.

Our goal is to transform the raw data into this interactive workspace. The main method responsible for this magic is display_alv.

Part 1: Building the Grid​

Before we can show our data, we need to give the ALV a blueprint. We can't just hand it a pile of numbers and text; we have to describe what each column should look like. This blueprint is called a Field Catalog.

Step 1: Designing the Columns (The Field Catalog)​

The field catalog is a list of instructions, one for each column. For each column, we specify things like:

  • fieldname: Which piece of data goes here?
  • coltext: What is the column header text (e.g., "Customer Name")?
  • checkbox: Should this column be a checkbox? ('X' for yes).
  • hotspot: Should the data in this column be a clickable link? ('X' for yes).

Let's see how we define the instructions for a single column—the checkbox for selecting rows. This happens in the build_field_catalog method inside our main class.

* Inside method BUILD_FIELD_CATALOG

" 1. Define the 'Select' checkbox column
ls_fcat-fieldname = 'SEL'.       " Data field is named 'SEL'
ls_fcat-coltext   = 'Select'.    " Header text is 'Select'
ls_fcat-checkbox  = abap_true.   " This IS a checkbox column
ls_fcat-edit      = abap_true.   " Allow the user to edit it (check/uncheck)
APPEND ls_fcat TO rt_fcat.       " Add this definition to our list
  • ls_fcat is a temporary variable that holds the definition for one column.
  • We set its properties one by one and then APPEND it to our final list of column definitions, rt_fcat. We repeat this process for every column we want to display.

Step 2: Displaying the Grid​

Once our field catalog blueprint is ready and we have our data, displaying the ALV is a single, powerful command. We call the method SET_TABLE_FOR_FIRST_DISPLAY.

This method takes our data and our blueprint and paints the interactive grid on the user's screen.

* Inside method DISPLAY_ALV

go_alv->set_table_for_first_display(
  EXPORTING
    is_layout             = ls_layout  " Overall grid settings (e.g., title)
    it_toolbar_excluding  = lt_exclude " Buttons to hide
  CHANGING
    it_outtab             = <gt_fcat>  " The actual data to display
    it_fieldcatalog       = gt_fcat    " Our column blueprint
).
  • it_outtab: This is the table containing the financial data we fetched.
  • it_fieldcatalog: This is the blueprint we just built, telling the ALV how to structure the data.
  • The result is a fully functional grid on the screen, ready for the user.

Part 2: Making the Grid Respond to Clicks​

Displaying the grid is great, but its real power comes from handling user actions. Our ALV needs "ears" to listen for when a user clicks the "Post" button or a document link. These "ears" are special methods called event handlers.

Handling Button Clicks: on_user_command​

When the user clicks a custom button on the ALV toolbar (like our "Post" button), the ALV triggers an event. Our program catches this event using the on_user_command method.

This method receives a special code (e_ucomm) that tells it exactly which button was pressed.

* Inside method ON_USER_COMMAND

CASE e_ucomm.
  WHEN 'POST'. " Was the 'POST' button clicked?
    " If yes, start the posting process.
    me->post_pdc_docs( ).

  WHEN OTHERS.
    " Handle other standard ALV buttons (like sorting).
ENDCASE.
  • e_ucomm contains the function code of the button. We gave our button the code 'POST'.
  • The CASE statement is like a receptionist's switchboard. It checks the code and directs the program to the correct logic—in this case, calling the post_pdc_docs method to begin processing the selected items.

Similarly, if we defined a column as a "hotspot" (a link), clicking on any cell in that column triggers a different event. We catch this one with the on_link_click method. This is perfect for letting users view a financial document that has already been created.

* Inside method ON_LINK_CLICK

" Read the data from the specific row the user clicked on.
READ TABLE gt_final INTO ls_final INDEX e_row_id-index.

" Call a standard function to display the document details.
CALL FUNCTION 'FI_DOCUMENT_DISPLAY'
  EXPORTING
    i_bukrs = ls_final-bukrs " Company Code from the clicked row
    i_belnr = ls_final-belnr " Document Number from the clicked row
    i_gjahr = ls_final-gjahr. " Fiscal Year from the clicked row

This method receives information about exactly which row and column were clicked (e_row_id), allowing us to fetch the correct data and take a specific action, like showing the full document details.

Under the Hood: The Event Flow​

Let's trace what happens when a user selects a few rows and clicks our "Post" button.

The ALV grid itself doesn't know what to do when "Post" is clicked. It only knows that its job is to notify our program. Our event handler methods (on_user_command, on_link_click) contain the intelligence to interpret those notifications and trigger the correct business logic.

Conclusion​

You've now learned how to bridge the gap between raw data and a user-friendly, interactive workspace. We've transformed a simple data list into a powerful tool using the ALV framework.

We covered how to:

  • Define the structure of our grid using a Field Catalog.
  • Display the data using the set_table_for_first_display method.
  • Listen for and react to button clicks with the on_user_command event handler.
  • Respond to clicks on data links using the on_link_click event handler.

The user can now view the data, select the items they want to process, and click "Post". But what happens next? How does the program take that list of selected items and actually create financial documents? That's the job of our central coordinator. Let's dive into the next chapter: the PDC Processing Orchestrator.