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

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



On 30/12/11 10:33, Pete Houston 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.

We get the odd out-by-one error on invoices. We tend to just lose it in
the FX gain/loss.

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

Yes, I'm happy with the way that 1.2 handles things.

Nigel