- SAP Managed Tags:
So what is "RENAMING WITH SUFFIX" ?
It is an addition for INCLUDE :
INCLUDE { {TYPE struc_type} | {STRUCTURE struc} }
[AS name [RENAMING WITH SUFFIX suffix]].
[AS name [RENAMING WITH SUFFIX suffix]].
So why am I such an admirer of this addition ? because it is a building block easily overlooked that a got a lot of potential .
usage scenarios:
Isolation of program changes
We are maintaining a very old ALV report program (Not ours !!! we were not born when it was written....) and we need to add new fields to the report.
So we add the new fields to the structure just to find out that the same fields name were was used or we simply want to isolate our changes to reduce the chance of breaking something...
The program is complex and we do not want to start analyzing it (Time !!!) .
RWS (Renaming With Suffix....) for the rescue !!!
Note the use of the qualifier MODS_1 for addressing.
*----------------------------------------------------------------------*
FORM test_6_1 .
*----------------------------------------------------------------------*
TYPES: BEGIN OF tp_mods_1 .
TYPES: field_01 TYPE string ,
field_02 TYPE string ,
field_03 TYPE string .
TYPES: END OF tp_mods_1 .
*----------------------------------------------------------------------*
TYPES: BEGIN OF tp_work_1 .
TYPES: field_02 TYPE string .
TYPES: END OF tp_work_1 .
*----------------------------------------------------------------------*
* The report structure type
TYPES: BEGIN OF tp_report .
* Those are the existing fields .
TYPES: field_01 TYPE string ,
field_02 TYPE string ,
field_03 TYPE string ,
* Long list of fields
field_99 TYPE string .
* Those are our new fields .
INCLUDE TYPE tp_mods_1 AS mods_1 RENAMING WITH SUFFIX _mods_1 .
TYPES: END OF tp_report.
DATA: st_report TYPE tp_report .
*----------------------------------------------------------------------*
*----------------------------------------------------------------------*
st_report-field_01 = 'This is st_report-field_01 ' .
DATA: st_work_1 TYPE tp_work_1 .
st_work_1-field_02 = 'I am from st_work_1-field_02' .
DATA: st_mods_1 TYPE tp_mods_1 .
* Here we can limit the target area using "-mods_1"
MOVE-CORRESPONDING st_work_1 TO st_report-mods_1 .
* Access individuals fields
st_report-mods_1-field_01 = 'This is st_report-mods_1-field_01 ' .
st_report-field_03_mods_1 = 'This is st_report-mods_1-field_03 aka field_03_mods_1 ' .
* Examine st_report
BREAK-POINT .
ENDFORM . "test_6_1
*----------------------------------------------------------------------*
And this is what we have in st_report:
Cross Tab (aka dynamic columns ) .
Another usage scenario where RWS shine is in the Cross Tab reports.
There are a lot of discussions about using cl_alv_table_create=>create_dynamic_table so I am not going to do that .
But what about those cases where the number of columns is not in the thousands ? do we really need create columns at run time ?
The reason I am saying that is because it simpler and cheaper to develop a program that use a fix number of columns .
Our mission:
A weekly report based on SFLIGHT and in this report for each week we need the total of PAYMENTSUM,SEATSOCC.
We need to cover a year . So it seems that we will have to create at least 53 * 2 = 106 fields .
What will happen if we also at some point want to add SEATSOCC_B and SEATSOCC_F for each week ? well this seems quite a lot...
Lets see how we can reduce the burden:
Program Y_R_EITAN_TEST_06_03 (Attached) will demonstrate it.
Our data setup looks like this:
*----------------------------------------------------------------------*
* For each week we want "Total of current bookings","Occupied seats in economy class"
TYPES: BEGIN OF tp_ent_xxx .
TYPES: paymentsum TYPE sflight-paymentsum ,
seatsocc TYPE sflight-seatsocc .
TYPES: END OF tp_ent_xxx .
TYPES: tp_sum_xxx TYPE tp_ent_xxx .
*----------------------------------------------------------------------*
*----------------------------------------------------------------------*
TYPES: BEGIN OF tp_vald_1 .
* Note the RENAMING WITH SUFFIX .
INCLUDE TYPE tp_ent_xxx AS ent_001 RENAMING WITH SUFFIX _ent_001 .
INCLUDE TYPE tp_ent_xxx AS ent_002 RENAMING WITH SUFFIX _ent_002 .
INCLUDE TYPE tp_ent_xxx AS ent_003 RENAMING WITH SUFFIX _ent_003 .
INCLUDE TYPE tp_ent_xxx AS ent_004 RENAMING WITH SUFFIX _ent_004 .
Up to.....
INCLUDE TYPE tp_ent_xxx AS ent_052 RENAMING WITH SUFFIX _ent_052 .
INCLUDE TYPE tp_ent_xxx AS ent_053 RENAMING WITH SUFFIX _ent_053 .
INCLUDE TYPE tp_sum_xxx AS sum_xxx RENAMING WITH SUFFIX _sum_xxx .
*----------------------------------------------------------------------*
This will generate our weekly sets.
If we need to add more fields for each week we only need to add them to type tp_ent_xxx .
The program analyze the data and will display only the active weeks .
This is done by using the set_technical method (The progam is using cl_salv_table).
In case of cl_gui_alv_grid we can use the field catalog (lvc_s_fcat-tech) .
This is the output from this program:
9 Comments
