Before this commit
==================
MO not closed even when flexible consumption is confirmed from the tablet view.
If in some operations less or more commodity is consumed then when we click on
mark as done and close mo, it only generates consumption warning wizard and the
state of MO is still in to_close and not done, since the backorder wizard is not
generated.
After this commit
=================
MO is closed along with consumption warning wizard and backorder wizard.
TaskID - 3192078
closesodoo/odoo#119491
X-original-commit: 8bd83439e3b5ae547e4fc2e21677ab8e925cb73a
Related: odoo/enterprise#40181
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
In consumption warning, we add a new button that can correct all
qty_done according to should_consumed_qty.
closesodoo/odoo#113538
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since the conversion of the list view to owl, the relative field size
has not been reimplemented. We have decided not to support it anymore.
So we will remove all its uses.
The relative width consists in adding a width attribute with a
value. This value corresponds to the weight of the field, the higher
it is, the more space the field will take. This size is only used when
the list is empty.
Example of this:
<tree>
<field ... width="2">
<field ... width="1">
</tree>
The first field will take 2x more space than the first one when the list
is empty.
closesodoo/odoo#110382
Related: odoo/documentation#3375
Related: odoo/enterprise#36020
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When changing quantities of raw moves after MO confirm,
procurement is run to fulfill updated need.
Since procurement creates new moves, some fixes were also done to allow
moves to be merged with older ones, including:
1) `date_planned_start` of merged MO included microsecond which
blocked merging new moves created by procurement with orig moves.
Removed microseconds.
2) `_set_date_deadline` did not allow a simple date update to moves with
orig or dest moves. Added context to hard set all moves in self to specific
deadline.
3) `_update_candidate_moves_list` when merging moves, did not return candidates
from pickings that were merged to same MO. Usually just mattered when decreasing
quantity. Added explicit check for sibling pickings in MO
closesodoo/odoo#93712
Task: 2859547
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- Many ui/text updates
- Fix To consume field display
- Add Draft/Done filters to Scrap views
- Fix BoM name_create problems due to _rec_name set to product_tmpl_id
Task: 3094741
Part-of: odoo/odoo#108446
Adapts the layouts of the immediate production and the production's
backorder to match the new grid css for groups.
Part of task-2985735
closesodoo/odoo#102958
X-original-commit: 5b999ee40e02647c0d2edfbce7081f6f8cf05857
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When mass producing from several reserved lots, we display a warning
message that the lot reservation is 'multiple'. This commit displays
that message in red.
task-2925474
Part-of: odoo/odoo#97588
This commit fixes two bugs:
1) Wrong source location
Before this commit:
- Source location is incorrect after merging MOs and 3-step manufacturing is selected.
- Operation type is incorrect after merging MOs
After this commit:
- Set the source location from the correct picking_type's value while merging MO.
- Set the Operation type for the merged MO to be the same as the original MOs';
2) Traceback when splitting mo
Before this commit:
- When splitting a MO without a "responsible user" set then boom it's throwing traceback
After this commit:
- The "responsible user" is no longer required which matches the existing MO behavior
TaskID - 2754217
closesodoo/odoo#99374
X-original-commit: 67e3f2f66aeb1aa1a93ad5091af7c0375f6d9a93
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Currently MRP only allows sequential scheduling of work orders.
This commit allows to specify the dependencies for work orders to be
scheduled in parallel or in a complex diagram.
By enabling the feature in the settings and at the bom level,
you can specify dependencies between operations:
on the operation form, select the operations on which the
current one depends.
The dependencies will be reflected in work orders during planning.
The workorders Gantt view has been adapted for you to visualize
and manipulate the dependencies.
Please note:
- work orders without predecessors will be started first
- they can all be done in parallel
- when all work orders of this step are finished, their successors
will start
- and so on, step by step
Also, with the feature activated at the bom level and no dependency,
the parallel scheme will be applied (all operations at first step).
Finally, without activation at the bom level, the dependencies will
be created in order to satisfy the current sequential model.
Task: 2691328
Part-of: odoo/odoo#87131
If a warehouse is set to a route like default 3-steps, updating the MO's
quantity to produce won't update the outgoing picking from
post-production to stock.
Since the quantity is now changed in the following pickings, no need to
put a warning in those pickings for the quantity change as their moves
quantity were automatically updated.
Task-2797359
closesodoo/odoo#86572
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usecase:
- Create a BoM with a product tracked by SN
- Create a MO with qty 5
- Mass produce
- Generate
-> All the `stock.move.line` in the move_raw_ids don't have
the qty done prefilled. The purpose of the feature is to create
and validate a lot of MO at once. Which is impossible if you have
to fill all the quantity manualy.
The choice of a new kwargs that directly set the qty_done is justified
by the performance.
-> For On a BoM with 10 components for a final product. For 1000 finished
product with SN
- If we do a loop on each `stock.move.line` to set
qty_done as the reserved quantity. It goes from 40s to 135s
- With the kwargs. It remaines 40s
closesodoo/odoo#83123
X-original-commit: 8ce5926b5a337dc97237f39492e094288b453743
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Previous versions of backorder mechanism would trigger reordering rules
for components of backorder MOs. This could lead to a procurement_group
mismatch (see original commit for details).
Backorders no longer trigger reordering rule, but it is still safer if
we clean the default_mo_ids when making backorders just in case. One
rare use case would be: if a user deletes multiple MOs'
procurement_groups, then creating backorders for those MOs at the same
time (i.e. via list view > multi-select + action > Mark As Done) can
result in incorrect procurement_group assignment due to default value
(same reason as explained in original commit).
closesodoo/odoo#84351Fixes: odoo/odoo#83742
X-original-commit: e3af56520fc3397f24c05b64d991f28a3227262b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Split a manufacturing order in several parts
using the back order mechanism
Merge several manufacturing orders related to the same product/bom
by cancelling all of them and creating a new one
closesodoo/odoo#82427
Task: 2662566
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Mass produce originally prohibited multiple lots components.
Later commit removed this limitation (among others).
This one displays a warning to make sure it is intentional.
task 2633369
closesodoo/odoo#77254
Related: odoo/enterprise#22797
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There is 2 major issues with the production of multiple serials number
- Performance issue
- Duplicated code with classic backorder mechanism
The performance issues exist since backorders were create one by one
and `stock.move` and `stock.move.line` are always recomputed. They
are not created in batch neither.
_generate_backorders is removed and replace by _split_productions. The
functionality are the same. Technicaly it does the maximum in batch,
first it creates all the `mrp.production` then all the `stock.move`
and finaly, it splits the existing `stock.move.line` among the new
`stock.move`
It means that the reservation is not recompute anymore during a
backorder process and will remain the same than the splitted production
order.
Performance metrics (10 components):
| 2 | 10 100 1000
before | 0.47s | 2.84s | 32.25s | 580.53s
-----------------------------------------------
after | 0.13s | 0.36s | 2.60s | 35.17s
task 2633369
Part-of: odoo/odoo#77254
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
In 1e93c161ca454313436b65427542db961f6ddcdd we trigger RR when
confirming a MO. Same thing should be done if we changed the product qty
for a confirmed MO.
Task-2653116
closesodoo/odoo#79332
X-original-commit: 22eb5c38ff45f4e5cd5d2025d31960efa051ad6b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Allow to produce several serial numbers at once.
Only when BoM do not contain any component tracked by unique serial number
and lot ones are from 1 lot.
Also allow to copy/paste serial numbers.
This applies to manufacturing orders.
Task: 2444742
Part-of: odoo/odoo#71732
Improve the UI for the MO and the WO with some new features, better readability and usability
- The forecast for the MO in draft makes the preparation of a MO easier. The behavior of `forecast_availability` depend of the state of the move
- The sum of expected duration and real duration in the MO, make the MO visually clearer
- The field Scheduled Date is rounding up to the next hour for less manipulation
- The automatic reference in a BOM if there is already a BOM for this product allows making less manipulation. I'm using this variable `number_of_bom_of_this_product` with the result of the query inside so I didn't need to do the query twice and the query doesn't take the current bom.
- A rounded value is better for the OEE in WO summary
- Have a tag for a workcenter can be a good idea to add more information to it. I'm using a random value for the color of the tag, we are doing it frequently to have a random color on multiple think.
- Knowing the final product of a WO is clearer
- To notify the user when creating a product with a reference that are already existing is a good idea.
- Change some color in the MO view for better readability
- And more minor tweak (like to align some part in the view)
--- Links ---
The PR: https://github.com/odoo/odoo/pull/74540
The PR on enterprise: https://github.com/odoo/enterprise/pull/20006
Task related: 2442895
closesodoo/odoo#74540
Related: odoo/enterprise#20006
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Updating the quantity to produce on a production order will recompute
the expected production duration. This can be counter productive on
prototyping production when no BoM are given. The default expected batch
duration is set to 60 minutes. Setting the actual production time then
updating the quantity to produce will naively change the duration to
60 x the new quantity.
This commit compute the duration pro rata in case of 'no BoM' production
and recompute everything in case of BoM production.
Task : 2278147
This commit introduce the immediate production mechanism. As it works on
stock.picking, marking a (some) production(s) as done without consuming
anything will pop a wizard allowing the user to transfer all the reserve
component quantities as done quantities.
Task : 2278147
- Default quantity on MO is 1.0
- Default quantity to consume on move is 1.0
- No open on the company_id from BoM form
- Optional=Hide for product, qty on BoM form
- Backorder button renamed to Validate
- Date deadline and origin to Miscellaneous tab
- Be able to remove stock_move when the MO is draft
- Some renaming in the menu and run scheduler under planning item
[FIX] mrp: fail to create stock.move after MO confirmation
Since the product_id on stock.move is readonly once it is set and the
MO is confirmed, it's not send to the server and the create crash
since product_id is NULL.
closesodoo/odoo#55270
Related: odoo/enterprise#12148
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When launch a consumption warning wizard by clicking the "Mark as done
and close mo" button, always close the MO. And return to tree view if we
open the tablet view from a 'start' button, return to workorder kanban
if we open tablet from that.
Task 2278147
X-original-commit: 4d03cf5e8d29933d5f96099f8f662c9084b20197
If the consumption wizard is triggered in a workorder (via 'Mark As Done
And Close MO'). We would like the confirm button redirect to the
workorder list view afterwards.
Task : 2278147
X-original-commit: 55e2a4d16d3a56b8f509d2d67a344c53d62474b6
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Bunch of last minute fixes including:
- serial handling in tablet view
- expected durations and backorders
- button unplan unlinks the leave but the computed aren't recomputed
then we need to manually set the date_planned_start/finished
then we need to not propagate them on the related document
(move/production) because they are required
- operation company_id wrongly set
task-2241471
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
Previously, when we upate the "Quantity to Produce" on a MO, we update
the components to consume according to the BOM we use. After this
commit, we now update the components according their current number set
on the MO.
For example, if we have a MO to use x component A to produce y product
B. When we update the number y to z, the number of A we want to consume
will be updated from x to x / y * z, regardless of the setting on the
BOM. If multiple components are used, all components will be updated
according to this rule.
Task: 2241471
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
- Create a product P
- Create a BOM:
Use 1 unit of C
Routing with 2 Operations
Start Next Operation: 'Once all products are processed'
- Create a MO for 10 units
- Process the first WO
- Scrap 2 components, produce 8 units in the first WO
- In the MO, change the quantity to produce to 8
The first WO is done, the second WO is still waiting for the previous
one to finish.
We change the state of the next WO.
opw-2244166
closesodoo/odoo#50690
X-original-commit: 8a723f0f104e64d336764431ea15eb3166cc52b7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this, unable to quick create production lot from
produce wizard in components, as default company was not
set correctly.
Fixes-2234784
closesodoo/odoo#49455
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Let consider a user U from a single company C (Multi companies = False)
- Let's consider a BOM B for a finished product FP with product P1 as component and product P2 as byproduct
- Let's consider that P2 is tracked by lot
- Log as U and create a MO for FP
- Produce the MO
Bug:
A widard was opened but it was impossible to create a lot for P2
opw:2216028
closesodoo/odoo#48556
X-original-commit: 30ebdee091362b8c857bdcad2bdf44bd698572c4
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit a4c0994 uses variable `qty` as input parameter but override it
at each loop iteration. The original value of `qty` is lost after the
the first pass and so give wrong results for all next iterations.
This commit uses another name to never lose the given value.
closesodoo/odoo#46587
X-original-commit: e1c30bceba6d47d8e087e540f995a02086fa6283
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Improve the inherited wizards of 'stock.warn.insufficient.qty' by adding
some piece of information about the quantity involved. Also
change titles to integrated the related product into.
task-2144636
Co-authored-by: Ankita Raval <anr@odoo.com>
Rahul Reddiar