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>

To reproduce:

1- Activate dropshipping from settings
2- Create lot tracked product and enable dropship route
3- Add a vendor in product purchase tab
4- Create a SO with the product and confirm
5- Go to generated PO and confirm
6- Go to generated dropship transfer linked to SO /PO
7- Enter a lot name for the product move line validate
8- Go to 'Inventory>Products>Lots/Serial Numbers'
9- Expand the dropshipped product, find the serial number used in dropship
10- Show the 'Transfer To' field if not visible, you will find it empty

Expected:
The 'Transfer To' field should have the last partner the serial was delivered to
in this case the customer in the SO

This commit fixes the issue and adds a test (also imporves the test class)

opw-3225342

closes odoo/odoo#123242

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

Before this change, when a package was unpacked the SQL query into the  method was looking up all the records into the stock_quant table to find duplicate entries. This could lead to severe performance issue on large database. With this change, if the  method is called on a recordset, the SQL query will only try to find duplicate records for records with the same product's ids and location's ids than those in the recordset.

closes odoo/odoo#121839

Signed-off-by: Tiffany Chang <tic@odoo.com>

When _get_rule does not find any rule, it returns False. This
could create some tracebacks as we mostly expect a stock.rule.

It will give:
if False in <recordset>:
Hence a traceback:
TypeError: unsupported operand types in: False in stock.rule()

By applying these changes will resolve this issue.

Sentry-4206998573

closes odoo/odoo#123151

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

In a 3-steps delivery with backorders, when removing the package in the 2nd step, it should be absent from the last step (OUT picking).
However, assigning a package on the backorder of the 1st picking and creating a new backorder reassigns the package to the OUT picking.
Settings: 3-steps delivery, packaging
Steps:
- create a SO of product A for 10 units
- on PICK_1 picking: put 2 units in Done and put in a package, validate, create a backorder
- on PACK_1 picking: remove the destination package for the 2 units, validate, create a backorder
- on OUT picking: the stock.move.line does not have a package
- on PICK_2 picking: put 2 units in Done and put in a package, validate, create a backorder
- on PACK_1 picking: the package was reassigned to the destination package
- on OUT picking: the stock.move.line has the original package that was removed before

This fix ensures that a package can't be assigned on 'done' stock.move.line

closes odoo/odoo#123575

X-original-commit: 863dc77f3034328ee0e85848e7e673b2de0211c9
Signed-off-by: Diez Stéphane (snd) <snd@odoo.com>

Steps to reproduce:
- Configuration -> Settings -> Activate multi-locations.
- Configuration -> Warehouses -> Three-step delivery.
- Generate a three-step delivery (like through a sale order).
- Select either PICK or PACK pickings.
- Print the delivery slip.
- There is a "warehouse address" field with the customer's adress in it.

It makes little sense to display the current warehouse for internal
transfers, as they keep being in the same warehouse after all.
This doesn't impact inter-warehouse transit as in this case, an outgoing
picking is done from one warehouse to the transit location and an
incoming picking is done from the transit location to the other
warehouse.
In both cases the addresses are correctly displayed and didn't use this
'warehouse address'.

opw-3335185

closes odoo/odoo#123509

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

**Summary :**
When using a great decimal precision, forecast_widget shows red
neverthless the available quantity is sufficient.

**Steps to reproduce :**
 - In Settings >> Technical >> Database Structure >> Decimal Accuracy
    - For usage __Product Unit of Measure__, set __Digits__ to **__6__**
 - Create products of type storable :
    - __Test Component__ with a __Qty on hand__ of **__76.6__** Units
    - __Test Product__
 - Create a BoM for __Test Product__, with Quantity set to **__1__** Units
    - Add component __Test Component__ with Quantity set to **__15.32__** Units
 - Create a MO for BoM __Test Product__ with a Quantity set to **__5__** Units
    - Confirm the MO.

**Before :**
Neverthless the __To Consume__ qty is set to 76.6, which is equal to the
__Qty on hand__ of the component, the forecast widget shows red as if
there's an insufficient quantity of the component

**After :**
With help of the Odoo's __formatFloat__ method, we round the data used
in the comparison defining the __willBeFulfilled__.
The forecast_widget now display properly, taking into account the digit
precision setup in the database.

opw-3281588

closes odoo/odoo#123074

Signed-off-by: Tiffany Chang <tic@odoo.com>

The report_stock_quantity model defines a view in its init method
to compute quantity information related to stock. This view
is made of two CTEs and a three-part query separated by UNION ALL.
The first CTE, existing_sm, retrieves the stock_move data
from the database that are later used by the remaining of the query.

