[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

Pete
-- 
Openstrike - improving business through open source
http://www.openstrike.co.uk/ or call 01722 770036 / 07092 020107

Attachment: pgptD8gU8LkMJ.pgp
Description: PGP signature