| 2011-06-12 19:57:57 |
Patrick Amstutz |
bug |
|
|
added bug |
| 2011-06-12 19:59:24 |
Patrick Amstutz |
description |
Hey,
This bug is related to the way stock.picking (especially Delivery Order) are handled. When the Delivery Order is created, on 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. |
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. |
|
| 2011-06-12 20:12:49 |
Patrick Amstutz |
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. |
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. |
|
| 2011-06-13 13:19:24 |
Amit Parik |
attachment added |
|
picking.ogv https://bugs.launchpad.net/openobject-addons/+bug/796320/+attachment/2167340/+files/picking.ogv |
|
| 2011-06-13 13:20:01 |
Amit Parik |
openobject-addons: status |
New |
Incomplete |
|
| 2011-06-14 10:00:20 |
Amit Parik |
openobject-addons: status |
Incomplete |
Triaged |
|
| 2011-06-22 05:58:13 |
Amit Parik |
attachment added |
|
Scenario1.ogv https://bugs.launchpad.net/openobject-addons/+bug/796320/+attachment/2177779/+files/Scenario1.ogv |
|
| 2011-06-22 06:01:57 |
Amit Parik |
attachment added |
|
Scenario2.ogv https://bugs.launchpad.net/openobject-addons/+bug/796320/+attachment/2177786/+files/Scenario2.ogv |
|
| 2011-06-22 06:03:15 |
Amit Parik |
openobject-addons: importance |
Undecided |
Low |
|
| 2011-06-22 06:03:15 |
Amit Parik |
openobject-addons: status |
Triaged |
Confirmed |
|
| 2011-06-22 06:03:15 |
Amit Parik |
openobject-addons: assignee |
|
OpenERP R&D Addons Team 2 (openerp-dev-addons2) |
|
| 2011-06-22 06:03:24 |
Amit Parik |
openobject-addons: importance |
Low |
Medium |
|
| 2011-06-23 11:31:43 |
Rohan Nayani(Open ERP) |
openobject-addons: status |
Confirmed |
In Progress |
|
| 2011-06-27 12:11:01 |
Rucha (Open ERP) |
openobject-addons: status |
In Progress |
Confirmed |
|
| 2011-07-22 12:26:38 |
Kirti Savalia(OpenERP) |
openobject-addons: status |
Confirmed |
In Progress |
|
| 2011-07-26 04:54:56 |
Kirti Savalia(OpenERP) |
openobject-addons: status |
In Progress |
Confirmed |
|
| 2011-10-17 07:39:32 |
Quentin THEURET @Amaris |
bug |
|
|
added subscriber Quentin THEURET |
| 2011-10-20 09:11:54 |
Atik Agewan(OpenERP) |
openobject-addons: status |
Confirmed |
In Progress |
|
| 2011-10-20 13:34:26 |
Atik Agewan(OpenERP) |
openobject-addons: status |
In Progress |
Confirmed |
|
| 2011-12-14 10:45:59 |
Kirti Savalia(OpenERP) |
openobject-addons: importance |
Medium |
Wishlist |
|
| 2011-12-14 11:17:03 |
Kirti Savalia(OpenERP) |
openobject-addons: status |
Confirmed |
Won't Fix |
|
| 2011-12-14 13:59:54 |
Olivier Dony (Odoo) |
openobject-addons: status |
Won't Fix |
Confirmed |
|
| 2011-12-14 14:02:09 |
Olivier Dony (Odoo) |
summary |
incoming shipment does not trigger corresponding delivery order |
Procurement - stock move relationships need to be improved to better handle e.g. split moves |
|
| 2012-01-20 14:36:28 |
Numérigraphe |
tags |
|
backorder |
|
| 2012-02-02 10:52:21 |
Numérigraphe |
tags |
backorder |
partial-delivery |
|
| 2012-02-15 20:12:31 |
Goran Kliska |
bug |
|
|
added subscriber Goran Kliska |
| 2014-03-13 09:05:49 |
Lionel Sausin - Initiatives/Numérigraphe |
openobject-addons: assignee |
OpenERP R&D Addons Team 2 (openerp-dev-addons2) |
|
|
| 2014-03-13 09:11:34 |
Lionel Sausin - Initiatives/Numérigraphe |
openobject-addons: status |
Confirmed |
Fix Committed |
|
| 2014-03-13 09:11:50 |
Lionel Sausin - Initiatives/Numérigraphe |
branch linked |
|
lp:openobject-addons |
|
| 2014-03-13 09:12:12 |
Lionel Sausin - Initiatives/Numérigraphe |
branch unlinked |
lp:openobject-addons |
|
|
| 2014-03-13 09:13:53 |
Lionel Sausin - Initiatives/Numérigraphe |
branch linked |
|
lp:~openerp-dev/openobject-addons/trunk-wms |
|
