Recently there was a question in the german DSAG Community if there is a trick to insert more lines at once into the table maintenance dialog than there are on the screen. Short answer: There isn't any easy way to do this.
Before I dig deeper into this topic and provide some solutions and workarounds, I would like to state that the lack of this - and other - functions is really a shame!!
SAP has become famous by Customizing. Nearly all of the customizing in an SAP-System is done by the generated table maintenance dialog. It hasn't changed for years. IMHO there is so much potential to improve data input.
The missing possibility of copying endless lines of data into a view is really annyoing. And there are some more functionalities that I am missing seen from users perspective:
Filtering data is very old-fashioned. You will have to select the fields you want to filter from a very small popup where the columns are sorted by name instead of using the sort order in table itself
it is not possible to sort data by column
it is not possible to move columns easily
From point of generating a table maintenance view there the following issues:
it is not possible to pre-define options
the visible size of a field
the type of field (checkbox, listbox)
fields of type decimals or integer will be moved from the overview screen to the detail screen even though there is no need for it
There is no place where modifications of the screens can be documented within the application. If you change the screen than you only can mark the dialog as "user changes are made - make sure to add them after generating the screens"
The only thing I recognized that has been fixed by SAP is the following:
Generating a table maintenance view created a table control with 80 characters in width so that many columns of wide tables are not directly displayed. The maxmimum possible value of 255 characters was not used. SAP changed that in some S/4HANA Release.
The selection of data and the behaviour of some standard functions can be enhanced or replaced by events. This is a good way to add customer specific behaviour.
But there are a lot of things that cannot be done by events because the event is executed at an unfavorable spot or it is even missing.
The data itself is stored in several data containers where EXTRACT and TOTAL are the most important ones. It is not clear when which data exists in these containers. The containers contain the data in a single character value. Therefore the data must always be assigned to a fitting data structure. Furthermore, there are two extra fields which should be considered when manipulating data.
I am sure that there are better ways to provide customer exits with a better API.
History and special features
I am aware that there are circumstances that make it hard or maybe impossible to replace such a central functionality like the table maintenance views. But I also think that SAP could have put some efforts to renew or modernize this medieval way of that entry.
The following functions come to my mind that are not so obvious and kind of hidden in the maintenance dialog:
Table comparison across systems
Usage in view clusters
It is possible to compare the current data with the data of remote systems. Data can also be taken over to update the current data.
The table comparison is not inseparable connected to the maintenance dialog so it should be possible to add this function easily to any other maintenance dialog.
BC-Sets are a powerful tool to define predefined data. You can save specific data as a BC-Set. This data can still be changed in the dialog but can also be recovered in the original version. Or data can be activated for special processes by getting the relevant data settings from a BC-Set.
As the BC-Sets refer to just data of a table it might be easy to adapt this function to any different working maintenance view.
Usage in View clusters
All table maintenance views can be used in a view cluster. In a view cluster there can be dependencies defined of how two or more tables are related to each other.
I believe that the current way of embedding maintenance views in a view cluster is way more complicated than it should be. In my opinion it should be a lot easier to define and implement dependencies using an ALV Grid.
I know that there is this BOPF-thing (Business Objects Processing Framework) and I thought, that this would replace the SM30-dialog, but 68fdcfd7801242baafce4e6cd1b5d218 answered in a question if BOPF could be used for customizing:
BOPF is not build to access (read and write) customizing tables. BOPF is built to work with transactional data, so only tables containing transactional data or master data should be accessed with BOPF. For customizing tables SM30 views are still the right tool.
So, we are still in need of SM30 dialogs...
Ideas for mass data entry
Back to main topic: how to add many lines of data into a maintenance view dialog. The way we all use to copy data into a maintenance dialog is the following:
Copy table data from another dialog by pressing CTRL+Y, marking entries, CTRL+C to copy the data.
Data can also be copied from Excel if the columns have the correct order
Inserting data by positioning the cursor in the first entry field of the first liine of the table control and pressing CTRL+V
Using this technique, you can only copy as many lines as there are shown on the dynpro. Mostly this is okay, because the essence of a customizing table is that there are not thousands of lines. But it is also common that customizing tables have hundreds of entries. And before I think of copying 20 times a block of data and inserting it to another table, I would be thankful for any other technique.
Here they are:
The SAPGUI provides the possibility of recording data input and automate it. This is nearly the same than Batch-Input. The difference is, that the scripts can be controlled by the user; there is no need to have an SAP report to insert the data. Another difference is, that the existence of dynpro elements can be checked. This makes it possible to only enter data in a field that is visible and ready for input.
The disadvantage of this solution is: It must be created for every new maintenance view. It is not generally usable.
There is a great (chargeable) product of the german company Ersasoft where recording can be done very easily: SimDia²
The table display transaction SE16N is the swiss knife of every SAP consultant. If you have the appropriate authorizations, you may enter data into a table by using transaction SE16N. If function code &SAP_EDIT works, then you simply can switch to edit mode. If not and you have the right to change values in debugging mode, then you can change the variables GD-EDIT and GD-SAPEDIT to "X" to achieve the same.
I hope that in most companies this only works in development and quality assurance systems and not in the production environment...! 😀 Even if it works, there are some circumstances where it might not work:
the foreign key might not me defined properly on dictionary level and only programmed be the dialog. in this case you might be able to enter data that are not valid
special checks that might be defined in the table maintenance view are not respected. Again, it's possible to enter invalid data
Dependent tables are not respected. sometimes it is important to fill dependent entries in another table. The maintenance dialog will inform you - SE16N will not.
At least I come to the most sensible option: A program! 😉 I am a developer and rarely do customizing. But the lack of mass data input in a customizing table triggers me from time to time. The forums question in the DSAG community now made me think of how a program should work to overcome this restriction.
The program can be used for every table where a table maintenance view exists for.
You have two choices:
import data from a CSV-file (not fully implemented; use of demo data)
import data from the clipboard (copied by Excel)
Mode of Operation
My solution needs to know the name of the table view of course. It will dynamically create an internal table with the tables structure. Additionally it adds the two fields ACTION and MARK. MARK is used by the table maintenance view for marking selected data. We do not need this. Important is the field ACTION where we define if the data entry should be inserted (N = new) or modified (U = update).
The data will be read from the desired source (file or clipboard) and split at the desired delimiter.
The created internal table with the imported data will be passed to function module VIEW_MAINTENANCE_GIVEN_DATA which displays it in the generated table view maintenance dialog.
My solution makes sure that only valid data can be inserted.