TYPES:
BEGIN OF ty_reg,
id(3) type n,
text(20) type c,
END OF ty_reg.
DATA:
dias TYPE STANDARD TABLE OF ty_reg WITH HEADER LINE,
feriados TYPE STANDARD TABLE OF ty_reg WITH HEADER LINE.
SORT: dias BY id, feriados BY id.
LOOP AT dias
READ TABLE feriados WITH KEY id = dias-id BINARY SEARCH.
IF sy-subrc EQ 0.
dias-texto = feriados-texto.
MODIFY dias INDEX sy-tabix.
ENDIF.
ENDLOOP.
la tabla de eventos del alv es para programar eventos relacionados después de mostrar el alv, que haga cosas al darle click o modifique colores,etc. es opcional ya que se puede construir para solo mostrar info.
en t_mara te queda las 2 filas pero solo con los campos MATNR y MATKL
1 MATNR: 200000001, MATKL: 450000560
2 MATNR: 200000001, MATKL: 450000560
se definen ambas tablas con el mismo id y diferente texto.
SORT: dias BY id, feriados BY id. // es requisito ordenar para el binary search
LOOP AT dias // recorre tabla días
READ TABLE feriados WITH KEY id = dias-id BINARY SEARCH. // recorre tabla feriados y compara campo id
IF sy-subrc EQ 0. //si el campo id de ambas tablas son iguales
dias-texto = feriados-texto. // asigna el texto de feriados a días
MODIFY dias INDEX sy-tabix. //esto asigna el valor de sy-tabix al id de la tabla dias cuando entra al if.
ENDIF.
ENDLOOP.
yo creo que del sentido común y experiencia. he pedido varias alv y el hacer cosas una vez que los generas es algo opcional hasta donde entiendo. El objetivo generalmente es generar el reporte en formato alv