SAP ALV

Rather than writing raw WRITE statements, ALV takes your internal table and renders a professional, interactive grid: users can sort, filter, rearrange columns, subtotal, and export to Excel, and can save their preferred layout as a variant. This consistency and power is why ALV is the default for list output.

DATA lo_alv TYPE REF TO cl_salv_table.
cl_salv_table=>factory(
  IMPORTING r_salv_table = lo_alv
  CHANGING  t_table      = lt_orders ).
lo_alv->get_functions( )->set_all( abap_true ).
lo_alv->display( ).

Version note: the older function module and the grid class are both still present and still supported, and you will meet plenty of both in any system with history. New code should use the simple class, and existing reports should be left alone unless you are already changing them. Rewriting a working report to change its ALV flavour is effort with no user visible result. See ABAP best practices.

The argument for ALV is not that it saves you writing a loop. It is the behaviour users expect, none of which you implement.

Sorting and filtering on any column, set by the user rather than by you.

Column selection and reordering, so somebody who cares about three fields out of twenty can see only those.

Subtotals and totals on numeric columns, grouped by whatever they sorted by.

Export to spreadsheet, which is the first thing a finance user does with any report and the feature most often requested on a hand-written one.

Layout variants, saved per user or shared, so the arrangement survives to next time. This is the one that matters most in practice: a user who has arranged a report the way they like it will use it, and one who rearranges it every morning will ask for a custom report.

Print with correct headers and page handling.

Every one of those is a request that arrives on a hand-coded report, one at a time, over months. Using ALV answers all of them before they are asked, which is the honest reason to use it rather than elegance.

There are older (REUSE_ALV_* function modules) and object-oriented (CL_SALV_TABLE, CL_GUI_ALV_GRID) ALV APIs. For new development, the simple CL_SALV_TABLE is preferred for read-only grids; CL_GUI_ALV_GRID is used when you need editable grids or fine control.

The practical guidance for choosing between them: CL_SALV for anything new, because it is the simplest to write and covers most needs. The older function module family is what you will find in existing code and it is worth being able to read. CL_GUI_ALV_GRID is the older object-oriented control, more capable for embedding in a screen and considerably more code. Reach for it only when SALV genuinely cannot do what is needed, which is usually about editable cells or tight screen integration.

Twenty minutes, and it demonstrates the return on the approach.

1. Write a report that selects a few hundred rows into an internal table and displays them with WRITE. Run it. It works and nobody would want to use it.
2. Replace the output with cl_salv_table: a factory call, then display. Three lines instead of a loop.
3. Run it and sort a column, filter, add a subtotal, export to spreadsheet.
4. Save a layout variant, leave the report, and come back. The arrangement persisted.
5. Now add a field to the selection and rerun. The column appears automatically, because the field catalogue came from the table's type.

Step five is the quiet benefit: the report follows the data structure, so adding a field is a change in one place rather than in the output code as well.

A read only list is where most ALV reports stop, and it is also where most user complaints start, because the obvious next thing to want is to click a row and go to the document.

The mechanism is events. The ALV object publishes events, your program registers a handler, and the handler runs when the user acts. Two cover the great majority of cases.

Double click on a row. The handler receives the row index, you read that row from your internal table, and you call the relevant transaction with the key. This turns a list of order numbers into a usable navigation tool and takes about fifteen lines.

A toolbar button. You add a function to the toolbar, and the handler runs your code for the selected rows. This is how a report becomes a small application: select the exceptions, press the button, post the correction.

Two habits that separate working code from code that irritates people.

1. Read the selection from the ALV, not from the internal table you built. The user may have sorted or filtered, and the visible order is not your order.
2. Do nothing destructive without a confirmation and a result message. A button that silently posts is a support ticket waiting to happen.

Once you have handled two events, the rest of the event list is the same pattern, and the documentation becomes readable rather than intimidating.

ALV’s saved layout variants let users keep their preferred column set and sorting, a big usability win. Building reports on ALV means you get all this for free and deliver a consistent experience.

Worth knowing where ALV sits now. In Fiori, the equivalent is a list report generated by Fiori Elements from annotations, and it provides the same capabilities for the same reasons. So the principle transfers even though the technology does not: describe the data and let the framework produce the list, rather than writing the output. See ABAP basics for where this fits in a first report.

Where teams get value is the field catalogue. Built by hand, it is a long block of assignments and the single most tedious part of writing an ALV. Derived from a dictionary structure, it arrives with the column headings, the data types, the field lengths and the conversion exits already correct, and the currency and quantity fields display properly because the reference fields came along too. That last point is the one people discover late: an amount column with no currency reference formats to the wrong number of decimals and nobody notices until an audit.

• Hand-coding output instead of using ALV.
• Using old REUSE_ALV FMs for new development.
• Ignoring layout variants that users value.

• Building a field catalogue by hand when the type would supply it. It is more code and it drifts from the structure.
• Selecting everything and letting ALV filter. The filtering is in the user's hands and the reading already happened, which is a performance problem ALV hides.
• Using the grid control where SALV would do. See internal tables, BAPIs and ABAP best practices for the surrounding material.

One more that costs real time. A report that selects everything and lets the user filter in the ALV looks responsive on a development system and reads millions of rows in production. The selection screen exists so the database does the filtering, and moving work into the grid is moving it to the slowest possible place. Restrict on the database first, then display what is left.

Displaying a table is a few lines, and building a report users choose to open rather than asking for a custom one is the part you do in the course.