Supported by
Supported by Inetum

The round-about routes of VALUE CHECK

images/thumbnail.jpg - Thumbnail

Have you ever come up against something in ABAP that seems to be one thing but is in fact another? The documentation says it is this and everything seems to indicate that it is, but after all it isn’t.

You’ve probably needed to, when setting a parameter in the report selection screen, check the possibilities of what the user can input to the available values in the data type of that parameter, right? VALUE CHECK exists for this. It seems simple. For example, it was assumed that the following might work:

PARAMETERS: P_BUKRS LIKE T001-BUKRS OBLIGATORY VALUE CHECK.

When you check, it doesn’t work.

The T001-BUKRS field is the BUKRS type, which is of the BUKRS domain which in turn has the T001 table of values defined, for which BUKRS is the only primary key. Even so this, lamentably, does not work. It does not work because, for some unfortunate reason, contrary to what would make sense and is understood from the documentation, CHECK VALUE does not take into account the domain of the field it validates. For this to work, the referred field needs to have an external key for the table of values.

In our case, therefore, although the table containing the list of possible values of BUKRS is T001 , for VALUE CHECK to work we have to first refer to some other table that has T001 defined as the external key. Such as T001K , for example:

PARAMETERS: P_BUKRS LIKE <strong>T001K</strong>-BUKRS OBLIGATORY VALUE CHECK.

Now it will work.

In summary: as you already know the table with possible values, instead of being able to use it you have to find another that defines it as the external key. This is complicating the simple with round-about routes. A rhetorician would call it circumlocution. I call it stupidity. I bet it’s a bug that SAP has proudly decided to ignore for ever.

Thank you Luís Rocha for the tip.

Greetings from Abapinho.