Orders for products with Phantom BOMs never "Done"

[Allison]

Using OpenERP v7

When an order is placed that contains a product with a Phantom BOM it will never reach the Done state.

Steps to reproduce:
1) Create a product with the following options:
- Product Type: Stockable Product
- Procurement Method: Make to Order
- Supply Method: Manufacture
2) Add a BOM to it with the following options:
- 2 regular stockable products
- BOM Type: Sets/Phantom
3) Place and confirm order for this product
4) Deliver the delivery order (assuming the line items are available)

Looking back at the sale order the "shipped" box never gets checked. Taking a look at the procurement.order tree view, filtering on sale order name, there is a record for the phantom BOM parent product that never leaves Waiting* state. With the procurement order for the phantom BOM parent product still in Waiting (and the corresponding stock move still in Waiting Availability,) the "shipped" box on the sale order will never become checked.

*Depending on if the phantom BOM parent product is MTO or MTS the states of the procurement order differ between Waiting/Exception, respectively. Neither allow the sale order to be completed.

[Rifakat Husen (OpenERP) (rha-openerp)]

Hi,

The fact is we are delivering the components for Set/Phantom BoM product and as soon as you delivered the
components, it should trigger/validate the dummy stock move of the main product. But main product's stock move
does remain in the waiting state and hence the procurement order.

This is a duplicate bug report and I have already fixed this problem in lp:1269365
Regards,
Rifakat

[Paulius Sladkevičius @ hbee (komsas)]

It's related with old bug that was not fully fixed please check lp:380529 and specailly last comment that we are facing now https://bugs.launchpad.net/openobject-addons/+bug/380529/comments/17

[Leonardo Donelli (learts92)]

If anyone comes here from Google:

This was fixed 27 May 2014: https://github.com/odoo/odoo/commit/1ef2c181033bd200906fb1e5ce35e234bf566ac6

I tested it by applying the single line change of that commit to an old affected version and the problem was solved.