One of the where conditions of existing_sm is (m.state != 'done' or
m.date >= ((now() at time zone 'utc')::date - interval '3month')).
m.state != 'done' is translated to m.state <> 'done' by the query planner.
This type of operator has the side-effect of turning off index scan.
Therefore, the scanning of the existing_sm CTE performs a Seq Scan
and applies the where conditions in a Filter node. This can be quite
ineffecient if the stock_move table is big, and if the selectivity
of the m.state != 'done' condition is high enough to theoretically
justify an IndexScan.

To fix that, we take the inverse of m.state != 'done', i.e. an IN cond.
This allows postgres to use Bitmap Scan, which
is usually better under these specific conditions.

E.g. speedup: db with 7M stock_moves, select from report_stock_quantity
with conds for state, date, product_id, warehouse_id, company_id
4.5s -> 2.5s

opw-3288364

closes odoo/odoo#122911

X-original-commit: aad458e5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>

Before this commit, when printing a The picking operation or delivery slip
reports for outgoing transfers, both the delivery and customer address are displayed
showing the same address.

The expected behavior is to have customer address only of there is a commercial
partner behind the delivery address, thus the customer address is hidden
if its not the case.

opw-3289441

closes odoo/odoo#123177

X-original-commit: ca59d082
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ahmed Khalaf (ahkh) <ahkh@odoo.com>

Forward port: https://github.com/odoo/odoo/pull/120965 added in a check
to prevent setting a reserved qty when using an import file.
Unfortunately this field was renamed in saas-15.2 during
https://github.com/odoo/odoo/pull/80434/



Therefore this fix ensures that we check the new field name.

closes odoo/odoo#122892

Signed-off-by: Tiffany Chang <tic@odoo.com>

A new validation was recently added to prevent importing
reserved quantities on stock move lines, to prevent inventory
discrepancies [1]. However, such validation inadvertently introduced
another issue, which is now, if the reserved quantity is not filled with
0, the new validation is triggered.

This commit fixes the above issue by not requiring the reserved quantity
to be provided.

In addition, a typo is fixed in the error message:
"it is not allow" -> "allowed"

[1] odoo/odoo#119201

X-original-commit: 76ad7b7d
Part-of: odoo/odoo#122892

When moving a package, the quant at source location is not
automatically removed

To reproduce the issue:
1. In Settings, enable
   - Packages
   - Storage Locations
2. Create a storable product P
3. Update the on hand quantity
   - 1 x P at WH/Stock in package PK
4. Create a planned delivery D with 1 x P
5. Confirm and reserve D
   - PK should be reserved
6. Validate
7. Open the package
   - Its location is "Partner Locations/Customers", which make sense
8. Inventory > Configuration > ... > Locations, open WH/Stock
9. Current Stock

Error: There is a line with PK. The quantity is 0 but still, it
create some confusion for the user who could believe that the package
is still in WH/Stock

This issue does not occur if the user goes through the product form
and click on the on hand quantity. The "incorrect" quant will not be
there. This is because, when loading the action, we call
`_quant_tasks`:
https://github.com/odoo/odoo/blob/05a7f5c04804423cfc3a833a1b3f0b5eec3fc147/addons/stock/models/stock_quant.py#L296-L300
This method will clean the quants (merge & unlink)

However, in the above case (step 9), the action is defined on XML side:
https://github.com/odoo/odoo/blob/7d4dfeb0e26b387dee312897264a68963f90267f/addons/stock/views/stock_location_views.xml#L24-L26
https://github.com/odoo/odoo/blob/d956e719d43c68abe6210e3136db576aaa6f60b8/addons/stock/views/stock_quant_views.xml#L190-L196


So, we can't make it behave as it does from the product form,
unfortunatly.

As alternative, we can try to call `_unlink_zero_quants` when we are
moving a package (and not `_quant_tasks` for perf matters as, so far,
we will not have any quant to merge)

OPW-3292238

closes odoo/odoo#122768

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

When processing several SMLs at once, the 'same product' policy of a
storage category is not respected

To reproduce the issue:
1. In Settings, enable:
   - Multi-Step Routes
   - Storage Categories
   - Packages
2. Create a Storage Category SC:
   - Allow New Product: same
3. Create two locations L1, L2:
   - Parent: WH/Stock
   - Type: Internal
   - Storage Category: SC
4. Create a putaway rule:
   - When in: WH/Stock
   - Package type: Pallet
   - Store to: WH/Stock
   - Having Category: SC
