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.

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 enteredSELECT 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.