Implementing Additional Checks in Table Maintenance Dialogs

Use case

A typical business case for the use of additional checks is the implementation of additional checking logic for data which the user entered. In my case, I’ll use the same table as last time, which has the company code as a key field. I will implement a check to verify that the company code that is entered actually exists.

Using table maintenance dialog events

The implementation of custom logic in table maintenance dialogs is done using so-called events. To get access to these, select Environment > Modification > Events from the menu while in the table maintenance generator screen.

How to call the events screen

You will get a popup informing you that you’re changing SAP data, which you can safely ignore. In the list that is opened, you have to select which event you want to use. Each event is tied to a certain point in the data maintenance process – if you’re familiar with the hooks programming pattern, that’s exactly what it is.

Your next task will be to pick the correct event for the job you want to do. Since there are close to 40 different events available, it’s best to use the SAP documentation for extended table maintenance events, which you can also access via the information button (). For my example, I want to perform a check after data was entered. The correct event for this is 05. You also need to enter a form routine name. Click Save after you’ve entered your data (important!) and click on the button in the Editor column afterwards.

Adding a new event implementation

After you have added your include, you’re taken to the ABAP Editor. This is the place where you can implement your custom check logic. Before I’m going into the details of the programming itself, let me explain which variables are available to work with the data in the table.

Interface variables to work with used data

The interface for these hooks is always the same. There’s a set of variables and internal tables that let you work with the data in the table control. It’s documented for each event induvidually (such as for event 01), but the generally available variables are the following.

Internal table TOTAL

The internal table TOTAL contains the complete dataset that is held in the table you are working with. Its structure is a combination of the base table structure and the structure VIMTBFLAGS. This structure contains fields that indicate the processing status of the table row.

Field symbols <ACTION> and <ACTION_TEXT>

Via these field symbols, you can access the processing status of the current table row of table TOTAL, which means they mark if the record was created, updated, or deleted. These field symbols should only be used for events that are called once for each table entry, meaning that they are executed in a loop.

If you want to read the processing status of table rows manually, it’s better to use the field VIM_ACT from the structure VIMTBFLAGS. <ACTION> indicates the processing status of the table itself. <ACTION_TEXT> is used if your underlying data table has a text table attached, and indicates the processing status of the text table.

The following constants are available to check the processing status.

• NEUER (value “N”) – new entry
• AENDERN (value “U”) – updated entry
• GELOESCHT (value “D”) – deleted entry
• ORIGINAL (value “”) – unchanged entry
• NEUER_GELOESCHT (value “X”) – new entry, deleted again
• UPDATE_GELOESCHT (value “Y”) – updated entry, deleted again

Internal table EXTRACT

While the table TOTAL contains all of the data that is in the data table, EXTRACT is the data subset that the user is currently working with. The exact contents of this table depend on the function the user is currently executing within the SM30 transaction. If he is adding new lines, the table EXTRACT will contain only the newly entered lines, while the table TOTAL will contain all old lines plus the new lines. The table EXTRACT has exactly the same structure as the table TOTAL. More information on table extracts can be found here: SAP documentation for table extracts.

Field symbols <XACT> and <XACT_TEXT>

These field symbols work exactly in the same way as the <ACTION> and <ACTION_TEXT> ones, but for the EXTRACT table. They, too, should only be used with events that are called in a loop.

Field symbol <STATUS>

This field symbol provides access to some general information. Especially important is the field <STATUS>-UPD_FLAG, which indicates if any data was changed in the table control.

Structure with the name of your table

Especially important for the event 05 (after adding new entries), this structure will hold the newly-entered data before it is moved to the main table. It can be accessed via the name of your custom table (in my case, the name is ZMYTABLE) and can be used for data checks.

Some of the available variables for extended table maintenance

These are the most important variables that are available in the extended table maintenance interface. There are a few more, but they are used only in special cases or only in a few events. On the next page, I will show you how to use these variables to implement a simple check on entered data.

Implementation of custom table maintenance logic in ABAP

Remember the include file you were taken to when you clicked the Editor button in the events screen? That’s where we’ll continue now. I hope you remember the name of the FORM you provided in the events overview, because this is the routine we have to implement now. Unfortunately, it’s not generated automatically. It takes no parameters, so the first step is to add just a simple FORM with no parameters to your include.

*----------------------------------------*
***INCLUDE LZMYTABLE_MAINTF01.
*----------------------------------------*
FORM check_data.

ENDFORM.                    "check_data 

This is what we’re starting out with. Now, it’s important to know what we want to actually check. Since the event 05 is called in a loop for each new entry made by the user, we have a rather simple job. We don’t need to check any flags or processing statuses. All we need to do is take the user-entered data and do a check with it. The complete implementation of the event looks like this.

Complete event implementation

FORM check_data.
 
  DATA lv_bukrs TYPE bukrs.
 
* Check the company code that was entered
  SELECT SINGLE bukrs 
    FROM t001 
    INTO lv_bukrs 
    WHERE bukrs = zmytable-bukrs.

   IF sy-subrc <> 0.
     MESSAGE e000 
       WITH 'This Company Code does not exist.'.
   ENDIF.
 
 ENDFORM.                    "check_data 

Notice that here, I’ve used the zmytable structure to read the user data. The reason for this is the point in time at which event 05 is called. Here, the entered data has not been transferred to TOTAL or EXTRACT yet, because we have a chance to do checks on the data first.

Now, whenever the user enters a company code, the FORM routine will check if it is valid. If it’s not, then an error message will be shown and the user has a chance to correct the data.

The custom check is working perfectly.

This concludes today’s post on extended table maintenance. The next post will be about maintenance views, and how they can be used to give the user additional information.

List of SAP table maintenance dialog events

The SAP documentation for these events can be found here: SAP documentation for extended table maintenance events