Sorry I hijacked you thread Adrian. I agree with you about averaging cost. and there is process that allows for this to come out in the Accounting.
Adrian Crum sent the following on 1/10/2008 12:18 PM: > Both of you are missing my point. If an accountant chooses to use the > average cost method for inventory, he/she is aware it is an AVERAGE, not > a "penny accurate" figure. If an accountant chooses to use lifo or fifo, > then they will expect a more accurate result. > > -Adrian > > BJ Freeman wrote: > >> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>> >>> >>> >> >> > > > >
