You know how the say the best admins, developers (…) are the lazy ones – why? Because the automate everything that makes sense to automate: let repetitive tasks be done by some kind of automation, e.g. a script: Once you have that, you’re way faster, you don’t make typing errors, and you script defines a kind of standard/best practice you can rely on, without having to think about it. Of course, your script, template or whatever can and should improve if you gain new knowledge. That being said, I often have to write a new ABAP-(ALV-)report from scratch: Select some data Maybe do something with it Display in ALV. This might be a throw-away report just to try something out, or a report to be used productively (or one – maybe silently – turning into the other, I guess you all know those examples). Say you’d want a report, selecting data from a database tabel (e.g. VBAP), with a select-option on one of this table’s fields (e.g. ERNAM), displaying what was selected in a ALV-Grid (with all features enabled). Easy, isn’t it? Won’t take you longer that a few minutes, right?! Guess how long it takes me: 3 seconds! (Time starts, when I can start coding in eclipse, e.g. I have supplied the name of the report, chosen a package and the transport request). Here’s what I do: jre_, + Ctrl+space + Enter VBAP, Tab, ERNAM. Activate (Ctrl+F3) Run (F8!). Did you take the time? It was fast, wasn’t it? And it’s not a quick-and-dirty style of writing (you know, just start coding with select * from … without caring to even create forms or methods), but a very nice one, according to whatever my standards are (e.g. everything in local classes, respecting naming conventions, strong (=non-generic) typing… etc.). So, you already know how I did that: I create myself a report-template in AdT, with variables for the table- and field-name. This is where it is defined: The custom variables make it flexible: And this is it’s full code for your inspiration: *REPORT generic Types: gty_data type ${my_table} , gty_tab_data TYPE STANDARD TABLE OF gty_data . *data, solely for select-options. data: gso_${my_table} type ${my_table}. *Sel-Screen: SELECTION-SCREEN BEGIN OF BLOCK sel_opt WITH FRAME TITLE text-t01. SELECT-Options: so_${my_table_field} for gso_${my_table}-${my_table_field}. SELECTION-SCREEN END OF BLOCK sel_opt. SELECTION-SCREEN BEGIN OF BLOCK mode WITH FRAME TITLE text-t02. PARAMETERS: pa_disp TYPE flag RADIOBUTTON GROUP mode DEFAULT 'X', pa_proc TYPE flag RADIOBUTTON GROUP mode. SELECTION-SCREEN END OF BLOCK mode. CLASS lcl_report DEFINITION. PUBLIC SECTION. class-METHODS: init. METHODS: get_data CHANGING ct_data TYPE gty_tab_data, display_data CHANGING ct_data TYPE gty_tab_data, process_data IMPORTING it_data TYPE gty_tab_data. ENDCLASS. "lcl_report DEFINITION CLASS lcl_report IMPLEMENTATION. METHOD process_data. FIELD-SYMBOLS: LIKE LINE OF it_data. CHECK it_data IS NOT INITIAL. LOOP AT it_data ASSIGNING . *do something ENDLOOP. ENDMETHOD. "process_data METHOD display_data. DATA: lr_alv TYPE REF TO cl_salv_table. DATA: lr_functions TYPE REF TO cl_salv_functions_list, lr_layout TYPE REF TO cl_salv_layout, ls_key TYPE salv_s_layout_key. TRY. CALL METHOD cl_salv_table=>factory EXPORTING list_display = if_salv_c_bool_sap=>false IMPORTING r_salv_table = lr_alv CHANGING t_table = ct_data. ##NO_HANDLER. CATCH cx_salv_msg . ENDTRY. lr_layout = lr_alv->get_layout( ). ls_key-report = sy-repid. lr_layout->set_key( ls_key ). lr_layout->set_default( abap_true ). lr_layout->set_save_restriction( if_salv_c_layout=>restrict_none ). lr_functions = lr_alv->get_functions( ). lr_functions->set_all( abap_true ). CALL METHOD lr_alv->display. ENDMETHOD. "display_data METHOD get_data. select * from ${my_table} into CORRESPONDING FIELDS OF table ct_data UP TO 500 ROWS where ${my_table_field} in so_${my_table_field} . ENDMETHOD. method init. DATA: lt_data TYPE gty_tab_data, lo_report TYPE REF TO lcl_report. CREATE OBJECT lo_report. lo_report->get_data( CHANGING ct_data = lt_data ). check lt_data is not initial. CASE abap_true. WHEN pa_disp. lo_report->display_data( changing ct_data = lt_data ). WHEN pa_proc. lo_report->process_data( EXPORTING it_data = lt_data ). ENDCASE. endmethod. ENDCLASS. "lcl_report IMPLEMENTATION START-OF-SELECTION. lcl_report=>init( ). Takaway: action you can take: Invest a little time to create a very nice template. From now one, use it whenever it is applicable. If you spot an error, or a chance for improvement, not only correct the report you just wrote, but also adjust your template accordingly. -> All further uses will benefit from that! If you start dirty, you might stay dirty. So start clean right away! Constraints/further ideas/notes: – You can put as much coding as you like in the template, but it will end up in only one report – structuring with includes (_sel, _top etc.) isn’t easily possible. – Your template doesn’t have to be a whole report, it could also be a method you often code. (I have one where I simply pass in a (any) table, and it displays it in ALV). – I the current unit-testing-hype it might be worth to think about to also have a temple (=jump-start) for the test class. – The template is in Eclipse, so I can use it in any system I access! (As opposed to those old templates in SE80 – I admit, I never made to much use of them!) – (You can probably share your template with your colleagues (and profit from their improvements to it) somehow e.g. with using git). Now over to you: How do you avoid repetitive tasks, while improving quality? Do you, too, use dedicated templates, or do you just copy and adept from another (well written) productive program?