mrp, procurements: does not round up product qty on order

Hello,

I have faced the same problem that is after running procurement "PO" takes 1 qty instead of 1.11 with same scenario
because in float value rounding should be apply after 2 digit,so as per my opinion PO should be created for 1.11 qty.

@ Dmitrijs : I do not agree according your Expected results ,you have suggested that PO will take 2 qty but it shouldn't.because as a generalize way the rounding applied after 2 digit, correct me If I am wrong .

@Team: I have faced other issue that is, MO goes in to "Read to Produce" state after done the reception of one qty.It will consume only 1 qty (as per virtual stock) but in MO it displayed correct qty (1.11)

Thanks!

On 17/01/12 09:51, Ravish(OpenERP) wrote:
> Hello,
>
> I have faced the same problem that is after running procurement "PO" takes 1 qty instead of 1.11 with same scenario
> because in float value rounding should be apply after 2 digit,so as per my opinion PO should be created for 1.11 qty.
>
> @ Dmitrijs : I do not agree according your Expected results ,you have
> suggested that PO will take 2 qty but it shouldn't.because as a
> generalize way the rounding applied after 2 digit, correct me If I am
> wrong .
>

Sure. The conditions are that:

* Enough or more product should be ordered
* Floor + minimal order qty increment

In my case the unit is PCE and I'm expecting integer rounding. If the
orders can only be done in thousands and 3210 qty is required, it should
be possible to configure rounding to round up to 4000.

>
> @Team: I have faced other issue that is, MO goes in to "Read to Produce" state after done the reception of one qty.It will consume only 1 qty (as per virtual stock) but in MO it displayed correct qty (1.11)
>
>
> Thanks!
>

Thank you for trianging this.

> ** Changed in: openobject-addons
> Status: New => Confirmed
>

--
With best regards,

Dmitrijs Ledkovs

credativ ltd Tel: 01788 298152
36 Regent Street Fax: 01788 298159
Rugby CV21 2PS - UK http://www.credativ.co.uk

credativ Ltd is registered in England & Wales, company no. 5261743
Registered office: Nelson House, 2 Hamilton Terrace, Leamington Spa,
Warwickshire CV32 4LY

Certified by AccredIT UK with the ICT Supply standard of quality for
Software Product Design and Development

Hello Dmitrijs Ledkovs ,

Sorry for the inconvenience , first of all I have missed one thing which is rounding field on product UoM
that's why I have removed the assignee.

Here, we have consider the cycle of SO to PO , there may be possibility our product procure method equal to "Make to oder".
now let me came on your conditions . if our product procure method is "Make to order" then no need to require more qty
of product then require. because it does not use in future .so for this ,best way we have consider enough product in PO
which will be same as consumed.

As per technical stuff of original rounding method that never consider 1.111 as 2 . let me explain some example below
 round(80.23456, 2) = 80.23, round(80.23556, 2) = 80.24.

So we have used this rounding function on rounding field of product UoM .currently all are working fine.

Now according to your scenario , if you wants enough qty for your PO then just change rounding field for 2 digit (as i shown in above example) like put the value 0.01 for this field and then try . I have attached video for this issue, So would you please check it and try this to your end and notify us.

I have taken example for 0.10 as decimal rounding in video .

Hope this will help for you . correct me if i am wrong
Thanks for your savvy!

On 18/01/12 12:35, Ravish(OpenERP) wrote:
> Hello Dmitrijs Ledkovs ,
>
> Sorry for the inconvenience , first of all I have missed one thing which is rounding field on product UoM
> that's why I have removed the assignee.
>

That's not the only problem. It is one of many problems here.

> Here, we have consider the cycle of SO to PO , there may be possibility our product procure method equal to "Make to oder".
> now let me came on your conditions . if our product procure method is "Make to order" then no need to require more qty
> of product then require. because it does not use in future .so for this ,best way we have consider enough product in PO
> which will be same as consumed.
>

No. Cycle SO to PO is not part of the bug.

The bug is in Cycle MO->PO (procurement for a MO). It may or may not be
part of SO to PO cycle. And the conditions should not matter.

>
> As per technical stuff of original rounding method that never consider 1.111 as 2 . let me explain some example below
> round(80.23456, 2) = 80.23, round(80.23556, 2) = 80.24.
>

Which is wrong. Above is arithmetic rounding, whereas ceiling rounding
strategy must be used.

> So we have used this rounding function on rounding field of product UoM
> .currently all are working fine.
>
> Now according to your scenario , if you wants enough qty for your PO
> then just change rounding field for 2 digit (as i shown in above
> example) like put the value 0.01 for this field and then try . I have
> attached video for this issue, So would you please check it and try
> this to your end and notify us.
>

This is a workaround and it still did not order enough product. It
procured 1.10 which is still not enough. 1.11 is required.

In your next test, make sure you have to existing stock, and try to
complete the manufacturing order WITHOUT 'force reservation'. As in,
make sure that the procurement actually orders enough raw materials.

> I have taken example for 0.10 as decimal rounding in video .
>

