Skip to Content
Author's profile photo Paul Hardy

International Editable SALV Day 2015

no change.png

Dear Programmers,

On the 8th of February 2008 James Hawthorne started the discussion (link above) as to why SAP does not give the CL SALV TABLE the option to be editable, as CL GUI ALV GRID is.

Today is the 7th anniversary of that blog, and hence is “International Editable SALV Day”.

I started a little discussion on this here on SCN last June:-

Back in the year 2003 I went to SAPPHIRE in Brisbane and the speakers from SAP made much of the convergence of reports and transactions.

To put that another way – people did not just want a list of blocked sales documents where the system could not determine the price. They wanted a list of such documents on a screen where you could actually change the price yourself to fix the problem, and then release the document there and then.

The obvious answer is an editable grid, rather like the table controls in classical DYNPRO.

In CL_GUI_ALV_GRID this was a piece of cake. You could set whatever cells you like to be editable, and programmatically add extra custom commands at the top of the screen e.g. a custom “release” button.

The CL_SALV_TABLE was supposed to be the successor of CL_GUI_ALV_GRID and SAP pushed us to use that instead. Whilst far better in many ways, CL_SALV_TABLE has some surprising drawbacks, making it actually have less functionality than its predecessors.

·         You cannot edit the data

·         You cannot programmatically add commands in the full screen mode

·         You cannot add separator lines between icons

All of this was available in CL_GUI_ALV_GRID. The really strange thing is that at the heart of a CL_SALV_TABLE instance is a a CL_GUI_ALV_GRID instance, so obviously all of the above functionality could be added if it was so desired.

You will see from the prior blogs that the history of this is as follows:-

·         Every single ABAP developer desires this extra functionality in CL_SALV_TABLE

·         Many workarounds have been proposed on assorted SCN blogs

·         SAP development looks for those workarounds, and changes the CL_SALV_TABLE to block them

·         People tried to do the right thing, and put a proposal on “idea place” to make the SALV editable, a proposal which got a lot of votes

·         A senior SAP person from the development department got very upset indeed, said the SALV was never meant to be editable, and closed off the idea.

To quote from “V for Vendetta” however you cannot kill an idea…….

Ideas are Bullet Proof.png

So eight years on and workarounds are still springing up. SAP development can close off certain avenues but with the enhancement framework it is possiblefor developers to get around virtually any barriers placed in their way.

Wouldn’t it be easier if this was not a fight between the central team at SAP who develop the ABAP language and the users of that language?

Someone once said that if there was a law, and virtually everybody broke that law on a day to day basis, would it not be worth looking at the law to see if it actually made sense?

I don’t mind admitting I have created several SALV reports in my company where the users can edit data and I imagine I am not alone. I am also sure SAP development would be horrified by this fact. They hate people doing workarounds, cannot fathom my anyone would do such a rule-breaking dangerous risky thing, just to keep the business users happy.

As I said at the end of my last posting on this subject might I humbly suggest to the red nosed SAP ALV development team that the easiest way to stop people doing workarounds is to remove the need for a workaround in the first place, by having the functionality as standard.

So the question is – in 12 months’ time will I be posting another blog to celebrate the 9th anniversary of International Editable SALV Day?

