Stock valuation misscalculation for product quantities with more than 2 decimal positions

Bug #1284238 reported by Andres Calle (TRESCLOUD)
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Committed
Medium
OpenERP R&D Addons Team 3

Bug Description

Using OpenERP 7.0, Postgres 9.1, modules warehouse, account, and mrp_jit

Steps to reproduce the error:
1. Create a Product "A" of type stockable, costing method average price, and set proper accounts for stock valuation in the product category.
2. Create a Stock Move (Menu Warehouse/Traceability/Stock Move) with product "A" and quantity 9.043 from "Virtual Locations / Inventory loss" to "Physical Locations / Your Company / Stock" (this are the stock locations for loading the oppening stock), confirm the move an go to product (Menu Warehouse / Products / Product), select product "A" and verify the quantity. Quantity shows as 9.040. Note that quantity is wrong, it should be 9.043.

Cause of error: I think the problem is related to stock valuation, although the inventory move is saved with 3 decimal positions the field quantity in account.move.line is saved with only 2 decimal positions (saves 9.04). Then the product quantity (product.product) is also updated with only 2 decimal positions (9.04).

Could you please help confirm this is a bug and provide tip on how to fix it?

Related branches

summary: - Automatic inventory valuation works only with two decimal positions
+ Stock valuation misscalculation for product quantities with more than 2
+ decimal positions
Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 3 (openerp-dev-addons3)
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Andres Calle (TRESCLOUD) (andres-calle) wrote :

Dear Amit,

I think I've solved the issue, I've already tested it succesfully! :). As it represent changes to the core modules I would appreciate your support in testing again and merging.

For solving the issue it was needed to properly set the "Rounding Precision" of the related Unit of Meassure (associated to the product) to 0.001 which means 3 decimal positions (explained just in case someone else has this trouble). It fixed the quantity shown in the product form "A", now it shows the expected 9.043.

Still one problem remains which needs change in code as follows: The field quantity in account.move.line is still saved with only 2 decimal positions (saves 9.04) the following fix is needed on the base code:

#file addons/account/account_move_line, line 436
-- 'quantity': fields.float('Quantity', digits=(16,2), help="The optional quantity expressed by this line, eg: number of product sold. The quantity is not a legal requirement but is very useful for some reports."),
++ 'quantity': fields.float('Quantity', digits_compute=dp.get_precision('Product Unit of Measure'), help="The optional quantity expressed by this line, eg: number of product sold. The quantity is not a legal requirement but is very useful for some reports."),

Best Regards,

Andres Calle
TRESCLOUD Cia Ltda

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Andres!

Appreciated ! This is the correct sloution , We have to use the product uom's decimal accuracy for account move line also.
For this fix you can make the branch and provide the merge proposal also I would like to request to RD team would you please accept this fix for v7 .

Thank you!

Revision history for this message
Andres Calle (TRESCLOUD) (andres-calle) wrote :

Dear Amit,

I've sent a merge proposal for this bug, but it is still under revision. Would you help me review it?

BR

Andres Calle

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

I request to OpenERP RD team to mearge this MP.

Thank you!

Changed in openobject-addons:
status: Confirmed → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.