ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adri...@hlmksw.com>
Subject Re: Accounting Average Cost Algorithm
Date Thu, 10 Jan 2008 23:35:14 GMT

I understand the point you're trying to make.

An accountant working for a user of OFBiz will want to verify OFBiz's output against manual

calculations. Our accountants do that all the time here where I work. So, if OFBiz is calculating

average cost one way, and the accountant is calculating average cost another way, then there
may be 
a discrepency. The accountant is going to question the accuracy of the accounting software.

All I'm suggesting is this: if the subject of this thread is "Accounting Average Cost Algorithm"

and we're really discussing an *algorithm* - then let's use a standard accounting algorithm.
If the 
issue is problems that arise when databases round numbers, then that's a different subject.
In that 
case we should be discussing "Errors Caused by Rounding In Databases."


Daniel Kunkel wrote:

> Hi
> Adrian, I'm starting to wonder if the point I'm trying to make is being
> missed.
> Yes, I do understand that there are reasons accountants would want to
> use another form of cost tracking, most commonly lifo and fifo.  
> The algorithm I'm suggesting only pertains to the "weighted average"
> when the business decides they want to use average cost accounting.
> And, for many products, where the cost per unit works out to an exact
> cent, the algorithm will work exactly as you would expect.
> Where this algorithm is different is in how it handles when the average
> cost doesn't work out to the exact penny.
> For example, you buy 1000 units for $ 5,788.54, at an average of $
> 5.78854 each.
> As you sell the units, you need to move the cost of each from an
> inventory account to an cogs expense account. The straight forward way
> to handle this moves $5.79 from inventory to expense for every unit
> assuming every unit is calculated independently and you apply simple
> rounding. By the time you are sold out, you'll notice the total expenses
> for this item add up to $ 5.790.
> The algorithm I'm suggesting will vary the costs of goods between $ 5.78
> and $ 5.79 in an such a way such that total expenses will exactly equal
> the total investment when you are completely sold out.
> I believe it is possible to achieve the same result via the more common
> method of storing 5.78854 in the database, but then you have complicated
> issues with floating point resolution, rounding, adjustments, and have a
> hard time making accounts exactly match.
> Daniel
>  Thu, 2008-01-10 at 13:18 -0800, Adrian Crum wrote:
>>David E Jones wrote:
>>>With modern systems, especially highly integrated ones like OFBiz, we  
>>>can do crazy things to get actual inventory costs and so on, but for  
>>>COGS calculations companies often don't want that. Because goods  
>>>purchased for resale vary in price and such, and there is often a  
>>>desire to even out such costs over a longer period, they actually  
>>>prefer to use averages and such because they are allowed in GAAP and  
>>>they can make the company's books look better.
>>The pages I posted to the Wiki have an example of what you described - using different
>>methods to achive a desired result.

View raw message