When a product has been unbuilt and also (mistakenly) scrapped, it's
impossible to reuse the serial number in production again, even if the
product is unscrapped.
This fixes the sanity check in a similar way to the _check_sn_uniqueness
function, not just checking for removed stock move lines, but also unremoved
stock move lines. A test case is also added to check this scenario.
This is a similar fix to a previous commit we did
(4f07b260807053586ac6c01cf92ac3d5e37b1041) where we bumped into a
problem with the duplicate serial sanity check.
closesodoo/odoo#142574
X-original-commit: 1761b95d9fda5d5355f35effd1f345a25ded1197
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product with two attribute “P1”:
- Color: Red and Blue
- Create a BoM:
- Product template: P1
- BoM lines:
- C1: 1 unit -> apply on variant P1 red
- C2: 1 unit -> apply on variant P1 blue
- Create a MO:
- 1 unit of P1 red
- Only the component C1 is added, which is correct.
- Change the product to P1 blue.
Problem:
The C1 component is not removed because to clear the move_raw_id,
we only check if the BoM is changed. However, in this case, it doesn't
change.
opw-3591800
closesodoo/odoo#142631
X-original-commit: 2a31cdb67338dd065b1aeb2d5e8c57724e8af236
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
After this commit, detailed operations is no longer a tab in the picking
but under a smart button in the form.
The field `show_operations` on picking type is no longer useful and will
be removed in a later PR targeting master
closesodoo/odoo#140898
Taskid: 3486636
Related: odoo/enterprise#50805
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a tracked product with BoM “P1”:
- component: add any storable product e.g “C1”
- byproduct: add any storable product e.g “B1”
- Update the stock of C1
- Update the stock of “P1” with two SN
- use the 2 SN of P1 as component in any MO and mark the MO as done
- Create a new MO to produce 2 units of P1
- Confirm the MO
- Click on “Mass produce”
- Generate two new SN
* First error : The byproduct quantity is not set
- Try to Mark as done the new MO
Problem:
A user error is raised: 'This serial number for product P1 has already
been produced'
When splitting the MO into two, a “stock.move.line” are created with
a qty_done = 1, leading to an error when verifying if the serial_number
of the move_finished has already been produced.
When clicking the "mark as done" button on the MO, the function
"_check_sn_uniqueness" is triggered and since the finished product is
tracked and there is a serial number set in the MO, the function
"_is_finished_sn_already_produced" is called:
https://github.com/odoo/odoo/blob/c84d80cc71ca0e7120dd293bfc56f9027bfdf9fc/addons/mrp/models/mrp_production.py#L2158-L2162
Within this function, we verify if the move lines of the finished move
have a lot and qty_done set. If this condition is met and we do not need
to exclude this move, an error is triggered.
https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2063https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2086
Solution:
Set "qty_done" to 1 only within the move lines of the components.
Opw-3566259
closesodoo/odoo#141521
X-original-commit: e0e6aed35d0f75c3ad01fbc329d7189f9e8d82f4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a kit product
- Create a storable product without BoM “P1”
- Create a MO to produce one unit of “P1”
- Add the kit product as component
- confirm the MO
Problem:
The Manufacturing Order is cancelled. This is because the MO contains
a kit product, and we need to generate moves based on its Bill of
Materials. However, at the same time, we cancel and remove the move
associated with the original product, which is no longer relevant.
But We remove it before creating the moves generated from the phantom
product. Consequently, since we cancel the move, the 'compute_state'
of the MO is triggered, and as there is only one 'move_finished' status
in 'cancel,' the status of the MO is set to 'cancel:
https://github.com/odoo/odoo/blob/5c238bbb18c682ff2d25f740aad604feb7bb5bbc/addons/mrp/models/mrp_production.py#L462-L463
Opw-3548464
closesodoo/odoo#140016
X-original-commit: baa0924974fee0115a0bce117141a8096455b88d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
To reproduce:
1. Create an MO of Product with BOM
2. Manually set qty for a component
3. Produce all
Issue:
Two consumtion warning lines are shown, and numbers are wrong
Part-of: odoo/odoo#140753
If there are pre-production rules, their delays should also be added to
the total delay of a manufacture route.
Task-3081481
closesodoo/odoo#137810
Related: odoo/enterprise#48516
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit
===================
In MO if a line is deleted or line has its to consume quantity reduced so in
done state transfers return is creating.
After this commit
===================
Stopped creating the return on done state transfer when quantity is reduced or
a line is deleted.
closesodoo/odoo#133696
Task: 3283010
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently when showing a BoM Overview, the stock_availability
is computed for each bom's component. This means that there will
be one read_group on report.stock.quantity by component. As this
is a postgresql View, querying it too often can degrade the overall
performances.
This commit tries to improve on that by computing the stock_availability
of all components without bom at the same level at the same time. Let's say
there is a BoM with 4 components, none of which has a bill of materials
of their own. Before this commit there would have been 4 read_groups, one
by component. Now there will only be 1 read_group.
Example speedup: customer database with 7M stock.moves,
7M stock.move.lines. BoM Overview with 33 nodes in the component
Tree: 3min30s -> 1min30s
X-original-commit: 8fa7a11bf41152a06537144c20d04921d3643272
Part-of: odoo/odoo#139067
Steps to reproduce:
- Enable manufacturing lead times in settings
- Create a BOM for product P with lead time 5 days
- Create and process an MO for product P
- End date is wrong
(add date_finished to the MO list view to check)
Bug:
when marking MO as done the end date is correctly set as today
but during the write the compute is triggered which delays it by
the lead time
Fix:
do not modify the end date of done MOs
opw-3536069
closesodoo/odoo#138431
X-original-commit: baa769a56a1236ec75a6042c56643464c2aabd3d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before this commit
=================
While updating the Bill of Materials (BOM), the work center and operation name
remained unchanged in the manufacturing order.
When Archiving/Unarchiving the operation doesn't show the "Update BoM" button
in the appropriate MO.
Steps to Produce
================
- Create a BOM1 with operations
- Create a MO with BOM1 and confirm MO
- Goto BOM and change the workcenter and operation name
- In MO Click on the 'update BoM' button
- Now you see the operation name and workcenter are not updated in MO
After this commit
=================
With this commit the work center and operation name get updated with the update
BOM click. For Archiving/Unarchiving the operation results to the display of
the "Update BoM" button in the appropriate MO. Directly editing an
operation will also cause the "Update BoM" button to appear
task-3461985
closesodoo/odoo#138256
X-original-commit: c343ebf0a28f6404f7ad6fc892c4a42edd2bbbe0
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Since commit[1] Serial number sequence rule takes priority over already
existing Serial numbers
Bug:
when disabling default Serial number sequence rule a validation error
is thrown since lot name is now empty
Fix:
fall back on the previous behaviour (get next SerialNumber) if sequence
is not set
(also added a clearer user error if neither is set)
note also updated the .pot file
opw-3514794
[1]:https://github.com/odoo/odoo/pull/134187closesodoo/odoo#137756
X-original-commit: 68d670a27be7baaaf53b0cf491234f8e0453d7f2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
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>
Simon Wydooghe