osv_memory cannot change decimal precision of fields, and probably because it ignores it

[Graeme Gellatly]

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.

[Amit Parik (amit-parik)]

Hello Graeme,

First thanks for the nice explanation!

I have checked this issue But I am not agree with your this point "osv.osv_memory does not respect the digits_compute argument."

Because in your case1 which is already posted on lp please check the lp :788064 and this issue is already fix committed just see the revision http://bazaar.launchpad.net/~openerp-dev/openobject-addons/trunk-bug-788064-mma/revision/4765

I have applied this patch at my end and it is working as fine so there in no issue with osv.osv_memory just missing the pass digits_compute = dp.get_precision('Purchase Price') in to cost field of the partial picking wizard.

I have attached a video on this after applied the above revision's patch so would you please check it and notify us about your problem and correct me is I am wrong on this.

And your first issue which is "use the same precision for all unit prices" I think this is your wish and which needs more improvement so for this issue I am suggesting, you have to post a another bug report which is as a "Wishlist" or you can post your this suggestion on <email address hidden> so our experts can check it and review it.

Thanks and Waiting for your reply!

[Amit Parik (amit-parik)]

Hello,

I have attached a video which solved the problem of bug lp:788064 which is similar to your bug report.
So would you please check it.

Thanks again!

[Graeme Gellatly (gdgellatly)]

Amit,

Firstly the fixed bug you refer to is in trunk not 6.0.
Second, I had already changed that field through inheritance and there is
nothing wrong with it. Besides the example I gave to use was product uom
and you will clearly see the issue.
Third, it isn't even an osv_memory field. This bug report is about
osv_memory.
Fourth, your bugfix is incorrect anyway, why should it be Purchase Price?
 What if it was a Sale, which is exactly the reason we need unit and total
precision consistent across documents, I have submitted enough bug reports
on this and am not submitting another as I have fixed the problem for myself
and am sick of being ignored.

Please check using at least example 1. You are incorrect that this fixes it
as that bug was about unit price, not UoM. Why do you not even test, it is
a 2 minute test?

On Fri, Jun 24, 2011 at 1:19 AM, Amit Parik (OpenERP) <email address hidden>wrote:

> Hello,
>
> I have attached a video which solved the problem of bug lp:788064 which is
> similar to your bug report.
> So would you please check it.
>
> Thanks again!
>
> ** Attachment added: "osv_osvmemory.ogv"
>
> https://bugs.launchpad.net/openobject-addons/+bug/800970/+attachment/2179348/+files/osv_osvmemory.ogv
>
> ** Changed in: openobject-addons
> Status: New => Incomplete
>
> ** Summary changed:
>
> - [6.0] osv_memory cannot change decimal precision of fields, and probably
> because it ignores it
> + osv_memory cannot change decimal precision of fields, and probably
> because it ignores it
>
> --
> 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):
> Incomplete
>
> 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 'un...

[Amit Parik (amit-parik)]

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.

[Graeme Gellatly (gdgellatly)]

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 f...

[Amit Parik (amit-parik)]

Hello,

@RD Addons2:

I correcting my above comment regarding case#1's decimal accuracy it is not a "Stock Weight" it is a "Product UoM" which we are using this product form 's "Real Stock" field.
I want to more elaborate on case#1 which is related to qty field, I missed this clarification on above comment.
I have checked the PO line and SO line's qty field there manually set a digits=(16, 2) so there also be needs to add digits_compute and use the decimal accuracy on this . Then you can add "Product UoM" decimal accuracy on partial picking wizard 's qty field and also add this decimal accuracy on "Change Product Quantity" Wizard.

About the Sale module's issue currently the bug is assigned to addons2 after completing addons2 related problem it will transfer to the sale module's related team.

Thanks.

[Mayur Maheshwari(OpenERP) (mma-openerp)]

Hello,

Thanks for Reporting.
It has been fixed in lp:~openerp-dev/openobject-addons/trunk-bug-800970-mma
Revision ID: <email address hidden>
Revision num: 4817

It will be available in trunk soon.

[Graeme Gellatly (gdgellatly)]

Well thanks, but bug report is for 6.0 series

On Mon, Jun 27, 2011 at 5:17 PM, Mayur Maheshwari(OpenERP) <
<email address hidden>> wrote:

> Hello,
>
> Thanks for Reporting.
> It has been fixed in lp:~openerp-dev/openobject-addons/trunk-bug-800970-mma
> Revision ID: <email address hidden>
> Revision num: 4817
>
> It will be available in trunk soon.
>
> ** Changed in: openobject-addons
> Status: In Progress => Fix Committed
>
> --
> 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):
> Fix Committed
> 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
>

[Yogesh (SerpentCS) (yogesh-serpentcs)]

Hello,

Thanks for reporting.

It has been fixed at lp:~openerp-dev/openobject-server/trunk-bug-800970-ysa and it will be merged soon to the trunk server.

Thanks,

[Graeme Gellatly (gdgellatly)]

Well thanks again, but again the bug report was for 6.0. Can we have it
fixed there too please.

On Tue, Jun 28, 2011 at 12:51 AM, Yogesh(Open ERP) <email address hidden> wrote:

> Hello,
>
> Thanks for reporting.
>
> It has been fixed at lp:~openerp-dev/openobject-server/trunk-
> bug-800970-ysa and it will be merged soon to the trunk server.
>
> Thanks,
>
>
> ** Changed in: openobject-server
> Status: In Progress => Fix Committed
>
> --
> 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):
> Fix Committed
> Status in OpenERP Server:
> Fix Committed
>
> 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
>

[Yogesh (SerpentCS) (yogesh-serpentcs)]

Hello,

6.0 :- It has been fixed at lp:~openerp-dev/openobject-server/6.0-bug-800970-ysa and it will be merged soon to the stable 6.0 server branch.

Thanks,

[Vo Minh Thu (thu)]

We are in the process of removing the current implementation of osv_memory from the trunk.