c2c-oerpscenario team mailing list archive

["Amit Parik \(OpenERP\)" <amp@xxxxxxxxxxx>]

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/4765 revision 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 a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
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