Chapter 4: Noted Item Data Retrieval

In the previous chapter, we met the "general manager" of our application—the PDC Processing Orchestrator. We saw how it gives commands, like telling a specialist to "go get the data." But how does that specialist actually find the right information in a database that contains millions of records?

The Problem: Finding a Needle in a Haystack

Imagine the SAP database is a gigantic warehouse, filled with billions of financial records. Our user has given us a very specific request: "Find all post-dated cheques from customer 12345 that are due next Tuesday."

If our program just wanders into the warehouse and starts looking at every single record, it would take forever and probably fail. We need a specialist—a data scout—who knows exactly where to look and how to use a map to find only the items that match the user's request, quickly and efficiently. This is the job of Noted Item Data Retrieval.

The Solution: Our Expert Data Scout (get_bseg_data)

Our expert data scout is a method called get_bseg_data. It lives inside our orchestrator class and has one single, focused mission: take the user's criteria, query the database, and return with a list of matching "noted items."

This method is the bridge between the user's request on the screen and the raw data stored in the system.

Step 1: Receiving the "Search Orders"

The first thing our scout does is receive its orders from the orchestrator. These orders are simply the values the user entered on the selection screen.

* Inside the Orchestrator class ZCL_BSEG_DATA_PROCESSOR

METHOD get_bseg_data.
  " The method receives the user's search criteria, like:
  " - gv_bukrs (Company Code)
  " - gr_kunnr (Customer Number(s))
  " - gr_duedt (Due Date range)
  " - gv_flag ('C' for Customer or 'V' for Vendor)
  " ... and so on.
ENDMETHOD.

The orchestrator has already stored all the user's inputs (like company code and due dates) in variables. The get_bseg_data method has access to all of them.

Step 2: Building the Precise Database Query

Now for the most important part. The scout uses these orders to write a very precise query to the database. In ABAP, this is done with a SELECT statement. Think of it as filling out a highly specific order form for the warehouse.

* Inside method GET_BSEG_DATA

" Based on whether we are looking for a Customer or Vendor...
IF gv_flag = 'C'. " Is it a Customer?
  SELECT *
    FROM zcds_bseg_bkpf " The 'map' to our data
    WHERE bukrs = @gv_bukrs AND kunnr IN @gr_kunnr
    INTO TABLE @et_cust1.
ENDIF.

Let's break down this simple "order form":

• SELECT *: This means "get me all the information for the records you find."
• FROM zcds_bseg_bkpf: This is the crucial part. We aren't searching the entire warehouse. We're searching in a special, pre-organized section called zcds_bseg_bkpf. This is a "CDS View," which we'll explore below.
• WHERE...: This is where we give our specific criteria. "Only give me records WHERE the company code (bukrs) is the one the user gave me AND the customer number (kunnr) is in the list the user provided."
• INTO TABLE @et_cust1: "Put all the records you find into this empty box (internal table) named et_cust1 and bring it back to me."

This query is executed directly on the database, which is incredibly fast. It returns only the handful of records that match, not the millions that don't.

Under the Hood: The Magic of CDS Views

You might be wondering what zcds_bseg_bkpf is. It's a Core Data Services (CDS) View.

Think of it this way: In SAP, financial document information is often split across multiple tables. The header information (like date and document type) is in one table (BKPF), while the line item details (like amounts and customer/vendor numbers) are in another (BSEG).

A CDS View is like a pair of magic glasses. When you look at the database through these glasses, you don't see two separate, confusing tables. Instead, you see a single, neat table where the related information is already joined together for you.

Our zcds_bseg_bkpf view is pre-built to link document headers and items, making our scout's job much easier. It doesn't have to waste time matching records between tables; the view has already done it.

Let's see how this works in a diagram.

By using the CDS view, our query is simpler to write and much faster to run. It's a modern and efficient way to fetch data in SAP.

Handling Both Customers and Vendors

Our data scout is also smart. It knows how to adjust its search based on whether the user is looking for Customer or Vendor items. The orchestrator tells it which one by setting the gv_flag.

The get_bseg_data method contains a simple IF/ELSE block to handle this.

* Inside method GET_BSEG_DATA

IF gv_flag = 'C'. " Customer search
  SELECT * FROM zcds_bseg_bkpf
    WHERE bukrs = @gv_bukrs AND kunnr IN @gr_kunnr
    INTO TABLE @et_cust1.
ELSE. " Vendor search
  SELECT * FROM zcds_bseg_bkpf
    WHERE bukrs = @gv_bukrs AND lifnr IN @gr_lifnr
    INTO TABLE @et_cust1.
ENDIF.

Notice the only real difference is in the WHERE clause.

• For customers, it filters on the customer number field (kunnr).
• For vendors, it filters on the vendor number field (lifnr).

The result, a clean list of noted items, is placed in the et_cust1 table regardless, which is then passed back to the orchestrator to be displayed.

Conclusion

You've just seen how our application performs its most fundamental task: finding the right data. We've learned that our "data scout," the get_bseg_data method, is a highly efficient specialist.

• It receives clear instructions (selection criteria) from the orchestrator.
• It writes a precise SELECT query to avoid searching irrelevant data.
• It uses a powerful tool, a CDS View, which acts like a pre-organized map to the database, making the search simple and fast.
• It intelligently adapts its query based on whether the user is searching for customers or vendors.

The scout has now returned with the requested data. The orchestrator has displayed it in the ALV grid, and the user has selected which items to process and clicked "Post." Now, the real action begins. How does our program take this data and create a brand new, official financial document in SAP? Let's move on to the next chapter and explore the Financial Document Posting Engine.