Skip to Content
Technical Articles

Replacing the good old maintenance view generator?

The view maintenance generator is one of the oldest functions of the SAP system. It is an easy way to generate a standard maintenance functionality to custom tables or views. The generated programs are used with transaction SM30 “table maintenance”. This technique is used all over the SAP system, mainly in customizing transactions.


The maintenance generator works like charm but has some annyoing limitations for users and also for developers. What do you expect from a modern table maintenance and what options are there?

Great tool

If generated the table maintenance, you have lots of basic features for maintaining a table or view.

  • adding entries
  • deleting entries
  • editing entries
  • copying entries
  • positioning to a specific entry
  • show only entries with specific values
  • transportation of entries of a customizing table
  • undo changes
  • authority check on group or table
  • built-in address support
  • built-in text support
  • time dependency possible
  • built-in feature for translation
  • value comparison to other SAP system

There are also some great features from programmers point of view:

  • easy to create
    • define read-only fields
    • define hidden fields
    • define subset fields
    • define selection
  • automatic search values
  • automatic check of foreign keys
  • easy to change
  • easily enhanceble by events
  • can be called from outside
    • with select options
    • given data
  • Dynpros can be modified to own needs
  • In addition with view clusters it is really easy to build “cockpit transactions” and combining tables


there are some limitations which make working with the table maintenance transaction really annoying.

From users view I would mention the following points:

  • The lines to copy and paste are limited by screen size. If you want to copy 100 lines from excel you will have to copy and paste in blocks
  • If there are list boxes or check boxes, then copy and paste for these fields is simply not possible
  • If there is a detail screen then copy and paste for a bunch of entries is also not possible
  • No search functionality (positioning on one entry is only possible for key fields)
  • the are of the table control is always too small if there are more than “some” fields in the table (depends on the fields length)
  • marking different entries is only possible with “block marking” which is not user friendly
  • If there are errors in copied entries than there will be on error for each field which is really annoying if you accidentally hit enter before having changed the key values…
  • Editing data always locks the complete table.

If you look from developers side I see these pain points:

  • It is not possible to influence the design of the maintenance screen
    • If a field points to a domain that has fix values then the field will be created as listbox
    • If a field is boolean, than the field will be created as checkbox
    • If there are currency or amount fields, then they might be “forgotten” in overview screen and appear only in the detail screen
  • there is a lot of generated code which might cause some trouble when changing table fields or view options
  • if there is the need to modify the changes then there is no place to document these changes. You can only set the flag “cannot be adapted automatically”
  • the given events are often insufficient

Little Enhancements

There are so many little things that would make the table maintenance much more comfortable. I do not understand why SAP did not improve this main feature of the SAP eco system. First I thought, ok, there will come S/4HANA and the SAPGUI will die so there will be something more modern that will replace this old fashioned table maintenenace based on table controls.

But even in times of HANA, Fiori and CDS-Views NOTHING CHANGED… 🙁

Modernizing SM30

I often thought about how easy it was to enhancing the table maintenance generator. It would be so easy to add an additional screen in the generator where all fields are listed and you can define the field length or the type of the field (listbox, checkbox).

Or adding a memo field where you could shortly document the changes made in the dynpro.

Simply setting the area for the table control to the maximum of 255 characters (maybe this already happenend in some late release…? I am not sure.)

But enhancing this really old generator might not be the best solution. So what options are there to provide a state-of-the-art maintenance which could be easily enhanced?


My expectations to a modern data maintenance are the following:

  • easy and simple to setup
    • no generated code if not necessary
    • authorization options
  • copy and paste from and to excel
  • value filter
  • search option
  • visualizing changed and new entries
  • summary of wrong input instead of one error message for each wrong entry

From developers point of view I would like to have these possibilities:

  • events for evaluating data and after input
  • events for selecting data (authorization, evaluation)
  • events for display options (changing cell colours etc)
  • adding random fields (descriptional texts, information for the changed field like material type of the material)
  • clear indicators of which entries have been changed, deleted, inserted
  • transportation must be possible for customizing tables
  • customizable double click features for field values
    • example: clicking on cell MATNR fills parameter id MAT with the field value and jumps to transaction MM03


