credativ team mailing list archive

["Dmitrijs Ledkovs \(credativ\)" <915481@xxxxxxxxxxxxxxxxxx>]

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


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

-- 
You received this bug notification because you are a member of credativ,
which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/915481

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

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  Using v6.0 addons revision 4996 with a demo database
  Using trunk addons revision  6339 with a demo database

  Steps to reproduce:
  in v6.0
  1) create new Bill of Materials with
  in trunk
  1) modify existing bill of Materials with

  - Product [RCK100] Rack 100cm
  - Product Qty: 9.00
  - Components:
     [LIN40] Wood Lintel 4m  x Product Qty 1.00

  = the rest is common =

  2) Create and confirm MO:
  - Product [RCK100] Rack 100cm
  - Product Qty: 10.00

  3) Run procurement schedular with automatic order point ticked.

  Expected results:
  MO consumed products: LIN40 qty 1.111
  PO quotation: LIN40 qty 2

  Actual results:
  MO consumed products: LIN40 qty 1.111
  PO quotation: LIN40 qty 1

  The bug:
  Even when the procurement will be completed there will not be enough stock to consume.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/915481/+subscriptions