Steps to reproduce the bug:
- Create Product P: with BOM type - Kit and BOM components > Set - Invoicing: on delivered quantity
- Create PO with P and confirm - shipment 1 will be generated
- Cancel the PO - shipment 1 - will also get canceled
- Reset the canceled PO to quotation and confirm it - new shipment 2 will be generated
- Validate the shipment and receive product KIT
Bug:
Check PO - 'Received Qty' was not updated
Inspired from: https://github.com/odoo/odoo/commit/c2dfdc3081764a492a94024f1fb57e15636b04c9
opw:1889303
closesodoo/odoo#27622
Pickings/MO/SO/PO can be linked. Only the increased quantity is
propagated between documents. However their ordered quantities can
also be decrease or they can be cancel. In this case an activity
is created on impacted documents in order to describe the situation
and inform the user that a manual action is probably require.
Also in order to propagate the increased quantity from a MO, we have
to do important modification in MRP and we want to avoid doing it before a
major release. That's why increased quantity on a MO also work with
activity at the moment.
Steps to reproduce the issue:
- change the demo user settings -> use Sales: User: All Documents only
- create a stockable product with dropship feature on and a supplier
- connect as the demo user
- create a sales order with this product
- confirm the order
- as the admin user, confirm the purchase order generated through dropship
- connect as the demo user
- open the confirmed SO
- add a line with this product
- save the SO
Bug:
An access rights error was raised.
opw:1866015
When confirming a move for a kit, it is basically unlinked and replaced
by moves for its component. The link to the purchase line was kept in
v10, but since rev[1] it is not anymore. Make an helper to get the
values and override it in purchase_mrp to add the purchase line link.
[1] https://github.com/odoo/odoo/commit/8248f0e153ae5fcc1449d0d05149b61df615ad4f
opw 779497
When we purchase products of type services,the received quantity is
always set to the ordered quantity.
We want to be able to manually enter a received quantity on service
products to have a better trace of what have been received or not.
We show the picking stat button olnly if there are picking
We show the columns qty_received, qty_invoiced and invoice_status
depending on the parent state, and not depending on the context passed
in the menu item.
- Create a manufactured Product A (sold as kit), invoicing based on
delivered quantity.
- Create the associated BOM, e.g. contains 2 Products B.
- Create a SO with Product A, validate
- Change the BOM so it contains 2 Products C
- Validate the picking linked to the SO
The delivered quantity is not updated since the delivered products (B)
are not the same than the products of the BOM.
This should not be the case. Changing a BOM should not affect the
invoicing. To solve this, we simplify the check and only verifies that
all moves are done.
The same change is applied for PO.
In previous versions, the quantity passed to the bom_explode was the number
of times you needed to count the BoM. If the BoM was for 2 dozens and you pass
48 units, 2 was passed to the bom_explode method. We are now doing the same
for the explode method and we check it is called this way everywhere.
product_uom._compute_quantity is an ensure one multi method taking a browse
record as second paramter. It replaces _compute_qty and _compute_qty_obj
to have a single and standard computation method.
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :
- Picking type not only for pickings but also for manufacturing orders
- Properties replaced by picking type
- BoM can only be produced with its routing (no other)
- Either produce without routing with only production orders, or produce with
routing
- By default, there is an order in the work orders (serially), but you can
override it to be able to work in parallel
- Time clocking on work orders and block time on work centers with reporting
on OEE, performance, losses, ...
- Real-time adaptation of timings on operations
- Lots/serial numbers can be inputted like in the pickings on manufacturing
orders. It is also possible to input them in the work orders.
- Material availability independent of production order state (possibility to
start production when only part of it is there)
- Work sheets on work orders
- Put messages on work orders to make your workers pay attention to something
- Full traceability link to see for each produced piece of stock, the
consumed pieces, ...
- Separate scrap object (a scrap is not done based on an original move
anymore)
- Separate unbuild system (if you want to unbuild into its original
components)
Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
Christophe Simonis