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>
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>
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>
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>
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>
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>
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>
Issue: In work centers with a capacity different than 1, the expected
duration was wrongly computed
Steps to reproduce :
1) Install Manufacture, enable Work Centers in Settings
2) Create a Work Center, Capacity = 2
3) Create a Product, with Manufacture as route
4) Create a Bill of Material :
Add any component
Add a operation line :
Work Center = created at 2)
Duration Computation = based on tracked time last 1 WO
5) Create a Manufacturing Order for the product 3), confirm
6) Set the real duration to 00:10, mark as done
7) Check the BoM Structure & Cost of the BoM 4)
-> Operations is 00:20
Why is that a bug:
To compute the expected duration, in mrp_workorder.py L691 we already
take into consideration the capacity of the work center.
When computing the time_cycle, we must give a time_cycle for 1 product
made with capacity 1, so we must first normalize the qty_produced fetch
from the DB to make like if we only produced the quantity once but in
the same amount of time
Side-Note: This also solves an issue with the Duration Computation based
on tracked time. The `limit` keyword was applied after the `group by`
so we effectively grouped all the operation_ids together, summing
their quantities and then limiting on the different operation_ids
opw-2562983
closesodoo/odoo#75557
X-original-commit: c78a25f92716bd6014de381c34f3bc268d1528ae
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
When a document (SO/MO) create a demand and this demand is directly
refill by an orderpoint, then write the source document that triggered
the orderpoint in addition in the origin field.
The purpose is to have an easy base tracking configuration even if
the priority and schedule date (and the final customer) could change
afterward (origin field still editable)
Part-of: odoo/odoo#75144
Usecase to reproduce:
- Enable multi steps manufacturing (pbm at least)
- Set a RR 0 0 on a component
- Confirm the MO
-> The scheduler is not run for the components
It happens because only the moves raw are confirm and not
the pickings from the procurement group (like in SO)
Part-of: odoo/odoo#75144
For improved cost analysis, byproducts can now have a "cost share" (out
of 100%) indicated. This cost share will by multiplied by the total BoM
cost (i.e. components + operations costs) and reflected in the stock
valuation. The final product will also have the byproducts cost
subtracted from its final stock valuation. This is of course only
applies when costing methods are appropriate (i.e. non-standard price).
Additionally, we can now "Compute Price from BoM" for byproducts (via
its product form) and the BoMs that it is a byproduct of are now counted
towards its # BoMs smart button (we will now also see these BoMs when
clicking on the smart button). Of course when there is no cost share for
byproducts then clicking on "Compute Price for BoM" will not change the
a byproduct's cost and if there are multiple BoMs the prodcut is a
byproduct of, the calculation will only be based on the first BoM it
finds (i.e. same as current logic for manufactured products).
BoM Cost report has been updated to include byproducts with cost shares
(byproducts with cost share = 0 will not show up in report).
Additionally we update the report to display operations only costs now
that BoMs are allowed to have no components in them.
Part 1 of Task: 2440068
Upgrade PR: odoo/upgrade#2727
Related ENT PR: odoo/enterprise#20169
Part-of: odoo/odoo#74951
This commit adds a new field to work orders to store the hourly cost of
its work center at the time of its completion. This is to avoid
inconsistent cost calculations when a work center's hourly cost is
changed after the WO is completed.
Part 2 (fix) of task: 2440068
Enterprise PR: odoo/enterprise#20169
Upgrade PR: odoo/upgrade#2727
Part-of: odoo/odoo#74951
Missed the case of copying a cancelled MO needing its cancelled
move_finished_ids to still be copied during commit:
79efbd0e4707892041ee7c58c81c1d7edd033edd
Steps to reproduce:
Step 1: make a MO and cancel it
Step 2: duplicate the MO and try to mark as done
Expected result: qty is produced
Actual result: Validation Error about quantity to produce must be
positive (due to no move_finished_ids)
Follow up to task: 2618962
closesodoo/odoo#75569
X-original-commit: 56e7d4acc59a802c7613c1184858bda5bfb26748
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
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>
If the prefix of the production sequence contains some dashes, it can
lead to undesirable behaviors
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Sequences & Identifiers > Sequences, edit "San
Francisco Sequence production":
- Prefix: "WH-MO-"
2. Create a MO
- Quantity: 2
3. Confirm, Edit:
- Quantity: 1/2
4. (Keep MO's name in mind and) Validate + Create backorder
Error: Backorder's name is "WH-MO-002" instead of "WH-MO-0000X-002".
Going back to the initial MO, its name became "WH-MO-001" (was
"WH-MO-0000X")
OPW-2618971
closesodoo/odoo#75270
X-original-commit: 076fe045f219dcb018b3b18215bfc3a0cfb3aa46
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
When combining a reordering rule, the 3-steps manufacture and
by-products option, the picking from the post-production to the stock
will not contain the residual products produced by the MO (by-products)
To reproduce the error:
1. In Settings, enable:
- By-Products
- Multi-Step Routes
2. Inventory > Configuration > Warehouse Management > Warehouses, edit
company's warehouse:
- Manufacture: 3 steps
3. Create 3 products P_compo, P_finished, P_secondary
- P_compo is consumable
- P_finished and P_secondary are storable
- Routes of P_finished: Manufacture
4. Create a reordering rule for P_finished:
- Min = Max = 1
5. Create a BoM:
- Product: P_finished
- Type: Manufacture
- Components: 1 x P_compo
- By-products: 1 x P_secondary
6. Inventory > Operations > Run Scheduler
7. Open the generated MO
8. Check Availability, Produce, Mark as Done
- Note that in the "Produce" wizard, we mention that one P_secondary
is also produced
- Also note that in "Finished Products" tab, there are 1 x
P_finished and 1 x P_secondary
9. Open the Transfers
Error: The picking Post-Production -> Stock does not exist
When creating the byproducts move
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L587
the field `move_dest_ids` is present (is the move created after
evaluating the RR)
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L580
so it is used, but this will cause the `_push_apply` to skip the
evaluation of the move
https://github.com/odoo/odoo/blob/f0eaa756c4947e2a595359959b34b14bfda81a07/addons/stock/models/stock_move.py#L678-L679
and `_assign_picking` will not run, as it normally do when creating the
manufacture
Thanks to this change, the picking Post-Production -> Stock will exist
and contain the residual products
OPW-2581762
closesodoo/odoo#75068
X-original-commit: 098af2fa85d2aebfc71b7e2342a1bbf05100e10d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
On BoM, a component line can be filter out depending
of the product variant to manufacture
(with "Apply on Variant" field).
Extend this feature to operation and byproduct line.
task-2614126
closesodoo/odoo#74973
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
Step 1: make a MO and create less than the quantity to produce
Step 2: Mark As Done (with no backorder)
Step 3: duplicate the MO and try to change the quantity to produce
Expected result: qty to produce changes as expected
Actual result: server error
Issue is due to the copied MO's `move_finished_ids` including a copy
of the cancelled finished move (i.e. the qty not backordered) so there
were 2 `move_finished_ids` for the product to produce. This resulted in
an access error since the onchange to update the `move_finished_ids`
only expects 1 move for the product to produce and results in a
singleton error.
Note we copy cancelled move_raw_ids because otherwise we wouldn't be
able to duplicate cancelled MOs without losing all of its components.
Issue 2 of Task: 2618962
closesodoo/odoo#75073
X-original-commit: 456c337534427db1296030b004ae061b47d8db79
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, MOs were not filtered based on selected BoM.
With this commit, We are filtering MOs to selected based on BoM.
Fixes#70215closesodoo/odoo#74698
X-original-commit: 847f61a7716c62b0076cef0aa13d58d7dd9d09eb
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Steps to Reproduce Bug:
- Add Attachment on Bom Line
- Delete Attachment
Bug:
- Attachment is still present on `ir.attachment`
With this commit, we are removing linked attachment on deleting `mrp.document`
closesodoo/odoo#74595
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previous fix commit 5e34a02 was too aggressive in when it would delete
the move_finished_ids. In certain use cases it would result in no
move_finished_ids and a corrupted MO:
Steps to reproduce:
1. Create a new MO
2. Save the MO (do NOT confirm)
3. Update the qty to product_qty (qty to produce)
4. Confirm + Mark As Done
End result: "qty to produce must be positive" error whenever MO was
attempted to be completed and MO can never be completed.
To fix this, we split out when the move_finish_ids. They should all
be deleted ONLY when the product to produce is changed. Unfortunately to
cover all cases, we must always wipe the moves whenever the product is
changed (e.g. when changing the product twice with the original product
being the final saved value, we have no way of knowing to keep the
original move_finished_ids due to onchange only being able to check
against the last saved value, not last selected value).
Additional test + test update done to support preventing this
catastrophe in the future.
Part of Task: 2618962
closesodoo/odoo#74859
X-original-commit: fa468782f4a52334fd055fb5cd11e2c62ddd6f9d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Tiffany Chang <ticodoo@users.noreply.github.com>
Issue: When preparing a work order for a product on which the bill of material had a line with duration set to 00:00, the work order expected_duration for that line was set to 60:00
Steps to reproduce :
1) Enable Work Orders under Manufacturing Settings
2) Create a Bill of Material for a new product "test"
3) On the BoM Form, go to Operation, add a line
4) Set an operation, a work center and for Duration Computation, set it to manually and 00:00 minutes and save
5) Create a manufacturing order for that product, check the Work Orders tab of the Manufacturing order form, the duration is set to 60:00
Why is that a bug:
Since we can set a duration of 00:00 in the Bill of Material, it means the work order can take 00:00 as expected duration, however it was set to 60.0 since 00:00 is evaluated as 0, which is considered `False` in a conditional assignment that was catching the case where the variable was `None`, which it can never be since it is a fields.Float that will be 0 in case of a `None` or `False`
opw-2603928
closesodoo/odoo#74660
X-original-commit: 331b4c3aa69b06316e762f79f17e882f40e1870e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
mrp - when a MO is generated from replenishment report, a log note is added
to chatter with the link of replenishment report, as this report got deleted
when to to qty is 0.0 then link dost not work. Hence added the simple text
for Relenishment report.
purchase_stock - When click on the order once button of replenishment report,
if vendor is not added on product then, added a new wizard with functionality
to directly jump on the edit product.
Added log note to the PO if po lines are generated through the Replenishment
report.
TaskId - 2427738
[IMP] stock: split method to create new or unlink unused OP
As, server action was added to the Replenishment menu, unless
until user clicks on the menu, new order point will not get
generate. Hence splitted the method and added to auto vaccum for
this.
TaskId - 2427738
closesodoo/odoo#66130
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Step to reproduce :
- Create a Manufacturing Order for several pieces of a product with a
work center routing
- Open the Work Order which has been created
- The Manufacturing Order is set to 'to close', instead of 'in progess'
Cause of the issue
The state of the MO was never computed based on WO status.
Solution
The state of a MO is set to 'to close' when a WO is set as 'done'
or 'cancel'
opw-2584446
closesodoo/odoo#74411
X-original-commit: c237c9c3214b58d303a8597df2c836872c5e522c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
Before this commit, it was required to always use the widget to edit the
consumed quantity of a component when multi-location or packages setting
is active. This was not user friendly so this commit relaxes the
requirement to only tracked products and gives users the option to still
edit the consumed move lines directly if desired. We also distinguish
between when using the widget is required or not with the widget button
color. Note that if quantity consumed is greater than amount reserved in
different locations, the difference will default to the move's source
location (this is consistent with what happens when the `qty_producing`
is changed in the MO and the consumed quantities are scaled to match.)
Task: 2518523
Upgrade PR: odoo/upgrade#2655closesodoo/odoo#73939
Related: odoo/enterprise#19732
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previous specification of making MOs unlocked by default was confusing
for users and made it too easy to accidentally change the qty to consume
rather than the consumed amount. This fix makes it so MOs are now locked
by default and will be unlocked/locked (including existing draft /
confirmed / in progress MOs) automatically when setting is changed.
Previous setting (Lock Quantities To Consume) has been repurposed for
this. When setting is active, no lock/unlock button will be visible to
match the updated setting description (i.e. non-done MOs can
never be locked).
Task: 2518523
ENT PR (only fixes test): odoo/enterprise#19732
Upgrade PR: odoo/upgrade#2655
Usecase:
- Create a production order without BoM
- Add a component
-> Traceback
It's due to a compute that try to access the UoM
while it's not set
closesodoo/odoo#74177
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
And convert the `t-esc` in the template to `t-out` while at it.
So this was a bit of a bummer initially, the PopoverWidgetField gets a
pile of JSON as its value (so from the server), and that pile contains
a template name (optionally) and... the template context,
basically. For leadDaysPopOver the issue was some of that context is
supposed to be rendered HTML to straight inject into the template,
marking that as HTML-safe would be a bit of an issue (having the JSON
specify which parts of the value it returns are HTML-safe being a bit
of a conflict of interest).
However turns out the thing is way over-complicated and
over-engineered: `lead_days_description` necessarily has a very
regular structure owing to being injected as a set of table rows, so
the various overrides to `_get_lead_days` just make their own lives
complicated by formatting the values they want to return into table
rows matching the format of an unrelated template.
Instead we can change the signature of `_get_lead_days` so the
"description" is a list of values to inject in the table (list of
pairs, each pair matching the corresponding columns of the table). The
template can then take care of formatting those values into table rows
the usual way, removing the need for any injection of raw content.
This also makes for better / clearer translation strings.
