credativ team mailing list archive

["Olivier Dony \(OpenERP\)" <796320@xxxxxxxxxxxxxxxxxx>]

Hi Patrick,

I understand your concern and I kind of agree that we could improve the
model a bit to support cases with split deliveries in a more reliable
way. However as Kirti tried to explain, this represents a non-trivial
change in the model, for a limited immediate benefit.

Usually when a split move line fails to be considered correctly by the system, the workaround is to resort to handling it manually. This is in fact consistent with the philosophy of OpenERP flows: the regular flows are handled automatically by the system, without going to far in specific cases as to make the system overly complex. And for the rest, give enough control to users so they can manually handle any special case without the system coming in the way.
This is illustrated by your example in comment #3, where the workaround is trivial: when the system did not do the work for you, you can just "Check availability" manually and fix it.

Nevertheless we can think about improving the model in the long run, for
instance by having a more explicit way to link "split" moves together so
they can be considered all together when that matters. For this reason I
suggest we keep this bug open as "Wishlist", and foresee a deeper
analysis to improve this in the future (i.e. after 6.1 release).

On the other hand, you related bug 794412 does highlight a case where
this could lead the user to wrongly believe that an order has been
completely delivered. This is different and we should indeed implement a
workaround right now, without waiting for a future new model.

Thanks for your well documented bug reports!

** Changed in: openobject-addons
       Status: Won't Fix => Confirmed

** Summary changed:

- incoming shipment does not trigger corresponding delivery order
+ Procurement - stock move relationships need to be improved to better handle e.g. split moves

-- 
You received this bug notification because you are a member of OpenERP
Framework Experts, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/796320

Title:
  Procurement - stock move relationships need to be improved to better
  handle e.g. split moves

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  Hey,

  This bug is related to the way stock.picking (especially Delivery
  Order) are handled. When the Delivery Order is created, one stock.move
  is produced corresponding to the sale order line. The conception
  problem comes from the fact that this stock.move is considered to
  represent the stock.picking entirely in its relation with other
  objects (sale order, procurement order, purchase order). This leads to
  serious functional miss behaviors, and would deserve some more
  conception and specification time.

  A related bug for this conception problem is
  https://bugs.launchpad.net/openobject-addons/+bug/794412.

  1,2) Reproduce the functional conception problem and observed result

  - Consider a sale order with "on order" procurement method. Let say you sell 200 CPU1, with 100 CPU1 in your stock (important for what follows).
  - Confirm the sale order, the corresponding stock.picking with one stock.move is created. Along with a procurement.order.
  - Launch the scheduler, a purchase.order (rfq) is created.
  - Validate the purchase.order, the incoming shipment, stock.move are created.
  - Back to the Delivery Order, put the first line in a new pack, leave 70 CPU1 in the current pack.
  - You change your mind, you want to deliver these 70 CPU1 partially. Click Check Availability, the first line (70) becomes available. Click Process, and process the first stock.move. Its state is Done. (sale order is 100% picked, related to bug 794412).
  - Now go back to the Incoming Shipment. Process it entirely.
  - The remaining stock.move in the Delivery Order is not set to Available

  stock.move split are simply not considered; the original stock.move is
  considered only.

  3) expected result

  - the remaining stock.move should benefit the newly received products
  first, and thus should be forced to available.

  4, 5) ubuntu 10.04. openEPR 6.0.2.

  A deep rethink/rebuild of pick-pack-shipment processes should be
  engaged. This bug's importance should not be considered as low.

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