Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
From IRC, earlier tonight:
[18:54] <freelock_> have some closed invoices showing as open on AR-> Search
fixed svn 6403
Re-opening: from IRC:
I am still seeing the invoices off by fractions in my AR -> Search as well as AR Aging (John Locke)
The point is that his amounts are off more than 0.001 and less than 0.01 "main currency units".
Damn, wrote a lengthy response and it disappeared instead of posting.
After discussion with Erik on IRC, I've become totally convinced that the correct solution is to round the amounts stored in the acc_trans table. Any other solution leads to unpredictable, confusing results.
I see no user story where it is helpful to know per transaction any amount that has been rounded. As Erik described it, the intent is to keep track of tax actually due to an authority, so that you're not surprised at tax reporting time, and to avoid having to recalculate the tax.
But we have to recalculate the tax at tax reporting time anyway, why not just make a tax report screen that recalculates the tax on the aggregate purchases, compares that to the tax collected, and shows the difference?
It makes no sense to track a fractional balance on a customer account. You can't reconcile a cash account with a fractional balance. You can't pay a tax authority a fractional amount. There's always potentially a difference between rounding the result of a tax rate on an aggregate of all sales of a category, and aggregating the tax rate applied and rounded to each transaction -- but this is something really easy for an accountant to understand, and I'm sure they have to deal with this in any bookkeeping system. So I think the most useful thing to do is make it clear on the tax reporting screen that there might need to be an adjustment for rounding, and show the net amount -- the difference between the calculated total and the collected total.
For now I am going to set the threshold (as it was in 1.3) to 0.005.
As for rounding, I think this should be handled by the tax module. The SSUTA tax module we have discussed on the list would round to the nearest cent per item, for example. Another might round to nearest cent for the invoice (but that may take some more work on the tax plugin system).
threshold set in 6439