Search This Blog...

Monday, January 30, 2012

Best practice functional consulting for user exits

For certain business cases, we cannot use standard SAP functionalities / configurations as a direct solution. In order to cater for such situations, SAP has provided these user exits. This enables you to use ABAP coding to define your own solutions / logic's as an enhancement to the existing functionality. For example, let's say you have multiple sales organizations in your organization. In the sales order creations transaction, if you want to do specific checks based on your sales organization, you can use user exits provided under include MV45AFZZ.
Some of these are; USEREXIT_DELETE_DOCUMENT, USEREXIT_FIELD_MODIFICATION, USEREXIT_MOVE_FIELD_TO_VBAK, USEREXIT_MOVE_FIELD_TO_VBAP, USEREXIT_SAVE_DOCUMENT
You can find the documentation on these user exits under IMG path: Sales and Distribution / System Modifications / User Exits

Key points to remember....

• Always check alternative solutions available -
Don't think user exit is the first solution available in SAP. Always try to find standard SAP solutions available. Check on internet / blogs to see any alternative solutions. Choose last options as user exits.

• Use the correct user exit for your requirement -
If you are not aware about the correct user exit to be used, please get in touch with your technical consultant or ABAP developer to find the exact location where the enhancement should be included.
Simple check that you can do is; place a break point in the user exit and execute relevant SAP transaction. Check whether system stops at the break point. Check whether all required data is available at that point. If everything is perfect, then you can use that user exit for your purpose.

• Document your requirement and enhancement required -
Always prepare a functional specification for your requirement. Include the functional flow in SAP. Mention the requirement properly, what needs to be done, expected outcome, etc. If possible include test data as well. More the details you include, better the clarity for the developer. Always use point form. Don't write paragraphs.

• If possible do a system walk through with the developer -
If possible, sit with your ABAP developer and show him what exactly you want. Same should be representing in the functional specification as well. Most of the time, this is much effective than asking the developer to go through the functional specification alone and do the changes. This will save testing / bug fixing time later.

• Keep documentation for future reference -
Save your functional specifications in a central location, where everyone can easily access. This includes documents like, functional specification, test data, user manuals, etc. These documents can be used to understand the functionality at a later point of time. Therefore future changes in the same area can be accommodated without impacting to the existing functionality. It is very important to keep the final version in the central location! Do not mix versions in your local machine.

• Use developer notes in the user exit -
Encourage developer to put a note in the user exit. This note should include a summary of enhancement and link to the documentation.

• Never use hard coding -
This is the most important point to remember by all functional and technical consultants.
Don't use the any hard coding in the ABAP code. If you use such hard coding, future business changes cannot be accommodated without changing your ABAP code.
Let's say you have mentioned sales organizations in the ABAP code -> if VBAK - VKORG = 'A100' OR VBAK - VKORG = 'A300'
In such a case, future changes in the organization structure (Such as adding new sales organization, say "A400") can only be accommodated via ABAP code change. This means you need to change the ABAP code to include your new sales organization.

How to avoid hard coding -

Ask developer to code a generic code in the user exit, which checks a custom table (Z table) for the logic, organization values and activation flag. Use this table to activate / deactivate your enhancements for relevant org unit.
In above mentioned case, you will have 2 entries in the table for VKORG "A100" & "A300" with the active flag. User exit is coded to check this table for relevant entry with the activation flag. Since it is active in the table, enhancement should work. For later changes (such as adding new sales organization) can be easily incorporated by adding another line to the above table with the active flag. Therefore no ABAP code changes are required!
Same table can be used as a central location to activate / deactivate all user exits in your SAP system.
Enhance same table to provide a reference to your central documentation as well.

By: Anupa Wijesinghe
E-Mail: anupaw@gmail.com
Blog: www.learnsaptips.com/

2 comments:

  1. Hello,

    I really appreciate reading your note. I just have one remark regarding variablization of some elements in abap code (in your example sales org if I remember well).
    You can use a central specific table as you described what is the best solution for me or if you do not have any other choice (customer requirement for example), you can create one variable (select options) in TVARVC table through STVARV transaction.
    Only the TVARVC variable name will be hardcoded in Abap program.

    That is an alternative solution.

    Greetings,

    Sapconsultant

    ReplyDelete
    Replies
    1. I forgot to precise that the main disadvantage of this solution is that you can not use "where used" functionality in SE11 transaction.

      Delete