in a double ledger system, both sides when summed must =0 not 0.000000000001 or greater
so the transactions must be calculated the same way. letting the math package when to average up or done will not accomplish this. Same with any calculation that will eventually end up in the accounting system. Daniel Kunkel sent the following on 1/10/2008 11:04 AM: > Hi Adrian > > I really appreciate your due consideration of the idea, and taking the > time do share your information. I too believe talking with an accountant > would be a good idea, and yet am fairly certain that penny accuracy is a > very worthwhile endeavor. I think those $800,000 oversights (from the > example), and floating point madness lead to difficult issues to resolve > later. > > You can perhaps get a better feel for some of the real issues by > following more of the thread at: > > http://lists.ofbiz.org/pipermail/dev/2006-March/010129.html > > One important excerpt: > >> The real problem is that different db treat approximations in >> different >> ways; it seems that the SQL specification says that whether >> rounding or >> truncation is used is implementation defined, see the comments to the >> following Jira issue: >> >> http://jira.undersunconsulting.com/browse/OFBIZ-565 >> >> So for example DerbyDB truncates while MySQL approximates numbers. >> For this reason, I really think we should not delegate the >> approximations to the underlying db. >> >> Another issue (but maybe a bit out of topic here) is that if we have a >> (double) variable that (after some calculations) has some decimals, >> and >> the variable will be stored in a db field with less decimals >> digits, we >> should approximate the variable to the db fields decimal positions >> BEFORE using it in any calculation; a good example of this is >> reported here: >> >> http://jira.undersunconsulting.com/browse/OFBIZ-567 > > > Thanks > > Daniel > > > On Thu, 2008-01-10 at 09:59 -0800, Adrian Crum wrote: >> They didn't make it. Oh well. I put them on the Wiki: >> >> http://docs.ofbiz.org/display/OFBIZ/Complete+the+implementation+of+the+Accounting+component+%28GL%29 >> >> Adrian Crum wrote: >> >>> I've attached some pages from an accounting textbook, let's see if they >>> get through... >>> >>> >>> Adrian Crum wrote: >>> >>>> I've found it's best to ask an accountant these types of questions. In >>>> this example, an accountant might expect average cost to be calculated >>>> a certain way, and not worry so much about "penny accuracy." >>>> >>>> -Adrian >>>> >>>> Daniel Kunkel wrote: >>>> >>>>> Hi >>>>> >>>>> It's so wonderful to see an integrated accounting system for OFBiz. >>>>> I've done some thinking about the algorithm used to calculate the >>>>> average cost of an inventory item, and thought I'd share it again. >>>>> >>>>> Rather than trying to store an "average cost" for an item, I believe we >>>>> would be much better off storing the "total investment" for each item. >>>>> >>>>> Most of the time, it won't make any difference, however I have seen that >>>>> directly storing the average cost leads to all sorts of floating point >>>>> resolution and residual adjustment issues, and complications when >>>>> purchasing inventory at a varying price. Most notably that the total >>>>> investments purchasing an item sometimes won't exactly equal the total >>>>> cost of goods expensed after it is all expended. >>>>> >>>>>> From http://lists.ofbiz.org/pipermail/dev/2006-March/010207.html: >>>>> >>>>> >>>>> For example, if you bought a million pieces for $3,889,107,143, and sold >>>>> them out of inventory one at a time for $3.89 without tracking/updating >>>>> the residual average cost.. eventually you'd have to account for >>>>> difference of more than $800,000! >>>>> >>>>> The solution: >>>>> >>>>> Keep a running "total investment" for each item. At the point that >>>>> you utilize an item, calculate and subtract the cost of those items >>>>> rounded to a penny for example. Other currencies will round to the >>>>> degree necessary for their currency. >>>>> >>>>> The effect of doing this will be that the cost of goods will >>>>> oscillate up and down, in the above example between 3.88, and 3.89 >>>>> in such a way that when you've sold your millionth item, the residual >>>>> investment remaining is exactly 0. >>>>> >>>>> Thanks >>>>> >>>>> Daniel >>>>> >>>>> >>>>> >>>>> >>>>> >>>> > > > >
