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>
When creating a backorder for a manufacturing order, date_deadline for
its raw_moves are lost in the process, as the field is set to copy
False. But the split of a manufacturing order is not a usual copy paste.
In this specific case, we need to keep the date_deadline as well, or
resulting moves wouldn't be able to be merged with moves in
pre/post-production pickings from the original manufacturing order.
Task-2797359
X-original-commit: b50db19fa0da58dc0734c8cd494795743eaf0984
Part-of: odoo/odoo#93233
- Add the concept of 'Days to Prepare MO' in mrp, similar to 'Days to
Purchase' but defined at the product level. Both concepts are merged into
Days to Order at the orderpoint level, taking the value of Days to Purchase
for orderpoints with a buy route and Days to Prepare MO for orderpoint with a
manufacturing route.
- Add the concept of 'Visibility Days' on orderpoints. The idea is to
avoid to create through reordering rules multiple small orders for the
same product on a small time frame but rather to order directly a bigger
quantity. When Visibility Days are defined, the quantity of the orders
created by a RR is not the quantity forecasted at Today + Lead times
(quantity that triggered the order according to the RR), but the
quantity forecasted at Today + Lead Times + Visibility days.
The Visibility Days are different for purchase and manufacturing.
Changing the route of the orderpoint will change its value. They
can be defined at the company level and further fine-tuned on the
orderpoint. In case of change of the parameters at the company level,
only orderpoints without a specific value of Visibility Days will
be changed.
- Alignement between Manufacturing and Purchase Security Lead Time
(previously the Manufacturing Security Lead time didn't impact the
procurement date, instead the manufacturing time was made longer).
closesodoo/odoo#86682
Task-id: 2738838
Pr: https://github.com/odoo/odoo/pull/86682
Related: odoo/upgrade#3415
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behavior:
When using 2 steps delivery and selling a kit product, not all
moves had bom_line_id set. So if you go in the transfers you
couldn't always see the "Kit" column in the operations.
Steps to reproduce:
- Activate 2 steps delivery
- Create a Kit with 2 products
- Create a quotation with kit and confirm it
- Go in the delivery
- In WH/Pick you can't see Kit column
- In WH/Out you can see the Kit column
opw-2796974
closesodoo/odoo#89371
X-original-commit: 88c3c3f49393af08e4070c0d2f5cccbec9096c1f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When creating a backorder for a manufacturing order, procure method for
its moves are lost in the process, as the the field is set to copy
False. But the split of a manufacturing order is not a usual copy case.
In this specific case, we need to keep the procure_method of the copied
moves, as it keeps the two/three-steps routes working for the splitted
manufacturing order.
Task-2797359
closesodoo/odoo#88208
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Currently, when changing qty_producing on a MO, consumed number of each
component will always be updated. In this commit, we add a new boolean
field manual_consumption to bom.line. If checked, that line won't be
updated when changing qty_producing.
The same but invisible field manual_consumption is also added to each
line on MO. It will use the value on BOM as defualt value. When user
manually set the consued qty, it will be checked automatically. Also,
when user manually update the SML, the field on SM will also be set to
true.
Task-2687494
closesodoo/odoo#80118
Related: odoo/enterprise#25607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
No longer show the reserved column from by-products production registration on an MO.
Task ID: 2797692
closesodoo/odoo#87225
Pr: https://github.com/odoo/odoo/pull/86768
X-original-commit: 7aa08fe325490bf6ca5efe8b9b7be4bcae843826
Signed-off-by: Tiffany Chang <tic@odoo.com>
Current behavior:
When using a product kit that have a product kit in his BoM some move line where merging when they shouldn't.
Because of this the delivered count wasn't correctly updated in any sale order using this product
Steps to reproduce:
- Create product B to manufacture with a BoM (type Kit) using component A and component B
- Create product A to manufacture with a BoM (type Kit) using product B and component A
- Create a sale order with product A
- Confirm the sale order and validate the delivery
- The delivered count of product A on the sale order stays at 0
opw-2777810
closesodoo/odoo#87000
X-original-commit: 0e6480811e2144a1034f1347a816a0bd052c4516
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
ISSUE 01
When adding a product to a sale delivery, another picking is generated
to return the additional product
To reproduce the issue:
1. Create two consumable products P01 and P02
2. Create and confirm a SO with 1 x P01
3. Add 1 x P02 to the delivery and validate it
4. Go back to the SO
Error: Another picking has been generated, it's a return for P02. This
picking should not exist.
When validating the picking, because of the new line, a sale order line
is created with a quantity equal to 0. During the SOL creation,
`_action_launch_stock_rule` is called and checks if a procurement must
be created and processed. To do so, it checks if the SOL quantity (0 in
our case) is the same than the procurement quantity (1 in our case):
https://github.com/odoo/odoo/blob/6a0cbff92141961655a5f3e33abc23a2c5b1045d/addons/sale_stock/models/sale_order.py#L543-L549
Since the values are not the same, a procurement is created and
processed.
The feature that updates the SO when adding some products to the picking
has been introduced by 1f0835a9d01b46b5cc617756f854c25541b644a7 and is
correctly working in 14.0 because the condition (in
`_action_launch_stock_rule`) is not the same:
https://github.com/odoo/odoo/blob/ec5475ee881c5ca2bcc992592bfa4edf12f492df/addons/sale_stock/models/sale_order.py#L572-L574
In 14.0, we check if the SOL quantity is greater than the procurement
quantity. The condition has changed in 15.0 due to a new feature
(bda3225c6cc27bb2c2933eda3cc68c6f9708daf3).
ISSUE 02
When delivering more than sold, a useless SM is generated.
To reproduce the issue:
1. Create a consumable product P
2. Create and Confirm a SO with 3 x P
3. Deliver 5 x P
Error: A new line appears (Demand: 2, Done: 0)
Because the delivered quantity is more than expected, an extra move is
created. Then, the extra_move is merged into the initial one a condition
is respected:
https://github.com/odoo/odoo/blob/6f2ba1e1b40a458e23c8ed712927c44d75d86614/addons/stock/models/stock_move.py#L1603-L1610
Here is the issue: the field `date_dealine` is not copied anymore (see
[1]). Therefore, the condition will never be respected
[1] fb781dcf57
OPW-2716309
closesodoo/odoo#85649
X-original-commit: fabc32c4733bb404e74dc111d80aa1fe1edd4bfb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Create + confirm a MO
- Add a byproduct with a Produced (qty) > 1
- Change the `qty_producing` to a non-zero qty
Expected result:
Byproduct's "Produced" qty stays unchanged and its "To Produce" is 0
Actual result:
Byproduct's "To Produce" defaults to 1 and its "Produced" qty is
updated to scale to the according to the amount `qty_producing` (i.e.
if `product_qty` = 2 and `qty_producing` = 1, then by-product's
"Produced" = .5
Additionally, a Missing Record error pops up because of missing
stock.move.line
Solution, don't allow byproducts added after MO is confirmed to default
to 0. Additionally allow byproducts to have 0 "To Produce" quantity and
don't sum the cost share of merged byproduct moves since when Produced
> To Produce then an extra move is created and the cost share ends up
being doubled during the merge.
closesodoo/odoo#85130
Task: 2716164
X-original-commit: 51ff14a56b909bdf22c9f1c4540347655578e1f4
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Due to many move values being set only during an onchange, there were
inconsistencies with the values of the products to manufacture and the
MO's components in the following cases:
- when a MO has manually added components/byproducts (i.e. not from a
BoM or a MO with no BoM) = missing values
- a MO is copied = incorrect values copied
- a backorder is made = backorders' moves contained new "-00#" name, but
original "-001" MO did not update all corresponding values to new name
There were also a couple of default values for manually added moves that
were either incorrect or not correctly saving.
Most of these inconsistencies are not visible to the user unless they do
a data export or are playing close attention (e.g. copying an MTO
triggered MO will copy the date_deadline, and this value cannot be
edited by the user.)
Part 6 of Task: 2667151
Part-of: odoo/odoo#80319
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@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
When cancelling a manufacturing order that does not include any
component, the associated moves won't be cancelled.
To reproduce the issue:
1. Create a storable product P
2. Create & Confirm a MO for 1 x P
3. Cancel the MO
4. Consult the form page of P
Error: The forecasted quantity of P is 1 instead of 0
The finished move associated to the MO hasn't been cancelled. Since [1],
we have the possibility to process MOs without any component, so the
cancellation process shouldn't be bypassed anymore.
[1] bf5e1debf9
OPW-2691422
closesodoo/odoo#80407
X-original-commit: 2adff866a598fc8fb872fb8127875fbb7cc7335c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In multi steps configurations, the additional products of a MO could be
missing in the associated picking
To reproduce the issue:
(Use demo data)
1. In Settings, enable "Multi-Step Routes"
2. Update the current warehouse:
- Manufacture: 2 steps
3. Create a MO for product "Table Top"
4. Edit the MO:
- Add 1 x Screw in the components
5. Confirm the MO
6. Open the generated Picking
Error: The operations only contains one line for "Wood Panel". There
should be a second line for the "Screw"
When adding the new component, a new stock move is created but the
latter does not have any `group_id` defined. This is the reason why the
generated picking does not include this stock move.
OPW-2671995
closesodoo/odoo#79894
X-original-commit: 720f29fc6b7626ae734187242870a27065441ac2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.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>
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
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
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>
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
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 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
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>
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
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
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>
A kits bom has a component but qty is 0. When sale this kits, the 0 qty
component won't be delivered, and the delivered qty of the kits will
always be 0.
To fix it, we don't find a stock.move and bypass the quantity check
since the stock.move are not generated when bom line quantities are 0.
Task-2580118
PR #72637closesodoo/odoo#72920
X-original-commit: fad7a15560c1d454be294f1a8d1ce5a57d576900
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Since we can't transfer service product, when compute delivered or
received kit quantities, we should skip the service components.
Task-2566373
PR #72306closesodoo/odoo#72575
X-original-commit: f86c7c0dfa09a2136ed1789a905eae9205de0c03
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
Create 2 product (Finish product , RM product)
Create 1 Kit BOM for Finish product with 1 Component(RM Product) and quantity : 0.0860
Create SO for 10 Finish product and confirm SO
Deliver RM product : Quantity : 0.86 ( as per define ratio in BOM) -> validate
Bug:
Delivery quantity on SO line shows : 9 instead of 10
opw:2540671
closesodoo/odoo#72724
X-original-commit: 89aa85f32e0a87d537f4d9ed9c22955d3269ddd1
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In a Manufacturing Order, the components' quantities are rounded using
the rounding precision of the produced product's UoM. This leads to
incorrect values.
To reproduce the error:
1. In Settings, enable "Units of Measure"
2. In UoM, edit Units:
- Rounding Precision: 1
3. Create two products P_finished and P_compo
- P_compo's Product Type: Consumable
- P_compo's UoM: L
- P_finished's UoM: Units
4. Create a Bill of Materials
- Product: P_finished
- 1 Component:
- Product: P_compo
- Quantity: 0.2
- UoM: L
5. Create a Manufacturing Order:
- Product: P_finished
6. Confirm, Mark as Done
Error: Qty to consumes became 0 and consumed qty is 0. Both values
should be 0.2L, but they have been rounded using the rounding precision
of Units
OPW-2529462
closesodoo/odoo#71293
X-original-commit: aff3a2e06801dfb7a58df5180fb4ab5487b27f02
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
To reproduce:
1. create and confirm a MO with register number checks on operations
2. duplicate the MO
The register number checks won't show up in the new MO
We didn't set copy=False for workorder_id on stock.move, when copy a
confirmed MO, the new moves are linked to old WOs on old MO. New WO
didn't link to any moves.
When create quality checks, we only create "register ..." checks for WOs
with move_id. As a result, new WOs without move_id won't have those
checks.
To fix, set copy=False on workorder_id of stock.move
Task 2484939
closesodoo/odoo#71000
X-original-commit: 6aaf337558e59474efcef937f0175ee531b4b477
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.
This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.
This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.
opw : 2451298
closesodoo/odoo#70975
X-original-commit: e8c1f6b1a3f58b68181bf4d2599bd37efb83b5c7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Some usage of `_bom_find` are performance bottleneck (one request by
product). By example, when the mrp is installed, search products
with fields compute by `_compute_quantities` (e.g. 'Negative forecasted
quantity'). it is due to the override of `_compute_quantities`
in mrp which will make (in the worst case) a `_bom_find` for each
product in the DB.
To avoid this situation the `_bom_find` method become batched
which can handle several products in once. The signature of the method
has changed and uniformize in all module.
Example performance Gain:
------------------------
In a DB with 7000 products (type 'product'), 500 locations, 1800 BoM,
9000 Stock moves, etc. Search in the tree view with filter "Negative
forecasted quantity":
Before: 10879 (nb SQL request) 12.67 +- 0.11 sec (Total RPC Time)
After: 159 (nb SQL request) 1.82 +- 0.03 sec (Total RPC Time)
task-2439019
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to validate.
task-2390516
X-original-commit: d9510aee26578e1b345a7700f7c94032d5745bf4
- make `bom_id` required. No sense to have a operation without BoM
- `company_id` of operation is now related
- Clean the multiple `allowed_operation_ids` into related
fields instead.
task-2373638
In order to have always a picking_type_id on a stock move (and
consistent with his parent model), make it compute store.
Then clean the call of picking_type_id without change the behavior
(/!\ `move.picking_id.picking_type_id != move.picking_type_id` because
of mrp). Fix some test where the location(_dest) was unset in moves.
Also:
- Clean the mess in the create of `stock.picking` about that
and add a onchange to keep location(_dest) consistent with moves.
- The move `description_picking` is set when the `picking_type_id`
change, not only at the create method.
task-2373638
This commit change the _split method to return new move values instead
of create it and confirm it.
This allow multi creation and multi confirmation when every move of the
recordset are split
Task : 2076873
closesodoo/odoo#58594
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
- Refactor `order_finished_lot_ids` compute, to be linked to the `lot_producing_id`
the the related production (less boiler plate). We can't remove it because
it is used in mrp_subcontracting, and keep the Many2Many, for the tag widget.
Remove the second field compute by this method, `finished_lots_exist` (never used).
- Remove unused field `needs_lots` (also it is a duplication
with `has_tracking` info) from `stock.move` (mrp)
- Remove unused field `done_move` from `stock.move.line` (mrp).
- Remove unused methods `_strict_consumption_check` and `_update_raw_move`.
- Remove unused variables.
odoo/upgrade#1594closesodoo/odoo#54996
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- MO/picking/PO/stock.move have now the "same" `priority` fields
(Boolean logic: Normal or Urgent).
These models are now sort by priority first. Note that the priority field of
stock move is a technical one.
- For MO and picking, the set of `priority` field change priority of
the related stock move. The prioriry field on stock move is
used by the scheduler for reservation ('Urgent' before 'Normal')
- The Stock Replenishment Report also take in account the priority
to be consistent with the reservation.
task-2246665
Fabien Pinckaers