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
After the odoo/odoo#52949 , the registering of tracked component,
in case of subcontracting, was broken. Fix and try to mimic
the same flow than before. The produce wizard has been replaced
by a clean MO form to register component and use backorder mechanisme
of MO to manage tracked finished product + tracked component.
task-2278147
closesodoo/odoo#54994
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Adding additional product to a production but consuming 0 on it will
trigger the consumption warning wizard while no difference with the bom
are occurring. This commit do not trigger the consumption issue in that
case.
Task : 2278147
closesodoo/odoo#54561
Related: odoo/enterprise#11885
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit extends the delivery slip so that products added as a kit
component to a stock.picking are grouped together by kit (or non-kit)
when at least 1 kit exists. Kit grouping occurs for products from a kit
without a package assigned. Non-kit section appears only when no
packages are assigned.
Implementation notes:
- Sub-kits (i.e. kits within kits) of kits are purposely not included
- Duplicate product names with different BOMs will be merged into one
since there is no straightforward way to distinguish them within
current db structure
- There are some cases where this doesn't work as expected and may lead
to components being grouped together under the same kit even if they
are from different kits (e.g. kit1 has bolts and so does kit2 => on
slip bolts will only show under kit1 section). Two cases where this
happens is when kits are added before 'Operation Type' is specified
and 'Operation Type = Manufacturing'
This completes subsection 1 of overall Improve delivery slip task.
Task: 2039720
- Create 3 products A, B1, B2
- Create a BOM for A:
Manufacture, 1 unit of B1
- Create another BOM or A:
Kit, 1 unit of B2
- Create a MO for A
- Click on 'Produce'
B2 appears as a 'By-product'. Upon saving, an error occurs because of a
rounding set to zero.
The issues is coming from the generation of the `move_finished_ids`.
Since the product A has a BOM kit, the latter is exploded and added as
'By-product'.
We should not try to find phantom BOM for this specific use case. A
solution is to not explote the move produced.
opw-2251423
closesodoo/odoo#53526
X-original-commit: 226ccc2f64d00a19e0ae8851c45051106aa49adc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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
This commit updates 4 features related to a MO being locked/unlocked.
1. Manufacturing orders are by default unlocked. A new configuration
setting has been added so users can set the default to be locked.
This setting only applies to new manufacturing orders after the setting
has been changed.
2. A MO now shows the same button options regardless if it is
locked/unlocked ('scrap', 'cancel', 'unreserve')
3. Workers can always change "Consumed Quantities"/"Produced" when
clicking on a component/finished product line unless state=Done and MO
is_locked. This includes adding new components/finished products.
4. Workers can now change "To Consume" quantity when clicking on a
component line, unlocked, and not in states 'Done' or 'Cancel'.
This is part of specification 6-Lock/Unlock of overall Editing in MO
form and backorders task.
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
Cause
When kit BOM line quantity is equal to zero in a sale order, it raise error
because trying to divide bom_line_data['qty'] / bom_line_data['original_qty']
when computing kit quantities.
Solution
As BoMs allow components with 0 qty, a.k.a. optionnal components,
we simply skip those to avoid a division by zero.
Cherry-pick of #38890
opw-2262540
closesodoo/odoo#52362
X-original-commit: ab780a9d65e43f58a5745a5b92a25fb234827eb7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
With a database that contains a lot of production with kits or
BoM with a lot of bom.line. The database could become slow.
Index on stock.move <-> mrp.production could improve it.
closesodoo/odoo#51870
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Followup of
https://github.com/odoo/odoo/commit/58df6c86e06304b2c5f020e0fb93988e9e388fe0.
By default, the create, when not specified as `api.model`, supports
creation in batch (thus the batching opportunity isn't lost here).
BUT, if a create override isn't specified as `api.model` or
`api.model_create_multi`, it won't be accessible in rpc calls (because
the ORM thinks a record in self is needed).
It doesn't look like somebody can create stock move lines from the web
client itself, but it doesn't cost anything to follow the global api
(and it's clearer to clearly specify the create as create_multi).
closesodoo/odoo#48964
X-original-commit: a4fd8f8062046bcea97d9f7cfe300e19020cdecd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In case of MTO+Manufacture, a sale order have a count of
manufacturing order created from it :
1. create SO with MFG+MTO product with quantity of 5.
2. confirm it. MO will be created for 5 Nos.
3. increase it to 7 . another MO created for 2 Nos.
4. there are 2 MO created based on 1 SO.
It was due that new stock move was merge, and the
'created_production_id' info was lost during the merge (keep only
the original one). To fix, avoid merging stock move with distinct
'created_production_id' (done by override
'_prepare_merge_moves_distinct_fields' and
'_prepare_merge_move_sort_method' methods ).
task-2199568
closesodoo/odoo#45800
X-original-commit: 1fb32cfd17122b625d211a7d22ec319fba35e87f
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Let's say we have a chain of move
wh1 - intercomp transit -> intercomp transit - wh2
The second move will be reserved according to what the first move
brought since they are chained. This behavior resulted in rev[0] which
tries to work around the ir.rule limiting the access of stock.move and
stock.move.line records in multi-company environment.
This patch wasn't perfect since, if the first move brought a lot, the
second move will reserve this lot and it will result in another access
error since the lot will still have the company of the first move.
We fix this by implementing the following logic: receiving from another
company should behave the same as receiving from the supplier, no
reservation is applied. We fix this by marking the inter company transit
as `_should_bypass_reservation` and we break the move chain if the
pull/push rule create an intercompany chain.
[0] 6ff34073153767d449804669f31e26c04de0a670
closesodoo/odoo#45601
Task: 2160847
X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`action_explode` unlinks the kit move and create the stock moves for the components.
As the `create_multi` is not used, it results in lots of delays. Use the `create_multi`.
closesodoo/odoo#45326
X-original-commit: 4818ee61b4f23ab7b388acd2bdd452c27e25fc0d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`action_explode` is called when confirming the moves of a picking. It
calls unlink() when the move contains a kit. As this method is not
multi, when confirming 50 kit moves, unlink is called 50 times resulting in
a lot of cache invalidation, prefetching and so on.
We make `action_explode` multi in order to call one time `unlink` per
kit levels.
X-original-commit: 096c682e748f7e581e48f0070ec8a3284d8a2fe7
As `_do_unreserve` was rewrited, the `_decrease_reserved_quanity` method
isn't useful since its purpose was to avoid to unlink all stock moves
and it is what `_do_unreserve` cares about.
See 2e41338f42e2ef9f2ac2b3e73b274c4af242b28a
closesodoo/odoo#42582
Related: odoo/enterprise#7488
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit let the manufacturing user to add new components or update
the quantity to consume of existing ones in a manufacturing order even if
the state confirmed. The BoM should be in flexible consumption.
In case of reserved quantity, updating the quantity on a raw move will
unreserve it entirely. We apply the same logic than the stock.picking one
Task : 2121714
This commit adds the possibility to choose in which operation a new product
will be consumed. New product can be added to the production once the
manufacturing order is in state draft.
Before this commit, the new product was consumed
automatically in the last workorder.
Task: 2121714
The next commits will allow changing the initial demand of
confirmed moves as well as adding move once the production
order is confirmed. In order to not duplicate again the unit
factor computation in multiple write and create, make the
field a stored computed.
Unit_factor is stored and only depends on product_uom_qty because
updating only quantity_done (after a partial production for
instance) should leave unit_factor unchanged for the futur
partial production.
Task: 2121714
When a manufacturing order was created through a stock rule, the `delay_alert`
feature was broken. Indeed, we should store on the order the `delay_alert` value
similar to what we do with the `propagate_date`, `propagate_date_minimum_delta`
and `propagate_cancel` fields.
We thus add the missing field and add the values in the multiple prepare methods.
We also the missing values for `propagate_date_minimum_delta` and `propagate_date`
in `_get_move_raw_values`.
task-2154781
closesodoo/odoo#42032
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this -
If we have follwing configuration -
Manufacturing -> Propagate Cancel -> True
Buy -> Propagate Cancel -> True
* BOM of a Car -
1) Component 1 -> Iron (MTO & Buy)
Now create a SO of product Car and confirm it.
It will create a MO (Car) and then PO (Iron).
Now if PO is cancelled, it will cancel its
move_dest_ids and on change of it MO will be
cancelled but delivery move will remain ongoing.
When action cancel is called on a move raw, it will
check if the production order is also cancelled.
If the MO is cancel, in this case cancel also its
move finished.
Task-2117832
closesodoo/odoo#42209
X-original-commit: 9522e51a3b290c91f23658a4fb781003ff1fd8d2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, The addition of new stock move lines in a
finished production via the unlock button did not impact the
traceability report. This was due to the fact that the new sml
has not been linked to the finished_lot_id.
Since `check_company` is intended for relational fields.
closesodoo/odoo#38939
X-original-commit: bf2f3f6ce1430c2603fe7fe199a28296b2d7416f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The condition needs to be fined-tuned, so revert for now.
This reverts commit 40487aca5c.
closesodoo/odoo#36470
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
It's due to MRP refactoring that confirm raw moves before finished
moves. It implies that in _assign picking, SFP with final product
will search a picking but the stock.move do not have a created_production_id
and it will be merged inside the intermediate SFP (it works before
because it was the intermediate SFP that was merged in the finished SFP).
_key_assign_picking is also added if multiple moves are confirmed w/
and w/h created_production_id, we won't merge them in the same picking.
closesodoo/odoo#36335
Signed-off-by: Christophe Simonis <chs@odoo.com>
usecase to reproduce:
- Set the warehouse with manufacturing 3 steps
- Create a BoM with a Components that use a Sub BoM
- Set Both product MTO + Manufacture
- Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO. So the solution would be to
add a condition to _assign_picking and don't merge moves if they come
from different MO, at this point the field created_production_id would
fit. However this solution is not robust if a customer creates a
new rule that add a 4th steps to the production process.
opw-2055688
closesodoo/odoo#35915
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Andrea Grazioso (agr-odoo) <agr@odoo.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
Make sure unbuild have proper sequence for each companies.
The produce wizard and workorders company is the one of the production.
The BoM line company_id is the one of its bom_id.
Added some tests.
task-1985992
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Usecase:
- Set table top as manufacture and MTO
- Create a MO for table(MTO)
- Confirm the MO
- Cancel the MO
The activity with the exception is not logged on the child MO
It happens because the _get_upstream_documents_and_responsible for move
linked to a MO is based on the created_production_id field. However it
is only set on the move that created the move_finished_ids for the new
MO. In the case of a MO that directly create a child MO the chain is:
MO -> move_raw_ids -> move_finished_ids -> MO2
The log_activity on cancel is based on the move_raw_ids and their
move_orig_ids in the previous case it's the move_finished_ids for MO2.
However the move_finished_ids for MO2 is directly link to the child MO
and the created_production_id is set on the move_raw_ids for MO parent.
Compare to PO, we could directly base the parent document on production_id
since the move_finished_ids are directly created.
Manufacturing Order can now be cancelled even if some move lines or Work
Orders are done (in this case, a wizard ask confirmation to the user).
Task #1969034
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
In a move chain, if the scheduled date of a move N is updated, we would
like to create an alert on the move N+1.
This commit adds a boolean field on stock.rule that, if set to True, will
create a next activity on the stock.picking of the move that are created
from this rule, in case the previous move has its scheduled date changed.
The message will depends on the propagation of the schedule date between
the two moves:
- If the date is propagated, the message informs the picking user that
the transfer is delayed.
- If the date is not propagated and the new date of move N is after the
schedule date of move N+1, the message says that the scheduled date
will be outdated.
Task: 2001643
Since previous commit moved decimal_precision module's feature into base,
use the new syntax for fields declaration
Remove the imports to the removed module
Remove the module from dependency in manifest
sed -i "s|digits=dp.get_precision('\([A-Z a-z]*\)')|digits='\1'|" **.py
sed -i "/from odoo.tools import decimal_precision as dp/d" **py
subproduct and byproduct are both used in code.
However the UI always shows by-product only.
Rename sub.product, sub_product,... in byproduct
in order to use the same term everywhere.
closesodoo/odoo#32540
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Rémy Voet (ryv)