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

[Chris Travers <..hidden..>]

On Fri, Dec 30, 2011 at 2: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.

Drift is less than half a penny per invoice.  It only shows up in
aggregate.  I.e. one might find that the AP report and the trial
balance screen show a couple pennies in drift over time.  That's a
problem but one that could be fixed periodically.  Everything is paid
to the nearest penny.

Honestly the sort of drift conditions we get in 1.3 are even fewer
than existed in 1.2.
>
>> 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.

I don't actually think this is a return to the previous problems.
There were a couple of round-off issues on fx stuff in 1.2 that have
been fixed in 1.3.  This is not one we were aware of in 1.2 but that
could be because there were a few other roundoff issues we were
working on.

A major reason to float currencies is that it makes reporting with
bank accounts in different currencies a lot better (currently fx gain
and loss can't be calculated on floating assets on arbitrary time
periods).

Best Wishes,
Chris Travers