c2c-oerpscenario team mailing list archive

[Patrick Amstutz <796320@xxxxxxxxxxxxxxxxxx>]

Hey Amit,

The Incoming Shipment should be related to the entire Delivery Order.
Here, the Incoming Shipment is only related to the first stock.move.

I demonstrate here the inconsistency of the present implementation:

In stock: 100 CPU1
Sale Order: 200 CPU1 on order

Create and validate the sale.order. Process procurement.order, validate
purchase.order. Go to the Delivery Order. From there two different
scenarios which should give the same result, but do not:

1)

- put the stock.move in a new pack, leave 70 CPU1
- click check availability, first line is available.
- go to incoming shipment, process.

-> the second line of the delivery order is NOT available


2)

- put the stock.move in a new pack, leave 130 CPU1
- click check availability, second line is available
- go to incoming shipment, process.

-> the first line of the delivery order is available (both lines are
available actually)


Both procedures are functionally the same, please Amit, explain me why we do not get the same behavior. Thanks.

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/796320

Title:
  incoming shipment does not trigger corresponding delivery order

Status in OpenERP Modules (addons):
  Incomplete

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