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