In another post on the extended table maintenance feature of SAP ERP, I’ll explain today how to use the event AA to build a custom selection screen for extended table maintenance.
The problem with filtering in extended table maintenance
Generated table maintenance dialogs have some filtering capabilities by default. It is possible to restrict the displayed values via the menu entry Selection > By Contents, but the interface is quite complicated and cumbersome.
Wouldn’t it be much nicer if we could just have a selection screen to restrict the displayed values, just like we know from SE16 and any report transaction? Well, we can! SAP provides the event AA: Instead of the Standard Data Read Routine to do just that. Let’s walk through the necessary steps to create a custom selection screen for the SM30 maintenance functionality.
How to build a custom selection screen for SM30
The first step is to add the hook AA to the events overview. If you’ve read my last post about extended table maintenance, you already know how to do this. Open your table and go to the table maintenance generator. Then select Environment > Modification > Events to open the events overview. Add the event AA, enter a FORM name and save.
Now go to the editor. The first thing we need is, of course, the selection screen that we’re going to show. In my example, I’m defining a simple screen with just the company code as a parameter to restrict the values shown. In code, it looks like this.
* Define a custom selection screen. SELECTION-SCREEN: BEGIN OF SCREEN 10. PARAMETERS p_bukrs TYPE bukrs. SELECTION-SCREEN: END OF SCREEN 10.
Next, we need to define the FORM routine that is called by the event AA.
* This form is called by the event AA FORM custom_selscreen.
Since we’re implementing our own data reading routine, we would now have to read the data in table ZMYTABLE from the database. We could use OpenSQL for that, but there’s a better way. There are already pre-defined FORM routines that do the data reading job for us. They are:
- TABLE_GET_DATA if the underlying object is a table
- GET_DATA_<viewname> if the underlying object is a view.
In this case I’m using TABLE_GET_DATA since the maintenance generator is based directly on the data table.
* Read all data into TOTAL first PERFORM table_get_data.
After executing this call, all the data from the database is in the internal table TOTAL. After that is done, we can show our selection screen. Here it’s done as a modal popup by using the addition STARTING AT, but we could also omit that and display it as full-screen. After the popup has been executed, we have the filter value in the parameter P_BUKRS. I’ve added a statement that doesn’t apply the filter when the value is empty, but that’s optional.
* Call the custom selscreen as a popup CALL SCREEN 10 STARTING AT 20 10. * If the user didn't enter anything, don't filter CHECK p_bukrs IS NOT INITIAL.
Now, all we need to do is loop over the data in the table TOTAL, apply the filter condition, and remove the record from the table if it doesn’t match. In order to have structured access to the table, we need to define a structured variable first that the data is moved into. Remember: the structure of the TOTAL table equals the base table plus the structure VIMTBFLAGS.
* Define a structured variable to read data DATA BEGIN OF ls_total. INCLUDE TYPE zmytable. INCLUDE TYPE vimtbflags. DATA END OF ls_total. * Now apply the filter LOOP AT total. * Move data so it is accessible via structure ls_total = total. * Check if the given BUKRS is contained IF NOT ls_total-bukrs = p_bukrs. * Filter row DELETE total. ENDIF. ENDLOOP.
And we’re done! Check out the result of our programming by calling SM30 with your base table as parameter. The popup will look like this.
The resulting table view will only contain entries that adhere to the filtering conditions. That concludes today’s post – as usual, you will find the complete program on the next page.