In my opinion there are two techniques which might be used for a modern table maintenance:

  1. ALV-Grid with customizing and additional code
  2. CDS-View with Fiory application

I am ABAP programmer since R/3 Release 2.1i  and so I have lots of know how for ALV grid programming. But I hardly know about the “web stuff”.

Option 1: ALV-Grid

ALV-Grid editing is not really easy but I could imagine a program that can dynamically handle any dictionary table or view and provide editing functions.

There are some hard tasks to be solved, but not impossible.

In the ALV-Grid you have a lot of standard functionality like copy and paste, search, filters, layout options and some other. Meanwhile the ALV-Grid cells also have an input history!!

Although there are really a lot of things to think about, it should not be too complex to design a framework that

  • automatically allows editing any table
  • displaying additional descriptional fields for field values
    • -> foreign key table
      • -> text table
        • -> read text in logon language
  • Implementing interfaces or BAdIs where special checks can be programmed

Option 2: CDS-View based

CDS-Views are very powerful. You can define complex selections and enhance the views quite comfortable. There are features where you can generate a ui5 application for a CDS-View with editing functionality and detail view. You will have to set up the right annotations and some other stuff. I also can imagine a program that generates the view with the needed annotations and then generates the maintenance app.

I am not sure about the mass editing functions (copy and paste from excel) and the ability to implement transportation issues for customizing tables.

OK, let’s go…

Uwe Fetzer said: Start a project on Github ?

Before I start I need a project name (like GRETA = “Generic Reliable Editable Table Application” or something like that…) and I would like to hear your suggestions… 😉

Is SM30 ok for the next 10 years?

Did I miss a feature that is important for you?

Is there a functionality you always missed?

Any ideas on technical design?


Current status of project

