Skip to main content

Chapter 1: User Selection Criteria

Welcome to the tutorial for our VAT Report project! We're going to build a powerful tool to analyze financial data, and we'll start with the very first thing a user interacts with: the selection screen.

Imagine you want to order a pizza. You don't just call the shop and say "send me pizza." You specify the size, the toppings, and the crust. You give them criteria to make the exact pizza you want.

Our VAT report works the same way. An accountant might not want to see all tax data from the beginning of time. They might only need data for a specific Company Code in the last Fiscal Year. The User Selection Criteria screen is our report's "order form." It lets the user specify exactly what they're looking for.

This chapter will show you how this "order form" is defined and how the user's choices are passed along to the rest of the program to fetch the correct data.

Packaging the User's Request​

When a user fills out the selection screen (e.g., enters '1710' for Company Code and '2023' for Fiscal Year) and clicks "Execute," the program needs to capture these values. In ABAP, these inputs are often stored in special variables called SELECT-OPTIONS. For our report, they might be named so_bukrs (for Company Code) and so_gjahr (for Fiscal Year).

But we can't just hand these variables directly to our powerful HANA database. We need to package them into a standardized format that the database query understands. Think of it like putting your pizza order onto an official ticket that the kitchen staff can read.

To do this, we use a helper class called cl_shdb_seltab. Its job is to combine all our user's filters into a neat package.

Let's look at how we package the criteria for one of our data sources, the BSET table (a standard SAP table for tax data).

DATA(ex_bset) = cl_shdb_seltab=>combine_seltabs(
  it_named_seltabs = VALUE #(
    ( name = 'BUKRS' dref = REF #( so_bukrs[] ) )
    ( name = 'GJAHR' dref = REF #( so_gjahr[] ) )
  )
).

This might look complex, but it's quite simple when you break it down:

  • cl_shdb_seltab=>combine_seltabs: This is us calling our "packaging" helper.
  • name = 'BUKRS': This is the technical field name for 'Company Code' in the database table.
  • dref = REF #( so_bukrs[] ): This links the database field name (BUKRS) to the program variable (so_bukrs) that holds the user's input.

The result, ex_bset, is now a perfectly formatted "order ticket" that tells the database: "Get me records where the Company Code is what the user entered AND the Fiscal Year is what the user entered."

Under the Hood: The Journey of a Request​

Let's trace the journey from the user's click to the packaged request.

  1. A user enters their desired filters on the selection screen.
  2. The program stores these values in SELECT-OPTIONS variables (so_bukrs, so_gjahr, etc.).
  3. The program calls the cl_shdb_seltab helper to package these variables into a standardized format.
  4. This "package" is now ready to be sent off to the database.

Here is a diagram illustrating this flow:

Preparing the Final Order​

In our report, we actually need to get data from two main sources (BSET and ACDOCA), so we prepare two separate "order tickets."

The code below, found in the get_amdp_data form, shows how we prepare these packages and then send them off to be processed.

First, we create the package for the BSET table, including a few more filters:

DATA(ex_bset) = cl_shdb_seltab=>combine_seltabs(
  it_named_seltabs = VALUE #(
    ( name = 'BUKRS' dref = REF #( so_bukrs[] ) )
    ( name = 'GJAHR' dref = REF #( so_gjahr[] ) )
    ( name = 'BELNR' dref = REF #( so_belnr[] ) )
    ( name = 'MWSKZ' dref = REF #( so_mwskz[] ) ) )
).

Next, we create a similar package for the ACDOCA table (the main financial journal in S/4HANA):

DATA(ex_acdoca) = cl_shdb_seltab=>combine_seltabs(
  it_named_seltabs = VALUE #(
    ( name = 'RBUKRS' dref = REF #( so_bukrs[] ) )
    ( name = 'GJAHR'  dref = REF #( so_gjahr[] ) )
    "... more filters
).

With our two neatly packaged requests (ex_bset and ex_acdoca), we are finally ready to ask the database for the data. We pass these packages to our data retrieval engine.

" Create an object that will fetch data from the database
DATA(lv_amdp) = NEW zcl_amdb_fico_tax( ).

" Send our packaged requests to the data fetcher
lv_amdp->get_data(
  EXPORTING
    im_qbset   = ex_bset
    im_qacdoca = ex_acdoca
  IMPORTING
    ex_final    = gt_final
    ...
).

The get_data method is where the magic happens. It takes our selection criteria and uses them to perform the actual query. This powerful technique is the subject of a future chapter, HANA Database Data Retrieval (AMDP).

Conclusion​

In this chapter, we learned about the most important starting point of any report: the user selection screen. We saw how it acts as a "control panel," allowing users to request exactly the data they need. We learned how the program captures these requests, packages them into a standardized format using cl_shdb_seltab, and prepares them to be sent to the database.

This ability to filter data is what makes our report flexible and truly useful.

Now that we know how to ask for the data, what do we do when we get it back? In the next chapter, we'll explore how to present the retrieved data to the user in a clean and interactive grid.

Next: Chapter 2: ALV Grid Presentation

Generated by AI Codebase Knowledge Builder