There is code to block the UOM changing if there are done moves.

Because it searches in non-sudo mode, it does NOT currently
stop you changing the UOM if the product has moves in a different
company.

closes odoo/odoo#134807

X-original-commit: 42674464
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

Steps to reproduce:
- Enable multistep routes (3 steps delivery)
- Create a new storable product (0 on hand quantity)
- Confirm an SO with that product

Bug:
forecast button is correctly red on the SO line but it's green on the
stock pickings

Fix:
button should be green if it's possible to reserve quantity red otherwise

opw-3440627

closes odoo/odoo#134841

X-original-commit: 0312c1bdc371e5a841b8d9e620c9fd7a49782b15
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

To reproduce the issue:
1. In Settings, enable:
   - Storage Locations
   - Package
2. Create a product P
   - Type: Storable
   - Tracked by SN
3. Process a receipt with 1 x P, serial S
4. Return P in a package
5. Process a new receipt with 1 x P, still S as SN

Error: An error is displayed "The serial number has already been
assigned [...]". This is incorrect, the user should be able to
receive that SN.

After step 3, there exists a quant Q1: -1 x P at Supplier Location
with S. Then, after step 4, a new quant Q2 is created: 1 x P at
Supplier Location with S and the package. Because the field
`package_id` is not the same on Q1 and Q2, both quants are not merged.

As a result, step 5, we will update Q1 and have -2 x P at Supplier
Location with S. This will trigger the constraint, hence the error
message.

OPW-3390615

closes odoo/odoo#134727

X-original-commit: 3a501855e65b6e82004d67beeecffe7286cc682b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

When stock is uninstalled, the sequences used in the warehouses for the
picking types are kept. However, since [1], picking types cannot be
duplicated anymore. When the module is re-installed, the picking types
are created with the same name, which is not allowed by [1].

[1]: https://github.com/odoo/odoo/commit/9034602a028fb22fbd139cf41a2f5c71d9d8d032



opw-3484352

closes odoo/odoo#134032

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Company can have multiple warehouses,
when user open replenishment and company has multiple warehouses.
this will lead to below traceback.

Steps to reproduce the error:
- Go to 'Manufacturing' > Configuration > Settings > Enable Subcontracting
- Go to 'Contacts' > Create a Contact > Sales & Purchase >
  Open Subcontractor Location > Enable Replenish Location
- Go to 'Inventory' > Configuration > Warehouses > Create multiple warehouses
- Create a storable product > Create BoM > Set Subcontracting in BoM Type >
  Set already created contact in Subcontractors > Save
- Go to 'Purchase' > Set Subcontractor in Vendor > Add Product > Confirm Order
- Go to 'Inventory' > Operations > Replenishment

Error: A traceback appears:
'ValueError: Expected singleton: stock.warehouse(1, 2, 3, 4)'

https://github.com/odoo/odoo/blob/3864542914efcb9d4e3cabd3cfdeecb842e4f380/addons/stock/models/stock_orderpoint.py#L414


here, we can get multiple warehouses for a company.
So it will lead to above traceback.

sentry-4358838167

closes odoo/odoo#131055

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The error can be raised either when a move is in state done or cancel. However, the error message only says we cannot split split if the move is in done, which can be misleading.

closes odoo/odoo#132389

X-original-commit: 45bab967
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Pedro Nogueira (pno) <pno@odoo.com>

Issue:
======
You can create the same sequence with the same code

Steps to reproduce the error:
=============================
- Install inventory and activate storage locations
- Go to inventory/configuration/Operations Types
- Create 2 operation typs with the following values:
name :any random name , type of Operations : internal transfer,
sequence prefix : test , locations as WH/Stock
- Go to sequences and search for test
- You will have 2 duplicate sequences with the same values

Origin of the problem :
=======================
- Creating an operation type always creates atuomatically a sequences if
  the sequence_code is provided but the sequence_id isn't.

Solution:
=========
Display an error when the name already exist.

opw-3238331

closes odoo/odoo#129394

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce:
- Deliver an SN-tracked product with the Destination Package set (put in pack button also sets this).
- Return that product without setting the Source Package (you can also click "put in pack" which will put the product in yet another pack).
- This already results in two lines with the same SN in the same location, one with +1.00 and one with -1.00 quantity.
- Deliver that product again and put in pack.
- Now there's three lines with the same SN in the same location, two with +1.00 and one with -1.00 quantity.

Bug:
source Package isn't set bydefault when confirming the move_line
we update the stock quantity for that lot_id and Package set to False
the existing quantity has a Package set so it is filtered out and a new
negative quantity is created

Fix:
set the source Package on the return

opw-3179388

closes odoo/odoo#131358

X-original-commit: eb989688ac2db026077d84a3f55321bc6bf44504
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

With this commit you wil have the function _get_gather_domain so you can override and manage the gather_domain by your own logic

closes odoo/odoo#130916

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

On a putaway rule, the "Having Category" condition is not always
respected.

To reproduce the issue:
1. In Settings, enable:
   - Storage Locations
   - Storage Categories
