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.
tl;dr
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
But…
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?
Expectations
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
Options
In my opinion there are two techniques which might be used for a modern table maintenance:
- ALV-Grid with customizing and additional code
- 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
- -> text table
- -> foreign key table
- 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…
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?
Cheers
~Enno
~Enno
Nenhum comentário:
Postar um comentário