Performance Issues on BSID and BSAD

Question

Hello guys,
for a custom report I need the balance data of a couple of vendors for different keydates. Therefor I tried to use function 'BAPI_AR_ACC_GETKEYDATEBALANCE' which works fine but takes a lot of performance time when getting data for more than one vendor or more than one key date. The function mainly reads BSID and BSAD tables which is enough for my report, so I tried to get it faster with creating my own select.
When looking at the popular SAP boards you get different opinions about the best way for the performance in SELECTS. So can you please tell me what you think would be the best way for tables BSID and BSAD?
I got the key fields company code as parameter and customer as range. I also need only normal documents (BSTAT = ' ') and only documents until one or more keydates as range (BUDAT <= keydate).
So what would be the best way?
(1) Moving the whole BSID/BSAD fields into local BSID/BSAD table or just the fields that I need (see example)?
(2) Doing one SELECT for every vendor no. in the range or getting all vendor no in one select?
Any other performance hints? :-)
   SELECT bukrs kunnr budat shkzg dmbtr pswsl pswbt FROM bsid
     INTO CORRESPONDING FIELDS OF TABLE gt_bsid
     WHERE bukrs EQ pa_bukrs
     AND   kunnr IN gr_kunnr
     AND   budat LE pa_stich-high
     AND   bstat EQ ''.
   SELECT bukrs kunnr augdt budat shkzg dmbtr pswsl pswbt FROM bsad
     INTO CORRESPONDING FIELDS OF TABLE gt_bsad
     WHERE bukrs EQ pa_bukrs
     AND   kunnr IN gr_kunnr
     AND   budat LE pa_stich-high
     AND   augdt GT pa_stich-high
     AND   bstat EQ ''.
Thanks a lot!
Regards
Michael

Answer 1

Almost always prefer one SELECT to a SELECT IN LOOP.
Another solution could be reading also some total table :
KNC1 (no special G/L, Balance Carried Forward + total DB/CR per period, one record per Fiscal Year)
KNC3 for special G/L (one record per fiscal year and special G/L indicator, only one total per year)
Only restrict access to BSID/BSAD for dates that are not end of period (or don't allow those...)
NB: From my experience, you can keep the INTO CORRESPONDING, just define a structure with only required fields, the actual generated SQL statement will only ask for those fields (read also Why "INTO CORRESPONDING" is much better than its reputation)
Regards,
Raymond