2. Create a Storage Category SC:
3. Create two locations L1, L2:
   - Parent: WH/Stock
   - Type: Internal
   - L2 only:
     - Storage Category: SC
4. Create a putaway rule:
   - When in: WH/Stock
   - Store to: WH/Stock
   - Having Category: SC
5. Create one storable product
6. Update its on hand quantity:
   - 1 product at L1
7. Create a planned receipt R for one product
8. Mark the receipt as Todo
9. Click on 'Set Quantities'
10. Open the detailed operations

Error: The destination location is L1. The putaway rule has been
applied without the storage category constraint: the destination
location should be L2

When applying the putaway rules, we first check if one of the
relevant locations already contains that product. And, if it's the
case, we use that location as destination location. However, we
don't filter out the locations without the correct storage category.
This explains why L1 is found and used.

OPW-3437174

closes odoo/odoo#131189

X-original-commit: 66c11acd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

Steps to reproduce the bug:
- Assume the current date is August 1, 2023.
- Go to general settings:
    - set purchase security lead time: 20 days
    - set manufacturing security lead time: 25 days

- Create a storable product “P1”
    - Routes: Manufacture + buy
    - Manufacture lead time: 1 day

- Create an order point:
   - preferred route: Manufacture
   - Quantity to order: 5
   - Click on “Order once”

Problem:
A manufacturing order is created, but the "Scheduled Date" is incorrect.
Instead of being set to August 1, 2023, it shows August 7th.

The issue occurs because initially, we calculate the `Lead days date`
as follows:
Today's date (August 1st) + manufacturing security lead time (25)
+ Manufacturing Lead Time (1) = August 27th.
However, we use the purchase security lead time (20) instead of the
manufacturing so 27 - 20 = August 7th

To determine the exact date, we call the function
`_get_date_with_security_lead_days`. In which we try to get the
appropriate rule to use. However, in this case, the preferred route
of the orderpoint is not passed as a parameter to the function.
Therefore, we use the first rule of the first route ("buy"), and we end
up using its security lead time.

opw-3439546

closes odoo/odoo#130431

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

To Reproduce
=============
- enable multi step routes
- edit Receipts operation and uncheck the two options under Traceability
- create storable product with Traceability using lot/serial number
- make purchase of this product and receive it in your inventory
- under inventory/reports/Locations click on line of this product
you will be stuck at that page even if you click discard

Problem
=======
There is an inconsistency between the view and backend, as we allow
receiving traceable product without setting `lot_id`, but in view
require `lot_id` if tracking is enabled on product.

Solution
========
following this [comment](https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move_line.py#L558-L560

), `lot_id` shouldn't be required on view.

opw-3422259

closes odoo/odoo#129322

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Following #127245

It happens because `_should_bypass_reservation` has been removed in 15.0
and only exist on the `stock.move` object and not the `stock.move.line`
anymore

opw-3336131

closes odoo/odoo#129054

X-original-commit: 7e917e8713e246811531f9d7c90395242e544057
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.

Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”

The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.

closes odoo/odoo#128929

Related: odoo/enterprise#44299
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

Steps to reproduce:
- Deliver an SN-tracked product with the Destination Package set (put in pack button also sets this).
- Return that product without setting the Source Package (you can also click "put in pack" which will put the product in yet another pack).
- This already results in two lines with the same SN in the same location, one with +1.00 and one with -1.00 quantity.
- Deliver that product again and put in pack.
- Now there's three lines with the same SN in the same location, two with +1.00 and one with -1.00 quantity.

Bug:
source Package isn't set bydefault when confirming the move_line
we update the stock quantity for that lot_id and Package set to False
the existing quantity has a Package set so it is filtered out and a new
negative quantity is created

Fix:
set the source Package on the return

opw-3179388

closes odoo/odoo#126308

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The field company id on stock lot is required but there is not a default
value. The default value should be the current company id

closes odoo/odoo#128621

X-original-commit: 9b216866
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

If `stock_dropshipping` is installed, the "Transfer To" field of a
lot does not work with standard flows

To reproduce the issue:
1. Create a tracked-by-sn product
2. Update its quantity with 1 x SN
3. Deliver SN to a partner
4. Open the list view of lots/serial numbers and enable the column
   "Transfer To"

Error: The field "Transfer To" for SN is empty, it should be the partner

The field `last_delivery_partner_id` is a computed one and the
compute method calls `_find_delivery_ids_by_lot` to get all relevant
information. In this method, we search the SMLs based on a domain
provided by `_get_delivery_ids_by_lot_domain`. If
`stock_dropshipping` is not installed, the method will return a
legit domain:
https://github.com/odoo/odoo/blob/7adc661be1eb426a90842160b2e062446d3ccc03/addons/stock/models/stock_lot.py#L191-L196
However, if the dropshipping module is installed, an override creates
the same domain (directly in the override, without any call to
`super`) and adds a `OR` condition:
https://github.com/odoo/odoo/blob/7adc661be1eb426a90842160b2e062446d3ccc03/addons/stock_dropshipping/models/stock.py#L62-L70


