I'm using editable OO ALV to display some records from custom table. The key is matnr in ref table is MARA. User can insert new records or edit existing records. I need to check if matnr exists in. Editable GRID ALV with save and refresh. The previous post REUSE_ALV_GRID_DISPLAY- 02 shows how to make use of field catalog in grid alv. This post shows how to make edit few columns editable and change the field values and updating the data base and refreshing the grid display after change and save.
International Editable SALV Day 2016. All encourage to “enjoy” SAP and the good old CL_GUI_ALV_GRID came along to replace function module REUSE_ALV_DISPLAY.
In this web log we will see how to assign default values while creating a new row in ALV Grid.
Sometimes we need to assign some default values when we create a new row in a grid using standard ALV Append row button.
In our scenario we will see how to assign default values to Airline Code (CARRID), Flight Connection Number (CONNID) and Flight date (FLDATE) when a new row is created.
To do that we need to handle DATA_CHANGED event in the program like mentioned below.
Definition of a class:
—-
CLASS lcl_event_receiver DEFINITION
—-
…….. *
—-
CLASS LCL_EVENT_RECEIVER DEFINITION.
*………….
PUBLIC SECTION.
METHODS:
handle_data_changed
FOR EVENT data_changed OF cl_gui_alv_grid
IMPORTING er_data_changed
e_ucomm.
ENDCLASS. “lcl_event_receiver DEFINITION
Implementation of a class:
*—-
*CLASS LCL_EVENT_RECEIVER IMPLEMENTATION.
METHOD HANDLE_DATA_CHANGED.
DATA: dl_ins_row TYPE lvc_s_moce. ” Insert Row
FIELD-SYMBOLS: TYPE table. ” Output table
Loop at the inserted rows table and assign default values
LOOP AT er_data_changed->mt_inserted_rows INTO dl_ins_row.
ASSIGN er_data_changed->mp_mod_rows->* TO FROM ls_outtab INDEX sy-tabix.
endloop.
endloop.
ENDMETHOD. “handle_data_changed
ENDCLASS. “lcl_event_receiver IMPLEMENTATION
*—-
*Register the events to trigger DATA_CHANGED event when a new row is created.
Testing:
1) Execute the report and press Append Row button.
2) Row is created with default values.
Sometimes we need to default previous row values to the newly created row. To do that we need to set the attribute
AUTO_VALUE
while populating field catalog. In our scenario we default values to Airline Code (CARRID), Flight Connection Number (CONNID) and Flight date (FLDATE) when a new row is created.
DATA LS_FCAT TYPE LVC_S_FCAT.
CALL FUNCTION ‘LVC_FIELDCATALOG_MERGE’
EXPORTING
I_STRUCTURE_NAME = ‘SFLIGHT’
CHANGING
CT_FIELDCAT = PT_FIELDCAT.
LOOP AT PT_FIELDCAT INTO LS_FCAT.
IF LS_FCAT-FIELDNAME = ‘CARRID’ OR
LS_FCAT-FIELDNAME = ‘CONNID’ OR
Alv Reports In Abap
LS_FCAT-FIELDNAME = ‘FLDATE’.
Use field AUTO_VALUE of the fieldcatalog to preset values when new
lines are added.
LS_FCAT-EDIT = ‘X’.
LS_FCAT-AUTO_VALUE = ‘X’.
LS_FCAT-CHECKTABLE = ‘!’. “do not check foreign key relations
MODIFY PT_FIELDCAT FROM LS_FCAT.
ENDIF.
ENDLOOP.
Testing:
1) Execute the report and press Append Row button.
2) Row is created with previous row values.
</font>
International Editable SALV Day 2016 – Year Eight
Dear CL_SALV_TABLE Fans,
Welcome to February 8th, 2016 which is the eighth International Editable SALV Day. See below for a link to a blog I wrote to celebrate this day exactly one year ago:-
As you may know back in the year 2000 we were all encourage to “enjoy” SAP and the good old CL_GUI_ALV_GRID came along to replace function module REUSE_ALV_DISPLAY_GRID.
This was nice and object orientated, which we all love. ABAP People love OO programming so much that sixteen years on, some have even started to use it!
Editable Alv Grid In Sap Abap Developer Salary
Anyway, what we liked about the CL_GUI_ALV_GRID was the fact that you could make some of the columns, or even individual cells, editable. This is what the end users were crying out for. SAP itself made a big song and dance about having a convergence between analytical applications and transactional applications.
That is, a business user did not just stare at the data and admire it, but could actually take action on the data they were looking at e.g. remove a billing block, or adjust the price.
Thus began a golden age. All the peoples of the world forgot their differences and at long last there was world peace, an end to sickness and suffering, and an increase in the average human lifespan to 206 years. As Rufus said “bowling averages were way up, mini-golf scores were way down”.
Then, a great disaster befell the universe. With the advent of 7.20 a new monster was created by SAP, named CL_SALV_TABLE and we were all told to bow down and worship this new beast.
It fooled us all with its sweet promises of dynamically generating the field catalogue based on an internal table, and we fell for it, writing many reports using this new class, and converting many an old report to use this bright new technology.
We laughed and sang and thought how wonderful we were. But as always, pride comes before a fall.
One day the business users came to us and said “what we most desire in the world is to have this or that column editable, and maybe a few cells here and there, based on certain logic”. They then stood there looking at us expectantly; after all we had always been able to do it before. Alas, lack – now we could not! We had been cast out of Heaven!
How could SAP play such a cruel trick on us? Pretending a new technology was superior in every way to the last, and not mentioning a whacking great hole in the middle. This was all the more annoying since CL_SALV_TABLE is nothing more than a wrapper around CL_GUI_ALV_GRID, adding some features, and clearly subtracting others.
For many years the sky turned black, and a plague of frogs rained down upon the SAP developer community. Then several programmers took a leaf out of Twisted Sister’s book and declared “we’re not going to take this, we’re not going to take this, and we’re not going to take this, any more”.
Here is the article that started the rebellion, written by Naimesh Patel
Since that point many people have joined the crusade, including my good self. There have been many approaches created as to how to get around this, get the benefits of the SALV and also make it editable. Here is the latest blog I wrote on the subject, building on the work of the others who went before me:-
Of course the best way around this problem would be for the powers that be at SAP to recognise that every single one of their customers desires this functionality. I wonder how far SAP would have got if they had said “we have embraced the internet age, with a wonderful suite of new UI5 apps. All of them will be read-only”.
This day marks the 8th anniversary of James Hawthorne going cap in hand to SAP and suggesting maybe the SALV could be brought up to parity with the CL_GUI_ALV_GRID and have an option to be editable.
SAP did in fact respond to this request. They said it was impossible, and just laughed and laughed and laughed. They are still laughing to this day, fit to burst. No-one in all eternity has ever laughed so loud and so long, with the exception of Jock McLaughing, the Laughing Scotsman, winner of the All Scotland Laughing Competition 2015.
We have to face the cold hard truth. It is never going to change. We have proved it is technically possible, not even that difficult, but all the powers that be do is look at our workarounds and then try to close them down.
Currently, the way around this problem is to:-
(a)Use CL_GUI_ALV_GRID
(b)Use one of the many workarounds you can find on the SCN as to how to make the CL_SALV_TABLE editable, though this is of course naughty
(c)Take a hybrid approach. Use the CL_SALV_TABLE to generate the field catalogue dynamically, and then pass that field catalogue into CL_GUI_ALV_GRID. There have been some articles on the SCN about that also.
Here is an example of such an approach by Łukasz Pęgiel :-
In conclusion, next year I will be publishing a blog celebrating the 9th annual International Editable SALV Day. See you then!
Cheersy Cheers
Paul