User exits have no defined interface, that is there is a lot of data available and a lot of program-internal data can be changed. Thus, the user exit is a very flexible and thus also a HIGHLY CRITICAL utility for customer-specific adjustments. When you use user exits for adjustments you must be very careful.
When you use user exits, we highly recommend that the functions you developed yourself should be programmed "switched", so when a problem occurs you can restrict whether it is caused by modifications in the user exit or if the problem is on SAP side.
For e.g: you define a user-specific ZZ* table with key "Modification" and attribute "active". This table contains an entry for each modification in a user exit. Before a customer-specific source code is processed by reading the customer-specific ZZ* table the system checks whether a user exit (and thus the respective modification) is active.
Changes to user exits in SD are MODIFICATIONS, since the original of an object belongs to SAP thus when you change a user exit an SSCR registration is also required.
Related: User Exits in Billing Document
Unlike the user exits described above, customer exits have a defined interface, that is you can only transfer certain fields to the interface and you can also only change certain fields in a customer exit. In addition, customer exits can be activated and deactivated and thus they can be "switched". With the activation of a project an object is created with the original on customer side, thus it is no modification but a customer-specific enhancement. When you use customer exits, you therefore do not need an SSCR registration either. If available you should use customer exits.
Of course, when you use customer exits for the correctness of the enhancement contents SAP cannot take on responsibility too.
E.g: in the SD billing document, for the SD/FI interface by customer exit the condition amount of every condition is split in half. Even though the customer-specific source code does not contain formal errors, from the business point of view the correctness of such an enhancement is extremely questionable.
Transaction VOFM is used to develop customer-specific routines for application areas, for e.g, conditions of pricing, output determination, data transport routines to copy quotations after sales order, sales order after delivery.
These routines are stored in Customizing of every application area (pricing, output determination, and so on), that is enhancements with VOFM can be activated/deactivated. SAP also delivers certain functions by VOFM.
For SAP routines and customer-specific routines, there are separate namespaces. Customer-specific VOFM routines also lie in the SAP namespace and must be assigned to an SAP development class that is, for customer-specific VOFM routines also SSCR registration must be carried out. As in SD user exits, in VOFM routines many fields and tables are available, thus the VOFM routines can be used very flexible and also highly critical. For the use of CUSTOMER-SPECIFIC VOFM routines the statements on the responsibility for enhancements by the customer, made for the user exits, apply (for example, maintenance responsibility, problems during upgrade).
Read Here for More SAP SD Tutorials