openerp-india team mailing list archive

["Ravish\(OpenERP\)" <915481@xxxxxxxxxxxxxxxxxx>]

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! 

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

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
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