Cheersy Cheers


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Pablo Casamayor
      Pablo Casamayor


      i agree 100%. It was high time a blog like this was published.

      Thanks for daring and showing so openly your opinion.

      Best regards.

      Author's profile photo Martin English
      Martin English

      Of course, if you were to describe it as an issue with a particular reporting component of Business Suite on HANA, you might get somewhere...

      In the meantime, run simple or run like mad (and get back to work on that book) 🙂

      Author's profile photo Paul Hardy
      Paul Hardy
      Blog Post Author

      The book is done, coming out shortly!

      Strangely enough, I have a chapter on the SALV, and at one stage talk about this very subject..... 😏

      Author's profile photo Eitan Rosenberg
      Eitan Rosenberg


      Lets start with something simple like:

      Multiple heading in ALV....



      Author's profile photo Nikolay Evstigneev
      Nikolay Evstigneev

      Hi, Paul!

      That's exact reason why I stopped using CL SALV TABLE once I tried it. I don't want to rewrite the screen logic of the report when users ask for "just one editable column".

      If also ALV input history is to be ever done (there was a note saying the opposite) I'll go on the booze the same day 🙂

      Author's profile photo Peter Inotai
      Peter Inotai

      >So the question is – in 12 months’ time will I be posting another blog to celebrate the 9th anniversary of International Editable SALV Day?

      If I calculate correctly it will be only the 8th 🙂

      Anyway, I like this blog. Reminds me to the new ABAP editor story with Thomas Jung, where in the end they did the downport to older releases.

      At least we still have CL_GUI_ALV_GRID and it was not flagged for obsolete, but I totally agree, that having this in CL SALV TABLE would make developers life easier.


      Author's profile photo Paul Hardy
      Paul Hardy
      Blog Post Author

      Leaving my inability to count aside, the greatest ever success in this area was SAP caving in in regard to Business Workflow.

      For almost ten years they put the workflow that runs inside of the ERP system into "maintenance mode" i.e. no new features, and kept the 3.0 ABAP editor inside transaction SWO1.

      This was to boil us customer frogs, hoping we would all stop using the free version of workflow and instead pay vast amounts of money for new "better" workflow systems with fancier names which we could then integrate back to our ERP systems.

      That did not work as well as SAP hoped, so in the end they caved in to the American SAP User Group Workflow pressure group and implemented about ten of fifteen fixes / enhancements and main one being the new ABAP editor in SWO1.

      Author's profile photo Peter Inotai
      Peter Inotai

      I never understood why they had that old editor in SWO1. It looked really inconsistent to me.

      BTW we also like the SAP standard Workflow engine so much, that we decided to have an own one instead in our product 🙂

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Paul, great blog indeed. You might be interested in checking out my recent CC discussion on "stuff SAP could easily fix". Well, this is probably not easily fixable (or, more importantly, perceived as a feature, not bug by SAP) but apparently one needs to get into the Customer Engagement program for things like that. And then there is, of course, prioritization, resources, etc.

      We do have great demand for editable ALV in our organization and now I'll make sure not to tell anyone how we do that. Thanks for the warning!

      Author's profile photo Horst Keller
      Horst Keller

      Wouldn’t it be easier if this was not a fight between the central team at SAP who develop the ABAP language and the users of that language?

      Just do be fair, a framework built with the ABAP language is not the ABAP language. But of course I understand, that from the user's view it's all the same ... 😏

      Author's profile photo Paul Hardy
      Paul Hardy
      Blog Post Author

      It is rather like the other day when I was in the Antique shop where the girlfiend of one of my mates works. Their computer had broken down so of course my wfe says "Oh, Paul works in IT! HE can fix it!"

      Now, I might now a bit about ABAP programming but how to fix a broken PC is usually beyond me - but as you say from the end users view it is all the same.

      Anyway, I sit near the help desk at work so I have picked up on the way experts deal with such problems.

      So I said "switch it off and switch it on again" which worked and I breathed a huge sigh of relief.

      Author's profile photo Nikolay Evstigneev
      Nikolay Evstigneev
      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      And so the legend of "IT guy" who can fix any device, write code in any programming language, install HANA server and configure intercompany process while at it will live on. You've doomed us all, Paul! 🙂

      Author's profile photo Simone Milesi
      Simone Milesi

      You forgot that the legends, in the darkest corner of company break rooms, whisper about the IT guy NEVER works, just sit and look at a laptop and get overpaid to do this!

      Author's profile photo Former Member
      Former Member

      I'll second....errr fifteenth this request.

      Author's profile photo Michael Fritz
      Michael Fritz

      Like this post and greetings to the SAP dinosaurs out there ^^

      Author's profile photo Luciano puppo
      Luciano puppo


      *& Report  ZIPPO_EDIT_CL_SALV the present template is derived from an

      *&                            original solution implemented by a

      *&                            SAP specialist from China


      REPORT zippo_edit_cl_salv.


      *       CLASS lcl_alv DEFINITION


      * cl_salv_controller_table is declared in cl_salv_table as friend

      * cl_salv_controller_table is not declared as final


      * within lcl_alv defined INHERITING FROM cl_salv_controller_table

      *   we can acced protected elements in cl_salv_table  via friendship


      CLASS lcl_alv DEFINITION INHERITING FROM cl_salv_controller_table ABSTRACT.


          CLASS-METHODS: get_grid

                          IMPORTING iref_salv TYPE REF TO cl_salv_table

                          RETURNING value(ret_grid) TYPE REF TO cl_gui_alv_grid.

      ENDCLASS.                    "lcl_alv DEFINITION


      *       CLASS lcl_alv IMPLEMENTATION





        METHOD get_grid. " to get the ref. of the instance cl_gui_alv_grid in OO ALV

          DATA: r_controller      TYPE REF TO   cl_salv_controller_table,

                r_adapter         TYPE REF TO   cl_salv_fullscreen_adapter.


              r_controller    ?=    iref_salv->r_controller.

              r_adapter       ?=    r_controller->r_adapter.

              ret_grid         =    r_adapter->get_grid( ).

            CATCH cx_root.

              " ERROR HANDLER TO DO ( if you want )


        ENDMETHOD.                    "get_grid

      ENDCLASS.                    "lcl_alv IMPLEMENTATION


      *       CLASS lcl DEFINITION






          TYPES: BEGIN OF t_row,

                    account_a(10)     TYPE    p DECIMALS 2,

                    account_b(10)     TYPE    p DECIMALS 2,

                 END OF t_row,

                 t_it                 TYPE STANDARD TABLE OF  t_row.

          CLASS-DATA: itab                TYPE           t_it,

                      ls_itab             TYPE           t_row,

                      r_alv               TYPE REF TO    cl_salv_table,

                      r_functions         TYPE REF TO    cl_salv_functions_list,

                      r_cl_gui            TYPE REF TO    cl_gui_alv_grid.

          CLASS-METHODS: srv_main RAISING cx_salv_msg,

                         srv_alv  RAISING cx_salv_msg,

                         srv_added_function FOR EVENT added_function

                              OF cl_salv_events_table IMPORTING e_salv_function.

      ENDCLASS.                    "lcl DEFINITION


      *       CLASS lcl IMPLEMENTATION





        METHOD srv_added_function.

          DATA: ls_layo TYPE lvc_s_layo.

      *    MESSAGE 'added function' TYPE 'I'.   "message to trace added_function event

          IF r_cl_gui IS NOT BOUND.

            r_cl_gui = lcl_alv=>get_grid( r_alv ).

            " to get reference of cl_gui_alv_grid instance


          CASE e_salv_function.

            WHEN '&EDIT'.

      ***        get front end layout ;  edit = 'X'  ; set front end layout

              r_cl_gui->get_frontend_layout( IMPORTING es_layout = ls_layo ).

              ls_layo-edit = abap_true. "'X'

              r_cl_gui->set_frontend_layout( EXPORTING is_layout = ls_layo ).


              r_cl_gui->refresh_table_display( ). "refresh grid to evaluate edit = 'X'

            WHEN 'REFRESH'.

              r_cl_gui->check_changed_data( ).    " to get modified data

      *                                           "     from front end grid to report

      *                                           " mouse double click on grid get the same


        ENDMETHOD.                    "srv_edit

        METHOD srv_main.

          ls_itab-account_a = 100.

          ls_itab-account_b = 450.

          APPEND ls_itab TO itab.

          ls_itab-account_a = 110.

          ls_itab-account_b = 2750.

          APPEND ls_itab TO itab.

          srv_alv( ).

        ENDMETHOD.                    "srv01

        METHOD srv_alv.

          DATA: r_events TYPE REF TO cl_salv_events_table.

          cl_salv_table=>factory( IMPORTING r_salv_table = r_alv

                                  CHANGING t_table = itab ).



              report        = sy-repid

              pfstatus      = 'ST_ALV'  " GUI Status created in the actual report

                                        "   adjusted via adjust template -> list viewer

                                        "  with '&EDIT'     added function

                                        "  with 'REFRESH'   added function

      *    set_functions = C_FUNCTIONS_NONE



          r_functions = r_alv->get_functions( ).

          r_functions->set_all( ).

          r_events = r_alv->get_event( ).

          SET HANDLER srv_added_function FOR r_events.

          r_alv->display( ).

        ENDMETHOD.                    "srv_alv

      ENDCLASS.                    "lcl IMPLEMENTATION


        FIELD-SYMBOLS: <f> TYPE lcl=>t_row.

        lcl=>srv_main( ).

        LOOP AT lcl=>itab ASSIGNING <f>.

          WRITE:/ <f>-account_a, <f>-account_b.


      Author's profile photo Paul Hardy
      Paul Hardy
      Blog Post Author

      Technical solutions to make the SALV editable have been around for a while. I describe something very similar to the code above in my book, for example.

      Below Naimesh notes he found a solution in 2008 which still works to this day.

      That is not really the point though - SALV has a CL_GUI_ALV_GRID object at it's heart so it should at the very minimum be able to do everything that CL_GUI_ALV_GRID does, but it cannot.

      That is just plain insanity on the part of SAP.

      As an example using CL_GUI_ALV_GRID I can bring up the report directly in editable mode. All the workarounds require a user to press a button to change the grid into editable mode.

      Unless I am mistaken? Has anyone got a workaround to bring up a SALV report in editable mode from the get-go?

      Author's profile photo Naimesh Patel
      Naimesh Patel

      Hello Paul,

      Yes, I think you will posting the 9th anniversary with waiting for SALV for editable function. As SAP has roadmap to go more on new UI techniques so, SALV would be left as is ...

      Coincidence that I also wrote the solution to make is editable in the 1st year of "Editable SALV" - November 2008 - Power of ABAP Objects: Overcome the Restrictions of SALV Model

      Whenever, I have new version of ABAP release, I would test the functionality and it works till ABAP 740 SP5 (thats latest I can manage till today).

      I would be more interested to see why SALV can't be made editable. There are few comments on the blog from ALV development team, that it is not designed for editable. I think, I'm already on the not-so-well-list for ALV team 🙂 as I'm causing more trouble for them.

      By not providing editable function, SALV is losing the purpose. Can you imagine the shock the end-users (and directors who approve the budget)  when you say - to make existing ALV report editable, I would need to change the design and use a different (older version - not that they care)... So, I always think (and want) to use SLAV but end up using the CL_GUI_ALV_GRID.

      Naimesh Patel

      Author's profile photo Former Member
      Former Member

      Hi Patel,

      I am with you. I've encapsulated CL_GUI_ALV_GRID long time ago - to hide the technicalities - and had actually forgotten about SALV. It's a bit of a non-issue.

      But on the topic of the new UI technology. I've just walked out of a meeting with yet another large customer that has come to the conclusion that

      - using the standard SAP transactions leads to unhappy users due to the cluttered screens

      - building a UI in JavaScript takes too long and is too high maintenance in the long run

      - the only sensible thing to do is to use controls like Cl_GUI_ALV_GRID and the splitters, drag/drop, etc to quickly build simple usable UIs that talk the language of the users, whilst calling standard SAP components behind the scenes to run standard business logic.

      Is it true Personas is free now? Because if it is, they will simple put Personas 3 (once it is out of ramp-up, I understand V3 doesn't need silverlight any more) in front of the ABAP UI and be done with it. Scrap Fiori.

      Does that strike a cord with anyone out there?

      Author's profile photo Paul Hardy
      Paul Hardy
      Blog Post Author

      Personas is indeed free now. Many companies actually paid for it (circa 200,000 euros) and then seethed when it became free - they got a credit for the amount they had spent, which could only be used to buy more SAP products and do you know - that did not calm a lot of those companies down for some reason.

      Version 3 of Personas is indeed looking good - SAP claims it fills some gaps that assorted companies have said makes the current version useless.

      However I would note that apart from the drag and drop nature of Personas that you use to configure the basics, if you want to do anything out of the ordinary - and most organisations do - then you have to use the programming language.

      That is not the end of the world - in fact to programmers like me that sounds great - as with a fully fledged programming language you can do pretty much anything you want.

      That fully fledged programming language is however JavaScript - so does that put Personas back in the "takes too long and too high maintenance" basket?

      Cheersy Cheers


      Author's profile photo Former Member
      Former Member

      Hi Paul,


      My gut feeling is that most UI requirements can be implemented using good old ABAP dynpro and rendered through Personas without the need to resort to JavaScript. The other UI requirements will probably be around dynamically moving objects around on the screen, making things fade in and out and flip around etc... which is all nice and fancy but probably not essential for an enterprise application...  Happy to be challenged on this.