5. Edit the warehouse:
   - Incoming Shipments: 2 steps
6. Create two products P01, P02:
   - Type: Storable
7. Create a planned receipt R:
   - To: WH/Input
   - Operations:
     - 1 x P01
     - 1 x P02
8. Mark R as Todo
9. Create two packages:
   - 1 x P01 in PK01 (! PK01 must be a Pallet)
   - 1 x P02 in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer

Error: Both packages are redirected to L1. Considering the product
policy of SC, one line should be redirected to L1 and the second one
to L2

To apply the product policy, the code looks at the quants of each
location. But it does not consider the incoming SMLs. Therefore, when
applying the putaway rule to the first SML, it selects L1 (which
makes sense). Then, for the second SML, because it does not see the
first one, it considers that L1 is empty and can be selected, hence
the error.

OPW-3204924

closes odoo/odoo#122742

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

When performing the picking action in the context of savepoint, the env
inside the action can randomly change causing an AccessError which is
caught as UserError (in the current point_of_sale code). Flushing before
calling a method in a savepoint will deterministically avoid this issue.

Note that the weakset used to store environments was modified in #121604
to avoid this kind of issue.

When using a cr.savepoint, the transaction must be flushed but in we
don't have any reference to the env that should be used on the cursor,
meaning that the env is chosen in the list of existing env. This choice
is random because Transaction.envs is using a Weakset.

In some case, the chosen env does not have the correct access right
because the context allowed_company_ids is corresponding to a company
coming from another test, leading to an access error, hidden by the try
except.
Flushing the environment before creating the savepoint will help to
prevent this issue by flushing on a well defined environment.

Note that the weakset used to store environments was modified in #121604
(master)

closes odoo/odoo#121849

X-original-commit: 211f2fce
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Steps to reprodue:
- Create a dropshipped product
- Sell the product to a client with a different language set
- Print the delivery slip

Bug:
delivery slip is currently being printed in the vendor's language

Fix:
Print the delivery slip in the client language when possible

opw-3193015

closes odoo/odoo#122789

X-original-commit: 2604caa305d82b53b6fc6b5f690135d6c715b496
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

closes odoo/odoo#122042

Related: odoo/enterprise#41329
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

It takes 70s to generate a receipt with 2000 serial numbers.

It happens because during the first part of the loop
(model `stock.move.line` in the `create` method).
It will update the initial demand of the move based on the new
stock.move.line and their qty_done.
Writing the initial demand of the `stock.move` will try to reassign
it (useless in our case) and rewrite the same value on its state's field.
The consequence is the invalidatation of the field on
the `stock.move.line` because it's a related to the `stock.move`.
In the second part of the loop, it check the sml state. Since it
was invalidate upper, it recompute it. That prevent a correct prefetch
and cause a performance issue.

We fix it by writing only once the information by move. And it
prevent the recompute later since the state is not write during the
loop.

closes odoo/odoo#121919

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

[FIX] stock: _log_less_quantities_than_expected call _log_activity_get_documents with empty dict and raises error

closes odoo/odoo#121691

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

Steps to Reproduce Issue for single picking:
1. Install Sales, Inventory
2. Create an SO and confirm
3. Go to the transfer, assign the done value to be less than demanded
4. Validate the transfer and cancel the backorder

Current Behavior:
There is no exception error on the SO chatter

Expected Behavior:
An exception error should be logged on the SO chatter

Other Info: When cancelling a backorder for a single picking,
the exception error about less quantity than expected is not logged on the SO.
"process_cancel_backorder" does not call _log_less_quantities_than_expected.
As defined in "process", the exception is only logged when validating multiple pickings at once but
one is to backorder but the other is not.

opw-3222508

X-original-commit: a1dfc58eebd1badc3eea501b23861748b3762d75
Part-of: odoo/odoo#121691

[IMP] stock: unreserve only quantity required if available quantity is less than quantity required when action_done on stock move.

Example:
Now there is this behaviour
Inventory quantity 4
Reserved quantity 3
Available quantity 1
If i do a stock move of 2 pieces, it will unreserve ALL the stock move of the product.

With this PR it will unreserve only the pieces that are required minus the available quantity not reserved , in this case 2 (new stock move) - 1 (available quantity) = 1

closes odoo/odoo#121692

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

Use case: Create an import file for a picking with stock.move.line directly in
it and add some reserved quantity on the stock.move.line.

