Menu

Implementing Additional Checks in Table Maintenance Dialogs

DevWorkbench    Monday August 18th, 2014   

In yesterday’s post about table maintenance dialogs, I discussed how to create a simple table maintenance dialog in SAP ERP. Today, I will explain how this dialog can be enhanced with additional logic, for example to implement custom checks on data entered.

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

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 (Info Icon). 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

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.

Variable interface for extended table maintenance

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.