And not enought product was ordered.....

> Hope this will help for you . correct me if i am wrong
> Thanks for your savvy!
>

Changing rounding on the unit of measure is wrong approach here. Because
my unit of measure rounding must be what it is. (For example in this
case integer quantities). The procurement scheduler should be changed to
using ceiling method, then rounding factors when figuring out how much
to procure.
--
With best regards,

Dmitrijs Ledkovs

credativ ltd Tel: 01788 298152
36 Regent Street Fax: 01788 298159
Rugby CV21 2PS - UK http://www.credativ.co.uk

credativ Ltd is registered in England & Wales, company no. 5261743
Registered office: Nelson House, 2 Hamilton Terrace, Leamington Spa,
Warwickshire CV32 4LY

Certified by AccredIT UK with the ICT Supply standard of quality for
Software Product Design and Development

Hello Dmitrijs,

I have clearly analysed this issue, But I think all are working correct as per the behaviour.

Now, I explain you the current behaviour of 6.1 trunk according to your scenario.

First Ravish was described you the SO to PO cycle and your behaviour for MO to PO. There is no difference in SO to PO or MO to PO scenario for created PO because the main thing is, here we have consider the quantity of PO. So that doesn't matter the PO created from SO or MO.

Yes, you are right. We are used a arithmetic rounding for this (Product UoM 's rounding precision as well as for all rounding).

You can see that we have used different value for rounding precision field for different 'Product UoM Category' like for kg and gm we have used 0.010 and for PC we have used 1.00 value. Because for unit type of categories, I don't think the product 's quantity going in to decimal value. As well as this field is changeable, So we can change this easily as per our requirement.

According to your scenario, If you want the PO for 1.111 PC quantity then you have to change your product UoM's rounding precision as 0.001 then and then only it will satisfied your scenario.

I have attached a video for this whcih is described the solution of your configuration as well as described that we have used different rounding precision for different product UoM category.

Now comes your another two problem.

#Ceiling Rounding..

You have suggested that we have to use 'Ceiling Rounding' instead of 'Arithmetic Rounding'. Below some example of Ceiling Rounding.
'Ceiling(0.00) = 0
'Ceiling(0.10) = 1
'Ceiling(0.20) = 1
.
.
'Ceiling(0.90) = 1
'Ceiling(1.00) = 1
'Ceiling(1.10) = 2

But As per my 'Opinion' the 'Arithmetic Rounding' is proper for this because we have used everywhere this same rounding functionality. But may be your suggestion is good because If we used a Ceiling Rounding then always satisfied our required product.

#Why used "Rounding Precision" in "Product UoM"?

Ans:- Currently quantity rounding is consider based on Rounding Precision field of "Product UoM" object because different UoM have different rounding as I described above. If our product UoM id PCS then there is no possibility that our product goes into decimal quantity, I mean it never possible If I Purchase or Sale 1.12 or 1.5 PCS in real scenario.

If our product UoM is in KG or Liter then it's possible, that's why we have consider different 'Rounding Precision' for different UoM.

So as per my "Opinion' this place is better for satisfy the quantity rounding that's why current behaviour is good.

Finally it's not a bug rather than your suggestion that's why I am setting it as a "Wishlist"

For last two point I am consider it as an "Opinion" because mainly for Ceiling Rounding point we need a more discussion then and then only we can look this issue on future.

@Experts: Would you please share your views on this.

Thanks and more suggestions are welcomed!

Expected behaviour: after running procurement, I should have enough stock to complete manufacturing order.
Current behaviour: after running procurement, I sometimes do not have enough stock, due to rounding errors.

As per original description, and in every video above, procurement does not order enough stock.

Think for the case where to manufacture 1 unit, I need square root of two qty of a raw material. And think about batch of size 1,10,100,1000,10000,... Rounding precission will not solve it, Ceiling upto N*(rounding precesion) will.

Hello,

We need to double check before implementing this. We might have to ceil the rounding in the case the rounding precision of the UoM is different from that of the purchase UoM (or supplier min qty).

The default rounding behaviour might not be appropriate because it's ROUND_HALF_UP, so it rounds down for .0 < qty < .5, due to this there may be cases where we can't cover unless we go and change the precision every time we notice an error... perhaps the system should behave better by default.

Thanks.

We encountered the same problem some while ago, I think it was while we had Francois Pietquin as a consultant over here at our company, in January 2011.

The procurement does not order enough to fulfill the needs due to real rounding instead of ceiling usage.

This is a certainly not "wish list" but a high priority concern for everyone that wants to use manufactoring to produce something.

We will (once again) ask the support to fix this as part of our contract.

OK, I found an old mail and therein:

https://bugs.launchpad.net/openobject-addons/+bug/718699

Hello,
Thanks for Reporting.
It has been fixed in lp:~openerp-dev/openobject-addons/trunk-bug-718722-ron
Revision ID: <email address hidden>
Revision num:4531.

qdp (OpenERP) (qdp) on 2011-03-17 Fix Released