On Fri, Dec 30, 2011 at 2:33 AM, Pete Houston <[email protected]> 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 ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
