[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multicurrency issue, concerns, and proposed longer-term direction.
- Subject: Re: Multicurrency issue, concerns, and proposed longer-term direction.
- From: Erik Huelsmann <..hidden..>
- Date: Wed, 4 Jan 2012 22:51:01 +0100
On Fri, Dec 30, 2011 at 11:33 AM, Pete Houston <..hidden..> wrote:
> On Thu, Dec 29, 2011 at 04:41:47PM -0800, Chris Travers wrote:
>> My recommendation at present is to do as follows:
>> 1) Add a user-configurable threshold setting (and make it default to
>> 0.005) for paid in full payments.
>> 2) Either accept there could be a few cents of drift in AR/AP or
>> create an SQL script to correct this if we need to.
> Many years ago when we used SQL-Ledger this was a big problem. We ended
> up with a stack of invoices which were 1 penny out and it took a
> disproportionately large effort to sort it all out. On moving to LSMB
> 1.2 this problem disappeared. If that's what you mean by drift then I
> certainly don't want to go back to those days. If it means running a
> script (say at the end of each month) to tidy up the oddments, that I
> can live with.
Last week I committed a fix to AR/AP generic (invoiceless)
transactions. After that, I worked on a new plpgsql program to
automatically create postings to resolve the differences. So, today I
finally found time to test and see if this case actually happens with
invoices. I'm glad to tell you: it does not. At least, I tested AP
invoices and there it does not.
>> Longer-run I think we need to be able to float foreign currencies and
>> handle fx gain/loss as a reporting matter rather than something posted
>> to the books. I don't see this as being possible until the financial
>> logic is redesigned so that would be *at least* 1.5, maybe later.
>> What do people think?
> I haven't delved into the financial logic, so cannot comment in detail.
> However, it should be the case that given an exchange rate and a target
> value in the foreign currency, LSMB should be able to calculate the value
> in the local currency, apply that and mark the invoice as paid in full
> with the difference going to FX gain/loss. This seems to be what happens
> in 1.2 (again, from my experience as a user and not looking at the code),
> so I don't know what may have happened in 1.3 to change it.
Looking at my test result from earlier today: nothing changed with
invoices -- however, it was probably never fixed with generic
Hope that gets you back good confidence in 1.3 :-)