Changing column order in SALV report and maintainability

[Jelena]

Dear Gurus, Wizards, Clerics of Level 5 and beyond, and other SAP Community members!

We have an SALV report that includes information about two different sales document types and some related fields. "As is" situation: 3 structures are defined, one for each document type (let's call those VBAK_A and VBAK_B) and third one for miscellaneous fields. There is a SELECT with JOIN on 2 VBAKs and Z table that connects the documents by number. This reads the data into an internal table defined using the first two structures. Then the rest of the data is added and at the end using MOVE-CORRESPONDING the whole shebang is placed into the final ALV table.

This works perfectly for adding new fields. Just add it to the respective structure then to SELECT and be done with it. But, of course, the users ruin everything.

Now the end users want to add some related delivery fields (which are in LIKP/LIPS) and they're adamant those fields must be placed in the middle of VBAK fields. If I add those fields to the VBAK_A / VBAK_B structures then that messes up SELECT mentioned above. (Can't use SELECT INTO CORRESPONDING because I'm selecting from two VBAKs using aliases and field names in the structure also have to be different, like A_VKORG and B_VKORG.)

So the question is: how to re-order the columns while keeping the report as simple to maintain as possible? Below are the options I came up with, none is perfect, so still looking for alternatives. Keep in mind this is 7.31 version (no CDS views and such).
1. Tell the users to take a hike and use a layout - tried and this wasn't met with great enthusiasm by the users.
2. Change the definition of final ALV internal table to put the fields in the order the users want. This would mean that going forward we would also have to add new fields to yet another structure. Was hoping to avoid this.
3. Use SET_COLUMN_POSITION method (like mentioned here) before displaying ALV. But this would mean always assigning column numbers manually, so much worse than previous option.
4. Put the fields in the right order in the current structures and in SELECT use "AS..." for the fields - tried and it makes SELECT so terribly long that ABAP Editor can't even handle it and starts freezing with some C parser error.

[matt]

4) Wow, really? I've had that problem in an AMDP, but never with OpenSQL.

[fabianlupa]

I don't understand the reasoning behind not using layouts. If you define the layout, set the column order as desired, set the layout as default with the SALV method and transport the layout with the report the users shouldn't even notice and you can maintain the displayed column order without changing the source code.

Or am I missing something obvious?

[Jelena]

"That's what she (=me) said". 🙂 I've been telling them the same thing: the report just provides you "baseline" information. The way you want to present it is up to you. That's why we have layouts, so that everyone could customize it the way they want. And default layout is for everyone.

I didn't know the ALV layouts can be transported though. Just ran a quick search and what do you know - there is a note for this. With this in mind, simply forcing a default layout is definitely the best option. I'll see if I can get away with this.

Thank you!

[DoanManhQuynh]

I dont know this solution suitable or not but I think it could be resolved using RTTS.

Ideal is, you already have internal table with structure type including 3 structure VBAK_A, VBAK_B, LIKP. create component for each struture then you can loop through those components table and create a new structure, after that move coressponding:

lo_struct ?= cl_abap_structdescr=>describe_by_data( ls_tab-vbak_a ).

lt_comp1 = lo_struct->get_components( ).



lo_struct ?= cl_abap_structdescr=>describe_by_data( ls_tab-vbak_b ).

lt_comp2 = lo_struct->get_components( ).



lo_struct ?= cl_abap_structdescr=>describe_by_data( ls_tab-likp ).

lt_comp3 = lo_struct->get_components( ).



APPEND LINES OF lt_comp1 TO lt_comp.

APPEND LINES OF lt_comp3 TO lt_comp. "Here i switch likp into middle of vbak_a and vbak_b

APPEND LINES OF lt_comp2 TO lt_comp.

above is just move all the likp into middle of the others structure but you can also loop through the components table and do much more complex assignment.

[Jelena]

Thanks for a reply! The report already includes 3 different structure types in the final ALV table. The challenge here is that now I have a "mix and match" of the fields. Before the ALV structure was like: VBAK_A fields, VBAK_B fields, the rest of the world. Now they want it like this: some VBAK_A fields, LIKP fields, some more VBAK_A fields, some VBAK_B fields, some other fields, more VBAK_B, etc. How to mix-up the fields but keep the report simple at the same time is what I'm trying to find out.

In the option you're suggesting the devil is in the details: "here I switch" - how exactly would you do that? Wouldn't this require coding the field names? How else would the program know what the field order is? Manual "re-ordering" is what I'm trying to avoid. Otherwise if someone wants to add a new field not only they have to add it to a structure and SELECT but also ensure the field order.

[DoanManhQuynh]

how the computer know what they should to know is what we tell them to know :). you told about maintain the order of field in select query also maintain the structures you created... then i proposed this solution that you dont have to do that. the point is after you select all data, using RTTS to get itab structure and re-sort it by order of end user. "here i switch" mean that, its not magic, just using field name like you said, or insert, read, loop etc...using index too.

you dont want to hard code, i got your point here so it may better to use layout setting. otherwise, if you dont tell abap which order these fields should shown, it couldnt be done.

[Jelena]

matthew.billingham - yep, thought it was a GUI problem but we have latest and greatest and as soon as I changed SELECT back to fewer lines the error magically went away. Yesterday we also found a report that apparently ran over the limit on the allowed SELECT WHERE... IN... items. Fun times. 🙂

[SimoneMilesi]

The real question is: if you have so many fields, how could be it useful for the users?
I mean, over 20 fields, you have so many informations you just get confused.

[Jelena]

simone.milesi - I'm not really sure how they're handling this. It's possible there are 2-3 groups of users and they are looking at different fields. Most columns are pretty narrow though, so the report is not terribly wide at least.