topic Re: Is this loop cond correct? in Application Development and Automation Discussions

Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 18:50:12 GMT

Hi Experts,

itab1 has from & to dates & itab2 has only budat.

I had written a loop as below:

loop at itab2 where budat ge itab1-from_date

and budat le itab1-to_date.

.......

.....

endloop.

when a valid date comes between from date & to_date, the loop is returing sy-subrc as 4. Seems something wrong in my loop condition.

can soemone correct this for me if so?

Thanks

Dany

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 18:56:44 GMT

How have you populated itab1-from_date and itab1-to_date?

Rob

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 18:56:50 GMT

Dan,

Do like this

Loop at itab2 into wa2.
 if wa2-budat GE itab1-from_date and wa2-budat LE itab1-to_date.
* Do process
 endif. 
endloop.

Regards,

Satish

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 18:58:39 GMT

the loop condition seems to be fine. Not sure why you are getting sy-subrc 4. Do you have some sample data with you?

Cheers

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:13:37 GMT

Hi,

Suppose, the budat in itab2 has values '20070827' and the

itab1-from_date = 20070810

itab1-to_date = 20070910.

Here the itab2-budat definitely lies in between from & to dates but after the above loop cond is processed sy-subrc turns to be 4.

please suggest

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:17:58 GMT

You're going to have to post your code if you really want help.

Rob

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:21:11 GMT

i think the loop should work definitely. Could you post the code as Rob has suggested.

Cheers

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:28:51 GMT

Hi Rob & Vijy,

The itab2 is getting popluated using an FM: FKK_READ_LAST_PAYMENTS

itab2 resembles a strcuture called FKKPAID which is as below:

BUDAT BUDAT_KK DATS 8 Posting date in doc

CPUDT CPUDT DATS 8 0 Accounting document

CPUTM CPUTM TIMS 6 0 Time of entry

OPBEL OPBEL_KK CHAR 12 Contract Account doc no

WAERS WAERS CUKY 5 0 Currency Key

BETRW BETZU_KK CURR 13 2 payment amount

BETZG BETZG_KK CURR 13 2 Total amount of payment

*********Code**********

loop at itab1.

i_tabix = sy-tabix.

loop at payments where budat gt yt_usage-from_date

and budat le yt_usage-to_date.

end of change - GANTIH

if sy-subrc = 0.

itab1-PAY_DATE = itab2-BUDAT.

itab1-PAY_AMOUNT = itab2-BETRW.

itab1-PAY_AMOUNT = itab2--BETZG.

itab1-pay_opbel = itab2-opbel.

MODIFY itab1 INDEX I_TABIX.

ENDIF.

endloop.

Thanks

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:36:57 GMT

As I see it from your code, you are not using itab1 dates but "yt_usage" dates. So where is the link between itab1 and itab2?

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:38:52 GMT

Oh! in order to simplify the terminology i used itab1 & itba2.

i mean : itab1 -->yt_usage

itab2 --> payments

Sorry for the inconvenience. Pls suggest

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:39:22 GMT

It makes no sense to test sy-subrc in the loop like this. It retains whatever value it had prior to entering it:

LOOP AT itab1.
  i_tabix = sy-tabix.
  LOOP AT payments
    WHERE budat GT yt_usage-from_date
      AND budat LE yt_usage-to_date.
* end of change - GANTIH
    itab1-pay_date = itab2-budat.

* itab1-PAY_AMOUNT = itab2-BETRW.
    itab1-pay_amount = itab2--betzg.
    itab1-pay_opbel = itab2-opbel.
    MODIFY itab1 INDEX i_tabix.

  ENDLOOP.
ENDLOOP

You should get rid of the nested loops as well.

Rob

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:43:14 GMT

Hi Rob

You mean sy-subrc cannot be used? please explain.

i dont think i can use "Read" here instead of loop at ..where...can you suggest an alternative?

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:44:16 GMT

Since you are updating "itab1" with the posting date based on the condition that the posting date should lie between the start and end dates, do the following.

LOOP AT itab1.

LOOP AT itab2 WHERE budat GE itab1-from_date AND budat LE itab1-to_date.

EXIT.

ENDLOOP.

IF sy-subrc = 0.

itab1-PAY_DATE = itab2-BUDAT.

itab1-PAY_AMOUNT = itab2-BETRW.

itab1-PAY_AMOUNT = itab2--BETZG.

itab1-pay_opbel = itab2-opbel.

MODIFY itab1.

ENDIF.

ENDLOOP.

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:45:31 GMT

Hi Dan,

The SY-SUBRC value will not change for each pass of the loop.

As rob mentioned it only has the last value before entering the loop.

Cheers

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:45:54 GMT

Once you are in the inner loop, you know that you already have matches on both tables.

To use READs instead of nested LOOPs, please see:

<a href="/people/rob.burbank/blog/2006/02/07/performance-of-nested-loops">The Performance of Nested Loops</a>

Rob

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:46:02 GMT

Rob - Can i use clear before checking before if sy-subrc = 0 so that the previous values are cleared from the header area?

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:48:34 GMT

Rob - No, There need not be any matching entries for both the tables

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:49:05 GMT

Not all ABAP statements set sy-subrc. The code I posted should work.

Rob

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:50:33 GMT

You may not ahve matching entries for both tables, but if you are in the inner loop, you must have a match.

Rob

Re: Is this loop cond correct?

Former Member — Mon, 10 Dec 2007 19:50:38 GMT

Once you enter the LOOP, it means a record is found and so SY-SUBRC will always be 0 inside the LOOP. Since you are updating only one record of itab1, even if there are several records of itab2 that may satisfy the criteria of posting date between from and to dates, you can simply exit the loop as I suggested previously.