The recomputation of stock move state is often done with already
the correct state (for instance in the case of move line deletion only
one of the deletion will change the state).
This commit check the move state before changing it only when it's
necessary.
Task: 2507143
X-original-commit: 80033446a091ff3ba98c58ba44ad665bfba30c98
Part-of: odoo/odoo#78547
Co-authored-by: Remy Voet <ryv@odoo.com>
Current Behaviour :
1. Enable Work Orders
2. Add an operation to a BOM
3. Disable Work Orders
4. Create a manufacturing order for this product and finish the manufacturing.
5. Print the production order
What is the current behavior that you observe?
The production order has the operations in it even though the work order option has been disabled. This is because disabling the work order option just hides the operations and does not remove it from the BOM.
What would be your expected behavior in this case?
The printed production should not show the operation.
opw-2660545
closesodoo/odoo#78544
X-original-commit: d73752c5fe983ce6a9147721e732396394a77cc4
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Issue: When replacing a tracked part while doing a repair, we
are changing the tracking number, but when checking for uniqueness,
we don't take that change into consideration
Steps to reproduce :
1) Manufacture product A with SN "A1" out of product B with SN "B2"
2) Make Repair Order for "A1" to replace "B2" with Product B (SN "B1").
3) Create Manufacturing Order product A (A2), select product B with SN
"B2" as one of the components.
4) Mark as done
-> Bug : "The serial number <B2> used for component <B> has already
been consumed".
Why is that a bug:
When checking for uniqueness we should take into consideration the
parts being replaced
opw-2625687
closesodoo/odoo#78407
X-original-commit: 79c673f9d15185be540dd535d7ebe10c8f138bf1
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
- Set the Decimal Accuracy at 5 digits for Product UoM
- Create a product X
- Create a kit BOM for X with a component Y, and qty 0.08600
- Create a Sale Order for 10 product X, confirm and deliver all
Issue
- On the SO, quantity delevered is 9.00000 instead of 10.00000, same
issue occur with the same flow with a Purchase Order.
Cause
As the quantity per kit was rounded when calling _compute_qty,
the calcul of quantity ratio was not well computed.
Solution
Avoid rounding the quantity per kit, as the quantity ratio is rounded
a few steps after.
opw-2590126
closesodoo/odoo#78516
X-original-commit: 2a2b198ea6ce1d0553c606404e6db1117dc1c4a2
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
PR odoo/odoo#76376 made it so operations (of a BoM) can now be
(un)archived in the list view. This commit makes it so we can also do
the same in the form view as well as see the "Archived" ribbon in the
form view.
Part 3 of Task: 2660820
closesodoo/odoo#78094
X-original-commit: e995860157becf34300365ac09e12ae57512e22a
Related: odoo/enterprise#21569
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The generate serial number button uses the stock.lot.serial sequence by default
(default value for name of stock.production.lot)
Serial Mass Produce (and other parts) allow to generate serial numbers
starting from a user supplied initial value.
This fix makes the button generate the next serial number
according to the last generated.
task 2647238
closesodoo/odoo#78258
X-original-commit: b80259dff3aaafb9d11af9d936f5106bdf5ed781
Related: odoo/enterprise#21641
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Jean-François Aubert <ajf-odoo@users.noreply.github.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
In PR: #74540 the MO.date_planned_start default was updated to
round up to the next hour. It was later decided this would be too
confusing so this commit reverts it back to the original default of now
(i.e. without any hour rounding)
closesodoo/odoo#77956
X-original-commit: 44c66cce8e545afd7b38c7fc81425fa69023798e
Related: odoo/enterprise#21506
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
- update MO list status colors: draft = blue, in progress = yellow +
make the WO status colors match (waiting = blue, in progress = yellow)
and make draft MO lines all blue (to follow current design standard)
- cleanup Activity in tree view (no label in tree + "Next Activity" in
column selection dropdown)
- make units of analytic accounting for WO = hours
- make quantity for move_raw_ids products (i.e. components for MOs)
always have positive analytic_account_line.unit_amount (i.e. when
changing a done move's quantity + changing a quantity twice made this
value negative)
- make "Copy Operations" on BOM open the list view in "current" instead
of "new" due to lack of hook to prevent form view (i.e. open BoM in
current view) changing when clicking on lines in the new window's
operations (also ends up being a better UX anyways since being able to
view the operations form view is desired).
Task: 2648460
X-original-commit: 65a2d478197f5b856212225319500ca61b161809
Part-of: odoo/odoo#77897
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
Improve 'Component Availability' and 'Product Availability':
Add these fields in form and tree view (the performance issues
is addressed in next commits and these fields will be load lazily)
task-2579011
Part-of: odoo/odoo#77092
The `_compute_json_popover` of (`mrp.production`)
was slowing down the tree view of MO (because it loaded
every move due to `production.move_raw_ids` even if there
isn't `delay_alert_date`.
Make it more lazier: we gain a speed up
when the there aren't any delay_alert_date
(always when the setup is simple)
To read 150 MO (7500 moves behind):
Before: 0.099 ± 0.002 SQL sec, 0.224 ± 0.005 Python sec (37 SQL requests)
After: 0.060 ± 0.0008 SQL sec, 0.096 ± 0.002 Python sec (29 SQL requests)
Also, unify the code with `stock.picking`.
task-2579011
Part-of: odoo/odoo#77092
This commit removes the action_confirm from the run_manufacture to do it
only after all the orderpoints have been processed.
In case a production, created in run_manufacture, triggers procurements
for one of its component. And those procurements have the same
parameters than another one still not run because after the manufacture
one in the queue. This new procurement will replenish its quantity plus
the other procurement's one.
That means too much quantity will be replenished.
closesodoo/odoo#77026
X-original-commit: a7bb9f1ac392c00be5bdd133fc5c73b9803c8b4b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
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>
Byproduct moves with same cost_share can be merge but only if there is
no other move with different cost_share in the list of move. This commit
allow merge move with same cost_share in any cases.
closesodoo/odoo#76709
X-original-commit: 41bd26f6522cf9f4e11962399504030c36512c39
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
It is currently impossible to create a MO from a mobile if there are
some work orders
To reproduce the issue:
1. In Settings, enable "Work Orders"
2. Create two products P_finished, P_compo
3. Create a BoM:
- Product: P_finished
- Components:
- 1 x P_compo
- Operations:
- Create a new one
4. Switch to mobile mode
5. Create a MO with P_finished
Error: When saving the MO, a Validation Error is raised "The operation
cannot be completed: - Create/update: a mandatory field is not set.
[...] Model: Work Order (mrp.workorder), Field: Unit of Measure
(product_uom_id)"
For a work order to be created, the request needs to provide one
additional field: `product_uom_id`. When setting the
product P_finished, `product_uom_id` is returned but not included
in the save request (because the field is declared as `readonly`)
OPW-2557181
closesodoo/odoo#76572
X-original-commit: 57c5e06f4f6de60ebc8b933ed327613588256273
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Component move with same product are not merge at confirmation as it
could be multiple different production steps.
opw-2583848
closesodoo/odoo#76401
X-original-commit: 390fce62462962e9a0131a082317e2e60e34041a
Related: odoo/enterprise#20801
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Commit 04f3cac527 makes picking_type_id compute on stock_move_line to
get the picking type of either the picking or the manufacturing order.
Right after, commit dd53f5323f set picking_type_id related of the
picking one to be able to search on it. (in this later scope,
manufacturing part was not needed, hence the related instead of compute.
This commit mix the two idea by having a new search function on the
computed fields to filter stock move line depending on their picking
type.
X-original-commit: d535108f96d62f217dda7cbb676f9d60b7477f4f
Part-of: odoo/odoo#76294
no need to make rounding during computing qty_available
STEPS (see the test):
* create product with uom dozens
* create product with uom units
* create bom kit to convert one to another
* set qty on hand to 1 for product dozens
* check qty for product units
BEFORE: qty=11
AFTER: qty=12
---
opw-2632782
closesodoo/odoo#76242
X-original-commit: 26b28408d8970baa8cbf59ffaff90cab1e579410
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.
opw-2637321
closesodoo/odoo#76116
X-original-commit: 864d90a064f093bd6ba24d8464ee491a443a320e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Issue: When creating a manufacturing order and setting a scheduled date
when no workcenter is set, a traceback shows up
Steps to reproduce :
1) Install Manufacturing
2) Enable work centers
3) Create a manufacturing order, in the work order tab, add a new line
and set a Scheduled Start Date, confirm the date
-> Traceback
opw-2633940
closesodoo/odoo#76117
X-original-commit: ebf54c802664e6c2143785b950667c136944fcbf
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
In case a production order loses its procurement group. The backorder
generation process do not have access to the last backorder sequence
used. This commit set a default value to avoid any traceback.
The new backorder name will not be guaranteed exact related to the
production sequence but will be unique in any cases.
closesodoo/odoo#76091
X-original-commit: aae07e88a8166cf26a8c81bb8ee37d630fd6672c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
We clean various graph archs taking into consideration that:
- the default type of a graph is "bar".
- a bar chart is by default stacked.
- the field attributes type="row" and type="col" does not make sense for
a graph view (since its implementation was separated from the pivot
implementation a long time ago))
- the boolean attributes should now take 1 or 0 as value (but the other
values are accepted for retrocompatibility).
Part-of: odoo/odoo#76065
Since return moves are linked to their original move, it's easy to
manage reservation in those case. We just don't bypass the reservation
when it comes from a reservation outside our stock in order to manage
the computation on linked moves and reserve pieces that were not yet
return.
Also add a return picking type for 2 reasons:
- Allow to select existing lot.
- Display reserved move line for an incoming picking.
Note that this picking type is just a default configuration and could be
modify by the user without any issue.
closesodoo/odoo#64384
Related: odoo/enterprise#20605
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The "BoM Structure & Cost" takes now in account
the subcontracting cost.
The subcontracting cost depends of the best supplier info in product
and subcontractor register in the BoM.
- Also add this subcontracting cost (to the cost field) when we click on
"Compute Price from BoM" in the product view.
task-2486811
Part-of: odoo/odoo#75041
Add `_get_extra_column_count` to extend and clean
extention for mrp_plm and mrp_subcontracting.
See enterprise commit.
task-2486811
Part-of: odoo/odoo#75041
When a product's has a kits bom, we consider it a kits product.
When a product is a kits product, we count its "on hand" and "forecast"
qty by caculating how many can be produced according to the bom.
We add status button to the show the qty on kit product form.
Task-2444000
COM PR odoo/odoo#75555
ENT PR odoo/enterprise#20440
UPG PR odoo/upgrade#2783
Signed-off-by: Arnold Moyaux <amoyaux@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
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
The `confirm_no_consumption` field was useless
(can be replace by a other condition). Also
it was compute in a slow computation method
which should't not use in batch (not ready for now)
See odoo/upgrade#2792closesodoo/odoo#75827
Signed-off-by: Tiffany Chang <tic@odoo.com>
Review Work Order pop up design:
- add mo reference and Components tab at first
Manufacturing Readiness:
- set 'When all components are available' as default
closesodoo/odoo#75675
Task: 2527408
Related: odoo/enterprise#20515
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
1. Activiate "Units of Measure" setting
2. Create and "mark as done" a MO
3. Unlock MO (may need to activate MRP setting for locking/unlocking qty
to consume to see button to unlock first)
4. Add a new component to MO and save.
Expected result: New component added
Actual result: Validation Error related to UoM
This is due to all components' UoM being readonly once the MO is Done so
when the new component move is created, it is missing a UoM value.
We fix this by making any newly added component lines' UoM not readonly
regardless of MO status. When a user saves a MO after adding a new
component, they will not be able to edit the UoM again due to
quant/stock move inconsistencies this can cause.
closesodoo/odoo#75436
Opw: 2514262
X-original-commit: ab0fcdbceef3e2df7b89766b074c386465c60ad7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Expected duration and real duration should be hide when the user doesn't use the Work Order aren't active
closesodoo/odoo#75677
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This revision has a similar goal than the previous revision
62c5b8d95c1ba5634e201c0c8a3e2d91fb2305a7
but this times, it's a kit/phantom bom which is nested in another
kit/phantom bom, and their computation is asked in the same time.
```
2021-08-20 11:29:54,835 1689 ERROR db_22687 odoo.upgrade.stock.tests.test_on_hand_quantity: FAIL: TestOnHandQuantityUnchanged.test_check
Traceback (most recent call last):
File "/tmp/tmpv3ujv2vr/migrations/testing.py", line 208, in test_check
self.check(value)
File "/tmp/tmpv3ujv2vr/migrations/stock/tests/test_on_hand_quantity.py", line 20, in check
self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[551[14585 chars] [8988, '137'], [8989, '137'], [8990, '20'], [[1793 chars]91']] != [[551[14585 chars] [8989, '137'], [8990, '20'], [8991, '126'], [[1778 chars]91']]
First differing element 1007:
[8988, '137']
[8989, '137'
```
```
SELECT b.id, b.type, p.id as kit_product_id, b.product_tmpl_id as kit_product_tmpl_id, pt.name as
kit_product_name FROM mrp_bom b JOIN product_template pt ON pt.id = b.product_tmpl_id JOIN product_product p ON p.pr
oduct_tmpl_id = pt.id WHERE p.id = 8988;
-[ RECORD 1 ]-------+-----------------
id | 2208
type | phantom
kit_product_id | 8988
kit_product_tmpl_id | 9049
kit_product_name | KIT Poulie AR G4
```
```
SELECT b.id, p.id as kit_product_id, b.product_tmpl_id as kit_product_tmpl_id, pt.name as kit_product_name, l.product_id as component_product_id, component_t.name as component_name FROM mrp_bom_line l JOIN mrp_bom b ON l.bom_id = b.id JOIN product_product p ON p.product_tmpl_id = b.product_tmpl_id JOIN product_template pt ON pt.id = b.product_tmpl_id JOIN product_product component ON component.id = l.product_id JOIN product_template component_t ON component_t.id = component.product_tmpl_id WHERE l.product_id = 8988;
-[ RECORD 1 ]--------+---------------------
id | 2213
kit_product_id | 8761
kit_product_tmpl_id | 8879
kit_product_name | VEL BP KIT direction
component_product_id | 8988
component_name | KIT Poulie AR G4
```
upg-22687
closesodoo/odoo#75735
X-original-commit: c2df3d43fe16dde9057422f573fed1b976bc1c0b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In the backorder process the operation are done in this order:
1. If the MO has workorders then set the remaining quantity as quantity
producing
2. Confirm the moves
However the system do not expect qty done on draft moves for a lot
of operations.
This commit inverse the order to allow some buisness logique to work
(e.g the analytic accounting)
opw-2469742
closesodoo/odoo#68708
Related: odoo/enterprise#18594
Related: odoo/upgrade#2739
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add analytic accounting for MO.
Post expense entries for:
1. raw material cost (change with consumed)
2. work center cost (change with real duration on work order)
Task-2469742
PR #68708
Rémy Voet (ryv)