Skip to Content

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.
  • 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.

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