we're using BaaNERP 5.0b and I have a question about the use of
the reporting 1 currency.
Here is what we hace in table tcemm170:
lcur = EUR
fcua = EUR
fcub = FRF

and in tfacr200, for example, here is a record:
ccur = FRF
rate(1) = 6.55957
rate(2) = 6.55957
amth(1) = 13519,70
amth(2) = 88683.40

it seems that rate(2) is not according to amth(2) ! I thought it would be 1 ?
Is that normal and what is the impact to the future ?
Thanks.

Hi there,

The way you have to look at your rate, ratefactors etc is dependent of your currency system.

If your currency system is dependent, which it apparently is if I look to your data then the following will be stored. Suppose I have a dependent currency system with as local currency (always the first one in the array by definition) HFL and I have as first reporting currency (always the second one in the array by definition) the EUR, which is also my reference currency.

Calculations should always be done via the reference currency, so in this case the EUR. So if you have a transaction in a certain transaction currency then the direct rate is stored from transaction currency to the reference currency, but the other rates are the rates from the reference currency to the other home currency (ies) with internal rate type.

So suppose with this scenario I would have as transaction currency als the HFL then the rates would be like
[2.20371, 2.20371]. So we have the direct rate stored from HFL to the reference which is the second one in the array and from there we have the rate from euro to HFL with internal rate type, which is again 2.20371.

To make it even more difficult we also now have the "express in base currency" attribute, which means that for each rate we have to know that attribute because we have to know whether we have to multiply or divide by the rate mentioned in the table. To find the express in base currency we need the rate type and the rate date. This means that in BAANERP you can only do meaningfull currency calculations when you have the full conherent set of rates, ratefactors, rate type en rate date and also use the generic functions of tcemm.dll5010.

I hope this explains the "at first glance" strange rates in the table.

Regards,
The Leerebeer