Skip to Content

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:

1_KM133_VF01.gif

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:

SE91.gif

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:

Where_used2.gif

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:

Programs.gif

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:


5_KM133_raised.gif

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:

2_XACCCR_before.gif

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:

3_XACCCR_after.gif

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:

4_CURTP_missing.gif

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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

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

    (0) 
  2. 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?

    (0) 

Leave a Reply