Filtering stock_pickings by selecting the product in the dropdown menu doesn't return anything
Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers
3. In the search field, begin typing the name of a product for which there is a transfer (e.g. Large Cabinet)
4. Click on the small arrow to the left of `Search Product for:` in the dropdown menu
5. Select the product you were typing
6. There is no result to the search even though there are transfers containing the product
Solution:
Remove `filter_domain`
The filter will be handled in the backend by `_name_search` of `product.product`, which already covers the same criteria (`default_code`, `name` and `barcode`)
Problem:
The display name (e.g. "[E-COM07] Large Cabinet") wasn't matched by the `filter_domain` because the domain sent in the RPC was:
```
"domain": [
"|",
"|",
[
"product_id.default_code",
"ilike",
"[E-COM07] Large Cabinet"
],
[
"product_id.name",
"ilike",
"[E-COM07] Large Cabinet"
],
[
"product_id.barcode",
"ilike",
"[E-COM07] Large Cabinet"
]
]
```
OPW-2732804
closesodoo/odoo#84388
X-original-commit: abd951b084422f8083764db3ec4441954cccfad1
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
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>
Usecase:
- Install mrp with demo data
- Log in chicago company
- Go to manufacturing list view
-> Access error is raise due to multicompany rule
It happens because the state.res_ids contains all the mrp.production
even in SF company. So it try to read records in the wrong company
and raise the error.
Instead of doing a read, we change that and do a search_read like in the
classic process using the state.domain. So it filter the wrong records
before reading them
X-original-commit: 2077ee3b9312fc511d8fd5d328b5c4e329d9b784
Part-of: odoo/odoo#83430
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 product has a valid EAN barcode, we would like to include the qty
of the product + its uom in its GS1 datamatrix (dm). There are a lot of
hardcoded values in report in order to fit GS1 standard:
- GS1 UoM codes are ALWAYS 3 digits (to indicate which UoM) + 1 digit
(to indicate number of digits) EXCEPT for Units UoM. Because we cannot
update a dict in QWeb, we check for both whether it's a supported GS1
UoM or a Unit separately rather than 1 general check.
- We hardcode the GS1 units value as '30' in this case (there are 2
options) because the code is specific to qty of a product (not qty of
product within a SSCC GS1 dm, there is a different value for that).
There are some limitations to this implementation due to
incompatibilities between Odoo + GS1, specifically:
- some Odoo UoMs are not included as GS1 UoMs => won't be included in dm
- # of Odoo quantity digits can exceed the number of digits allowed in
GS1 (8 digits for Units, 6 digits for all other UoMs, including
decimal values from rounding precision, e.g. 1 cm with rounding
precision 0.000001 has 7 digits as 1.000000) => won't be included in
dm in this case
- Odoo treats "fl oz" (Volume) and "oz" (Weight) as separate UoMs but
GS1 does not => we only handle weight for now
- Odoo supports non-integer values for Unit UoM but GS1 does not => we
round quantity to an integer value.
Note that implementation includes flexibility for users so they can
add/remove UoMs from the GS1 nomenclature rules as wanted/needed. This
includes user created custom codes (e.g. 90, 92-99 + extra character -
code isn't required to start with these numbers, but it won't be GS1
compliant) to handle UoMs not included in GS1 specifications as long as
they are correctly configured as quantities if user wants to be able to
rescan quantities back in with barcode app and match the 6 digits or
less quantitiy requirement when printing.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
Part-of: odoo/odoo#82389
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
This commit adds a new print menu option for pickings so users no longer
have to click on picking form > Packages smartbutton > switch to list >
select all packages > Print "Package Barcode with Content" to have the
same result.
Part of Task: 2494740
Related ENT PR: odoo/enterprise#23323
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
Two updates:
1. Match the ZPL layout, i.e. remove text centering / horizonal lines.
2. Make layout match 4x12 format (same used by Product Labels). Note
that unlike the Product Labels, we expect the lot labels to ALWAYS be
printed in a 4x12 format (i.e. we keep it simple and contained within
1 template).
Task: 2494740
Part-of: odoo/odoo#82389
Steps to reproduce:
- go to inventory report
- remove the "Product > Location" Group by filter.
Problem:
The buttons “Inventory at Date” and “Create” are like merged together because there is no margin right
opw-2721995
closesodoo/odoo#83453
X-original-commit: a33e04df672658c8306a1052b1db79f233f8c54c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
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>
Fixes a couple of things;
1. Backorder use case when unassigning a move in reception report.
To reproduce:
- Create a Delivery w/ Demand = 8 of a stored product not in stock
- Create a Receipt w/ Demand = 10 of the product
- Assign 8 of product to delivery (don't forget to activate Reception
Report in settings
- Mark 4 of product as done > mark as done > create a backorder
- Open reception report in backorder (shows 6 instead of 4, this is a
known limitation of reception report) + unassign + close report
- Reopen report + assign 4
- Finish the backorder
Expected result: Delivery has 2 moves totaling a demand and reserved
amount of 8
Actual result: Delivery has 2 moves where 1 is fully reserved but the
other isn't and cannot be reserved (even though product in stock).
Issue was due to move split during unassign not taking into account that
the amount being unassigned could be greater than the amount still
assigned (due to backorder amount > demand qty since it doesn't know how
much was done in the original receipt). This would lead to the move
linked to the original receipt's move expecting a greater quantity from
the original move (and therefore not reserving any more quantities.)
2. Trying to unassign from an already done move. (i.e. backordered move
from above unassigned after the delivery is already done) isn't allowed,
so in case of unassigning from a done move, we don't do a split.
3. In case of failure of unassigning, fail gracefully (i.e. don't switch
button status since this is misleading).
Discovered during task: 2662730
closesodoo/odoo#83338
X-original-commit: 3c0c780032ed07da7ec14bdad8df2ff48fc5f4ef
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@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
Several UX improvements:
1 - Add "Unbuild" filter to MOs (1 or more 'Done' unbuilds) + added
Unbuilds smart button to MO form view
2 - When copying an operation across BoMs, it is annoying that it adds
"Copy" to the end of the name, so we remove that.
3 - Display a warning when using an expired Lot/SN in detailed operations
view (burger window + tab).
4 - Allow adding/removing WO Real Duration + add/remove/edit specific time
time tracking (time_ids) for Done, Unlocked MOs.
5 - Allow search WOs by product to manufacture
7 - Fix validation error message typo
Parts 1-5 and 7 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>
*: mrp,point_of_sale,purchase,sale,stock
This commit adds the product tag model access to accurate manager groups.
task-2675384
Part-of: odoo/odoo#79296
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>
First step to stream QWeb templates: removing the two post
processing operations applied on rendered templates. This
should slightly speed up the rendering of every page.
1/ Don't remove empty lines after rendering, but fix the root
cause of: view inheritancies and QWeb compilation that don't
add extra empty lines.
2/ handle page break in the two reports that uses it, rather
than processing every view produced.
closesodoo/odoo#82244
Related: odoo/enterprise#23328
Signed-off-by: Fabien Pinckaers <fp@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 the bug:
- Install inventory and sales
- Create a SO > Confirm
- Click on the delivery > print > delivery slip or picking operation
Problem:
Only the name and phone number are in the report
opw-2697221
closesodoo/odoo#82235
X-original-commit: 35e6abce0e662cae6a55293f31620114ad5ecd8a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
2 issues:
- When going to the report forecast the value of the stock is computed.
However the stock user should not be able to access the valuations
- Since an access error is return the graph view is not instanciate and
the javascript code try to amend an empty result to the DOM. It results
with a traceback on top of 403 page
closesodoo/odoo#82074
X-original-commit: dbc6b1999ad478d0fdb5774624fd50ca4018be22
Related: odoo/enterprise#23185
Signed-off-by: Arnold Moyaux <arm@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>
Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
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
Step to reproduce:
Try to print traceability report
Current Behaviour:
Traceback wrongly generated header
Behaviour after PR:
No Traceback, the header is now correctly generated
opw-2704299
closesodoo/odoo#81673
X-original-commit: 6b567326edc7bc691d87d911759ee30a24a8a1d7
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
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>
Since 6f182eeeab UoM should be created through the UoM category tab as the UoM form view is now unusable.
To ensure that this is the case, we remove menu link to the form view and update the other to lead to UoM category instead.
opw-2702953
closesodoo/odoo#81221
X-original-commit: 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Merlin (megu)