But it contains an error: the `AND` operator is missing, it should be
```py
'&', ('location_dest_id.usage', '=', 'customer'), ('location_id.usage',
'=', 'supplier')
```
As a result, for an SM to be found, its source location usage has to
be `supplier`. This is the reason why, in the above use case, the
lot does not have any `last_delivery_partner_id`: we did not find
such an SML.

OPW-3386247

closes odoo/odoo#128271

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Usecase to reproduce:
- Create and validate a PO + receipt
- Import a file containing a different PO line quantity

Expected behavior:
The PO line is modified and the receipt has the a new move

Current behavior:
UserError asking to modify the quantity done of stock.move.line instead
reserved quantity.

Following commit 76ad7b7d

The purpose is to block import with reserved quantity

It happens because the PO line import trigger the creation of a new
stock.move and reserve it (create the stock.move.line). However since
it's created by the system the data are correct.

There is no issue in multiple step since the internal step requires
the move_orig_ids and thus the product_uom_qty is empty

To fix it:
- Relax the constraint to only consider sml having an impact on quant

opw-3336131

closes odoo/odoo#127888

X-original-commit: 38468d0364519cf90c2546cc4a11b93da195b604
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Traceback due to variable quant not instanciate during import.
It's due to commit a381b6fd

closes odoo/odoo#126852

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Before this commit:
When importing `stock.quant` with two lines with the same product and
different counted quantities, only the last line is taken.

After this commit:
Each line creates a `stock.quant`, even if a similar Quant exists.
The records will be merged at a later time by `_merge_quants`.

Steps to reproduce:
1. Create a storable product
2. Go to Inventory > Operations > Inventory Adjustments
3. Create a file with two lines with the same product,
    and different counted quantities
5. Favourites > Import Records & upload the file

OPW-3340017

closes odoo/odoo#126458

X-original-commit: 45f7368222ead5df600992c66f0da56b3a7e959a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>

Currently the to do filter in inventory transfers doesn't really filter anything.

Steps to reproduce the error :

1- go to inventory/operations/transfers

2- Select to do filter from the sections filters

The reason of the issue is that the domain in the xml file is missing some conditions.

I added the same conditions from the saas-16.2 since it works correctly there.

opw-3376083

closes odoo/odoo#125888

Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>

product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.

opw-3229080

closes odoo/odoo#121262

X-original-commit: ea923a08
Signed-off-by: Tiffany Chang <tic@odoo.com>

The purpose of this commit is to review the responsiveness and spacing
of some settings that were visually broken.

The nested checkboxes were growing too much on smaller screens
making the content overflow.

This commit adapts these checkboxes settings to make them more readable
and consistent.

Task-3113372

closes odoo/odoo#108902

Related: odoo/enterprise#35323
Signed-off-by: Tiffany Chang <tic@odoo.com>

In https://github.com/odoo/odoo/pull/123074

, the fix done did not take the formatting of numbers
bigger (or equal) than 1000 into account.
For example, 1000 become "1.000,00" and parsing it again will return a 1.

To fix this, simply modified the thousandsSep to an empty array

closes odoo/odoo#124963

Signed-off-by: Steve Van Essche <svs@odoo.com>

Steps to reproduce the bug:
- create a new transfer
- Click on new line but leave it empty
- Change operation type

Problem:
A traceback is triggered, because the onchange of picking_type is
triggered, so we try to get the description of each product in each
move. However, since the move does not have a product set,
an error is thrown:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/product.py#L235-L239



opw-3349646

closes odoo/odoo#125010

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps:
1- Duplicate inventory operation - Delivery Order
2- Process new order with duplicate
3- Add products and try to save

Issue:
Traceback

Cause:
The ORM tries to insert a new record of stock.picking but triggers a constraint on unique(name, company_id). When creating a new transfer the name is computed from the sequence of the stock.picking.type but here when we duplicate a stock.picking.type it creates a new sequence which starts with id 1, if the there is already a transfer with uses it the constraints will be triggered. We just have to make the stock.picking.type which are duplicated use the same sequence

Solution:
Enable the copy of the sequence_id so that two ``stock.picking`` from duplicated operation types will never collide on their name.

opw-3331835

closes odoo/odoo#122838

Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

If a user adds a new SM to a picking without any scheduled date,
traceback will appear

To reproduce the issue:
1.  create a new picking and remove the scheduled_date.
2.  try to add a new storable product in move lines.

Error: A traceback appears: "TypeError: '>' not supported between
instances of 'datetime.datetime' and 'bool'"

On the picking form, the default SM date is the scheduled date of the
picking:
https://github.com/odoo/odoo/blob/2c3f53d5a0380e7de27977f56f20307ff2bccabf/addons/stock/views/stock_picking_views.xml#L358


Therefore, in the above use case, when triggering the onchange/compute
methods, the field `date` of the SM will not be defined. At some
point, we need to get the forecasted quantities of the SM product
(see the method updated by this commit) and, to do so, we compare
the SM date with `now`. Since this date is `False`, it will lead to the
above traceback

sentry-3979281197

closes odoo/odoo#124274

X-original-commit: e6179a51
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>