Step to reproduce:
- Inventory > Configuration > Operations Types > Manufacturing (or any other operation type with code 'mrp_operation')
- Change 'Type of Operation' to 'Receipt' (or any other but 'manufacturing')
- Uncheck box field 'Use Existing Lots/Serial Numbers'
- Change 'Type of Operation' back to 'Manufacturing'
- Set correct value for 'Default Source Location' (type Receipt changed the value to 'Vendor', need to fix it)
- Create a storable product with the route 'Manufacture' selected.
- Create a BoM for this product, with a component tracked by lot (Add quantity to component)
- Create a MO for the product > Confirm > Check Availability
Current Behaviour :
Quantity are reserved, but the lot_ids are not visible
The behaviour is due to the fact that hidden parameters still have effect when they should act as their default value. To ensure it's the case, they are set back to their original value when the user switch between configuration to avoid ending in a wrongful configuration.
Behaviour after PR :
Lot ids are shown no matter the hidden configuration of picking type
opw-2680370
closesodoo/odoo#82377
X-original-commit: 22bbf43eba0927bdf27218da16f8435b33756112
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
Issue: The button # To Process in mrp/views/stock_picking_views.xml
at line 33 uses the domain state confirmed, draft, planned, or progress
But the default filter, which is called "to do", show those 4 states +
to_close (in mrp/views/mrp_production_views.xml line 309)
Side-Note: Issue also present in 14.0, so starting the bug fix from
here. 12.0 doesn't seem to have a to_close state but the count and
filter domain also do not match
Steps to reproduce in 14.0
On Runbot, go to Inventory click on the "# to process" button on a
Manufacturing card.
- Choose any MO and create a work order. On this work order, click
"Start", then "Done".
- The MO is now in the "To Close" stage.
- Go back to Inventory Overview. The number to process has gone down by
one.
- Click on the "# to process" button, you will see that the "To Close"
MO appears in the list but is not counted by the button.
(written by dido)
For 13.0 I haven't been able to find steps to reproduce but the button
has not changed between the two versions
opw-2636447
closesodoo/odoo#76834
X-original-commit: 7f3b65bb42444ccb02bfb80931b52a94924fcdb0
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
When recieving a kits product, it will be decomponent in the picking. In
this commit, we add a column in the picking to show the info of the kits
in picking.
Task-2444000
COM PR odoo/odoo#75555
ENT PR odoo/enterprise#20440
UPG PR odoo/upgrade#2783
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
When registering lot or serial number for a component in a workorder,
the manufacturer can create it on on the fly. We would like to give this
ability a restriction depending on the picking type.
This commit blocks the creating by default but leave the possibility to
tick a new checkbox on the manufacturing picking type to allow the
creation of lot and serial number for components inside the production process.
Task : 1891864
Usecase to reproduce:
- Set manufacture step to 2 or 3 steps
- Create a MO
- Go on the PC picking and validate some quantities w/h BO
Traceback because there is no documents to log the activity.
It happens because the function used in groupby and sorted
(in the method _log_less_quantities_than_expected) expect a picking.
The purpose of _log_less_quantities_than_expected is to generate
an activity on the next picking in order to notify that some quantities
will be missing due to the cancelation of the back order. In order
to find the following picking it uses the destination moves from the
current's picking moves.
Picking w/h BO Next Picking (activity to post)
| |
moves -----------> destination moves
However in the case of 'pick components' picking type(PC) the destination
moves are linked to a manufacturing order and not a picking. So it
_log_activity_get_documents return an empty parent since picking_id is
False.
In order to fix it, _log_activity_get_documents only add the tuple
(object where the activity should be log, responsible for the activity)
if the object is not False. It also add a hook in order to add
(mo_id, repsonsible) during _log_less_quantities_than_expected on top
of (picking_id, repsonsible) in order to log activity on MO directly
linked to PC.
This commit also add a missing precision_rounding in backorder
confirmation
opw-1908753
closesodoo/odoo#29385
The purpose is to be able to plan manufacturing order
without propagate the components's documents directly.
Except when the manufacturing comes from a pull rule, it will
be confirmed directly.
In order to do it, it will just create the moves without confirm them.
They will be only confirmed after a 'Mark as Todo' click.
Refactor production order state:
- Directly have an idea of linked workorders's state
- Computed in order to manage it in a single method
- Add tooltips for each state
Remove the None in availability selection field instead use a False
Also refactor the ready_to_produce field in order to only set as
assigned a production order that have the component for its first
workorder.
add missing string labels
rephrase the error message
add missing _description
removed forward-ported hr_equipment.pot
was unclear, courtesy of the translators
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Currently applying a color to a kanban item applies it to the whole
card. This creates usability issues as the content is not dynamically
updated to match the chosen color.
This commit proposes to apply the color only to the header and let the
card content standard. It helps designing cards that are always usable
and readable.
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
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).
Florian Damhaut