This reverts commit 656d8ace87.
The rational was: "If people don't have inventory, they will need a
backorder anyway and it's logical to not display the popup even
if the picking type has 'ask' for create backorder".
Also for the barcode application in OE we only show the reserved lines and
you could have the message if the picking was not fully reserve. Even if
you completed all the lines. So we could have a single flow for backend
and frontend.
But it's difficult for poeple to understand that the backorder is
base on the reservation and not on the initial demand. So we do a
step back. On top of it, people usualy won't mix flow. So they
could totaly use the "always create a BO" option on picking type
when they use the barcode and "ask" when they use the backend.
closesodoo/odoo#136725
X-original-commit: ed291c4d47783c5912ffb40db7893c321ccdb1e2
Related: odoo/enterprise#47959
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previous fixodoo/odoo#131279 missed marking component lines added in
from the consumption warning wizard as "additional". This made it so the
added line was also added into the backorder when it should NOT have
been (since the backorder should only be based on the original MO's
values).
Followup of task: 3456604
closesodoo/odoo#136728
X-original-commit: 7a45b691781e2862e87da7914a8b3b9a6487b7e9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
When adding a new raw SM to a confirmed and locked MO, it should still
be possible for the user to define the to-consume quantity (else, he
would have to unlock the MO and only then to edit the new line)
OPW-3253204
closesodoo/odoo#136009
X-original-commit: b78c468317079ac415d7b1fdbd4d4d081ff3976b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Previous fixodoo/odoo#121602 did not correctly handle the case when not
all of the qty to manufacture is manufactured (the qtys to change to
were miscalculated in this case).
Additionally, it missed fixing a few more use cases when setting the
qtys to match the wizard's lines/qtys:
- if the UoM of a MO's component line is changed => the correct qty was
not correctly converted into the move.product_uom's qty (now it is)
- if a component's move is deleted before the MO is confirmed => the
move (i.e. the missing component) was not correctly added back into
the MO (now it is)
- if there are 2 MO component moves with the same product => both were
set to the same "correct qty" value (now we only set the first move to
that qty, others are set to 0 since we have no way of knowing how to
distribute the qtys otherwise)
Also, since an UserError needed to be added in case of a missing comp
move for a tracked product, existing error logic has been updated to
list all applicable products and the message has been improved to be
more helpful.
Note that the fix for saas-16.4 and earlier is slightly different from
this fix due to the change in how stock move original demand qtys no
longer change like they used to (see: odoo/odoo#130342) and because a
backorder bug was also exposed by this change.
closesodoo/odoo#135796
Task: 3456604
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
This commit replaces the opening of the stock moves detailed operation
wizard by the one2Many record preview. This means creating a move in a
picking is still done via a new line but the edition is done via the
`fa-list` button that open the record in the web client. The goal is to
reduce the RPCs call as much as possible. The stock move lines data are
stored in the stock move record until the picking save.
Additionally, this commit change a bit the immediate transfers flows.
The stock move show only initial demand (`product_uom_qty`) but the
column wording is still "Done". In the detailed operation view, the
stock move line `qty_done` is displayed as "Reserved".
At picking validation, the user is expected to enter the same quantity
in `product_uom_qty` and `quantity_done`. If `product_uom_qty` is equals
to 0, the done quantity is used as actual transfer quantity. If
`product_uom_qty` is different than 0 but small than the done quantity,
an error is raised.
Task: 3256447
Part-of: odoo/odoo#124409
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Add a tracked component
- Add another component (no tracked)
- Create a MO to produce 1 unit of the product "P1":
- Confirm
- Unlock the MO
- Set the "to consume" quantity of the tracked component to 0.
- Try to validate the MO
Problem:
A user error is triggered: “You need to supply Lot/Serial Number for
products:”
Solution:
If the quantity to consume is 0, ignore the serial number verification
for this move.
opw-3471256
closesodoo/odoo#135657
X-original-commit: 5e591cf36cdc6dcbdb8a5ee3753247578a771e9f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
If a subassembly was used as component in a finished good and both the
subassembly and finished good were unbuilt, the subassembly could not be
produced again with the same serial (specific use case: medical hardware
refurbishment, medical device is produced/packaged (subassembly), put as
a component into a procedure pack (finished good), both are returned and
unbuilt so the medical device can be refurbished and produced/packaged
again into a subassembly with the same serial).
The _is_finished_sn_already_produced function duplicates domain was
wrongly picking up stock move lines related to the unbuild of the
finished good, making the function wrongly returning True. This fixes
the search domain and adds a test to prevent regression.
closesodoo/odoo#135716
X-original-commit: 4f07b260807053586ac6c01cf92ac3d5e37b1041
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The 'sale_ebay' module adds the `product_variant_ids` one2many field on
the `product.template` form view. The `product_variant_ids` view
contains `virtual_available` (depending on `uom_id`). When the user
changes the `uom_id` of the `product.template`, onchange is triggered,
it takes a snapshot of the previous data, and it will computes the
previous value of `virtual_available`. But the associated compute
method will fail with a traceback:
File "/data/build/odoo/addons/stock/models/product.py", line 199, in _compute_quantities_dict
res[product_id]['qty_available'] = float_round(qty_available, precision_rounding=rounding)
File "/data/build/odoo/odoo/tools/float_utils.py", line 54, in float_round
rounding_factor = _float_check_precision(precision_digits=precision_digits,
File "/data/build/odoo/odoo/tools/float_utils.py", line 29, in _float_check_precision
assert precision_rounding is None or precision_rounding > 0,\
AssertionError: precision_rounding must be positive, got 0.0
The `precision_rounding` is `0.0` because the `uom_id` of the product is
empty. It is is empty because we force the `uom_id` of the
`product.template` to be `False` in `initial_values` (before the
snapshot), and then the `uom_id` takes the value of its
`product.template` (`False`). But actually, the cache of the product
should be full with its previous values before doing the snapshot.
This was not the case because we only copy data from store fields
(see `fnames`). Then compute fields was computed after setting field
change to `False`.
opw-3334822
opw-3419392
X-original-commit: 5021e77ba52fac465a5d842ac04c0a3a22aea2dd
Part-of: odoo/odoo#135635
Co-authored-by: William Henrotin (whe) <whe@odoo.com>
Fix the issue when update the bom on a draft MO, the product_qty and
product_uom_id will be reseted to 1.0 unit.
The original product_qty and product_uom_id hould be kept when update
bom.
X-original-commit: f1a397ede16c56db3410fd9c5fe387dc98c46422
Part-of: odoo/odoo#135691
Steps to reproduce:
- Create and confirm an MO with extra components in stock
- Update the quantity to produce
Bug:
the reserved qty is not updated (it actually is but to the previous
value if you update MO quantity multiple times)
since this commit[1] moves are now assigned during the write
before the new product_uom_qty is written on them
opw-3489226
[1]:https://github.com/odoo/odoo/pull/93712closesodoo/odoo#135548
X-original-commit: cc23ebefb4a15d163ec508cd535bf757cf626fa5
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to Reproduce the Bug:
- Create a storable product "P1" with 2 Bills of Materials:
- BoM 1:
- Component: C1
- BoM 2:
- Component: C2
- Create a MO:
- Select BoM 1.
- Save.
- Select BoM 2 without saving. Result: The component C1 is deleted
and replaced by the component of BoM 2.
- Select BoM 1.
Problem:
The component of BoM 2 is not cleared. Because we check if the new BoM
is different from the original one, but since we didn't save the change
when selecting BoM 2, the `move_raw_ids` are not cleared.
Solution:
Clear the `move_raw_ids` if any move with `bom_line` is not linked to
the current BoM.
OPW-3473387
closesodoo/odoo#135044
X-original-commit: f874fd46fcf8c2668c6d2ab42224196868ec0f0a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- In Manufacturing, create a the following BoM
- Product: P1
- Components:
- 2 x P2
- 2 x P2
- Set the quantity in stock for P2 to 2
- Open the Overview from the BoM
Issue:
The 'Ready to Produce' column will indicate 1, as it checks line by line
how much product there is in stock compared to what is required for this
line.
To avoid this, we just need to sum the quantities required by products.
closesodoo/odoo#134890
X-original-commit: b8fda0bdb2238cba21a4541f4292da04003704cf
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create a serial tracked product
- Update quantity add random SN
- Edit "ir.sequence" for serial numbers
(search sequence with dev mode enabled)
- Add a prefix for exemple "xx%(doy)sxx"
- Manufacture the product and generate new serial
Bug:
if a serial already exist next number in the sequence will be generated
instead of using the sequence
Fix:
apply same logic than for lots i.e. first generate from sequence then
take next number if it already exists
opw-3291532
closesodoo/odoo#134879
X-original-commit: df96d9ca10c576981f6af79e330b5b46cdeea377
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
To reproduce the issue:
1. Create two products A, B
2. Create two BoMs:
- Product: A
- Component: B
- Product: B
- Component: A
3. On one BoM, open the report "Structure & Cost"
Error: an Odoo Server Error is raised: "[...] maximum recursion
depth exceeded while calling a Python object"
The error occurs because of the cycle between both BoMs. There is
already a check for that in `:MrpBom.explode`:
https://github.com/odoo/odoo/blob/2a73890d304476833d76bac9a36ef92f12f267a3/addons/mrp/models/mrp_bom.py#L329
But it's too late in the flow. We should not be able to configure
such BoMs.
OPW-3200969
closesodoo/odoo#132806
X-original-commit: ba66f6b2ad3ea226779af23cdb4ddf223dd7fe85
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
Goal:
* Simplified modifiers to only have one way to define modifiers;
* Remove states attributes on python field;
* Use python expression in view `required`, `readonly`, `invisible`;
* More accurate validation of xml views.
This commit change the syntax to python expression. The next commit
will update/convert all xml views.
Before this commit:
* the `required`, `readonly` and `invisible` attributes can only have
values of `True`, `False`, 1, 0 or a python expression to use the
context;
* the `attrs` attribute define a dict. The key of this dict was
`required`, `readonly` and `invisible` and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluate by the javascript with view fields
and other contextual values as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
* the `states` attribute in the view was a comma separated list of the
state. This list was combined with the `invisible` attribute;
* the `invisible` attribute on python field is used as default value;
* the `states` attribute on python field was dictionnary with state as
key and list of tuple. This structure was combined with `readonly` view
attribute.
* After combining, the resulting domains of the different attributes
`required`, `readonly` and `invisible` are evaluated with the values of
the fields. The `invisible` attributes is splitted into two use:
`invisible` and `column_invisible`.
After this commit:
* The attributes `required`, `readonly`, `invisible` and
`column_invisible` define python expression. This python expressions
are evaluate by the javascript with view fields and other contextual
values as: context, uid, parent, active_id, active_ids, active_model,
allowed_company_ids, current_company_id.
The domains can contains contextual value and will be evaluate by the
javascript.
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
<field name="field_b" states="draft"/>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
<field name="field_b" invisible="state != 'draft'"/>
```
Some inherited views will be modified differently in order to maintain
the previous behavior:
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
<field name="field_a" position="attributes">
<attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
</field>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a')" invisible="field_b">
```
```xml
<field name="field_a" position="attributes">
<attribute name="readonly" add="(not field_c)" separator=" or "/>
<attribute name="invisible">field_d != 3<attribute>
</field>
```
Validation:
A stricter control is made on the level of the attributes (modifiers)
and the fields necessary for these. The use of the previous attributes
'attr' and 'states' triggers an error (these no longer exist after the
application of the migration script)
task-2495504
Part-of: odoo/odoo#104741
Steps to reproduce the bug:
- Create a storable product "P1"
- Add 2 variants:
- Color: Red and Blue
- Size: XS and M
- Create a Bill of Materials (BoM):
- Add any components
- Create operation "OP1":
- Apply only to: Red XS
- Create operation "OP2":
- Blocked by "OP1"
- Apply to all variants
- Create a MO with the variant "P1 (Blue and M)"
- Try to confirm the MO
Problem:
a traceback is triggered, the issue has been fixed in: https://github.com/odoo/odoo/commit/0f21fde26fa4387d93722092ebf21d294fcfcd4f
Solution:
Link only if an operation is blocked by another operation with the same attribute values.
OPW-3329263
closesodoo/odoo#131727
X-original-commit: 2fa8e2f64292483c0aa27141fe59eb4a6ff8effb
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
-Create a product in kg as storable.
-Add it into the BOM of another as grams.
-Create an MO with the BOM with more than 1 quantity to be produced.
-Set the quantity to be produced to 1, validate and create backorder.
Bug:
Error message: "It is not possible to reserve more products of test kg
than you have in stock."
Fix:
correct conversion of units during backorder reservation of component
closesodoo/odoo#129152
X-original-commit: 8f26839998f21e521ecaeba38a2bcc6c72894f41
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce
==================
- Create and confirm MO with BOM1
- Consume the theoretical qty of your MO
- Update the BOM1
- Click on the `Produce All` button
- You will receive a message that the consumed quantity does not match the quantity
of the BOM1 anymore
- When clicking on the set quantities and validate button, the consume
quantities are not the ones that are previewed in the flexible consumption message,
but the initial MO quantities.
So in this commit, we updated the `To Consume` quantities as per the flexible
consumption wizard.
task - 3323154
closesodoo/odoo#128488
X-original-commit: fe95a33770c8b701b007310e2b9b5f7b0596f5a9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Create a subcontracted product with components tracked by lots
- make a PO for 35 the product and send components from multiple lots
- login as subcontractor on the portal
- record uncomplete production and change the default consumed lots
Bug:
split production ignores the done quantities on the initial move
on the Backorders components are considered to be consumed in the
default order
Fix:
Consume components on the initial move as indicated by the user
reserve the remaining components for the Backorders as usual
opw-3186773
closesodoo/odoo#127467
X-original-commit: c39256ba6df257ee79fb66eab61617f5fec166b9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce the bug:
- Enable the "by-product" option in the mrp settings.
- Create a product A with the following Bill of Materials:
- Component: 1 unit of Product B.
- By-product: 2 units of Product C.
- Create a Manufacturing Order to produce one unit of Product A.
- Confirm the MO.
- Set the quantity of Product A to 1.
- Set the quantity of the by-product "C" to 1 instead of 2.
- Attempt to validate the MO.
Problem:
When validating the MO, we check if the sum of the cost share in the
“move_byproduct” does not exceed 100. However, we do not exclude the
cancelled move, leading to incorrect calculations.
opw-3375388
closesodoo/odoo#127178
X-original-commit: 7fb1c9ff07f5ec05fc313283a497137327d9ce3a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, if a move is followed by a second move, if the destination
location of the first move is changed, and done, the second move will be assigned
and reserving from the new location.
This commit, compares the location destination of the move in `_action_done` with
the move_dest_id source location and breaks the link between them if they don't match,
the first move would trigger push rules if any exist and the destination move is set to MTS
to be able to reserve qty from the its source location.
Other minor improvements:
-Recomputes the state of the move when creating a backorder to correct
the backorder picking state.
-Recompute the state of move_dest_ids linked to PO when cancelling the PO
to show that it is converted to MTS.
closesodoo/odoo#123759
Task: 3321842
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This is a missing test for #126066 .
closesodoo/odoo#126667
Task: 3370869
X-original-commit: 1b4a0d871662670ec2a360379913d1e30feec40c
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Pawel Fertyk (pafe) <pafe@odoo.com>
The "Update BoM" button action was moved from `mrp_plm` to `mrp` so it
can be displayed if the BoM was updated now. This action can be called
for confirmed MO now.
Each time a change is done on a BoM, all the draft and confirmed MOs
using this BoM will be notified the BoM changed, thanks to a new boolean
field, `bom_has_been_updated`.
An exception however: if the MO is confirmed and the BoM's product was
changed, the MO shouldn't have the "Update BoM" button displayed.
Otherwise, it would change the finished product of a confirmed MO.
Also, it's important to notice than due to a limitation, only changes
done at the BoM level will mark it as modified. That means that
modifying subrecords in their own views (for example, adding steps in a
BoM's operation) will not mark the BoM as updated !
See odoo/enterprise#35969
task-3089368
Part-of: odoo/odoo#110227
In a Manufacturing Order, if the user manufactures a product without any
BoM, they can generate a new BoM who will take the information from the
MO. So, the new BoM will have a BoM line for each MO's component, an
operation for each MO's work order, and the By-Product lines will be
copied too.
task-3089368
Part-of: odoo/odoo#110227
If applied, this commit will solve the issue of keyError when we confirm the
manufacturing order and work order (s) are deleted.
Steps to produce:
- Configure BOM with 'Operations'.
- Set operations in the 'Consumed in Operation' field which is in 'Components'.
- Create MO using that BOM.
- Delete the work order(s) from MO.
- Click on the 'Confirm' button.
Fix this issue when the work order is not available for that operation,
setting False in stock.move record(s).
sentry - 4171798106
closesodoo/odoo#123033
X-original-commit: 36e02b91e88c5e014d132643b6ffb24a71342d6c
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock
Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.
After:
The qyt_available for P1 is 5.
closesodoo/odoo#122939
X-original-commit: b32554322d4c26665bdcb29fd58bb95f12faa20e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
When creating a scrap order on a product which has at least one kit BoM, an option is added to create a scrap order for this kit.
The user can select from the kit BoMs of this product and the scrap order will add stock moves for all the components of the selected kit instead of for the product itself.
Task: 2479234 (nr 9)
Community PR: https://github.com/odoo/odoo/pull/114315
Enterprise PR: https://github.com/odoo/enterprise/pull/37764
Part-of: odoo/odoo#114315
Allows to close an MO even when all consumed components are 0.
To avoid cancelling the MO immediately when it is confirmed without any
raw moves, a change was also implemented in stock_move to skip the
check to remove the linked MO in case `skip_mo_check` is set in the
context.
Task: 2479234 (nr 7)
Community PR: https://github.com/odoo/odoo/pull/114315
Enterprise PR: https://github.com/odoo/enterprise/pull/37764
Part-of: odoo/odoo#114315
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
Currently, when a specific capacity is defined for a product in a
workcenter, if a setup / cleanup time is given, it will be added to the
existing setup / cleanup time of the workcenter.
What we want instead is to be able to fully define what the
setup/cleanup time is for this specific product. So the given times in
the specific capacity override the times defined in the workcenter for
that specific product.
To help with that, we set the workcenter's setup/cleanup time as a
default for their related specific capacities, since if not changed,
they will follow the workcenter times.
Updated the tests so their specified capacities match the new behaviour.
closesodoo/odoo#119212
Related: odoo/upgrade#4576
Signed-off-by: Tiffany Chang <tic@odoo.com>
Related enterprise PR: odoo/enterprise#39669
Steps to reproduce:
Install mrp_workorder
Create Product P1, Workcenter W1
Edit W1 > Specific capacities > Add line: Product = P1, Start time = 5, End time = 5
Create BoM > Product: P1, Operations tab > Add line: Workcenter = WC1, Default duration = 60:00 min > Save
Click on overview stat button
Issue:
The created operation has expected time of 60:00, instead of 70:00. The workcenter start and stop times are considered in this calculation, so the workcenter capacities should be considered too.
Solution:
Use `_get_expected_duration` to compute the expected duration.
opw-3229485
closesodoo/odoo#121060
X-original-commit: 7b5a30fb3e51434154050052ec39ed299c6094d3
Related: odoo/enterprise#40905
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
Step 1: Create new MO
Step 2: In page by-products click three dots to show column cost_share
in tree by-products
Step 3: Create new Byproduct and input cost share >100% or <0% or input
two byproducts
where their cost share adds up to more than 100%
Expected result:
Validation error: total byproduct cost_share cannot exceed 100
or Validation error: cost_share values must be positive
Actual result:
Values saves without issue
Issue is due to `move_byproduct_ids` being removed in the mrp_production
overrides of
`write()` or `create()` and having the `_compute_move_byproduct_ids`
populate its values.
This removal is causing the constrains to not be enforced, therefore we
set the constrains
field to `move_finished_ids` since changing of this value will ensure
that the values are
correctly checked.
Note: There will be a decrease in performance since this means the
constrains will be
called whenever the MO's product to produce is changed, but hopefully it
will be
minimal since there is no simple fix for this issue.
closesodoo/odoo#120797
X-original-commit: 9d6ff93d0f5b39e939f632486a97093b59d335ef
Signed-off-by: Tiffany Chang <tic@odoo.com>
The finished move of a production order should be deleted if we change
the product to avoid having draft stock move detached from any business
documents
closesodoo/odoo#118957
Task: 3172098
X-original-commit: 4478560d7769a8a795a94aead875e02d1394dd71
Signed-off-by: Adrien Widart <awt@odoo.com>
To reproduce:
1. Manually create lot "0000001" for a lot product
2. Create a MO for this product and click generate-serial button.
Validation error raised since we are trying to generate lot/sn "0000001"
again.
When useing action_generate_serial, ir.sequence always try create a
lot/sn in form "00000dd". If user already created the same one, the
generation will fail.
We already tried to avoid this issue for sn in _get_next_serial() by
finding the latest sn and create new one base on it.
To fix, we also allow _get_next_serial to be applied to lot.
Part of Tast-3187003
closesodoo/odoo#118481
X-original-commit: dc69748ea2698077782d839cf7da48e987f17ffc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Steps to reproduce the bug:
- Go to the warehouse settings:
- enable “3 steps for manufacturing”
- Create a storable product “P1” with 2 BoM
- Create an orderpoint:
- Preferred route: Manufacturing
- Product: “P1”
- BoM: select the second BoM
- To order: 1
- Click on the “Order once” button
Problem:
The manufacturing order is created with the first BoM instead of the
second.
As we are in 3 steps, the “run_pull” function is triggered first, with
values prepared from the orderpoint so the bom is well set:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_orderpoint.py#L515-L523
Then the “run_manufacture” function is triggered but with vals prepared
from the move, not from the orderpoint, so we lose the BoM information
that the user has selected:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move.py#L1334-L1340
opw-3217945
closesodoo/odoo#117732
X-original-commit: 2371cd29e1c0cfa54b682b2100b9db7f5633a7b4
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Add the group 'mrp.group_mrp_routings' on the main user to make field
'workorder_ids' visible in the form view of 'mrp.production'. Many
tests use that view, and require the subviews of that field to be
present in order to create records.
closesodoo/odoo#116779
Related: odoo/enterprise#38858
Related: odoo/documentation#3968
Signed-off-by: Raphael Collet <rco@odoo.com>
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a second warehouse WH02
- Let WH01 be the existing one
3. Create two storable products P_compo, P_finished
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operation Type: "WH02: Manufacturing"
5. Create a MO:
- Product: P_finished
Error: Once the product is set, nothing defines the BoM (and
therefore the components, picking type, and so on)
When opening the MO form, the picking type is directly defined with
"WH01: Manufacturing". Therefore, when looking for a BoM, we use
that picking type as criteria -> we will not find the BoM of step 4
Notes about the fix:
- Small behaviour change: once the picking type is set, it does not
change automaticaly (whatever the BoM is)
OPW-3122384
closesodoo/odoo#116515
X-original-commit: 93381af48e20a10c3fded88f010f89cd03cc5131
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
No need a common file for 3 tests. On top of it contains
global variable and a lot of indirection, making it impossible
to read.
Also before the quant reservation commit, a savepoint was call
during the action_assign and trigger a flush and recompute all.
Since it has been remove, it's computed during the first read on
it, that's during the mark as done and since the MO state is not
draft it will keep the default value (False). Call it after create
to trigger the computation at the right time.
+ a bit of linting
closesodoo/odoo#115328
Related: odoo/enterprise#38207
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
Fix the isuue that manual consumption is not correctly calculated when
backorder/split/merge.
closesodoo/odoo#115429
X-original-commit: d72ddd80d8a6aaa808c07db685972a1c05e8d6a4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
when plan workorder, cancelled/done workorders are taken in to account
when they block current workorder. In this fix, we ignore then when plan
workorder.
Task-3126569
closesodoo/odoo#114940
X-original-commit: 1b629659cb651c62fdd2c880ae591f9a9bb2e1eb
Related: odoo/enterprise#38020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently, if the user change qty_done on any raw moves without
changing qty_producing on the MO, it's not possible to validate the
order. In this commit, we make it possible to validate the order as an
immediate production.
When qty_producing is 0 and validate the MO:
1. manual consumption moves: current consumed qty will be kept when
process the MO.
2. non-manual consumption moves: For tracked components, if
use_auto_consume_compoents_lots checked, and there is enough products
reserved, the qty_done will be filled, otherwise, an error will be
raise to ask user to fill in lot/sn. For non-tracked components,
qty_done will be filled.
Task-3116125
Part-of: odoo/odoo#113538
Previously we set a component on MO to be manual consumption by comparing
the To Consume and Consumed, if they are not the same, we consider it a
manual consumption. Now if any input activity in the Consumed cell, we
will consider it a manual consumption.
Note that in the code, we make the css class change happended in the
list renderer instead of the field widget. We do that because we want to
change the background color of the whole cell not just the text of the
field.
Task-3116125
Part-of: odoo/odoo#113538
This commit only adds the missing test from the original PR
since the feature was added back in without the test
opw-3032052
closesodoo/odoo#113562
X-original-commit: 542516b6b07c44e08b21271fbc9129c446e12c1b
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Arnold Moyaux