Change selection screen texts without hard coding them

images/thumbnail.jpg - Thumbnail

Even though many ABAP programmers tend to forget this, the less texts you hard code in your program the simpler it will be to translate it.

Here’s a simple but rather obscure way to manipulate selection screen texts while still being able to translate then. This way you can, for example, prefix them with icons.

The curious case of the partially protected structure

images/thumbnail.jpg - Thumbnail

The other day I was trying (and failing) to modify a line of a SORTED TABLE.

DDIC structure key

images/thumbnail.jpg - Thumbnail

Today when I want to create a SALV I always create a DDIC structure with the data elements already set to show the texts I need. This avoids the need for code to manipulate the field catalog.

APPEND STRUCTURES do more stuff than I thought

images/thumbnail.jpg - Thumbnail

During all my ABAPian life I was convinced that APPEND STRUCTURES had one single purpose: to add new extra fields to an existing standard table.

But I recently learned that they let you do two more things after all:

Thou shalt always use a predefined structure with ALV

images/thumbnail.jpg - Thumbnail

It is common to find an ALV data structure explicitly defined in the code. If this is done, the field catalog has to be manually constructed. If a predefined structure (from DDIC or declared as a TYPE) is used instead, the field catalog can be automatically built. This approach is always better and results in less code, even if the field catalog needs to be adjusted here and there. https://abapinho.com/en/2011/12/automatizar-catalogo-alv/

Thou shalt consider using SM34 clusters

images/thumbnail.jpg - Thumbnail

If a development requires more than one customising table consider grouping their maintenance views under a cluster. This way it will be more intuitive to maintain them. This makes even more sense if one depends on the other since in the cluster definition these relations can be explicitly defined.

Example: Como encavalitar tabelas (portuguese)

Thou shalt use a constants table

images/thumbnail.jpg - Thumbnail

Whenever you feel a constant value can change and you can’t add it as a user parameter, store it in ZCONSTS. This table should never be used directly. Instead, a class like ZCL_CONSTS should be created to properly access it, like shown in this article: https://abapinho.com/en/2009/06/constantes/ (portuguese only)

Resist the temptation of using T900 or similar tables for this purpose. It’s true that a lot of people do it. But it’s ugly, durty and besides these tables don’t even have an adequate key because they were not designed with this in mind.

SE16N's technical view

images/thumbnail.jpg - Thumbnail

Hi. How’ve you been? How’s life? All cool? This tip is so simple that if we don’t talk for a while it will all end too quickly. The sun is shinning. It rained in the morning but now it stopped.

Moving on.

Every time I see someone still using SE16 I wonder why, since SE16N is so much better and already exists for so long. But this is not the tip.

Adding values to a standard domain

images/thumbnail.jpg - Thumbnail

If you think it’s impossible to add values to a standard SAP domain without requesting an activation key, you’re wrong.

Compare a table across two systems

images/thumbnail.jpg - Thumbnail

The SCMP transaction compares the content of a table across two systems. It is very useful, especially for parameterization tables.

It is very easy to use. It allows for the pre-selection of the registers and fields to compare. It also allows you to only display the differences, which is convenient for tables with lots of data. I don’t think any more explaining is required. Ite et videte.

This tip recently appeared in the ex SAPtricks blog and I think it is so useful that I have reposted it here, in case you haven’t already seen it.