Comment 23 for bug 610738

Just to clarify
I added "move_value_cost" and "move_value_sale" to stock_move
avg_price is always sum(move_value_clost)/sum(product_qty)
* for product
* for product + stock_location
* for product + stock_location + production_lot
* for product + production_lot
obviously the avg_price might be different for these aggregates
the avg_price must be used for moves where the source location is internal.
only this guarantees that sum(move_value_clost) is 0 when product_qty is 0

move value_cost must also be used to create accounting moves
* either for each move
* at month end
this guarantees that accounting values = stock_accouting values (basic assumption for any audit)

further more this allows to calculate the correct and matching value of inventoy for historical dates (fiscal years/month end) - a must have for accountants

return moves must use the price based on the "move_value_cost" of the corresponding "out" move
= move_value_cost/product_qty * return_qty

saving move_value_cost will also avoid rounding differences
sum(move_value_cost) is likely not sum(product_qty*price_unit) or product.avg_price * sum(product_qty)
this could be avoided by sum(round(product_qty*price_unit, precision)) whereas precision is now a variable in V6 and hence make the script unnecessary complex

the usage of move_value_cost would also allow more easily to integrate the definition of unit_prices like
price / Unit
price / 100 units
price / 1000 units
price in ¢ / Unit
which is a common issue in technical production and even day to day products like gasoline price is priced in ¢/Liter here
see https://code.launchpad.net/~openerp-commiter/openobject-addons/chricar_price_unit
the often discussed method to increase the number of decimals is not helpful, because this is done for all products.