Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

How to find the fields that are made 'Required' in screens modified by a Support Pack Upgrade

0 Kudos


Is there a way to find the fields that were made 'Required' in the screens modified by a support pack upgrade.

I am able to find the list of screens that were modified, but not the changes to the fields within those screens.

Tables D020S has some screen info, and D021T seems to have field descriptions;

Which table is the Input 'Required' field stored for a screen field. Appreciate responses.

Thanks in advance,



Active Contributor
0 Kudos

You have the menu version management -> comparison in dynpros (transaction SE51), to display the differences. between the support package and the previous version.

0 Kudos

Thank you Sandra for the response.

I should have been more clear.

I would like to mass compare a lot of screens ( in the thousands ) to find the ones with new mandatory fields. The SPs implemented delivered over 5000 screen changes, and some of these would now have required fields. I would like to find these fields and in the related screens.

0 Kudos

That's a really titanic task, I don't think it's the usual way to do it; I'm pretty sure there are "release" notes about the general functional changes. After that, all batch input custom programs should be tested again to make sure they work.

Note that relying on the "required" attribute is not sufficient. There are probably as many checks inside the ABAP code as via the dynpro attribute.

In solution manager, there's a tool (CDMC - change impact analysis), but I remember this kind of analysis did not exist when I looked at it (in 7.1 or 7.2).

Anyway, you are the last one to decide. You should debug SE51 to see how the version comparison is achieved. I guess you should use SVRS_GET_VERSION_DIRECTORY_46 (valid in 7.4), to get each version (equivalent to the internal statement IMPORT DYNPRO, but the function module is for versions). You get the dynpro in an obscure format ("required" is in bit 3 of FLG3 of D021S table), so you may prefer using the function module RPY_DYNPRO_CVT_INTO_EXTFORMAT to convert this obscure format in a more readable format.

As I said previously, I think it will take you much more time to develop and analyze, than solving the probable very few issues in the test system or even in the production system.

0 Kudos

Another thing, in the 5000 dynpros, only a few ones are of some interest for you, I think, if it's about checking the impact for custom batch input programs. If so, you might reduce the list to only the dynpros you have "batch inputed". You could search for CALL TRANSACTION or BDC_OPEN_GROUP in all your custom programs, and then get the list of dynpros manually. Then you do the intersection between the 5000 dynpros and your "batch inputed" dynpros, and you analyze manually those dynpros instead of spending time to develop a too much complicated tool.