Modification of TMG without regeneration in SAP
What is TMG?
TMG (Table Maintenance Generator) is a tool used for maintaining entries in a table such as entering and deleting multiple records, triggering events while updating entries etc. TMG can be created using the transaction codes SE11 and SE54.
Why to modify the TMG without regenerating it?
Whenever a table is modified by inserting a new field, we have to regenerate the TMG (Table Maintenance Generator) to get the new field in the maintenance screen. It will be difficult to regenerate an existing TMG with lot of customizations made in code and screen. All those customizations will be lost during regeneration. So to retain the customizations made in TMG, a manual updating technique can be adopted.
Using TMG for maintaining entries in the table.
Before handling modification let us view an existing TMG. A custom table ‘ZNSFLIGHT’ is created and TMG is generated for demo purpose. This table is copied from the standard table ‘SFLIGHT’.
- Go to transaction SM30. Give your table name and click on the ‘DISPLAY’ button.
2. Click on the ‘DISPLAY/CHANGE’ button.
3. Now click on the ‘NEW ENTRIES’ button.
4. Add new entries and save it.
Modification of TMG without regeneration
Add a new field to the custom table ‘ZNSFLIGHT’ and activate it.
We have to include this field to the TMG of ‘ZNSFLIGHT’ without regenerating it.
- Go to transaction SE54. Give table name, select ‘Generated Objects’ and click on the ‘DISPLAY’ button.
2. Get the function group name.
3. Go to SE80 and open the corresponding function group’s code.
4. Expand the ‘Screens’ node and select the screen no: 002. (In my case, screen no: 002 is displayed for adding new entries in TMG).
5. Select the layout of the screen and click on the Dictionary/Program Fields button.
6. Give the table name and click on ‘Get from dictionary’.
7. Select the new field which was added to the table. (In this case ‘LAND1’ will be selected) and click ‘OK’.
8. Drag this field and add it with other input fields. Save and activate.
9. After screen modifications, activate the function group.
NB: There is one more addition we have to do in the code (flow logic of screen 002), that part will be discussed later in this document.
10. Now for testing the TMG, go to SM30, give the table name and click on the ‘Maintain’ button.
11. The new field added manually to the screen will be displayed now. Now click on the ‘New Entries’ button.
12. Add new entries and click the ‘Save’ button.
13. Now give another country and click the save button.
14. Here the new country is not modified. It will display the old value after saving.
15. In order to prevent this error, we have to modify the flow logic of the screen 002.
16. Go to SE80, give function group name and select the screen 002 and open the flow logic (Steps 3 and 4).
17. Give the new field name inside the CHAIN – ENDCHAIN, then save and activate the code.
18. To test the update functionality, go to transaction SM30, give the table name and click on the ‘Display’ button.
19. Next, click on the ‘Display/Change’ button.
20. Now Double click on the existing entry.
21. Provide another value in the ‘Country’ field and click ‘Save’ button.
22. Now the update function will work perfect.
Why were the customizations done in the first place in the TMG? Why were the TMG events not used?
BR,
Suhas
Hi Suhas,
This is a small example to show "how to update a TMG without regeneration"; just want to show it is possible to modify the TMG without regenaration 🙂 . Usage of TMG events is irrelevant in this simple example for adding one more field to the screen.
I didn't get u.
Few years back, we developed a bespoke process which had it's own application document type, status and version management. Like any standard SPRO nodes, we also created a separate tree for our development ( similar to transaction OLMW ) and added the customizing tables under nodes and subnodes. Lot of customizing tables , text tables, maintenance views and view clusters were created for the same.
To make the development look professional, we tried to copy the screen of sales doc type configuration ( transaction VOV8). If you see the overview screen of VOV8, the screen is designed manually. Now, if SAP decides to add a new element to the screen, it has to follow the steps provided in the blog otherwise the whole design will go haywire. In our case, also initially things went smooth. But later on, client asked for addition of new fields, so we too had no options but make changes without regenerating the screen. Since every step was well documented, support team didn't have any issue.
This kind of development makes sense, when everything is freezed and no more changes need to be done. Always better to follow standard process than look for a workaround.
Thanks Anson John Abraham for sharing this blog.
Regards,
DPM
Hi DEBOPRIYO MALLICK,
Thanks a lot for sharing your experience.
I too came across such situation where the existing TMG holds many custom codes and the plan for regeneration became a nightmare for me. After some surfing I got this idea to modify the TMG without regenerating it. I have added the new fields and everything worked perfectly. 🙂
Very Nice Document .. really helpful.. Thanks!!
Hi ishani Gupta,
Happy know that it was useful to you.
Thanks for sharing, it was very helpful.
Keep sharing this kind of stuffs. 🙂
Thanks,
Anubhab
Thanks for the feedback Anubhab Chirui
Nice article... Well Documented...
Thanks for the feedback Ravi.
John,
Thanks for sharing another way of adding new fields into TMG without regenerating.
But,when SAP provides the option of re-generating the TMG by just choosing the options in the menu bar why one will be interested in doing the same thing manually by adding code which is more error prone.Still,I prefer the regular way of regenerating the TMG which saves time,unless if there is any additional benefit of doing the same thing manually.
K.Kiran.
Hi Kiran,
This method will be useful when the function group associated with the TMG contains lot of custom codes and we don't want to loose it during the regeneration.
Why should it contain custom code in first place? If you are manipulating the TMG FuGr manually then there is a high probability of messing it up altogether.
Let me explain you the problem with an example.
- Suhas
Hi Suhas,
I came across this situation when I was working in a support project. My requirement was to add an extra field in an existing custom table and to make relevant changes in its TMG. I have gone through the funtion group of the TMG and found lot of customizations made in it. It was totally a chance of risk for me to regenerate it. Then I came up with a solution like this which will not mess up with the existing code. I have posted this article to share my experience and to give a new method to update the TMG. Also I accept that, this is not the standard way to update the TMG.
John,
Now I understood the situation and empathise with you on this approach considering one has to move the custom code to the corresponding events and then regenrate the TMG.
Earlier developer would have used EVENTS rather than coding direclty in generated INCLUDES.But still the risk of code getting vanished if somebody without checking regenrates the TMG for accomodating new fields at a later date.May be you can add table documentation warning the Developer that TMG has custom code without EVENTS.
K.Kiran.
Kiran,
I have done that 🙂
Experience shows that this approach is very far from the point where it would be advisable. Never do it this way, always try to do it be generating the TMG, use events. If all this fails, always keep your changes in a separate include.
But if SM30 is simply not suitable, maybe do not use it at all once you do not need the transporting mechanism etc.
Exactly, +1!
TMG is not supposed to handle all the fancy stuff users want it to do. If you don't think TMG events cannot help you achieve your requirement, then build a custom solution.
+1 😉
Nice and simple
Thanks for sharing it sir.
I was damn sure that there must be a way to add fields without regeneration .
Its really worthy for me. I have a question, If a TMG in which we are using events too..wants to regenerate.
At that situation will this procedure work ?
Thanks & Regards
Taran
It should work. Technically we are adding new fields to the table and updating the module program to consider the new fields while updating data. We are not modifying the codes written inside the events.
I also suggest you to consider the standard methods while modifying the TMG. Please read the comments provided by the experts above.
Regards,
Anson
thanks for the info
Guys,
Its a good Article.. .thanks for your efforts.
But here is the easy way yo do this....
http://www.sapyard.com/sap-tmg-no-need-to-delete-regenrate-after-change-of-table-structure/
Regards,
Bharathiyar S.