Of the Quirky and Old – strange and funny ABAP constructs explained 2 – the negative currency conversion rate

Background

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 ).
ELSE.
local_amount = foreign_amount * exchange_rate.
ENDIF.

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.

Conclusions

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.