Comment 10 for bug 707287

As you can see in the product page the products UoM is clearly defined as LB. We generate manufacturing orders from LB. So everything is perfectly configured in our BOM. Now if you look at the second image it shows all of the stock moves for this particular product. Everything looks the same except the last line which is a much older stock move. It is registered as a purchase order in PCE. So a long time ago someone made a mistake, either the product really had the UoM as PCE or they made a mistake during the order process.

SO, Now even if the product is perfectly properly configured, when the scheduler runs and it comes to this product in the stock_move table for future moves it will halt the entire scheduling process and return the stack trace below. The only way that I can ever run the scheduler again is if I manually go to my database and make all entries of a compatible conversion type. This would indicate that we could NEVER change the UoM because we could have mass errors.

This doesnt just happen out of the box, something triggers it, but I assure you this is a bug, a serious bug. Besides the scheduler, in this scenario I could go to manufacturing and try to make a manufacturing order where a BOM had this product in it, and it would return the same error, making it impossible to use the product unless it was set to consumable or we did the database mod.

I even modified with help, my stock.py code so I could see the stock moves happening while the scheduler was running, so when it gets to this type scenario I can go to the stock_move for the product in question and this result is accurate 100% of the time. Extremely frustrating.