I have used field exits since several years ago and I have had some nightmares with them also
Then I want to share some hints about field-exit uses:
1. What is a data type ?
In my personal opinion, the purpose of data types is misunderstood and undervalued by many ABAP programmers.
This is specially true when programmers only develop for one country and do not need translations (example: you develop for a company working in Spain, then you define the titles only in spanish but if you are developing for a multinational company you MUST define titles in several languages). The use of data type for internationalization is very valuable.
In this thinking line, data types have "semantic" in the sense that they helps to provide meaning to entities (type of data) created and living within the ABAP workspace.
Another point is: data types create standardization within the system. Every time a field is created using a data type, the field get the same characteristics and meaning of any other field created using the same data type.
Finally, the obvious: data type helps to verify and control data quality and data restrictions (through domains, off course).
2. Why field exits ?
Each field exit works attached to a data type.
Field exits go one step further in data quality management. It is possible to implement complex data checking via field exits or data checking that depend on the specific dynpro (transaction), user, etc.
3. What can not be done via field exit ?
Field exits have some limits by design:
a. Field exit only can issue an error message, not warning and not informative messages.
It has not sense informing that the data input is correct but it has sense only to inform when the data is incorrect.
b. Field exit can not retrieve some environment information
As far as I know, a field exit CAN obtain general information from the system (sy- variables) but it can not obtain information about the programm/transaction variables. Field exit purpose is to verify input values alone.
It is possible to use some tricks to transfer information from outside to the field exit (set parameter, for example) but, in my experience, these tricks easily fails (and the field exit could cause problems).
4 Some hints
a. Grouping
It is a good idea creating functions groups dedicated only to field exits. These groups must contain no more than 5 field exits or so in order to make them manageable. Off course, grouping must reflect some criteria: field exits created within a certain development project, field exits related with certain business functionality, etc.
b. Scope
It is a bad idea (very bad ) assigning "global" scope to a field exit, the consequences could be a general problem because the data type could be used in several different transactions.
It is possible to perform an analysis using "where used references" in ABAP workbench but, in general, this analysis would be very time consuming and it is, by far, better to assign the field exit only to selected dynpros.
Another point about scope: refreshing a field exit to implement a change in it (when transporting to a productive system in line) seams to have a bigger delay when the field exit is working in many dynpros and sometimes the refresh must be forced (there is a standard report to force the refresh).
I hope this reflections would help you programmers to understand and use successfully field exits as a powerful and helpful tool.
