Vendor invoices in foreign currency

[Erik Huelsmann <..hidden..>]

Hi all,

Well, we're advancing our testing -or actually production- and we've
run into a new issue. We have a vendor which is set up with EUR as its
currency. Our company currency is CAD (the important thing here is
that it's not EUR).

After the permissions fixes related to the 'exchangerate' table, we're
now able to enter these invoices without problems. /However/ we can't
apply payments to them. The reason is that the function
'payment_get_open_invoices()' from Payments.sql generates a 'division
by zero' exception.

I have identified the cause, but wonder about the solution. What's
happening is this:

When there's no FX rate for the day, one is entered by the accountant
entering the vendor invoice. This creates a record for that day and
currency in the 'exchangerate' table. The table contains two columns:
one for the buying rate, the other for the selling rate.

The invoice-entry code determines in which column to insert the rate using:

 $buysell = ($form{vc} eq 'customer') ? "buy" : "sell"

Meaning that the rate entered for the AP invoice gets inserted into
the 'sell' column.

Later, in the function mentioned
(Payments.sql::payment_get_open_invoices()), there's a 40+ line query
which determines the rate (buy/sell) to be used on the type of account
it's dealing with: when the account is of class 1 (Vendor) it uses the
'buy' rate, else it takes the 'sell' rate.

While writing this down, I think the Payment.sql side of things is
correct: when you receive money in a foreign currency, it is worth to
you in your local currency whatever you can get for it when you sell
the acquired currency (sell rate). The other way around: when you have
to pay someone in a foreign currency, the equivalent amount is of
course the amount you have to spend to acquire the foreign currency
(buy rate).

This implies the Payment.sql side of things is correct, /but/ the
criterion used to select either the buy or sell columns - although it
looks reversed - has been there since the initial import of the
repository.


Could it be that Payment.sql is actually *not* correct? Should I apply
a fix there?


Bye,

Erik.