Skip to Content
Author's profile photo Tobias Reiner Dolgener

Dangerous Modifications – How to avoid error message KM133?

In my work life as a SAP Support Engineer in the SD ERP billing area, I often face delicate situations. Sure, for the functioning of an ERP system the invoicing process is of major importance. Without issueing an invoice and posting the amount receivable to accounting, it would be difficult to generate revenue.

If you get an error here, which you can not solve yourself, then often urgent assistance is called for. More so, when the month end or year end accounting period is close, and something has to be posted, but failed.

On one of my last week-end shifts, I had to assist in such a critical case.

The invoice could not be released to accounting, because the error message KM133 appeared:


Unlike to other error messages, here not much information is shown in the help text. “Currency/valuation type does not exist” – this is a system error – contact the SAP Hotline”.

  • Why did this error occur?
  • What had been the root cause?
  • How can it be resolved?

For those questions I had to find an answer. The month end closing was not possible, the invoice process and related update to the FI module blocked. Such challenges, where as well time pressure is on, are very demanding. For me this is also motivating, in the limited time avalailable I can test my knowledge and analysis abilities. If I can find the solution, then of course this is also an accomplishment and gives me a feeling of being successful.

In my opinion, the cases, where an error message is given, can be investigated more easily, because often in the program code those have a designated place. In transaction SE91 you can check this:


The message error consists of two parts, the “message class” (which is here “KM“) and the number (133). After entering this information on the main screen, clicking on the display button will show the description of it:


Then after marking the line and clicking on the “where-used” button (alternatively press Ctrl + Shift + F3), by choosing “programs”, you can list the relevant places in the coding:


As a starting point it can be known that in these three listed programs the KM133 could be issued. With debugging (/h) I could identify that the error  occurs in the last one, include LPC50U02:


Then here in the coding, it can be seen why the error message is  given. The field for the currency valuation type (I_CVTP) is not filled and empty, therefore the system can not find it in the related customizing table TCVAL, the select fails with sy-subrc = 4 and the error has to be raised.

But hen this is only the reason for the error, the hard part of the analysis work is to find the root cause. Why is this field empty?

Here to go further, good debugging skills and some experience are required. Important to know is that the process of the accounting document creation starts with function module RV_ACCOUNTING_DOCUMENT_CREATE. The investigation will have to start there, with the execution of this function. Then the structure, which keeps the values and the currency type in the SD-FI interface is XACCCR.

By observing the filling of this structure I could identify that a modification with custom-code is responsible for the error. Before the user-exit EXIT_SAPLV60B_008 is executed, the date in the structure is stil complete:


But then after the code in the exit had been processed by the system, it is obvious that a manipulation had been done in XACCCR, with missing CURTP:


A new line had been appended and several fields remain empty. This is the later cause why the KM133 error occurs. The currency valuation type is missing:


Success! The solution could be found.

To avoid such issues, it is absolutely necessary to test exactly what effect does own coding have on the standard behavior! What is intended? Is the processed data complete?

I would also suggest to study note 301077, which contains an overview of the available user-exits in the SD-FI interface. There you can find a description, which user-exit is intended for what modifications.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Maria Du
      Maria Du

      I like it.

      thank you.

      Author's profile photo Tobias Reiner Dolgener
      Tobias Reiner Dolgener
      Blog Post Author

      謝謝 Maria!

      Author's profile photo Former Member
      Former Member

      Very Good.Thank u

      Author's profile photo Tobias Reiner Dolgener
      Tobias Reiner Dolgener
      Blog Post Author

      Thank you NIGIL Wilson for your positive feedback!

      Author's profile photo Amitesh Anand
      Amitesh Anand

      Thanks Tobias for such a nice document, and your way of presentation is very systematic which helps understand the issue and the resolution.

      Author's profile photo Tobias Reiner Dolgener
      Tobias Reiner Dolgener
      Blog Post Author

      Thanks Amitesh Anand !

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Another very useful way of finding the location of an error is to create a watchpoint in the debugger on sy-msgno, with sy-msgno = 133 (for example). The debugger will then stop at the location where the message is issued - even if it's done in some disguised manner not visible using SE91.

      Should it turn out that more than one message with the same number is issued, then keep going until sy-msgid has the correct value, although I've been using this method for years and never had this happen!

      Finally, I'd strongly recommend that you learn to use the new debugger. It's way more powerful than the old one, and has only been available for what, ten years?