Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
Delivery slip packages contains products not present in the package
Steps to reproduce:
1. Install Sales and Inventory
2. Go to Settings > Inventory > Operations and enable Packages
3. Create and confirm a sale order with product A, B and C
4. Click on the delivery smart button and create and assign different packages for products A and B
5. Set done quantities for products A and B
6. Validate the delivery with no backorder
7. Click on Print > Delivery Slip
8. Product C is in both packages
Solution:
Don't print empty moves when packages are used
Problem:
`_get_aggregated_product_quantities` returns all move lines related to a certain `stock.picking`, even the empty ones
It is called for each package so the same empty lines will be displayed for all packages
OPW-2727659
closesodoo/odoo#84138
X-original-commit: 1b39e170537d48a29a0dda06776cfacef41b9c8f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
It is currently not possible to update the quantity of a product from
the inventory report
To reproduce the issue:
1. Create a storable product P
2. Update its on hand quantity to 100
3. Inventory > Reporting > Inventory Report
4. On the line for P, update to quantity to 75
Error: The quantity becomes 0 instead of 75
When setting the quantity from the inventory report, the client calls
the `write` method with the context key `inventory_report_mode` defined
and equal to `True`
This `write` leads to `_set_inventory_quantity` which triggers
`action_apply_inventory` (without disabling the context key!):
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L150-L158
At the end of the inventory update, it resets the field
`inventory_quantity` to 0:
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L592
To do so, the `write` method is called again and here is the issue:
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L244-L248
Once `inventory_quantity` is updated, since `inventory_report_mode` is
still in the context and equal to `True`, `action_apply_inventory` is
called again. Then, when applying again the inventory, it will consider
the value of `inventory_quantity` (i.e., `0`) to define the new
quantity.
OPW-2737437
OPW-2746201
closesodoo/odoo#84002
X-original-commit: 6500e99cbfda44ebd1931acd657e86841ac2342a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Go to Settings > Technical > Decimal Accuracy
- Change Unit of Measure to 4 digits
- Go to Inventory report or Valuation report
Bug:
The decimal accuracy in Valuation report for quantity or reserved quantity was in two digits instead of four digits
The decimal accuracy in Inventory report for qty_at_date was in two digits instead of four digits
PS: In stock move report or stock move line report, the decimal accuracy of quantity fields are in four digits
By default digits of Product Unit of Measure is 3, that's why some test had to be modified
opw:2410981
closesodoo/odoo#82989
X-original-commit: 0cf5c4e8241c46724defc0ea7e0d2c881ec2eeab
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usecase to reproduce:
- Create a planned receipt of 10 product A
- Set quantity done to 10
- Put in Pack
Actual result:
UerError "There is not move line to pack"
Expected result:
Pack them
It happens because since we are in a receipt without suggestion (by
default) then the fields `move_line_nosuggest_ids` is used.
But `_set_quantity_done` on `stock.move` will first try to fill
move line with reservation before creating new ones.
So the move_line_nosuggest_ids will not contain the quantity done
on planned quantity
closesodoo/odoo#83430
X-original-commit: 3c7453a61372d6ecdeae099d49cbc79844c144ae
Related: odoo/enterprise#23767
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Some projects start to have real planning and in multiple
steps the `stock.move` that are not linked to a RFQ or a MO
are always merge together with the minimal date are result.
It's not flexible since you don't know the correct quantity
for a specific day. And once this quantity is received, you
don't know the next date.
We just add a system parameter for now and it will be modify
in master to be able to do this configuration for everyone.
X-original-commit: b9fffac7a8b6ccef2d957b5564ce615b2e1b0b36
Part-of: odoo/odoo#83430
The `check` decorator in `sql_db.py` was on a lot of `Cursor` methods.
It checks if the cursor is close before be using a the method.
Remove it because:
- It is completly redundant because `psycopg2` do already the job
to check the cursor before usage.
- It complicated the call stack and lead to a small overhead of
highly use methods (can be more than 1% of the execute call)
- Also the nature of
the Error isn't correct: raise `OperationalError`
(https://www.psycopg.org/docs/module.html#psycopg2.OperationalError)
instead of `InterfaceError`
(https://www.psycopg.org/docs/module.html#psycopg2.InterfaceError).
Part-of: odoo/odoo#80961
In case of a MRP subcontracting, it is not possible to process the
delivery with several backorders.
To reproduce the issue:
1. Create two products P_compo, P_finished
- Both storable
- P_compo must have the route "Resupply Subcontractor on Order"
2. Update P_compo's quantity: 5
3. Create a BoM:
- Product: P_finished
- BoM type: Subcontracting
- Subcontractors: a partner P
- Components: 1 x P_compo
4. In Inventory, create a planned transfer T:
- Operation Type: Receipt
- Receive From: P
- Operations: 5 x P_finished
5. Mark as Todo
6. Inventory > Resupply Subcontractor, find the delivery of P_compo for
P and process it
7. Back to T, set the done quantity to 1.25
8. Validate T (with backorder)
9. On the backorder BO1, set the done quantity to 1.0
10. Validate BO1 (with backorder)
11. Open the second backorder BO2 and validate it
Error: a Validation Error is displayed "You can not enter negative
quantities.", which doesn't make sense
The issue comes from the inner method `_get_available_move_lines` in
`_action_assign`. When validating a picking, at some point, we are here,
at the beginning of `/mrp_subcontracting._action_done`:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L36-L37
To understand what happens next, we need to note that, in this method,
the associated MO will be marked as done later (on line 76). Back to the
current line (L37), we are calling `super` which leads to the
problematic `_get_available_move_lines`. Suppose we are on step 10 (we
are validating the first backorder), we have
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1390-L1391
`move_orig_ids` contains two stock moves, each one associated to one MO.
However, as said above, the second MO is not yet marked as done, this
will be done later on in `/mrp_subcontracting._action_done`. Therefore,
`move_lines_in` is only defined with the first SM, from the first MO,
with a quantity of `1.25`
Further in `_get_available_move_lines`, we have:
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1403-L1405
`move.move_orig_ids.mapped('move_dest_ids') - move` gives two SM, and
here is the issue: the second one is already processed, so both are kept
in `move_lines_out_done` and the sum of their quantity is equal to
`1.25 + 1 = 2.25`
Therefore, at the end of the method, when computing the difference, it
gives a negative difference. This negative value will be used to create
a SML and later on, it will trigger the validation error.
Once the above issue is fixed, there is another "invisible" issue that
need to be fixed: when generating several backorders on the deliveries,
only the first one will trigger the creation of a new MO. Suppose we are
back in `/mrp_subcontracting._action_done` (still on step 10 in the
above case), in the first for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L39-L43
`move._get_subcontract_production()` returns the two MO (from the
initial picking and from the first backorder). However, since the first
one has already been processed, the if-condition is validated.
Therefore, this for-loop is done and the second MO is not processed (the
quantities are not recorded and its field
`subcontracting_has_been_recorded` is not defined to `True`). As a
result, still in `/mrp_subcontracting._action_done`, we are now in the
second for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L71-L72
`_subcontracting_filter_to_done` removes the two MOs because the first
one is done and the second one has not its field
`subcontracting_has_been_recorded` set to `True`. The condition in the
first for-loop is not accurate enough.
OPW-2731658
closesodoo/odoo#83658
X-original-commit: 1b740ae148acfc832b124122763817b08ea110ab
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit we could print the product labels of a picking from a
picking, but we couldn't print only the lots/sns. This commit adds in
this ability. Because we want to be flexible with this label printing
(i.e. have the option to choose between printing zpl or pdf + 1 per
unit or per lot/sn), we include it in the general "Print Labels" button
with additional wizards.
Note that we assume:
1. If there are no lot_ids in the picking => default to only product
labels wizard (i.e. this also means if a picking that only creates
New Lots/SN, lots/sns will not be printable until picking is
validated.)
2. Lots/SN PDF labels will only be in the 4x12 label format
3. Batch pickings can also print lot/sn labels
Part of task: 2494740
Related ENT PR: odoo/enterprise#23323closesodoo/odoo#82389
Related: odoo/upgrade#3202
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When a package name is a valid SSCC number, we prefer to auto-print the
datamatrix to be used by shippers, which includes:
- the SSCC number
- the pack date (i.e. when it was put in pack)
- the weight of the package (only when less or equal to 6 digits)
Pack date field was added to accomodate this and defaults to when
package is created (e.g. when buying packaged meat at the supermarket,
it's assumed the pack date is when the package of meat was created).
SSCC datamatrix will auto-print now in 3 package reports:
- Package with contents
- Package Barcode (PDF)
- Package Barcode (ZPL)
Note if ability to create datamatrix appears to not work (only in PDF
versions) then standard 1D barcode will be used.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Upgrade PR: odoo/upgrade#3202
Part-of: odoo/odoo#82389
When printing Lot/SNs barcodes, it's sometimes desired that we print a
GS1 compliant datamatrix with the following info (when applicable):
Product barcode,
Lot/SN barcode,
Best By Date,
Expiration Date
For flexibility, a setting has been added for when the GS1 datamatrix
should print instead of 1D barcode.
Note that datamatrix will automatically exclude invalid product barcodes
(i.e. non-EAN compliant) and datamatrix size can vary based on amount
of data in datamatrix (so size has been set to accomodate expected
largest gs1 compliant datamatrix possible).
If it appears that datamatrix cannot be created, then default to
standard 1D barcode. Note that zpl printer has built in datamatrix
creation command, so we can always assume they will print correctly.
Part of Task: 2494740
Part-of: odoo/odoo#82389
When a product's barcode is EAN compliant (i.e. EAN-8, EAN-13, GTIN-14})
and feature to create DataMatrix is fully installed then we would like
to print its GS1 datamatrix on the package content report.
Additionally, if the product is tracked, we would like to include its
SN/Lot if assigned one + any "use by"/"expiration date" to make the
overall usefulness of the report go up.
Part of Task: 2494740
Part-of: odoo/odoo#82389
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
It is sometimes impossible to unbuild a product because of decimal
values.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Units of Measure"
2. Set the decimal accuracy of "Product Unit of Measure" to 4
3. Set the rounding precision of "Units" to 0.001
4. Create two products P1, P2
5. Create a BoM:
- Product: P1
- Quantity: 3
- Type: Manufacture
- Components: 5 x P2
6. Process a MO with 3 x P1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Quantity: 1
8. Unbuild
Error: An error message is displayed "The quantity done for the product
"P2" doesn't respect the rounding precision[...]"
At some point, for each SM associated to the UO, the modules uses the
value of `product_uom_qty` to write the done quantity of the SM. The
rounding of `product_uom_qty` is based on "Product Unit of Measure" so
the component's SM has its quantity equal to `1.6667`. Moreover, writing
the done quantity trigger the creation of the associated SML. As a
result, the SML has its done quantity equal to `1.6667` while the
rounding of the associated UoM is `0.001`. When calling `_action_done`
on such a SML, it will raise an error because the value doesn't respect
the rounding.
Side note: the error message is incorrectly written, the indents in the
file are displayed on the front-end.
OPW-2710038
closesodoo/odoo#83369
X-original-commit: c11d772f39179c5dec5eb431b6f4bc02c680643a
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Due to many move values being set only during an onchange, there were
inconsistencies with the values of the products to manufacture and the
MO's components in the following cases:
- when a MO has manually added components/byproducts (i.e. not from a
BoM or a MO with no BoM) = missing values
- a MO is copied = incorrect values copied
- a backorder is made = backorders' moves contained new "-00#" name, but
original "-001" MO did not update all corresponding values to new name
There were also a couple of default values for manually added moves that
were either incorrect or not correctly saving.
Most of these inconsistencies are not visible to the user unless they do
a data export or are playing close attention (e.g. copying an MTO
triggered MO will copy the date_deadline, and this value cannot be
edited by the user.)
Part 6 of Task: 2667151
Part-of: odoo/odoo#80319
Allow use of reception report for MOs. Same behavior is expected as with
(non-outgoing) pickings. With exception that procurement group linkage
should be included when assigning.
Original Reception Report Task: 2500844
Follow Up Reception Report Task: 2632884
Task: 2662730
Part-of: odoo/odoo#79627
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
In some cases, when making an inventory adjustment, the `in_date` of the
new quant will be incorrect
To reproduce the issue:
(Let D01 be the current date)
1. Create a storable product P
2. Set its quantity to 1
3. Process a delivery order with 1 x P
4. Set the date in the future
- Let D02 be this date
5. Make an inventory adjustment with 1 x P
Error: The `in_date` of the quant (for P in the stock location) is D01
instead of D02 (can be observed either directly in PSQL, on the form
view of the quant (via Locations > Current Stock), or by adding the
field on the tree view)
When validating the stock adjustment, at some point, the module calls
`_action_done` on a SML (1 x P from Inventory Adjustment to the Stock
Location). To do so, it decreases the quantity of the origin location
and increases the quantity of the destination location thanks to
`_update_available_quantity`:
https://github.com/odoo/odoo/blob/b4a9e5b8307ab1b730effe2de23f15260326ef6c/addons/stock/models/stock_move_line.py#L485-L493
But here is the issue: when decreasing the quantity in the virtual
location (Inventory Adjustment), it finds an old quant (the one from
step 2 in above use case). It then stores its `in_date` (D01) and since
this date is before the current one (D02), D01 is kept, used to update
the quant quantity and returned in `action_done`. As a result, when
increasing the quantity in the stock location,
`_update_available_quantity` is called with the parameter `in_date`
defined and equal to D01. Again, D01 will be the earliest date, so the
date will be used to create/update the quant in stock location.
OPW-2702198
closesodoo/odoo#83009
X-original-commit: e27ee5cd6b19351a00030310d1db3a0defe5b31a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In some cases, the SM description is incorrect
To reproduce the issue:
1. Create a product P
2. Create a receipt with 1 x P
Error: The description of the SM is incorrect: `<p><br></p>`. It should
be the name of P
Another example:
1. Create a product P:
- Internal Notes: "Lorem Ipsum"
2. Create a receipt with 1 x P
Error: The description of the SM is incorrect: `<p>Lorem ipsum<br></p>`.
It should be "Lorem Ipsum"
Since [1], `product_template.description` is a HTML field.
[1] bea5790713
OPW-2732208
closesodoo/odoo#82917
X-original-commit: 73f05114307b6ec6590da22903751ab79e7efa90
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Il during the scheduler an exception append, the error is not correctly logged.
This PR allow to catch the error with logger analyser (like sentry).
closesodoo/odoo#82648
X-original-commit: c68e1d1c13d116bda6b91fcbbcd61a26739a9894
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Suppose a tracked-by-usn and consumed product returns in the stock
thanks to a repair order. Using again this component in a new
manufacturing order will raise an error
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two products P_finished, P_compo
- Storable
- P_comp tracked by USN
3. Update the quantity of P_compo:
- WH/Stock: 1 x Lot01
4. Create a manufacturing order MO:
- Product: P_finished
- Components:
- 1 x P_compo
5. Confirm, Check availability and Mark MO as Done
- (Lot01 should be consumed)
6. Create a repair order RO:
- Product: P_finished
- Parts:
- Type: Remove
- Product: P_compo
- Lot: Lot01
- Destination Location: WH/Stock
7. Confirm RO, Start RO, End RO
- (There should be one Lot01 available in stock)
8. Repeat 4-5
Error: When checking the availability on the MO, Lot01 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number Lot01 used for component P_compo has
already been consumed" although this lot should be available
When checking the uniqueness of the lot, nothing includes the products
back in stock thanks to the repair orders.
OPW-2701668
closesodoo/odoo#82544
X-original-commit: 3d9355f90fa1dd9436f1745c515c89947ed04de0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Two key are used for the same purpose. Remove one and
use its content directly in the report
clean commit bef1765b197a9e9d510a7d20d0364333402473b0
Part-of: odoo/odoo#82312
use case to reproduce:
receipt a product tracked by lot
produce a lot with a component tracked*
open the traceability report for the lot's component
you have a traceback.
it's due to last_delivery_partner_id field present in the tree view of lots.
it triggers _compute_delivery_ids that call _find_delivery_ids_by_lot in multi.
the call in the recursion(trigger by *) redefine delivery_by_lot and erase the previous result.
so the cache is not correctly update and traceback
closesodoo/odoo#82351
X-original-commit: e6bcc77c58d39adbd782e776eb2f6d5c470eb0e2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
with l10n_mx_edi_stock being introduced in enterprise - we require the unit of measure object in the aggregated lines so that it can be used on the delivery report.
odoo/enterprise#21591
Task-2585661
closesodoo/odoo#82224
X-original-commit: 4d074686c1eb716020b950ea86650ecf2bda08aa
Related: odoo/enterprise#23244
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Current behavior:
Filter "Owner is not set" on Package in inventory app was causing a traceback
Steps to reproduce:
- Go in inventory app
- Go in package
- Apply a filter "Owner is not set"
- You get a traceback
opw-2714726
closesodoo/odoo#82237
X-original-commit: e4b350907f01253a96ddc763d6fdbdd307874e23
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce:
-Create a quote with 2 lines (same product - different lead time).
-When a partial delivery is made (e.g., 5 of 10), Odoo places the operation related to the remaining undelivered quantity (5), on the last line in the Operations list.
-When the next delivery is made, Odoo deducts the quantity from the first operation in the list instead of from the line whose deadline is closest.
Current Behaviour :
Odoo assign button assign quantity to the first move line in the list.
Behaviour After the PR:
Odoo assign button assign quantity to a move line based on the priority, the closest deadline and the id.
opw-2657048
closesodoo/odoo#82062
X-original-commit: 430f4f2ca1cebaea62415ee72bf4369684abbfaa
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
- Install stock with demo data
- Log in Chicago company
- Chicago partner has inter-company transit set on Customer and Supplier
locations
- Jeff Lawson (partner address of chicago warehouse) has Customer and
supplier locations set instead of inter-company transit.
It prevents the following usecase:
- Enable synch SO and PO between chicago and SF company with automatic
confirmation
- Create a product with route Buy and MTO
- Create a PO in company chicago that buy to SF comapny
- Validate the PO
You have an error with rule since it try to pull from intercompany
transit instead of customer
However if you log in San Francisco company Jeff Lawson has
inter-company transit set while it should not.
It happens because during the demo install the partner is added through
a write and the company is not provided and the code was missing a part
in that case.
closesodoo/odoo#82006
X-original-commit: 46c49ce4f6c9677463425981f01b69117c11943e
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There is 2 major issues with the production of multiple serials number
- Performance issue
- Duplicated code with classic backorder mechanism
The performance issues exist since backorders were create one by one
and `stock.move` and `stock.move.line` are always recomputed. They
are not created in batch neither.
_generate_backorders is removed and replace by _split_productions. The
functionality are the same. Technicaly it does the maximum in batch,
first it creates all the `mrp.production` then all the `stock.move`
and finaly, it splits the existing `stock.move.line` among the new
`stock.move`
It means that the reservation is not recompute anymore during a
backorder process and will remain the same than the splitted production
order.
Performance metrics (10 components):
| 2 | 10 100 1000
before | 0.47s | 2.84s | 32.25s | 580.53s
-----------------------------------------------
after | 0.13s | 0.36s | 2.60s | 35.17s
task 2633369
Part-of: odoo/odoo#77254
Improvements of the Inventory Adjustements page, among which:
- Add a new 'Apply All' button (without the need to select a record)
- Show the date at which the last count was done
- Add warning icon next to duplicated SN
- Allows to change the lot_id when empty and no quantities are set
closesodoo/odoo#78361
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Due to floating point representation, some floats may have some
insignificant decimals. Therefore, `float_compare` should be used when
comparing such numbers
OPW-2699576
closesodoo/odoo#81138
X-original-commit: 7f30ef42717b009ee569db58b885ce863d969a06
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
This commit adds an index on picking_type_id for models stock.picking
and mrp.production.
Filtering on picking_type_id is often done via the Inventory Overview.
This should speed up the list render in case of many object.
Task : 2648449
closesodoo/odoo#80434
Related: odoo/upgrade#3068
Related: odoo/enterprise#22535
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Add a "clear qty" button to revert the change by "set qty" button in
(batch) picking.
On the move, Whenever the qty_done != reserved, we consider it a
manual change from the user. "set/clear qty" buttons won't change the
line with manual change.
Show "set qty" button when there are moves with 0 qty_done and non-zero
reserved. Show "clear qty" button when we don't show "set qty" button
and there are moves with qty done == reserved but the number is not 0.
Task-2659233
closesodoo/odoo#78737
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce:
- Test upgrade request 40290
Issue:
Traceback raised.
Cause:
The _find_delivery_ids_by_lot function can raise a
RecursionError: maximum recursion depth exceeded if
there is a loop in the path of lots.
When running the function recursively for
lot_id contained in produce_line_ids the same lot
can be reached multiple times.
In the case of db 40290:
move_380->move_381
move_381 and move_419 both in lot_1320
move_419->move_423
move_423 and move_380 both in lot_567
move_380->move_381
...(goes on forever)
Solution:
Use a lot_path optionnal argument to test if
a lot has already been visited.
Full Traceback:
```
Traceback (most recent call last):
File "/tmp/tmp81rzi7n7/migrations/testing.py", line 208, in test_check
self.check(value)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 85, in check
self.assertFalse(diff, msg)
AssertionError: [('stock.menu_action_production_lot_form', 195, 'Inventory > Master Data > Lots/Serial Numbers', 310), ('mrp.menu_mrp_traceability', 258, 'Manufacturing > Products > Lots/Serial Numbers', 310)] is not false : At least one menu or view working before upgrade is not working after upgrade.
('stock.menu_action_production_lot_form', 195, 'Inventory > Master Data > Lots/Serial Numbers', 310):
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 879, in get
return field_cache[record._ids[0]]
KeyError: 567
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 882, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'stock.production.lot(567,).delivery_count'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 182, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 293, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 319, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3227, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3247, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5867, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1106, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1265, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 122, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
[Previous line repeated 926 more times]
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 197, in _find_delivery_ids_by_lot
move_lines = self.env['stock.move.line'].search(domain)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 1810, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4683, in _search
self._apply_ir_rules(query, 'read')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4464, in _apply_ir_rules
expression.expression(domain, self.sudo(), self._table, query)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 431, in __init__
self._unaccent = get_unaccent_wrapper(model._cr)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 405, in get_unaccent_wrapper
if odoo.registry(cr.dbname).has_unaccent:
File "/home/odoo/src/odoo/15.0/odoo/__init__.py", line 104, in registry
return modules.registry.Registry(database_name)
File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 61, in __new__
return cls.registries[db_name]
File "/home/odoo/src/odoo/15.0/odoo/tools/func.py", line 71, in wrapper
return func(self, *args, **kwargs)
RecursionError: maximum recursion depth exceeded
('mrp.menu_mrp_traceability', 258, 'Manufacturing > Products > Lots/Serial Numbers', 310):
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 879, in get
return field_cache[record._ids[0]]
KeyError: 567
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 882, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'stock.production.lot(567,).delivery_count'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 182, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 293, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp81rzi7n7/migrations/base/tests/test_mock_crawl.py", line 319, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3227, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3247, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5867, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1106, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1265, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 122, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot()
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 204, in _find_delivery_ids_by_lot
for delivery_ids_set in line.produce_line_ids.lot_id._find_delivery_ids_by_lot().values():
[Previous line repeated 926 more times]
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 197, in _find_delivery_ids_by_lot
move_lines = self.env['stock.move.line'].search(domain)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 1810, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4683, in _search
self._apply_ir_rules(query, 'read')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4464, in _apply_ir_rules
expression.expression(domain, self.sudo(), self._table, query)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 442, in __init__
self.parse()
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 701, in parse
right_ids = comodel.with_context(active_test=False)._search([(path[1], operator, right)], order='id')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4682, in _search
query = self._where_calc(args)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4438, in _where_calc
return expression.expression(domain, self).query
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 431, in __init__
self._unaccent = get_unaccent_wrapper(model._cr)
File "/home/odoo/src/odoo/15.0/odoo/osv/expression.py", line 405, in get_unaccent_wrapper
if odoo.registry(cr.dbname).has_unaccent:
File "/home/odoo/src/odoo/15.0/odoo/__init__.py", line 104, in registry
return modules.registry.Registry(database_name)
File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 61, in __new__
return cls.registries[db_name]
File "/home/odoo/src/odoo/15.0/odoo/tools/func.py", line 71, in wrapper
return func(self, *args, **kwargs)
RecursionError: maximum recursion depth exceeded
```
closesodoo/odoo#80606
X-original-commit: acceb903b0487987edd5da9ce343c0f6c3ff44d8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Clean the code for onchange method with putaway rule applied, merge
them into one onchange method.
Task-2614519
closesodoo/odoo#80519
X-original-commit: 5f562895c4d2f9beac7e0458fcee493b0141f1af
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
When applying putaway rules, the qty of all existing assigned SM lines are
summed to calculate the incoming qty of the product to determine if the
capacity has been or will be met. When a SM - that a putaway rule will apply
to - is created, then it will have its SM lines included in this calculation when
it shouldn't. In this case, we need to ignore the qty of those lines
Task-2614519
X-original-commit: 14738c7e5ecfba81e7ccbd401e1204d3bac960aa
Part-of: odoo/odoo#80519
Now when apply putaway rule on a package with package type, we calculate
the weight of the package according to the product in that package
instead of using the max weight of the package type.
Task-2614519
X-original-commit: 0281ebec36dbb9effd3d2913c0d38c88f9f19920
Part-of: odoo/odoo#80519
Package won't have a company_id untill the move is validated.
Previously, the package_type_id on package has the check_company to be
true. This forbiden any package type with company_id to be used on a not
validated package. In this commit, we remove check_company to avoid
this.
Task-2614519
X-original-commit: 66cbccb15368713ef04d2ba0f9e8808b72557b41
Part-of: odoo/odoo#80519
Previously when apply putaway rule, we only count the packages in the
location to check if there is enough space the incoming package. Now we
also count all other assigned incoming packages to that location to
avoid overflow.
Task-2614519
X-original-commit: 21373dbc507e57c3a19b415583a5b0595a66c1a3
Part-of: odoo/odoo#80519
When apply a putaway rule to find a putaway location, we only pass the
product and/or package info to _get_putaway_location. This is not
enough since the putaway rule can also be applied to packaging.
X-original-commit: 9f339938aec075c5385dca349dfc6a7c2d43b6ad
Part-of: odoo/odoo#80519
Put in Pack won't trigger any onchange to use putaway rules. In this
commit, we apply putaway rule in Put in Pack when only one move line
is put in pack. We also check if the ml to put in pack are all in same
package type, if so, we set that package type on the package.
Task-2614519
X-original-commit: 023b69ac2ccac2456bcb1a8b1b66b468e213b86a
Part-of: odoo/odoo#80519
Yannick Tivisse