You must be Logged on to comment or reply to a post.
  • Hello this is a very good project, but in my knowledge Alv with SALV class is not editable easily.

    And for cds view lot of Sap customer don't have hana or fiori?

    I follow this project.

    • Thanks for your interest!

      I am not sure if ALV-Grid is the next out-dated technique?!

      And CDS Views and Fiori will come as sure as death and taxes... 😉

    • Not difficult either, just hacky.

      You need a child class of cl_salv_model.

      From there you can grab the controller, and from there the internal grid object.

      data: table type ref to cl_salv_table,
            grid_adap TYPE REF TO CL_SALV_GRID_ADAPTER,
            grid      TYPE REF TO CL_GUI_ALV_GRID.
        data(controller) = table->r_controller.
          full_adap ?= r_controller->r_adapter.
          grid = full_adap->get_grid( ).
        catch cx_root.
          grid_adap ?= r_controller->r_adapter.
          grid = grid_adap->get_grid( ).

      Whether it's worth the hassle is another story. Personally I just hate creating field catalogs so I do use this

  • This is a very good thing. Especially if you plan this right you don't need to choose if the view is fiori or alv grid based. You can implement both.

    Is SM30 ok for the next 10 years?

    Currently I don't know how SM30 is implemented for an S4/Hana System and especially if SAP has any plans to replace / rework the SM30 - but to answer the question above - no. The SM30 is not okay for another 10 years or more.

    And in times with ABAPGit and Github it is quite easy to develop such a new tool as a customer. And because you asked if you missed a feature - if we start such a project, it will grow automatically and new features will be added more or less frequently.


  • First let me thank you for an interesting read and your detailed point of view.

    Then second, on the opinion part, I consider the maintenance view creator sufficient as it is. It’s a fast & easy way to create a maintainable table. And the most annoying thing in my opinion is the screen-area-size issue, but that is solved in S/4 HANA 1610. And even before, redesigning the view is not that much an effort (just double-click the screen number and go).

    As far as the why, that is mostly related to the fact that I only use the tool for customizing tables (or custom master data), which implies that there is a limited amount of time that a user spends using the tool. And again, this limited use also implies that I’ve rarely encountered the need to use events as well.

    So it’s all a matter of pro’s and con’s I guess, but the tool remains fast & easy. Creating all requires only 5-10 minutes..

    Now, recently a customer wanted a better looking & more user friendly interface (because the data was more reliable to change), and so we turned to the newer program models. Create a CDS, generate an oData service and use Fiori Elements to generate the application. And of course we had to write some code in the oData service to do the CUD part of CRUD. But it took us way more as 10 minutes to get it done..

    But of course, if someone would provide a better tool (or a CUTE-r one), I’m surely gonna try it out and use it.



    • Hey Patrick, thank you for sharing your experience with maintenance views!

      In my projects I have encountered the opposite. There was often the need to make the editing dialog smarter.

      You say, that it is sufficient to have a "poor" solution when it's used only a limited time. I partly agree... If there are some basic settings need to be done, it is sufficient. But if like every year or every month there are some changes then the dialog should be comfortable in a way that the user can easily see what has to be done. Simple maintenance views are often "cryptic" because of missing additional information (descriptive texts) or visual details (icons, colors). So if the view is used rarely but constantly the maintenance should be easy to understand.

      Yes, creating is fast & easy, but it generates a lot of artefacts in the system, which IMHO is not necessary. It is not seasonable.

      • True, and I think we agree Enno.

        In fact, I'm mostly running with this: if the tool doesn't fit the requirements, pick another tool.

        (Though if this turns into a cost/time issue, then it might happen that the requirements are changed.. sometimes we developers want to push it too far and are gold-plating without realising it 🙂 )


        • At least there is no other tool... ;(

          (Though if this turns into a cost/time issue, then it might happen that the requirements are changed.. sometimes we developers want to push it too far and are gold-plating without realising it ? )

          haha, yes that's true. But often this also comes from the customers side. Often without knowing that this causes a lot of work and the programmer simply implements it w/o pointing to the unusual or time consuming issue.

  • SM30 - Yes it could use a rework.

    What I use it for now is as above "master" data or Z configuration tables.  It's only used internally in IT and by super users.

    The users generally hate it.  So I use a different tool.  Yes, it involves creating a custom program.  It is a lot longer than 15 minutes.

    It would be really cool to have a quick and easy way to create a user friendly interface.  "CUTE" is a perfect name.

      • It depends on the table(s).   ALV is usually a nice option.  If I use that it can be hours to days.  Then of course there is the trusty classic dynpro.  That is usually a project that lasts longer.  They want to do more than just modify/add/delete.  They want some facts and figures.  They might want some mass update too.

        So I would love to see your new ideas.  Something that I could give my end users that didn't take so long to develop would be a win.


  • I developed a framework already, but it need a small class (with respect to an interface) to be implemented for each table. It might be possible to generate it... However, the code belongs to my client.

    There is a problem with editable ALV. If the dataset is too large, you can't deal with it all at once. So if for example, you filter your dataset by a specific field, and there are maybe 1000 entries, and then you delete those records, it will only delete those that are visible - not all of them.


    • That's an important point. Thanks! I was sure that I once read about a short cut that causes the grid to load all lines at once and not only after scrolling, but I might be wrong. I haven't found any hints about this... :/

        • You are right.

          I thought the problem is only with copy, but I can confirm there is also a problem with delete function.

          I have been able to reproduce it with a larger dataset.


          To be more accurate, the problem isn't with visible records, but with "loaded" records (some of them might not be visible on screen).

  • /
  • While it does not cover all the listed requirements, I created once an FM what is generating a selection screen + editable ALV for any table. I use it when SM30 is not sufficient - could be a good starting point.

  • Don't we have the starting point already?

    If we enhance the SE16N with authorization checks and CTS connection most of the work would be done already.

  • Did I miss a feature that is important for you?

    Business Configuration Sets! If you want to deliver default values for your application and you are not SAP so you cannot somehow provide them in client 000 you can use BC Sets which bundle table contents directly or based on IMG activities (and the maintenance views) in a workbench object. This is a very good alternative to delivering a report which fills all tables with defaults as you can also easily compare your current customizing values with the BC sets. This is also the approach abapGit uses currently to support customizing.

    The generated dialogs using TMG have some support for BC-sets, so you can look up if an entry was created by a BC-set and in the customizing IMG you can chose to display available BC-sets for the activity. Also I think (not entirely sure) when importing the BC-set the maintenance dialog is executed using BDC, which is also why you need to adjust the modification flag of the dialog if you modified the dynpro logic in an incompatible way.

    Also I guess if you create something else for table maintenance the integration with IMG activities will be a bit more manual (no automatic grouping by IMG activity in customizing transports, you have to create a tcode for every table you want to maintain to include it in an activity (?), no generation of the transport object in SOBJ?).

    • Hey Fabian,
      Thanks for mentioning the BC sets! I left them out because I never understood what these were for and how they are used. In more than 20 years of SAP consulting / programming I never got in (productive) touch with BC sets...

      The possibility to integrate alternative maintenance views in IMG should be discussed/ checked. that was not an important point for me, but eventually for others.

        • People who use BC sets are at least those who use abapGit for developing applications which need to be delivered with some initial customizing. I also use them for automating daily backup via abapGit (I had to create a program to write customizing table contents to automatically refresh data in those BC sets before abapGit runs).

          • Christian, it's a very simple program which manually recreates existing BC sets, with more or less the same function modules as in abapGit (SCPR_TR_READ_DATA, SCPR_CT_TRANSPORT_CHECK, SCPR_TEMPL_MN_TEMPLATE_SAVE), by selecting all customizing tables belonging to given packages (the ones I daily backup with abapGit). Here is my selection screen. I run the program right before ZABAPGIT.

  • Sound like a great project (although I would have expected that these improvements will be delivered by SAP and not as a community project).


    I would like to add a few points to the expectations list:

    • View cluster (Hierarchical view)
      In my opinion, the integration of multiple views in a view cluster (SM34) is one of greatest strengths of the maintenance view framework.
    • (Automatic) preceding selection screen
      Such screen can be implemented manually already now (using FM VIEW_MAINTENANCE_CALL), but it requires a manual implementation for each and every view.
    • Custom additional functions/buttons
      Can be implemented already now, but it's quite cumbersome: It requires a complete cloning of all GUI statuses.
    • Hey Shai,

      i have waited long enough for an alternative to sm30... 🙂 I also think that SAP should have provided a modern solution.

      Thanks for listing your expactations. Good Points! Selection screen is planned. Custom Buttons is a very good Idea! And yes, CUTE should also be capable of being used in view cluster. I have that in mind and I think that the most use cases (level 2 automatically linked to the key fields of level 1 table) can be implemented quite easy.

  • Regarding "Editing data always locks the complete table":

    • For the matter of fact, in case you use subsets, it would lock only the processed subset.
    • I once tried to implement locks in record level (only for updated records), but it quite fast led to overflow of SAP lock table.
    • Thanks for sharing your information about locking entries, Shai! I think the best way of locking is the one you mentioned: selection screen and then locking these keys. If someone calls the complete table then everything is locked... ¯\_(ツ)_/¯

      • Just take into account that in case of large datasets, you should better define "subsets" and lock these (instead of record keys). Otherwise, in case you lock all record keys, an overflow in lock table will occur.

  • I use SE16N_INTERFACE function module whenever I try to edit a table. It does most of the checks for me. What it doesn't support is Events and that is a very critical functionality for a generic table maintenance program.

  • I wrote such a beast once (editable ALV grid which dynamically reads the table definition).

    On the section screen you said what table you wanted (lots of checks were done of course) and there was a button to pop up the selection screen whit the selection fields generated dynamically.

    Initially I did not do anything very clever for reasons which will become obvious shortly. The most important thing was to be able to upload from the clipboard, and naturally to download to excel as well.

    I gave it to some end users to use who had never even seen the IMG or used SM30 type table maintenance views, but they were to be in charge of the customising for this new area.

    They loved the thing ... and here is why.

    The elephant in the room is that it is quite difficult to edit data using an ALV grid. The cells are just too small and when you put your cursor in an empty cell often you have to blank out the existing entry (e.g. the quantity zero)  which defaulted itself there.

    So when my users wanted to update the customising they downloaded the table to Excel, did all their changes there and then put the entire table on the clipboard and uploaded it again. If it was up to them they would never change one value inside SAP.

    We then had to go all over the top bonkers and develop an application to do integrity checks on the data uploaded to SAP before they could save it ... and the users could define the integrity check rules ... using the very same ALV table maintenance thing ...

    Since none of them had ever done any customising in SAP before they all thought this was perfectly normal and presumed that was how all customising in SAP was done...

    Cheersy Cheers


    • Hey Paul,

      why am I not surprised about your first sentence? 😀

      yes, there are some issues editing the ALV grid...

      At least you have the input history for fields which was one of the most arguements against the grid.

      The integrity checks must of course be done. But these are no others than in the normal SM30, are they?

      I am quite happy with the current status of the project so far (see github). Yesterday I tried to join the text table which was quite a big effort (a lot more than I expected).

  • Hi Enno,

    great to see some progress in the field of making tables editable more easily and bringing the User Interface to a next level.

    We have taken a look at the same problem two years ago and decided to take an commercial approach to the problem and created a product, NextTables.

    NexTables became available officially in early 2019. It is SAP plattform based, has an ABAP backend is extensible via BAdIs and configurable via a web frontend.

    It might be worthwhile for the readers out there to be aware of this alternative. If you want to remove this comment, no problem with that as well.

    Here are all the details:

    Feedback is very welcome 😉




    • Hey Sebastian!

      Your tool looks really great! Comfortable and user-friendly. I see the hard work behind it!

      A web ui has a lot of advantages.

      Good luck for your product - CUTE will come...! 😀


  • Hi Enno,

    have you already checked the new ABAP Restful Programming Model aka RAP here ?

    It is now available on S/4 1909. The model allows a simplified OData publishing from a business object based on CDS. With the help of UI annotations in the CDS a UI5 template similiar to SM30 maintenance view is automatically generated. You can then create a stand alone Fiori app with the embedded template or use it as a part of a more comprehensive app.



    • Hey Eskender,

      Thanks for your comment! Yes, I know about this feature.

      My goal is to have some generic customizable function where nothing has to be generated.

      ~ Enno

  • Moin Enno,

    great post. At the moment, I am pondering over how to implement a modern interface for an SM30 table view.

    While searching for some technical updates (my system is a non-S/4-system), I now wonder, if SM30 maintenance view is the right technique at all.

    Did you pursue this project?

    If yes, I am very interessed in the results 🙂

    Thank you + Cheers,


    • Hey Marcus Preis

      thanks for your comment! All the Pros and Cons have been discussed above. I created this project because I think that SM30 is not adequate anymore.

      I have corrupted my local project with my last enhancements and didn't get it back to working again... 🙁

      The next steps was to implement some kind of plugins for specials fields. But I have no really good concept so far. As I just said, the last efforts went slightly wrong...


  • Here's my point of view. Some kind of modern staging would be awesome, but being aware of CTS and the well known tools and processes around it, i somehow can only imagine this in kind of a long term topic for SAP... So, if you want to create customizing even in s4, you do have to use sm30 and table generation...

    The quite cool things about sm30 is, how fast, reliable and powerful it is... Mass edit customizing, compare easily, check changedocs and so on... But i think quite a lot of consultants don't need these things so excessively. To be honest, i don't see the Fiori Controls handle this kind of versatility.

    What i see - there is just a slightly change coming with Fiori. Launchpad Customizing and Variant Management. But the web-abstraction of the CTS-features seem surprisingly inadequate and incoherent. You can add customizing to a transport, but can't create a transport.

    I personally would love to model the customizing using BOPF exposing it using ODATA, but i haven't looked into how i could make those customizeable in SM30 as well, which would be a win. If somebody has a hint, i would be quite happy.

    So, any news or probably unknown directions/development we are maybe not aware of?