ABAP_to_the_Future

15
ABAP Programming for SAP HANA
The first time the program runs, all such items are sent to the government, and
the variable GD_LASTEXTRACT is updated to the date those items were sent to the
government so that they don’t get sent again. However, what if some new items
are added later? They need to be sent as well. Therefore, the program reads the
entry date of the cleared item ( CPUDT), and if the entry date is later than the last
extract, then the new record needs to be sent to the government and the latest
extract date updated accord ingly. The ABAP code to perform this logic on the
records retrieved from the database is shown in Listing 15.18.
if not gt_output[] is initial.
LOOP AT gt_output.
IF gt_output-cpudt GE gd_woff_date AND
"Cleared item created after customer went bad and
gt_output-cpudt GT gd_lastextract.
"Cleared item created after last extract
"Extract the record
CONTINUE.
ELSEIF gt_output-cpudt LT gd_woff_date AND
"Cleared item created before customer went bad and
gt_output-cpudt GT gd_lastextract AND
"Cleared item created after last extract
gt_output-augdt GE gd_woff_date.
"The item has a clearing date after the customer went bad
"Extract the record
CONTINUE.
ELSE.
"Do not extract the record
DELETE gt_output.
ENDIF.
ENDLOOP.”Cleared Items
if gt_output[] is not initial.
gd_baddebt_flag = 'X'.
perform populate_openitems.
endif.
endif.
endloop. "Dead Customers
Listing 15.18 Removing Bad Debt Records from a Table on the Application Server
You will notice in Listing 15.18 that ever y single record that could possibly be
sent to the government is retrieved fr om the database, and then some business
logic is done to remove the ones that are not required. This breaks one of the SQL
golden rules—namely, minimize the amount of data sent from the database to the
application server. Getting records you do n’t want is like ordering 10 elephants
686