![]() The first one looks quadratic too, but bukrs, belnr, gjahr are almost the complete primary key of bseg, so for every line of it_bkpf there not many lines found by the SELECTs. The first is faster because it is just linearly bad ASSIGNING FIELD-SYMBOL(), so you don't need the MODIFY anymore, this will also slightly improve the performance. Instead of using internal tables with HEADER LINES, you have to LOOP. To have the best performance for the single line read, itab has to be TYPE HASHED (or at least TYPE SORTED with the proper key). COLLECT is not supported for TYPE STANDARD tables (this is clearly stated in the SAPHelp), the internal table has to be TYPE HASHED (there are technical reasons behind, I am not going into details).Īfter that you LOOP one internal table (itab2) and READ TABLE the other (itab). However the real issue is here: COLLECT itab2. However your WHERE condition uses offset, so I am not sure, if the SORTED table will help, but it is worth a try. If you do a LOOP with WHERE condition, you get the best performance if the internal table is TYPE SORTED (with proper key). You can also check table BSET (looks like you are interested in "tax" lines) As far as I see from the coding, you select G/L items, so you can check if using BSIS/BSAS would be better (instead of BSEG). JOIN (BSEG is cluster table in ECC so no JOIN possible, but transparent table in S4/HANA, so you can JOIN it with BKPF). There are several performance issues here: If you need more information on the terms, syntaxes, and so on, you'll find them in the ABAP documentation (inline or web). Note that I propose a (non-unique) secondary index, not a primary one, because as you don't want to change (too much) the 1st part, this will avoid potential issues that you might have with a primary index. MODIFY itab FROM itab USING KEY by_doc_key TRANSPORTING budat If you want to update the BUDAT component later, not in the 1st part, then store the document key + BUDAT in a distinct internal table (say itab_budat), and define a non-unique secondary index on itab with the document key fields (say by_doc_key), and you'll only need this straight forward code : LOOP AT itab_budat ASSIGNING. The only thing to do is to first store the lines of BSEG in a temporary itab_temp, to contain only the lines of one document at a time, so that you loop only at these lines, and then add them to itab. Now, if you accept to adapt a few little things in the 1st part, right after reading the lines of BSEG of every document, then you may simply loop at these lines, no need of an index or binary search or hash table, and that's done. So, you shouldn't group ("collect") by document number only, or you risk to mix documents of distinct companies or years. Not related to the performance but on the data model: the key of a financial document is made of 3 fields, company (BUKRS), document number (BELNR) and year (GJAHR).you should measure the performance of your code with transaction SAT, and you will see on which operation the time is spent.If these concepts are unclear, I recommend the ABAP documentation: Row-Based Administration Costs of Internal Tables and Internal Tables - Performance Notes ![]() Essentially, as you want to optimize only the 2nd part, the only issues seem to be with itab operations (loop, read, modify), that you may improve by using an index or a or a hash table on the internal table itab. I guess all people gave you all the hints to optimize your code. Now I am running in the background for 1,5 millions records and it continues after 1 hour. ![]() Read table itab with key belnr = gwa_belnr_sums-belnr Lv_5per_total = con_5per_tax * gwa_belnr_sums-dmbtr. ![]() Loop at git_belnr_sums into gwa_belnr_sums. Move-corresponding itab to gwa_belnr_sums.Ĭollect gwa_belnr_sums into git_belnr_sums. So the declaration of the tables was: DATA : BEGIN OF itab OCCURS 0,Īfter your suggestion I made the following changes: types: begin of ty_belnr_sums,ĭata: git_belnr_sums type sorted table of ty_belnr_sums In the 2nd loop I compare the sum per belnr with the amount of the belnr/account and do what the code says.ġst of all the initial code existed and I added the new one. In the 2nd part in the 1st loop I summ the amounts per belnr for the accounts that start with 73. Modify itab transporting budat where belnr = itab2-belnr.ĭoes anyone have an idea on how to fix the 2nd part?Īfter the 1st process ITAB has 1,5 million records. If itab-dmbtr between lv_5per_lower and lv_5per_upper. Read table itab with key belnr = itab2-belnr Lv_5per_total = con_5per_tax * itab2-dmbtr. The 2nd part which is doing 13,5 hours is the following: sort itab by belnr. Select * from bseg into corresponding fields of itab Both of them process 1,5 million records, but the first part is taking 20 minutes and the 2nd part is taking 13,5 hours!!!!!! ![]()
0 Comments
Leave a Reply. |