The import of stock.move.line is not possible directly via a
stock.move.line menu but it still possible on a picking or
mrp.production import. However the create does not expect that
and never reserve the quants. So it result with quant <-> sml
inconcistencies in the data and the error can not reserve more
than you have in stock.

opw-3277938

closes odoo/odoo#120974

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

This issue only occurs on Firefox because ´has´ is not supported
and the following rule is not applied:
https://github.com/odoo/odoo/commit/2cd0106e63785dd34553c2b4747d72b93b9a7afd



Anyway, there is an existing css rule that is applied if the field
class is correclty added.

Steps to reproduce:
- Open Sale
- Add some content in the sale order line

opw-3201461
opw-3285854
opw-3266130
opw-3244581

closes odoo/odoo#121182

Signed-off-by: Pierre Paridans (app) <app@odoo.com>

Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”

Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered

Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.

opw-3300559

closes odoo/odoo#120969

X-original-commit: a6666de7
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

Steps to reproduce:

- Install purchase, inventory and manufacturing.
- Now create a subcontractor, with it's corresponding location, it's set
by default.
- Go to this new location and set it as replenishment location.
- Now create a Request for Quotation using this subcontractor.
- We will receive a traceback whent trying to access replenishment.

Issue:

We got a traceback caused by the fact that we are trying to set
as replenishment location, a location that doesn't have a warehouse.

Solution:

We need to add the handling of this case, so we won't always need
a warehouse for the orderpoint.

opw-3164276

closes odoo/odoo#113361

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

During the OWL refactoring of the reception report, the "Print" button
was hardcoded to only work for pickings. Unfortunately this means the
button did NOT work when the report was opened for a MO.

This is due to the report printing being dependent on the report's
context values which can either be `default_picking_ids` or
`default_production_ids` (and this is by design to avoid additional file
extensions to handle both cases).

When this button was used in the previous legacy_web_report's
client_action, the entire action's context + data used to be passed as
part of the Print action:

https://github.com/odoo/odoo/blob/30fcb2e60fed17a473353b21bac4916e9ab77b10/addons/stock/static/src/legacy_web_report/client_action.js#L109-L119

The `data` and `context` is then stringified and added into the
reportURL:

https://github.com/odoo/odoo/blob/30fcb2e60fed17a473353b21bac4916e9ab77b10/addons/web/static/src/webclient/actions/action_service.js#L1042-L1050

But passing of the data isn't necessary in this case, and most of the
context's content is not needed since the backend is still receiving +
apply the current user's context thanks to the action_service:

https://github.com/odoo/odoo/blob/30fcb2e60fed17a473353b21bac4916e9ab77b10/addons/web/static/src/webclient/actions/action_service.js#L1079

always providing it to the backend

https://github.com/odoo/odoo/blob/30fcb2e60fed17a473353b21bac4916e9ab77b10/addons/web/controllers/report.py#L87



Therefore, to avoid an extra long report URL of all of the report's
data/context, this fix has been designed to capture only the necessary
context value and manually build the print URL accordingly.

Noticed during task: 3046178

closes odoo/odoo#119954

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

In the case of draft pickings/MOs, the reception_report_main
component's "Assign All" button was NOT disabled, which could result
in an IndexError if the button was pushed. Note that this issue does not
occur for the "Assign All" button within a table because the button is
correctly not shown at all when there are no assignable lines within it.

Noticed during task: 3046178

Part-of: odoo/odoo#119954

Steps to reproduce:
- activate Reception Report in settings
- create outgoing picking for a product (qty > qty in stock)
- create an incoming picking for the same product with a non-int qty
- confirm the incoming picking + click on "Allocation" smartbutton
- assign product to outgoing picking + click "Print Labels" (either at
  top of report or within the table of outgoing moves)

Expected result:
Labels and created + printed

Actual result:
ValueError because int() is called on a non-int value within the label
template

Note that the the `onClickPrint` within the reception_report_line.js
already correctly did the Math.ceil rounding on the qty

Noticed during task: 3046178

Part-of: odoo/odoo#119954

	Currently `report.stock.quantity` has a field defined in it called `move_ids`:
	`move_ids = fields.One2many('stock.move',readonly=True)`

	This virtual field has no corresponding inverse field so when performing a search_read on the model, it fails
	in fields.py when trying to do:	`inverse_field = comodel._fields[inverse]`

	In addition, this field is apparently not used anywhere in the source code and not queried in the SQL View.

	This means the model can never be search_read by default.

	Since this field is never used, it isn't stored, and the model is `_auto = False`, removing it won't break any database.

closes odoo/odoo#120696

X-original-commit: e3b1a887
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>