Chapter 3: Report Data Model

In the previous chapter, we saw how our program takes a final data table called gt_sfinal and uses the ALV framework to present it as a beautiful, interactive grid. This raises a fundamental question: what exactly is gt_sfinal? And how does the program know what "shape" the data should have?

Before you build a house, you need a blueprint. Before a factory assembles a car, it has a detailed schematic. In programming, we also need blueprints for our data. These blueprints are called data structures or data models. They define the exact shape of our information, ensuring every part of the program knows what to expect.

This chapter is all about these data blueprints. We'll explore how they're defined and why we need different blueprints for different stages of our report.

The Two Blueprints: Raw vs. Finished

Imagine you're building a wooden chair. You start with raw materials: planks of wood, screws, and a can of varnish. This is your initial set of items. After you cut, assemble, and finish the chair, you have a completely new object. It's still made from the original materials, but it's now in a more useful, enriched form.

Our report program works in a very similar way. It uses two main blueprints:

1. The "Raw Materials" Blueprint (ty_final): This blueprint defines the structure of the data as it's first fetched from the database. It's a direct, no-frills collection of fields.
2. The "Finished Product" Blueprint (ty_sfinal): This is the blueprint for the final data that gets shown to the user. It contains all the raw fields plus new, enriched fields (like names and descriptions) that make the report more meaningful.

Let's see how these are defined in our program.

Defining the Blueprints in Code

In ABAP, we use the TYPES keyword to create our data blueprints. These definitions are typically stored in the main program file, in a section dedicated to data declarations.

Here is a simplified look at our "raw materials" blueprint, ty_final:

* Blueprint for the raw data fetched from the database
TYPES:
  BEGIN OF ty_final,
    bukrs TYPE bukrs,      " Company Code (e.g., '1710')
    belnr TYPE belnr_d,    " Document Number
    hwste TYPE hwste,      " Tax Amount in local currency
    * ... plus many other raw fields
  END OF ty_final.

This code tells the program: "I'm defining a structure named ty_final. Anything of this type will have a field for bukrs, a field for belnr, and so on." It's a simple container for the data we get from the database.

Now, let's look at the "finished product" blueprint, ty_sfinal:

* Blueprint for the final, enriched data ready for display
TYPES:
  BEGIN OF ty_sfinal,
    bukrs  TYPE bukrs,        " Company Code (e.g., '1710')
    butxt  TYPE butxt,        " Company Code Name (ENRICHED!)
    belnr  TYPE belnr_d,      " Document Number
    hwste  TYPE hwste,        " Tax Amount in local currency
    lifnr  TYPE lifnr,        " Vendor Number (ENRICHED!)
    namel  TYPE name1_v,      " Vendor Name (ENRICHED!)
    * ... plus all the other fields
  END OF ty_sfinal.

Notice the difference? ty_sfinal has extra fields like butxt (Company Code Name) and namel (Vendor Name). This information doesn't exist in the initial data pull; it's added later in a process we call enrichment.

Creating the Actual Data Tables

Once our blueprints (TYPES) are defined, we can create the actual "containers" (internal tables) that will hold our data. We do this using the DATA keyword.

DATA:
  " A table to hold the raw data, based on the ty_final blueprint
  gt_final TYPE STANDARD TABLE OF ty_final,

  " A table to hold the final display data, based on the ty_sfinal blueprint
  gt_sfinal TYPE STANDARD TABLE OF ty_sfinal.

Now the program has two empty tables: gt_final, which is shaped to hold the raw data, and gt_sfinal, which is shaped to hold the final, polished data for the ALV grid.

The Assembly Line: From Raw to Finished

The heart of the program is the "assembly line" that transforms the raw data into the finished product. This happens after the initial data is fetched from the database and placed into the gt_final table.

The program then loops through each raw record in gt_final, performs some lookups to find the extra information (like names and descriptions), and builds a new, enriched record that it places in the gt_sfinal table.

This transformation logic is a key part of the Data Transformation and Enrichment step. Here’s a simplified view of what that process looks like in the get_amdp_data subroutine:

* Loop through each row of raw data
LOOP AT gt_final INTO DATA(gs_final).

  " Step 1: Copy the raw fields to the 'finished product' structure
  gs_sfinal-bukrs = gs_final-bukrs.
  gs_sfinal-belnr = gs_final-belnr.
  gs_sfinal-hwste = gs_final-hwste.

  " Step 2: Enrich the data by looking up additional details
  " (The real code looks up vendor names, descriptions, etc.)
  gs_sfinal-butxt = 'My Company Name'. " Add the Company Name
  gs_sfinal-namel = 'My Vendor Name'.   " Add the Vendor Name

  " Step 3: Add the newly assembled, finished row to the final table
  APPEND gs_sfinal TO gt_sfinal.

ENDLOOP.

After this loop finishes, our gt_sfinal table is full of clean, enriched data, perfectly structured and ready for the ALV Grid Presentation.

Visualizing the Data Flow

This diagram shows the journey of our data, flowing from the database through our different data models.

Conclusion

In this chapter, we learned about the critical concept of the Report Data Model. We saw that data needs a defined "shape" or "blueprint" to ensure it's handled consistently throughout the program.

Key takeaways:

• Blueprints are essential: We use TYPES in ABAP to define data structures.
• Different stages need different blueprints: We use a simpler model (ty_final) for raw data from the database and a more detailed, enriched model (ty_sfinal) for the final presentation.
• Transformation is key: The program converts data from the raw model to the finished model by adding valuable information, making the report more useful.

We now understand how the user provides input, how the final grid is displayed, and how the data itself is structured. But how does the program manage all these steps in the correct order? The next chapter will explore the "master conductor" of our report.

Next: Chapter 4: VAT Report Orchestration

---

Generated by AI Codebase Knowledge Builder