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 <[email protected]> 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. ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
