Displaying a table with cl_salv_table: "itab is not type compatible with formal parameter t_table"

Question

I need to display an internal table with cl_salv_table. Currently I take the bkpf table, cut out three columns and insert them into the internal table. But now it's saying that the parameter and lt_bkpf are type-incompatible.

Here is my Code:

SELECTION-SCREEN BEGIN OF LINE.

SELECTION-SCREEN COMMENT 5(15) p_name1 FOR FIELD p_blart.
PARAMETERS: p_blart TYPE blart.

SELECTION-SCREEN END OF LINE.

AT SELECTION-SCREEN OUTPUT.
  p_name1 = 'Belegart'.

INITIALIZATION.
  p_blart = 'DD'. "Set default value
END-OF-SELECTION.

Data:
BEGIN OF gt_bkpf OCCURS 0,
  bukrs LIKE bkpf-bukrs,
  blart LIKE bkpf-blart,
  gjahr LIKE bkpf-gjahr,
END OF gt_bkpf.

SELECT bukrs, blart, gjahr
  FROM bkpf
  WHERE blart LIKE @p_blart
  INTO CORRESPONDING FIELDS OF @gt_bkpf.
ENDSELECT.

cl_salv_table=>factory( IMPORTING r_salv_table = go_table
                        CHANGING t_table = gt_bkpf ).

  go_table->display( ).

Please don't re-ask the same question as the one you have used to solve the first problem, ask the question concerning your current problem about `CX_SALV_NOT_FOUND`, and tell us which line is concerned by the error. Thank you. — Sandra Rossi, Oct 07 '20 at 18:32

score 3 · Accepted Answer · edited Oct 08 '20 at 05:59

3

The internal table is declared with header line (because of OCCURS), this is obsolete and not supported in OO environment. You have to declare the table like this:

TYPES: BEGIN OF ty_bkpf,
  bukrs TYPE bkpf-bukrs,
  blart TYPE bkpf-blart,
  gjahr TYPE bkpf-gjahr,
END OF ty_bkpf.

DATA: lt_bkpf TYPE STANDARD TABLE OF ty_bkpf.

Please note the LIKE is also replaced by TYPE.

edited Oct 08 '20 at 05:59

Suncatcher

10,355
10
52
90

answered Oct 07 '20 at 15:02

József Szikszai

4,791
3
14
24

I'd like to add that you can still send a table with header line as a parameter, you just need to use the itab[] convention. This obviously only works if you're calling the method from non-OO code. – gabrielbaca Oct 25 '20 at 22:27
@gabrielbaca: that is correct, but isn't is better to correct the root of the problem and get rid out of all obsolate language elements? – József Szikszai Oct 29 '20 at 09:13
That's ideal but not always feasible. You may need to introduce new functionality in a legacy program and not be able to modify everything. A scenario that comes to mind that is still used is reports with Select-Options, which are always created as range table with header line. In that case you always need to use the itab[] notation to send it a class method. – gabrielbaca Oct 29 '20 at 21:08

Displaying a table with cl_salv_table: "itab is not type compatible with formal parameter t_table"

1 Answers1