Skip to Content


My second blog about old, strange, funny or otherwise quirky ABAP-stuff that most ABAP-programmers will encounter sooner or later is a short one. It’s just that, while being busy writing an ABAP-program that needed a currency conversion, I stumbled upon something that I had never noticed before. Until now, I always used function ‘CONVERT_TO_LOCAL_CURRENCY’ for the conversion, thus being ‘protected’ from the way the exchange rates are actually stored. Nothing special and all in a day’s ABAP, you will rightfully say.

However, this time I had to use the exchange rate that was stored in a CO-PA table to calculate from a foreign currency to the currency of the CO-PA record. The exchange rate is stored in one field of the table, so I lazily presumed that multiplying the foreign amount by this exchange rate would do the trick. I didn’t even check existing exchange rates but just ran a first test. The result of the conversion from SGD (Singapore Dollar) to EUR (Euro) confused me, because the amount had changed from a positive to a negative value and seemed a bit to high (or rather low).

So I did what I should have done in the first place: check the CO-PA field. This is what I saw in SE16:


My first reaction was: how can a numeric field (data element KURSF) contain a slash. But of course, this had to be the result of a conversion exit. So I checked the domain and saw that this was true. Conversion exit ‘EXCRT’ does the trick:


I checked the current conversion rate between SGD and EUR on the Internet and found that I had to divide the SGD amount by the exchange rate, not multiply. But this still didn’t explain the negative result. So I checked the KURSF-field again with SE16, but now I first de-activated the conversion exit in the user-specific SE16-settings.


This showed that the exchange rate is actually a negative value:


From this I concluded that for negative exchange rates, I have to divide the foreign amount by the absolute value of the exchange rate.

IF exchange_rate < 0.
local_amount = foreign_amount / abs( exchange_rate ).
local_amount = foreign_amount * exchange_rate.

Actually, in the specific CO-PA table I had to process, all exchange rates were stored as a negative number, except when the foreign and local currencies were the same. For example, the exchange rate from GBP to EUR is also stored as a negative number.



Is there a conclusion to be drawn from this? Yes, a programmer (or at least I) should always check his/her assumptions. I’m curious if there are more examples of this type of implicit logic to be found in SAP systems.

To report this post you need to login first.


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

  1. Jelena Perfiljeva

    Good post, thanks for sharing. Ran into this negative number thing myself few months ago when using VBRK-KURRF field.

    I believe this may have something to do with the way the exchange rate is maintained in TCURR. It may be entered as “direct” and “indirect” (at least since 4.7), e.g. we can enter 1 GBP = X EUR or 1 EUR = X GBP. Not 100% sure though.

    1. Tuncay Karaca

      Hi Jelena & Ben,

      Customizing exist at SPRO > SAP NetWeaver > Currencies > ine Standard Quotation for Exchange Rates and Enter Prefixes for Direct/Indirect Quotation Exchange Rates

      So based on direct or indirect you can choose prefix which is in table TCURP.

      Exchange rates can be entered as a direct or indirect quotation. Here you can maintain two prefixes that can be used to differentiate between direct and indirect quotation exchange rates during input and output.

      But there is a warning “Changing the prefixes in a running production system is risky. If such a change seems meaningful, you should coordinate and plan this in your company with care and be sure to inform all the affected areas.”

      If there is no entry in TCURP table, conversion routine of KURSF domain determines prefixes as default p = ‘ ‘ and m = ‘/’.   Include LSCUCF01 subroutine


  2. Gregory Misiorek

    i like to think of negative notation of currency conversion rates as showing a reciprocal or fraction or raising to the power of -1 while still using only one storage location, so any number between -1 and 0 is indirectly more than 1 when multiplied. i think it goes back to saving processing resources or representing values in the most economical way possible.

    btw, conversion exit has nothing to do with conversion rate except for sharing their names.

    nice example.

    1. B. Meijs Post author

      Hi Gregory,

      Thanks for you reply. I know of course that conversion exits and conversion routines have nothing to do with each other. If they wanted to save processing, disk and memory space, they could have chosen also for storing the exchange rate as a fractional value. This is actually done in the CO-PA table I had to use as you can see in the last screenshot.


Leave a Reply