Amit,

Thanks for this.

Decimal Precision bug has already been submitted and triaged bug 780413.  I
have today submitted a discussion paper regarding this, extending to cover
the issue with similar documents using different precisions.

On Fri, Jun 24, 2011 at 7:38 PM, Amit Parik (OpenERP) <email address hidden>wrote:

> Hello,
>
> @RD Framework:
> I have checked again this issue and you are right "osv.osv_memory does not
> handle properly digits_compute argument". I have applied the patch on this
> http://bazaar.launchpad.net/~openerp-dev/openobject-addons/trunk-bug-788064-mma/revision/4765revision and create a new db It is working fine But the problem creates when
> I am restarting the server, then osv_memory can't handle digits_compute So
> this is the generalizes issue for all osv_memory.That's why I am also affect
> this issue to server and confirming this issue on server side
>
> @RD Addons2:
> Now about your case #1 you have talked about the qty field on partial
> picking wizard, and this is is also confirm I would like to suggest here to
> use a "Stock Weight" 's decimal accuracy on qty field of the partial picking
> wizard.
> That's why I am confirming your case#1 on addons side.
>
> According to your "Average price (cost price)" related issue which is
> already post on lp:788064 and after this bug 's fixes on server side it
> will solved and I am also related that bug to this one.
>
> @Graeme:
> Thanks for your reply!
> Now I would to like giving the answer of your question regarding your
> comment#3 "why should it be Purchase Price?"
> Ans : Because the cost price is always related with the purchase order or
> purcahse price. In partial picking wizard the float field "Cost" is coming
> only when your recepation is incoming, means your picking is gerenared from
> the PO and also you have select the "Average price" in porduct form. So this
> field does not related to sale or sale price.
> That's why here using "Purchase Price" 's decimal accuracy.
>
> Now let 's disuss about your first point which is "use the same precision
> for all unit prices".
> This point is a "Wishlist" so would you please post new bug report on this
> and if you allow me then I will post.
> Because your this point needs a more improvement and discussion So I am
> consider this as a "Wishlist".
>
> Hope you will agree with me and correct me if I am wrong on this.
>
> Thanks.
>
>
>
> ** Also affects: openobject-server
>   Importance: Undecided
>       Status: New
>
> ** Changed in: openobject-server
>   Importance: Undecided => Medium
>
> ** Changed in: openobject-server
>       Status: New => Confirmed
>
> ** Changed in: openobject-server
>     Assignee: (unassigned) => OpenERP's Framework R&D
> (openerp-dev-framework)
>
> ** Changed in: openobject-addons
>   Importance: Undecided => Low
>
> ** Changed in: openobject-addons
>       Status: New => Confirmed
>
> ** Changed in: openobject-addons
>     Assignee: (unassigned) => OpenERP R&D Addons Team 2
> (openerp-dev-addons2)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/800970
>
> Title:
>   osv_memory cannot change decimal precision of fields, and probably
>  because it ignores it
>
> Status in OpenERP Modules (addons):
>   Confirmed
> Status in OpenERP Server:
>  Confirmed
>
> Bug description:
>  A while back I reported a bug about rounding too early, and that we
>  needed to have seperate unit price precision as well as totals and use
>  the same precision for all unit prices regardless of document, and the
>  same total precision regardless of document or else we have strange
>  errors.
>
>  Anyhow, while the problem was agreed and recognised it was deemed too
>  big a change.  So I went about changing it myself.  It works perfectly
>  with just one exception.  osv_memory fields.  Now truthfully I think
>  the problem might be that they don't respect decimal precision at all.
>  However they definitely can't be changed by inheritance.
>
>  So case 1. Does not respect decimal precision at all.  Change UoM
>  precision to 3.  Raise a PO for 1 product, so 2.555 units of (although
>  it doesn't matter), go to the incoming shipments and you will see the
>  quantity with 3 decimal places.  Now press validate and the wizard
>  pops with just 2 decimal places.  Hmmm.
>
>  Case 2 is a bit trickier.  However is case 1 is the bug, then you
>  might not need to do this.  Create a new Decimal Precision called
>  unit.  with a precision of 5 digits.
>
>  Now create a module which inherits some objects, say product.template
>  changing standard price decimal precision to be 'unit', and
>  stock.change.standard.price changing new price to 'unit' (Note 1 is
>  osv the other osv_memory).  Find a product, give it a cost method of
>  standard price and you will see 5 digits.  enter .07654, then change
>  it to average cost.  So we have 5 digits.  Now click update standard
>  price and see only 2 decimals (or receive a shipment priced at 0.07654
>  if you have set Purchase Price precision also to 5 and low and behold
>  our average cost is 0.08)
>
>  Now for the awful workaround - use digits=(16,5) in osv_memory field
>  definition and it works fine with inheritance, which leads me to the
>  conclusion that in fact the bug is osv.osv_memory does not respect the
>  digits_compute argument.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/800970/+subscriptions
>