So what is “RENAMING WITH SUFFIX” ?
It is an addition for INCLUDE :
INCLUDE { {TYPE struc_type} | {STRUCTURE struc} }
        [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:
/wp-content/uploads/2013/10/capture_20131010_090634_295464.png

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:

Clipboard03.jpg

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Daniel Klein

    We are using ZZ-Fields for adding additional data. And we did not have any request of adding a field with the same name as SAP-standard ones…

    The suffix is only useful if you are copying many fields via MOVE-CORRESPONDING and don’t want to mix the standard structure up.

    (0) 
    1. Eitan Rosenberg Post author

      Hi,

      The “RENAMING WITH SUFFIX” is very useful in any case where you want to have groups of fields (within the same structure)

      addressed under one name and still avoid name conflict in individual fields.

      Please dl http://scn.sap.com/servlet/JiveServlet/download/47512-1-202753/Y_R_EITAN_TEST_06_03.txt.zip

      and have a look there at there .

      You are right about the MOVE-CORRESPONDING and I did mention it in this document.

      Regards .

      (0) 
    2. Custodio de Oliveira

      Daniel Klein wrote:

      We are using ZZ-Fields for adding additional data. And we did not have any request of adding a field with the same name as SAP-standard ones

      And how do you know SAP is not going to add new fields which has the same names as the ones you created?

      (0) 
      1. Daniel Klein

        because of the namespace we use.

        ZZ and YY are reserved for customer fields.

        see https://help.sap.com/saphelp_nw04s/helpdata/en/cf/21eb61446011d189700000e8322d00/content.htm

        “The customer creates append structures in the customer namespace. The append structure is thus protected against overwriting during an upgrade. The fields in the append structure should also reside in the customer namespace, that is the field names should begin with ZZ or YY. This prevents name conflicts with fields inserted in the table by SAP.”

        (0) 
  2. Matthew Billingham

    I could see this would be useful for old programs, but I very rarely use includes. The most common use of includes is

    1. A replacement for proper modularisation – this is bad. Proper modularisation means function modules and classes (and in old SAP versions, performs).

    2. Common data declaration – this is bad because it means you are using global data

    3. Common forms – this is bad because a change to the include changes all the programs that use the include.

    There are a lot of discussions about using cl_alv_table_create=>create_dynamic_table so I am not going to do that .

    This is good, because the correct way to handle dynamic tables is via RTTS.

    (0) 
    1. Eitan Rosenberg Post author

      Hi,

      I think that we have to be more pragmatic when we are dealing with SAP which means that we have to choose the most cost
      effective tools and technique for the current task .

      “Common data declaration – this is bad because it means you are using global data”
        I fully agree. We have to minimize the number of those pesky variables to the minimum required by system .
        But until SAP will give full OO support to to every element of programing (this means also Module Pool)
        I guess we have to use what we have on hand this means also using global data (There, I said it….).
       
      “Common forms – this is bad because a change to the include changes all the programs that use the include.”
      Very bad. I hate those there is no excuse to use them.

      “RENAMING WITH SUFFIX” is a tool to define types and needs to be treated as such (Like every other tecnology that is availble)

      By the way the program included “Y_R_EITAN_TEST_06_03” the only “global data” is the input parameters.
      (There was a left over so I updated the source)

      /wp-content/uploads/2014/04/screenshot_01_427511.png

      Regard.

      (0) 

Leave a Reply