- Create a MO, components needed are 1 unit of Prod A and 1 unit of Prod
B.
- Click on "Check Availability"
The button "Unreserve" does not appear unless all components are
available.
opw-724940
When clicking on smart button "Manufacturing" for a variant, the action
"act_product_mrp_production" was called to apply the default filter on
product_id = active_id to select the right mrp.production. But the field
product_id was also called "Raw material" and a wrong domain was applied
each the action was triggered from a variant.
opw:725050
When clicking on the "manufacturing" vignette in the inventory
dashboard, the records were not filtered correctly (example: add a new
warehouse, a new "manufacturing" vignette appears for this warehouse in
the inventory dashboard, clicking on it would display the MO of all the
warehouses).
With this fix, as with the pickings, it will only show the count of MO
filtered to that specific picking type in the vignette, and clicking on
it will displayed the filtered ones.
We implementent the method of the compute field the same way the similar
method for the picking is implemented.
fixes#15008
The field resource_type in mrp.workcenter tree view must be invisible because
this field was not available in the form view before f9f4bba
Adding resource_type in the form view had no business case.
opw:698183
filter 'products' doesn't exist on product.template, it is named 'consumable'
rename 'search_default_products' to 'search_default_consumable' in actions
Closes#14690
The location field is shown all the time. However it is only used for 2-steps
which is more complicated to configure and understand. That is why advanced
routings group is used to hide this field in other cases.
Having 'Post Inventory' button highlighted makes it look like a necessary step
to take. However in practice using 'Mark As Done' is sufficient. Moreover this
action also posts the inventory.
Removing the oe_highlight makes it look like an optional step. It is still
necessary in some cases with SO / MO when not all products are produced.
As the finished move or the one after might automatically split into its components,
it is not a good idea to select a Phantom BoM for a production order, so
this is for the moment, the best way to avoid it.
When updating quantity, it should take use a similar
method as for generating the moves, but with
the quantity already produced (and posted) deduced.
The parameters for these method needed to be changed.
When all the moves are posted,
we should create the necessary extra moves.
If the quantity is put back to the quantity posted, it
might also need to delete moves.
In byproduct, it should take into account the subproduct factor.
When the quantity produced on the work orders has reached the quantity to do,
it should not allow anymore to use the "Done" button on work orders, but
rather use the Finish button instead. With the Update button on the manufacturing order
it is possible to do more.
The labels of the fields say that they store hours, but actually they store minutes. Correct the code to store hours.
Add digits to fload field for a better display in the webclient
date_planned_start should also be Start Deadline instead of Expected Start Date.
We don't want the Expected dates to function as a planning tool, but as
a priority for the planning of the workorders.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
=======
Purpose
=======
The company form should be heavily simplified. It's complex to have some settings on the company form, and others on the Settings menu of the related app. It would be much easier to have all settings in Settings menu (res.config) and nothing on the company, even if some of the Settings are multi company. (Stored on the company but set from the Settings menu).
As you open the lots in a raw material move in a production order,
you should not see the temporary stock move lots from the work order.
Also the quantity_done should not take into account those. They will
when they press 'Done' on the workorder.
When posting inventory, the temporary stock move lots on the workorder,
should be transferred to the split move.
For splitting and unreserving, some optimizations are done.
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).
MRP module is migrated to the new API. It excludes mrp models that will change
quit a lot during the new MRP conversion. Actually most of the code is not
migrated, but at least side models and their methods are already migrated.
This should lessen the diff when writing the new MRP.
Split files and move them according to the new API guidelines. Containing
- mrp splitted into its main models and files
- stock code moved into its own models and files
- various renaming
Nicolas Martinelli