Fellow ABAP Developers,

I would like to raise a possible issue or misunderstanding that I have come across recently when using the CL_SALV_TABLE->FACTORY method for generating ALV reports. It had recently come to my attention that when exporting a report to spreadsheet from ALV, that the negation symbols would be missing in a spreadsheet and output when the ALV originated from the CL_SALV_TABLE->FACTORY method. A SCN/Google search revealed only two previous posts on the matter which will be referenced below. The posts suggested solutions from anonymous users which resolve the issue but fail to adequately explain the behavior. I want to raise this again for discussion not only for clarity of the problem/misunderstanding but to make a point in the chance there are other developers out there who used this method but are not aware of the potential issue.


When using method CL_SALV_TABLE->FACTORY to generate ALV reports, negative signs or symbols do not come across for domains which do not have a “Sign” attribute for them flagged. This means inherently that these domains are not meant to have negations signs or any other symbols for that matter attached to them. However, even prior to CL_SALV… the use of these corresponding data types never seemed to be an issue for output to ALV when negation is done directly on the field. In fact, ALV always displays the correct value on screen (shows negative symbol) when using the REUSE FMs and CL_SALV_TABLE->FACTORY. The problem comes when the fields are exported to spreadsheet and possibly other methods (raw text) from ALV. In the case where this is exported to a spreadsheet from ALV, and using the CL_SALV_TABLE->FACTORY method to generate the ALV, the negative signs are missing. This behavior with the signs and spreadsheet export did not seem to be an issue when using the REUSE FMs.

In my experience, the spreadsheet export function is used very frequently in relation to ALV which is why I see this to be very problematic as one may view the data correctly on screen through ALV (negative sign shown) but when exported, the data is now invalidated because the sign is now missing.


As mentioned earlier, a simple internet search revealed two discussions on this:

1. http://scn.sap.com/thread/2069432

2. http://scn.sap.com/thread/1042384

Anonymous users suggested the following two solutions:

1. Do not use a data type of a domain that does not have their sign attribute flagged.

2. Call method on the columns experiencing this issue SET_SIGN( ‘X’ ).

ex. lo_column->set_sign( ‘X’).

The problem or misunderstanding with solution 1 is that this may not always be clear on what types to use for the ALV output, assuming the developer is aware of this potentiality and corruption of exported data.

The problem or misunderstanding with solution 2 is that the column type CL_SALV_COLUMN should have this attribute “SIGN” set to true ( ‘X’ ) by default. This means that this is being overridden somewhere, but alas, could find no documentation which mentions this in the class tree or reasoning for this.


  1. Bring this potential problem to the attention of other developers who may have used this method incorrectly and have not checked the ALV export data which may contain negative signs.
  • This problem misunderstanding could be easy for a ABAP developer to miss especially if they are migrating from the REUSE FMs.
  • It may also be harder to catch the issue as the spreadsheet export might not be checked as the ALV on screen output shows the correct symbol.
  1. Why, in more depth, does this behavior occur?
  • Data is displayed correctly in ALV on screen but not in the export.
  • This did not appear to be an issue with RESUE FMs.
  • Why and where does the SIGN attribute get set to FALSE for column type CL_SALV_COLUMN when using the FACTORY method?
  1. Was this behavior intended for CL_SALV_TABLE ALV use and the developer must explicitly set the SIGN attribute where this behavior for effected columns may occur?
  • Would it be better if the class default for attribute SIGN be left TRUE for CL_SALV_COLUMN?
    • What advantage is there for a user to explicitly define this if the problem/understanding can be avoided altogether if this remains TRUE?
      • Perhaps other issues arise when this is set to TRUE?

     4. Are there any other similar caveats such as this one that a developer migrating to CL_SALV from the REUSE FMs should be aware of?

To report this post you need to login first.

1 Comment

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

Leave a Reply