Re: Vendor invoices in foreign currency

[Erik Huelsmann <..hidden..>]

After sleeping on it, I decided that it's probably best to have
payment_get_open_invoices() follow the Perl code.

Committed a change to that effect in r4222.

Bye,

Erik.

On Fri, Dec 16, 2011 at 10:08 PM, Erik Huelsmann <..hidden..> wrote:
> 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.