Menu

Implementing Additional Checks in Table Maintenance Dialogs

DevWorkbench    Monday August 18th, 2014   

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

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

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.