SAP - ABAP. Changing the summing row in an ALV grid

I work as an ABAP developer in one of the domestic companies implementing SAP.

The other day, a specification came from the consultant with the task of making a special summing line (ALV GRID), which will contain all kinds of amounts, values, names, etc., which should not be in the standard. You also need to realize the ability of the user to change the data in this line manually.

For those in the tank: the summing lines are yellow, the sums are displayed in them, in this case by the debtor.

image

Porakinin brains and asking colleagues, I decided to send a consultant to hell with such requests received 2 solutions:

  1. Make your own line of summing, which will lie in the inner plate. Customize the output for it with color, amounts, etc.
  2. Try to substitute the necessary values ​​in the standard line of summing.

The first option immediately threw. Just recently, I ruled development with such a line, you won’t get hemorrhoids - you cannot sort filter data in ALV, the line can move somewhere, etc. etc. In addition, the standard line has a bunch of cool and useful goodies like collapsing lines into one or a hierarchy of sub-sums. The only negative - no matter how you turn it, it’s impossible to open the standard line of summing up for editing (well, or too laborious).

The second option - is it even possible ?! Having received approval from the authorities for the investigation of the issue, he wentogled, and on the very first link the good Indian explains that this is completely legal and real. The CL_GUI_ALV_GRID class has a GET_SUBTOTALS method that returns links to tables with sums of all levels that can be easily changed in your program. It looks like this:

image

Hooray, comrades! The task is clear, and even an action plan has been outlined. Left values ​​should only be inserted in the summing lines for debtors. Those. we pass the IT_SORT parameter to the SET_TABLE_FOR_FIRST_DISPLAY method, in which we indicate the first sort level - sorting by customer. We take out the table of amounts of the 1st level (these will be the amounts for debtors) and substitute the necessary values ​​there:

Schematically looks like this:

FORM fill_sort  CHANGING ct_sort TYPE lvc_t_sort.
  APPEND INITIAL LINE TO ct_sort ASSIGNING FIELD-SYMBOL().
  -spos      = '1'.
  -fieldname = 'KUNNR'. "Фууууууу хардкод!!!!
  -subtot    = 'X'.
  -up        = 'X'.
ENDFORM.
go_alv_grid->set_table_for_first_display( ... ).
PERFORM set_subtotals.
...
FORM set_subtotals .
  DATA: lr_collect01   TYPE REF TO data
      .
  FIELD-SYMBOLS:   TYPE ANY TABLE
               ,  TYPE ty_data
               .
  go_alv_grid->get_subtotals(
    IMPORTING
      ep_collect01   = lr_collect01
    ).
  ASSIGN lr_collect01->* TO .
  IF  IS ASSIGNED.
    LOOP AT  ASSIGNING .
       "Подставляем необходимые значения в строку
    ENDLOOP.
  ENDIF.
ENDFORM.

“Will it really work ?!” I thought, and with trembling hands I started the report. It worked!!! But not quite right. Values ​​are displayed only in subtotal, which appeared "under" the screen. Those. those to which you need to scroll down. The solution was found quite quickly on the Internet: to cause a soft update of ALV after changing the sums:

go_alv_grid->refresh_table_display( i_soft_refresh = 'X' ).

If you do not specify the i_soft_refresh parameter, the update will recount all subtotal and overwrite our data.

All?! Can I take it for a test ?! Well, that wasn’t the case ... well, wait ... what if the user changes the sorting? Or will filter the data? Or will he do anything with our table !? It will be updated and all our values ​​will disappear! Damn ...

But, as it turned out, the CL_GUI_ALV_GRID class has a magical and very useful event: AFTER_REFRESH, which is fired every time the ALV is updated. This time, the action plan is as follows:

1. We catch the AFTER_REFRESH event;
2. We obtain criteria for sorting the current ALV state (which will now be displayed on the screen): go_alv_grid-> get_sort_criteria;
3. We check: at the first level of sorting there should be a debtor (-spos = 1 AND -fieldname = 'KUNNR') and summing (-subtot = 'X');
3.a. If everything is ok, run a subroutine that substitutes the necessary data into the summing lines: PERFORM set_subtotals .;
3.b. Otherwise, we change the sorting criteria in such a way that the debtor is at the first level and summing is enabled for it;
3.b.I. If there is no debtor at all in the sorting criterion, then we remove the sorting of the 9th level (if there is one), increase all other levels by +1, and insert the first level sorting by the debtor;
3.b.II. If sorting by the customer is in the table, but not at the first level, then we increase all sorting levels lower than the customer’s level by +1, and change the customer’s sorting level by 1;

4. Set the correct sorting criteria: go_alv_grid-> set_sort_criteria (lt_sort);
5. Next, we start the ALV update with recounting the amounts (here you need to be careful not to start infinite recursion, because the AFTER_REFRESH event will work again);
6. The event will work for the 2nd time, but the sorting criteria will be correct, and filling in the subtotal lines will start (by the way, there is a problem - you need to check if the correct amounts are set so that the program does not hang up due to infinite recursion, because after changing the amounts we need to start the soft update ALV).

Profit! Getting praise from superiors and consultants! No matter how the user tortures ALV, the first level of sorting will always have a debtor, for him there will always be a line of summing with the necessary values.

There is only one problem left - the user still cannot change data manually. He wants to. But, after talking with the consultant, we decided to catch a double click on such a line and throw out a window with the input fields that the user will fill in, press Enter and they will get into the necessary fields in the table. The question arises, how to distinguish the summing line from the usual? Answer: yes it’s easy of course! What kind of stupid questions? There is an excellent parameter in the DOUBLE_CLICK event: is_row-rowtype. It is empty in the usual lines, and filled in the office. It is usually filled with a line of this type:

S 0101 0000000001

It was found out experimentally that S is the summing line (there is also the value T - the total line of sums), 0101 is the sort level (at least the last 2 digits). The second field of the is_row (index) structure contains the row number of the sum table of the required level. All information is there! We

act : 1. Check that the user clicked on the subtotal;
2. We get a table of sums of the first level: go_alv_grid-> get_subtotals;
3. We read the necessary line sub_total_tab [is_row-index];
4. We show the user a window with input fields (we insert the current values ​​of the line into them);
5. We get user data;
6. Insert user data into our line;
7. Softly update ALV.

Well, that’s all! Everyone is happy, everything works! Well, at least for me, while the consultant is on vacation and has not yet checked.

Also popular now: