SAP SD Debit Memo Debugging
When you are developing your inner Sherlock Holmes to hunt down and kill a tricky system issue, debugging in SAP can be frustrating.
Stalled Testing Teams Are Expensive
Your SD Debit Memo issue can be a show stopper for your testing team. Your solution can't be released to production until this problem is solved! How are you going to work your way out of this situation?
Here are 7 Different Ways to Solve Your Debit Memo Issue
In this Blog, we are going to show you 7 different ways to solving your issue -- using a typical contract to Debit Memo (DMR) issue in SAP's SD - Sales and Distribution module. This process can be applied to other modules just the same.
Problem Statement:
A service contract debit memo request is to be billed and invoiced. This step works fine in DEV, however in the test system (TST) the DMR loses the reference to the service contract and therefore a wrong quantity is referenced.
Use the SAP ABAP Debugger to See the Contract Reference
Using the SAP ABAP debugger, we can see that VBAP (DMR item table) is already missing the contract reference before COBL_FUELLEN, this is the spot where the reference is missing in TST, but it is present in DEV. This is a hint that during contract reference the VBELV (contract ID) reference is not established.
Puzzle: where is VBELV filled in DEV, and what is causing the failure in TST?
Tracking down this broken link can lead you to expend a few hours of expensive debugging time that may not yield the correct fix. Often this is caused by having too much confidence in your initial assessment of this issue. And as a result jumping to unsupported conclusions. How you start oftentimes dictates if you are successful or not.
But it can get a lot worse
During any debugging session, unrelated topics seem to want to bubble up to the surface that really have nothing to do with finding the final fix. They are like Gremlins sent by the IT Gods to distract you!
How do you fix this?
Focus, focus, focus.
Here are 7 focusing steps to successful closure
Not at all a trivial question, while multiple areas in SD - Sales and Distribution could be touched, how do you narrow down and find the culprit?
- Check any non-released transports, config or development in DEV. If it is not released it won't exist in TST.
This is why you need to know how the current transport system is setup and the transport path. - Compare customizing objects between DEV and TST, such as
Item Category, Requirements type and class, copy routines between the header and item have to be consistent. - Compare key code pages if enhancement spots, BADI (Business Add-In), or user exits are active in both systems.
If data is manipulated in a BADI in DEV that is not active in TST, this may be the culprit. - Compare master data such as the material master setup.
The material master used on the contract depicting a service leads to many details on the contract item. For example, the material master determines the item category indirectly and the requirements class which sets the item's special stock indicator. In our case we seek to set special stock indicator "E" for sales order stock. - If all above fails, run two concurrent debugging sessions between both systems side-by-side.
A dual-monitor setup or using a large display can be advantageous as you want to see both debugging sessions next to each other, showing the code page as well as the call stack and key data points. Use corresponding break-points, rolling up towards the critical section where the difference occurs. - Compare your service contract setup in both systems DEV and TST
Make sure the contract header and items are set up in the exact same way in both systems,- otherwise you can't be 100% sure the difference won't cause the disruption. - While comparing the service contracts, it may not be enough to look at the contract transaction screens only (VA43). You would be well advised to review the entire header and item tables in SE16/SE16N.
The tables are VBAK, VBAP, VBRP, etc.
We got lucky! AMO* - in our case we found that the plant was missing on the DMR, and low and behold, also it was missing on the service contract line item in TST. However, it was present in DEV. The plant prevented SOBKZ = "E" and VBELV and item to come in. Problem solved.
*) AMO - A miracle occurred.
Lessons Learned
- First off, unintentional user error can lead to issues. Lack of knowledge of the SAP data model can sometimes lead to incomplete data.
It is not easy to get your mind around the SAP data model . - Second lesson learned is to follow a methodical proven troubleshooting process like the one we outlined above.
- Don't spend too much time trying to solve the issue yourself, give it the old college try, but then document the issue, and
don't hesitate to reach out to your consultants sooner, and move on.
Summary
We love to help our customers succeed. That's why we write these short tutorials so that everybody can learn from our experience. If you would like to talk to someone from Detering Consulting or me, press this button and let's see if I can help you
Key Words:
VBAP-VBELV originating document and VGBEL, SOBKZ, Item category, document type, copy control, Copy Routine 151, VOFM, vbap, COBL_FUELLEN, VBAK, VBAP, VBRP, MARA, MVKE.