How to analyze an error message in debug

Very often an error or warning message is not clear or does not provide the necessary details to find the exact
cause of the error.
A classic example is the error message 'The date 00.00.0000 is not convertible (please correct)' which can be
triggered in several transactions. When this message is triggered by MRP or in transaction MD04, it does not
specify exactly what is the planning element for which the error happened.
Another typical issue is a custom error message being triggered by an exit or BAdI, but you don't know exactly
which exit or BAdI is triggering the message.
For such cases, there is a very simple trick to find exactly where the error message is triggered.
Lets see a very basic example. I'll get into transaction CO02 and enter a production order that does not exist.
The following error message will be triggered:

The last three digits are always the message number and the rest is the message ID.
When a message is triggered by the system, the message ID is stored on SY-MSGID and the message
number is stored on SY-MSGNO
Now I want to know exactly where this error message is triggered.
Open transaction CO02, enter a production order that does not exist on the database. Type '/H' on
the command to open debug and press enter.
Click the button 'Watchpoint' to create a new watchpoint.

Generated by Jive on 2015-10-16+02:00

1

How to analyze an error message in debug

You will get the following screen, where you will create a watchpoint for SY-MSGNO, where the value
of the variable is '017'. In some cases, you don`t know the message number, so you can leave the
condition empty. In such case, system will stop on every message, instead of goig directly to the
desired message.

Confirm and press F8 to continue with the program execution.

System will stop exactly on the point where the error message is triggered.

Generated by Jive on 2015-10-16+02:00

2

How to analyze an error message in debug

Here we can also check the values of the internal tables and see why the error message is triggered. We can
also see that the message is hardcoded as an error, because there is an 'e' before the message number.
Similarly, It would be possible to set a watchpoint for SY-MSGID, where the value is equal to 'CO'.
On this example, I can see that the error is happening after function module CO_DB_HEADER_READ is
called. This is the function module where the order header is read from the database, so I can get deeper into
the code to find exactly where the order is read.
With a little knowledge of code we can find the solution of problems that we would spent hours researching and
checking on the documentation.
Check also the following document for a quick step-by-step to analyze authorization in debug:
How to analyze authorization issues in debug

Generated by Jive on 2015-10-16+02:00

3

How to analyze an error message in debug

Generated by Jive on 2015-10-16+02:00

4