Re: Multicurrency issue, concerns, and proposed longer-term direction.

[Erik Huelsmann <..hidden..>]

Hi Pete,

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
transactions.

Hope that gets you back good confidence in 1.3 :-)

Bye,

Erik.