1, the following paragraph, I don't know what your specific purpose is, but judging from its location, it should be problematic: because when L_GIT-VALSTK_CATG is not within the scope of GT_VALSTK_CATG_RNG, a lot of work done before will be wasted, so can we consider moving this judgment forward?
If L _ GIT _ VALSTK _ CATG is in GT_VALSTK_CATG_RNG.
Collect L_GIT into DT_GIT.
Otherwise.
Clear L_GIT.
ENDIF。
2. There should be something wrong with the program logic. You want to find the location index of the purchase order number first, and then cycle ekbe from this line, but you use method of bisection, which can speed up the search theoretically, but there should be bugs. For example, if the sequence number of five pieces of data is A B B B C, then you use method of bisection to find the location of the item with the number B, and the index should be 3 instead of the expected 2 (only from method of bisection's logical analysis, this needs to be verified.
3. It is also a point that I personally think is more important:
Because the data of EKKO may not have corresponding data in EKBE, there will be an empty cycle of EKKO, and at the same time, 18 times will be searched in EKBE (LOG(300000) = 18), and the search for18 times will be fruitless; On the other hand, one piece of data may correspond to multiple pieces of data in the EKBE, that is to say, even if the location index is found correctly, it still needs to cycle 300,000 pieces of EKBE, and it will cycle many times, which will inevitably affect the speed.
Suggestion: loop EKBE in the first layer, and record the EBELN in the previous line of EKBE. If the current line EBELN is equal to the previous line EBELN, there is no need to re-read EKKO; if not, it is read from EKKO once, and any EBELN in EKBE has a unique record in EKKO, so it is not necessary to recycle EKKO. The result is that EKBE only needs to cycle once, and EKKO only needs to read.