Purpose of this Document
The purpose of this document is to explain how you can debug an error message that is raised when output SPED is creating a delivery. SPED is an output that will create an inbound delivery from an outbound delivery. An error may occur during the processing of the SPED output. This error is stored in the processing log of the output and the inbound delivery is not created. This document shall illustrate how you can debug such an issue.
Motivation for this Document
As a trouble-shooter of LE-SHP issues, I would often be presented with the problem “Sped fails to create the inbound delivery”. Looking at the processing log of output SPED, I would usually see the error message preventing the creation of the delivery. The next step is to debug the error message to see why & where the error is being raised. To debug the error, I set a watchpoint on the message number (system field SY-MSGNO) and try to reproduce the issue. However, the watchpoint is never reached, yet the error is still raised. This prompted me to ask: “Where is this error raised?”, “Why is my watchpoint not reached?”. Digging deeper into the code, I discovered the answers to these questions. The motivation behind this document is to share this knowledge and to empower the reader to debug SPED error messages.
An Example
Outbound delivery is created. SPED has been determined (See figure 1)
Figure 1: SPED determined in outbound delivery, not yet processed because GI not posted.
The goods issue of the outbound delivery is posted. However, the red traffic light shows us that SPED failed (See figure 2)
Figure 2: SPED has failed
The first place to check why SPED fails is the processing log (See Figure 3):
Figure 3: Processing Log
We can see that error VL377 is the error causing a problem. If the long text is not sufficient, the trouble-shooter will proceed to reproduce the issue and debug to catch where the error is raised.
Debugging the error message
The SPED output is usually processed in the update task. Furthermore, the SPED coding processes the message in the background task. This means that there are certain flags that need to be set in the debugger for the system to reach the watchpoint.
1) Before saving the delivery, turn on the debugger and switch on update debugging (See figure 4)
Figure 4: Turn on Update Debugging. Menu: Settings - Display/Change Debugger settings
2) Save the delivery. This triggers update debugging (See figure 5) where the SPED coding is executed.
Figure 5: Update debugger triggered
3) In another session, go to customising transaction V/34 to check the processing routine assigned to output SPED (See figure 6)
Figure 6: V/34 – take note of the program / form assigned to the output
4) In the update debugger session (step 2), set a breakpoint at program /SPE/STO_ID_PROCESSING / Form STO_ID_CREATION (from step 3)
Figure 7: Breakpoint at output processing routine
5) Press F8 to get to the breakpoint (See figure 8).
Figure 8: Breakpoint is reached at output processing routine
6) Reading the code, you will see the following:
* (0) Redirect this NAST processing to separate LUW - in case it is * called with processing time 4 (Immediate) in the update task CALL FUNCTION '/SPE/CALL_PROC_IN_NEW_LUW' EXPORTING is_nast = nast IMPORTING ef_leave = lf_leave. |
In this function, the system executes the following code:
* Exit here if it is NOT called in UPDATE TASK from delivery processing * ... otherwise start new LUW (tRFC) to process this message |
In this code, you can see that function /SPE/CALL_PROC_NAST is called in the background task. This means that setting a watchpoint on SY-MSGNO will not be reached if the error is raised in that function.
7) Before the code reachs the “Call Function ‘/SPE/CALL_PROC_NAST’ IN BACKGROUND TASK”, you need to set the “TRFC (in Background Task): Block Sending” flag in the debugger (See figure 9):
Figure 9: Set the flag to prevent function from being processed in background
8) Press F8 to continue the process. You will receive an update termination message (as you interrupted the update).
9) Go to transaction SM58 and search for the entry you just created. Place cursor on the function module (Figure 10)
Figure 10: SM58 – place cursor on the function module.
10) Follow the menu path: Edit – Debug LUW (Figure 16). This will open the debugger. Here, you can set the watchpoint on SY-MSGNO = 377. If raised, your watchpoint should be reached (Figure 17). This answers the question “Where is this error raised?” which was asked at the beginning of this document. You can then continue your analysis from here.
Figure 11: Debug LUW Menu
Figure 12: Watchpoint on SY-MSGNO is reached
Conclusion
The above example uses error VL377. The long text of this error is clear and usually you would not have to debug VL377. However, there are other errors that do not contain such a clear long text. The above procedure can be applied to any error message arising from the SPED delivery creation.
Being able to debug SPED errors allows me to see exactly where and why the error message is being raised. It saves the trouble-shooter the time of searching SPRO for the appropriate setting as they can see the exact setting they are looking for in the code.
If you have any thoughts, insights or tips on the above content, I welcome your feedback. I will strive to improve the above content based on any feedback received.