# ofbiz-dev mailing list archives

##### Site index · List index
Message view
Top
Subject Re: Accounting Average Cost Algorithm
Date Thu, 10 Jan 2008 23:35:14 GMT
```Daniel,

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
costing
>>methods to achive a desired result.
>>
>>
>
>
>

```
Mime
View raw message