In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@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
Improve 'Component Availability' and 'Product Availability':
Add these fields in form and tree view (the performance issues
is addressed in next commits and these fields will be load lazily)
task-2579011
Part-of: odoo/odoo#77092
Component move with same product are not merge at confirmation as it
could be multiple different production steps.
opw-2583848
closesodoo/odoo#76401
X-original-commit: 390fce62462962e9a0131a082317e2e60e34041a
Related: odoo/enterprise#20801
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
no need to make rounding during computing qty_available
STEPS (see the test):
* create product with uom dozens
* create product with uom units
* create bom kit to convert one to another
* set qty on hand to 1 for product dozens
* check qty for product units
BEFORE: qty=11
AFTER: qty=12
---
opw-2632782
closesodoo/odoo#76242
X-original-commit: 26b28408d8970baa8cbf59ffaff90cab1e579410
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In case a production order loses its procurement group. The backorder
generation process do not have access to the last backorder sequence
used. This commit set a default value to avoid any traceback.
The new backorder name will not be guaranteed exact related to the
production sequence but will be unique in any cases.
closesodoo/odoo#76091
X-original-commit: aae07e88a8166cf26a8c81bb8ee37d630fd6672c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Allow to produce several serial numbers at once.
Only when BoM do not contain any component tracked by unique serial number
and lot ones are from 1 lot.
Also allow to copy/paste serial numbers.
This applies to manufacturing orders.
Task: 2444742
Part-of: odoo/odoo#71732
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>
Issue: In work centers with a capacity different than 1, the expected
duration was wrongly computed
Steps to reproduce :
1) Install Manufacture, enable Work Centers in Settings
2) Create a Work Center, Capacity = 2
3) Create a Product, with Manufacture as route
4) Create a Bill of Material :
Add any component
Add a operation line :
Work Center = created at 2)
Duration Computation = based on tracked time last 1 WO
5) Create a Manufacturing Order for the product 3), confirm
6) Set the real duration to 00:10, mark as done
7) Check the BoM Structure & Cost of the BoM 4)
-> Operations is 00:20
Why is that a bug:
To compute the expected duration, in mrp_workorder.py L691 we already
take into consideration the capacity of the work center.
When computing the time_cycle, we must give a time_cycle for 1 product
made with capacity 1, so we must first normalize the qty_produced fetch
from the DB to make like if we only produced the quantity once but in
the same amount of time
Side-Note: This also solves an issue with the Duration Computation based
on tracked time. The `limit` keyword was applied after the `group by`
so we effectively grouped all the operation_ids together, summing
their quantities and then limiting on the different operation_ids
opw-2562983
closesodoo/odoo#75557
X-original-commit: c78a25f92716bd6014de381c34f3bc268d1528ae
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
When a document (SO/MO) create a demand and this demand is directly
refill by an orderpoint, then write the source document that triggered
the orderpoint in addition in the origin field.
The purpose is to have an easy base tracking configuration even if
the priority and schedule date (and the final customer) could change
afterward (origin field still editable)
Part-of: odoo/odoo#75144
Missed the case of copying a cancelled MO needing its cancelled
move_finished_ids to still be copied during commit:
79efbd0e4707892041ee7c58c81c1d7edd033edd
Steps to reproduce:
Step 1: make a MO and cancel it
Step 2: duplicate the MO and try to mark as done
Expected result: qty is produced
Actual result: Validation Error about quantity to produce must be
positive (due to no move_finished_ids)
Follow up to task: 2618962
closesodoo/odoo#75569
X-original-commit: 56e7d4acc59a802c7613c1184858bda5bfb26748
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
If the prefix of the production sequence contains some dashes, it can
lead to undesirable behaviors
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Sequences & Identifiers > Sequences, edit "San
Francisco Sequence production":
- Prefix: "WH-MO-"
2. Create a MO
- Quantity: 2
3. Confirm, Edit:
- Quantity: 1/2
4. (Keep MO's name in mind and) Validate + Create backorder
Error: Backorder's name is "WH-MO-002" instead of "WH-MO-0000X-002".
Going back to the initial MO, its name became "WH-MO-001" (was
"WH-MO-0000X")
OPW-2618971
closesodoo/odoo#75270
X-original-commit: 076fe045f219dcb018b3b18215bfc3a0cfb3aa46
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
When combining a reordering rule, the 3-steps manufacture and
by-products option, the picking from the post-production to the stock
will not contain the residual products produced by the MO (by-products)
To reproduce the error:
1. In Settings, enable:
- By-Products
- Multi-Step Routes
2. Inventory > Configuration > Warehouse Management > Warehouses, edit
company's warehouse:
- Manufacture: 3 steps
3. Create 3 products P_compo, P_finished, P_secondary
- P_compo is consumable
- P_finished and P_secondary are storable
- Routes of P_finished: Manufacture
4. Create a reordering rule for P_finished:
- Min = Max = 1
5. Create a BoM:
- Product: P_finished
- Type: Manufacture
- Components: 1 x P_compo
- By-products: 1 x P_secondary
6. Inventory > Operations > Run Scheduler
7. Open the generated MO
8. Check Availability, Produce, Mark as Done
- Note that in the "Produce" wizard, we mention that one P_secondary
is also produced
- Also note that in "Finished Products" tab, there are 1 x
P_finished and 1 x P_secondary
9. Open the Transfers
Error: The picking Post-Production -> Stock does not exist
When creating the byproducts move
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L587
the field `move_dest_ids` is present (is the move created after
evaluating the RR)
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L580
so it is used, but this will cause the `_push_apply` to skip the
evaluation of the move
https://github.com/odoo/odoo/blob/f0eaa756c4947e2a595359959b34b14bfda81a07/addons/stock/models/stock_move.py#L678-L679
and `_assign_picking` will not run, as it normally do when creating the
manufacture
Thanks to this change, the picking Post-Production -> Stock will exist
and contain the residual products
OPW-2581762
closesodoo/odoo#75068
X-original-commit: 098af2fa85d2aebfc71b7e2342a1bbf05100e10d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
On BoM, a component line can be filter out depending
of the product variant to manufacture
(with "Apply on Variant" field).
Extend this feature to operation and byproduct line.
task-2614126
closesodoo/odoo#74973
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
Step 1: make a MO and create less than the quantity to produce
Step 2: Mark As Done (with no backorder)
Step 3: duplicate the MO and try to change the quantity to produce
Expected result: qty to produce changes as expected
Actual result: server error
Issue is due to the copied MO's `move_finished_ids` including a copy
of the cancelled finished move (i.e. the qty not backordered) so there
were 2 `move_finished_ids` for the product to produce. This resulted in
an access error since the onchange to update the `move_finished_ids`
only expects 1 move for the product to produce and results in a
singleton error.
Note we copy cancelled move_raw_ids because otherwise we wouldn't be
able to duplicate cancelled MOs without losing all of its components.
Issue 2 of Task: 2618962
closesodoo/odoo#75073
X-original-commit: 456c337534427db1296030b004ae061b47d8db79
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previous fix commit 5e34a02 was too aggressive in when it would delete
the move_finished_ids. In certain use cases it would result in no
move_finished_ids and a corrupted MO:
Steps to reproduce:
1. Create a new MO
2. Save the MO (do NOT confirm)
3. Update the qty to product_qty (qty to produce)
4. Confirm + Mark As Done
End result: "qty to produce must be positive" error whenever MO was
attempted to be completed and MO can never be completed.
To fix this, we split out when the move_finish_ids. They should all
be deleted ONLY when the product to produce is changed. Unfortunately to
cover all cases, we must always wipe the moves whenever the product is
changed (e.g. when changing the product twice with the original product
being the final saved value, we have no way of knowing to keep the
original move_finished_ids due to onchange only being able to check
against the last saved value, not last selected value).
Additional test + test update done to support preventing this
catastrophe in the future.
Part of Task: 2618962
closesodoo/odoo#74859
X-original-commit: fa468782f4a52334fd055fb5cd11e2c62ddd6f9d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Tiffany Chang <ticodoo@users.noreply.github.com>
Step to reproduce :
- Create a Manufacturing Order for several pieces of a product with a
work center routing
- Open the Work Order which has been created
- The Manufacturing Order is set to 'to close', instead of 'in progess'
Cause of the issue
The state of the MO was never computed based on WO status.
Solution
The state of a MO is set to 'to close' when a WO is set as 'done'
or 'cancel'
opw-2584446
closesodoo/odoo#74411
X-original-commit: c237c9c3214b58d303a8597df2c836872c5e522c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
Previous specification of making MOs unlocked by default was confusing
for users and made it too easy to accidentally change the qty to consume
rather than the consumed amount. This fix makes it so MOs are now locked
by default and will be unlocked/locked (including existing draft /
confirmed / in progress MOs) automatically when setting is changed.
Previous setting (Lock Quantities To Consume) has been repurposed for
this. When setting is active, no lock/unlock button will be visible to
match the updated setting description (i.e. non-done MOs can
never be locked).
Task: 2518523
ENT PR (only fixes test): odoo/enterprise#19732
Upgrade PR: odoo/upgrade#2655
Step to follow
- Create a product with 2 variants and set route to Manufacture
- Create a BOM for the product
- Create an MO for one of the variants
- Save (in Draft State)
- Edit
- Change to the other variant
- Confirm
- Finish the MO Order
- Look at product moves on MO
Cause of the issue
In MrpProduction._onchange_move_finished method, self.move_finished_ids
was not empty before being assign.
Solution
Removed the records from self.move_finished_ids before
assign another one to it.
opw-2572644
closesodoo/odoo#73563
X-original-commit: 5e34a02c3d897d888bf52b1977c25047326b76a8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
- The work order state changes based on the availability of the components
- So if all BOM components are available the state of the first WO is set to ready
- The color of ready in the WO tree editable view will stay blue as long as done reserves the green color
- If one or multiple components are not available, the state of the first WO is set to waiting
- The color of waiting in the WO tree editable view is set to orange
By default to launch takes workorder_ready_count so it counts only ready WOs
- The user can always process the WO without restrictions even if the WO state is waiting
Task-2426773
closesodoo/odoo#71250
Related: odoo/enterprise#18523
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: nouraellm <nea@odoo.com>
The problem arises when a user creates a backorder for a MO after
registering overconsumption of some components through the simplified view.
The quantities of the components of the new backordered MO are then wrong.
Components that were over consumed in the first MO will have smaller
quantities in the new MO, the difference being the amount over consumed.
This problem does not appear in the case of the Tablet View where a proper
recalculation of quantities is done.
closesodoo/odoo#64911
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When planning a Manufacturing Order, if an operation takes place in work
center with a different time zone, the computed date may be incorrect
(the start date may be outside the working hours)
To reproduce the error:
(Use demo data. Current timezone: Europe/Brussels)
1. In Settings, enable "Work Orders"
2. Open an existing Work Center
3. Click on "Standard 40 hours/week"
4. Set Timezone to "Asia/Bangkok"
- Note that all slots are between 8:00-12:00 and 13:00-17:00
5. Create two storable products P_compo and P_finished
6. Create a Bill of Materials BM:
- Product: P_finished
- BoM Type: Manufacture this product
- Components: 1 x P_compo
- Operations: 3 x Operation with existing work centers
7. Create a Manufacturing Order:
- Bill of Material: BM
- Quantity: 100
8. Save, Confirm, Plan
Error: (it depends on the time the test is done) The 'Scheduled Start
Date' of the second operation is incorrect. Adding the time zone
difference gives a time that is outside the work center's timetable
(i.e., outside 8:00-12:00 and 13:00-17:00).
The computations do not consider the time zone of the work center.
OPW-2393330
closesodoo/odoo#71332
X-original-commit: dab24e497f095d0c7857f07d037e9cb16749e2ea
Related: odoo/enterprise#18572
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.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>
If a MO is validated with all of its (component)
move_raw_ids.quality_done = 0, then when trying to validate the
nonsensical "The quantity to produce must be positive" validation error
will occur. This is due to all move_raw_ids being marked as Cancelled,
which auto-updates the MO state to cancelled, which prevents the
validation from properly completing.
To avoid this error, we prevent the user from having 0 consumption for
all components.
Task: 2422698
Related (v13 fix + bug description) Task: 2463893
ENT PR (test fixes): odoo/enterprise#18355closesodoo/odoo#71068
X-original-commit: 81ba7084aeb3899787d083a2a2568a490f9c53e5
Related: odoo/enterprise#18411
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <ticodoo@users.noreply.github.com>
Prior to this commit, MOs would throw a usererror if there were no
components in it. This restriction made it so MOs created by a
replenishment (i.e. `warehouse.orderpoint`) for a BoM with no components
were never confirmed and the `qty_to_order` would accumulate for each
replenishment's new draft MO.
Steps to reproduce:
1. create a bom for a new product (w/ manufacturing route) with no
components
2. create and confirm a sales order for the new product
3. go to Replenishment and automate the product's replenishment
4. create a new sales order for the product
Expected result: 2 confirmed MOs where the quantity of the first MO
matches the first sale order's quantity and the 2nd MO matches the
second sale order's quantity
Actual result: 2 draft MOs where the first MO matches the quantity of
the first sale order and the second MO matches the quantity of the first
sale order + the quantity of the second sale order
This commit makes it so MOs can now be confirmed even when it has no
components. Note this requires changing the logic in a few locations to
ensure expected behavior still occurs including:
- backorders are automatically confirmed.
- `reservation_state` is recalculated when expected (will be blank when
no components).
Task: 2422698
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>
The button plan of in the manufacturing order tree view doesn't
confirm correctly the draft MO selected (but only the related moves).
task-2479111
closesodoo/odoo#70608
X-original-commit: ef9515611ac96368eae14fc941bca15e3724557a
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, if any workorder is stared to produce, qty
producing was 0. After this commit, if product tracking is none
then system will suggest the remaining qty of workorder to produce
when user is start it.
TaskId - 2480775
closesodoo/odoo#70207
X-original-commit: 5bbc234d43a415be18fcfa42dad33b1577644719
Related: odoo/enterprise#18086
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Considering the MO under consumption situation:
component A, to consume = 2, consumed = 1
Previous, after "mark as done", the MO will have two lines:
component A, to consume = 1, consumed = 1, state done
component A, to consume = 0, consumed = 0, state done
Now, after "mark as done", it will be consistent with picking:
component A, to consume = 1, consumed = 1, state "done"
component A, to consume = 1, consumed = 0, state "concel"
Task 2446915
PR #66583
ENT PR odoo/enterprise#16554
This commit is a revert of revert 561b3461a0
and 97ba860fd38c530d3f3678f676754862afad0f11.
Previously we split moves when no picking, now we consider it
unnecessary.
Task 2446915
COM PR #66583
ENT PR odoo/enterprise#16554
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Generic operations will be applied for every manufactured product passing
through the work center.
An operation linked to a bom will only be applied when the specific manufactured bom is produced
So on a BOM, every operations must be created for this specific BOM
The widget many2many is wrong because it will overwrite the generic operations
opw:2458974
closesodoo/odoo#66888
X-original-commit: a430c06ec6ec286a2d9ef55de6eebec60feeae3f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Go to an existing BOM B
- Edit B and try to add an existing operation O in operations tab
Bug:
It was impossible to add an existing operation
opw:2458974
closesodoo/odoo#66712
X-original-commit: ffab43fbf54b2f914b34c18da2391f3a18b3326c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Add and improve onchange warnings when a duplicate SN is used in
following cases: inventory, picking (any type), manufacturing, scrap,
and "Update Quantity" (i.e. directly edit quants from product form).
Improvement includes:
- include location where the existing SN is
- auto-correct source location when appropriate (e.g. trying to scrap a
SN in the wrong location)
The goal of this is to prevent but not restrict duplicate SNs so users
can have some flexibility (especially if a dupe SN occurs because of an
error such as doing pick-pack-ship out of order.)
closesodoo/odoo#61287
Task: 1924758
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replenishment is great to replace MTO but misses the direct link between SO and PO (smart buttons on both SO and PO to link to the corresponding PO and SO).
The info is actually there in the forecasted report but it is not accessible directly from the PO and in the case of the SO does not highlight the corresponding line of the SO.
This adds a graph icon in the PO, MO and receipt form to directly access the forecasted report (it already exists for SO and delivery).
The information linked to the SO/PO/MO/receipt/delivery is also sent to the forecasted report to highlight the corresponding line.
Note that in the case of the SO, the information needs to go first through the qty_at_date widget (which contains the link to the forecast report).
The graph icon for the PO, receipts and MO turns red when the forecasted quantity at expected date is negative. This is done using the new 'forecasted_issue' field.
closesodoo/odoo#62264
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When `qty_available` was being called
for a kit and its components at the same time,
e.g.:
- Kit product
- Product 1
- Product 2
The kit product available qty was always computed to `0.0`,
because when computing its component available quantity,
they were computed to `0.0` because they were marked
as `protected` by the ORM when calling the compute method
for these records at the first call.
When the `qty_available` compute method for the kit
then called recursively the `qty_available` compute
method for the component, as the component record
were marked as protected,
the ORM filled their value with the Falsy value `0.0`.
This issue occured particularly in the upgrade integrity unit test
which makes sure the available quantities of the products remain
unchanged after upgrade. This test computes the available
quantities for a bunch of products at the same time,
and its therefore likely a kit product gets its available
quantity computed as the same time than its components.
upg-3185
upg-4215
upg-4228
upg-5558
upg-5745
upg-5856
upg-6012
upg-6064
upg-6076
upg-6306
upg-6514
upg-6588
upg-6729
closesodoo/odoo#65758
X-original-commit: 8e152a567a6003dae4abb3b537b963eec4142d6d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
- 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
Behavior prior to this commit:
- normally when editing the Scheduled Date on a MO, the date on the
related stock moves is updated. However this does not happen once the
MO is planned
- if the date is edited and the MO is planned, the MO is automatically
unplanned, but the date on the stock moves is not automatically updated
Behavior after this commit:
- when the date is updated on the MO and it is planned, the dates on the
stock moves will automatically update, so that the behavior is
consistent with how it would work if you clicked Unplan first then
updated the date.
Note:
- this commit is forward ported from 14.0. Only the unit test was
ported, as the behavior had already been modified to match the
expectation.
opw-2417108
closesodoo/odoo#64006
X-original-commit: 97f79960dbb3aa371378f576cfdce9670ca8ccce
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
Behavior prior to this commit:
- when the warehouse uses a 3-step manufacturing process, if I create a
Sales Order, the MO generated does not show the SO# as "Source", instead
it shows the MO#
Behavior after this commit:
- the MO source shows the SO# (similar to how it works when using the
2-step or the 1-step manufacturing process)
- the origins are assigned thus:
- Delivery Picking = SO name
- Post-prod Picking = SO name
- MO = SO name
- Pre-prod Picking = MO name
Note:
- there is no implementation change in this commit - we just ported the
test from the original commit in 13.0 (the behavior in 14.0 was already
OK)
opw-2380717
closesodoo/odoo#62512
X-original-commit: 0281dee6da75e68403772ebd368d57c1feb98c37
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add 2 warnings on Units of Measure and Decimal Accuracy.
Therefore, users are warned when their UOM/decimal changes can
cause inconsistencies in quants reservation.
Also, we want to prevent the issue at the root by ensuring that both the move
and the quant have the same reserved quantity.
The contrary can happen e.g. when a product is defined in Liters (rounding .001)
but used in an operation in ml (rounding .01, so e.g. 187.5ml).
The conversions between the 2 UOM can cause the differences of reservations.
In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom
is not more precise than the overall Decimal Accuracy. That way, if
the reserved quantity changes between UOM conversions, the move line created
is in the quant/product UOM, and we do not have move line's reserved quantity >
quantity in stock.
We do the same for _update_reserved_quantity (stock.move), when updating
a move line.
In _update_move_lines, because of UOM conversions, new_quantity_done
can differ from ml.product_uom_qty, which triggers the creation of an extra
move line, leading to reserved quantity > quantity in stock. To prevent
that, we compare the reserved quantities in the product UOM.
opw 2206902 (Example 1)
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
closesodoo/odoo#62279
X-original-commit: 478a42beb5876171afeab7df27fa69548edbf849
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Current behavior before PR:
It is possible to create a BOM that has a BOM line that reference the
same product as the BOM itself. This is undesirable as when we create a
manufacturing order for this product we will have an error.
It is a regression bug that was introduced in commit
575353e251a0cce3bbff759edaeb56b5718beb11 between v12 and v13.
Behavior after PR is merged:
When saving a BOM it will validate that no product line references the
same product, or the same product variant, as the BOM itself. Note that
it is allowed to have a BOM for a product variant that references
another variant of the same product.
opw-2347941
closesodoo/odoo#59633
X-original-commit: 917e4c67b4aa14ca71ec6cba4bc6d20a86459f42
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit makes sure we do not try to update the quantity on a
finished stock move (during record production or confirming the produce
wizard) if there is no finished move available.
Closes#57227closesodoo/odoo#59430
X-original-commit: 141df3b398aee2bac10e3ce94e15bb4bd14d17af
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Rémy Voet (ryv)