Selling a product with phantom BOM ignores chained locations and procurement gets stuck

Bug #700154 reported by Don Kirkby
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
Medium
OpenERP R&D Addons Team 2
5.0
Confirmed
Undecided
Unassigned

Bug Description

I'm testing this bug on version 5.0.15 running on Ubuntu 10.04.

When you add a product to a sales order and that product has a phantom bill of materials (BOM), there are two problems: the stock moves for the component products ignore any chained locations that should affect them, and the procurement for the main product never gets marked as complete. This means that the sales order never gets marked as shipped.

I will attach a merge proposal that includes a test for this bug, but here are detailed steps to reproduce the problem:
1. Create a new database with the sample data included. Choose the Manufacturing Industry profile. Leave the rest as defaults and don't add any extra modules.
2. Configure a product with a phantom BOM that you can sell. I used PC0. Change the product's supply method to "make to order" instead of "make to stock". Go to the bill of materials and change the BOM type to Sets / Phantom, and also . There's also an extra bill of materials that points to the PC0 product but is named RAM on demand. It appears to be a mistake, so just delete it. Make sure to save changes on both screens.
3. Create a sales order to the Agrolait customer. Add a line with the phantom product (PC0).
4. Confirm the sales order and remember the order reference.
5. Go to the Stock Management: Outgoing Products screen. Double click on the packing list for your order reference.
6. You should see three stock moves: KEYA, MOU, and PC1. Click the Check Availability button and they should all become available.
7. Click the Packing Done button and Make Picking and Close. The packing list should now be done.
8. Go to the Stock Management: Delivery Orders screen. Look for a packing list for your order reference.

Expected behaviour:
There should be a delivery order for your order reference, and it should have three stock moves for the same three products as the packing list from the Outgoing Products screen. When you ship that delivery order and reload the sales order, it should be marked as picked. This is the behaviour you will see if you sell products that don't have phantom BOM's.

Actual behaviour:
There is no delivery order for your order reference. The sales order isn't marked as picked, even though you've shipped the only packing list there is. If you go and look at the PC0 procurement order, you'll see that it's still waiting.

Analysis:
There are two problems here: the code that explodes the BOM doesn't call action_confirm on the stock moves it creates, and it doesn't link those stock moves to the original PC0 stock move with move_dest_id. All of this code is in the mrp module's StockMove._action_explode() method. Calling action_confirm is what generates the delivery order. If you don't linking to the PC0 stock move with move_dest_id, then it never gets marked as done and the procurement gets stuck.

Related branches

Revision history for this message
qdp (OpenERP) (qdp) wrote :

just for info: i saw a bug similar few times ago in the trunk and it should be fixed there.

Revision history for this message
Azazahmed Saiyed (OpenERP) (saz-openerp) wrote :

Hello,

I have tested the scenario in latest 6.0 stable but everything working like the expected behavior suggested by you in bug specification.

Would you please check the test case in latest stable release and notify us if you still able to reproduce the bug in latest version.

Thanks.

Revision history for this message
Azazahmed Saiyed (OpenERP) (saz-openerp) wrote :

Hello,

I have executed your test case in stable 5.0.15 as you have written in your bug specification.

I am also not able to get the delivery order as you have written but it is not due to the bom method "sets/phantom".

Because I have also tested the same by making a new product and everything works as expected. Would you please check it again with the new product instead of using demo product "PC0".

Then let us know about it. Waiting for your reply.

Thanks.

Changed in openobject-addons:
status: New → Incomplete
Revision history for this message
Don Kirkby (donkirkby) wrote :

I see the problem even with a new product, so I'm not sure what we're doing differently. I used the following steps to reproduce the problem in stable 5.0.15 from lp:~openerp/openobject-addons/5.0.

1. Create a new database with the sample data included. Choose the Manufacturing Industry profile. Leave the rest as defaults and don't add any extra modules.
2. Create a new product called "Peripheral Kit" with code "KT99". Change the product's supply method to "make to order" instead of "make to stock". Change the supply method to "Produce". Choose the "Accessories" category.
3. Click the Bill of Materials button on the Product screen, and then create a new bill of materials. The name and product should all be filled in by default. Change the BOM Type to "Sets / Phantom".
4. Add a mouse and keyboard (codes MOU and KEYA) to the bill of materials.
5. Create a sales order to the Agrolait customer. Add a line with the phantom product (KT99).
4. Confirm the sales order and remember the order reference.
5. Go to the Stock Management: Outgoing Products screen. Double click on the packing list for your order reference.
6. You should see two stock moves: KEYA and MOU. Click the Check Availability button and they should all become available.
7. Click the Packing Done button and Make Picking and Close. The packing list should now be done.
8. Go to the Stock Management: Delivery Orders screen. Look for a packing list for your order reference.

Expected behaviour and actual behaviour were as described in the bug description.

Changed in openobject-addons:
status: Incomplete → New
Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

I am confirming this issue only for the following reason for 5.0.
-> There is no delivery order created by the followed the steps of comment #4.

I am confirming this issue in trunk because the procurement not going in to running state.
To produce this issue I have followed the following this steps.

1) Create a product (Make to Order->Produce) then created it 's BOM and set the BOM's type as a "Sets / Phantom".
2) Create a Sale order and confirm it.
3) Go to Warehouse Management/Delivery Orders open the delivery order -> process and validate .
4) See the SO 's state which is in "process" state.
5) Go To Warehouse/Schedulers/Procurement Exceptions and open the related procurement -> Run the procurement nothing should be happen.

So the SO never goes to in done state.

Thanks

Changed in openobject-addons:
status: Confirmed → In Progress
Changed in openobject-addons:
status: In Progress → Confirmed
Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Kirti Savalia(OpenERP) (ksa-openerp) wrote :

hello Don Kirkby ,

it has been commit in lp:~openerp-dev/openobject-addons/trunk-bug-700154-ksa
Revision no : 4465
Revision ID: <email address hidden>

Thanks.

Changed in openobject-addons:
status: In Progress → Fix Committed
qdp (OpenERP) (qdp)
Changed in openobject-addons:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.