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#121247

X-original-commit: ea923a08
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

closes odoo/odoo#120994

X-original-commit: 92cd7d08
Signed-off-by: Tiffany Chang <tic@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#120947

X-original-commit: a6666de7
Signed-off-by: Djamel Touati (otd) <otd@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#119238

X-original-commit: 1a264d7d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

	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#120416

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

[1] hides the length UoM if the package is related to a specific
carrier (BPost, Fedex, etc). However, there will still be an issue when
the carrier is not defined: if the length UoM of the database is `ft`,
so will the length UoM of the package type. Moreover, the dimensions
fields are integer:
https://github.com/odoo/odoo/blob/b1012175393ca5612899c1a0f1d3803ed8d4fe94/addons/stock/models/stock_package_type.py#L19-L21


As a result, it will be impossible for a user to encode a package type
with a length equal to 10in

[1] 9250accb

OPW-2865471

closes odoo/odoo#119519

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

The current view replaces the existing groups attribute of the inventory
page in the product template form view with two specified groups (with
only one of these groups being newly introduced in stock).

This commit changes the product view to utilise an xpath that adds the
single new group (stock.group_stock_user), instead of replacing the
content of the attributes.

closes odoo/odoo#119223

X-original-commit: 43c888bb
Related: odoo/enterprise#40085
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>

Steps to reproduce the bug:
- Create a storable product “P1”
- Create a purchase order with 3 unit of “P1”
- Confirm the PO and receive the delivery
- Go to inventory > operation > Inventory Adjustments
- Select the “quant” of “P1”:
    - quantity = 3
    - inventory_quantity = 0
- Click on “Apply”
- Apply the wizard

Problem:
The quantity is updated to 0

When the `_apply_inventory` function is called, a move is created and
validated to ensure that the quantity matches its corresponding
`inventory_quantity`:
https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_quant.py#L606-L611

`inventory_diff_quantity` is equal to -3 in this case, since it's the
result of computing `inventory_quantity` - `quantity`, which is (0 - 3).
Since we add a minus sign to `inventory_diff_quantity`, the final result
becomes `3`.

Afterward, we call the `_update_available_quantity` function with a
minus sign as well, so the value becomes -3:
https://github.com/odoo/odoo/blob/e1cea2640fc064a56b0dba4f79e6b8a91a48b4fc/addons/stock/models/stock_move_line.py#L307

As a result, when we add `quant.quantity`, which is 3, the final result
becomes 0 (3 - 3):
https://github.com/odoo/odoo/blob/9d34c72b2c7bc187c5aac771e9e8cbddd7ead5f2/addons/stock/models/stock_quant.py#L635



Solution:
If no inventory_quantity set, ignore the apply of inventory for this
quant.

opw-3268542

closes odoo/odoo#119195

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

If applied, this commit will solve the issue of the singleton when there are 2
quants with the same location and same products but one quant with a lot and
another quant without a lot number.

Steps to produce:
- Create one quant with location-1 and without lot number.
- Create another quant with location-1 but with the lot number.
- Create 3rd quant with location-1 with same lot number as step2.
The error will raise in 3rd step as it is not accepting the 2 quants where one
is with lot number and another is without lot number.

see - https://tinyurl.com/2hqrgmwm



sentry - 4024572562

closes odoo/odoo#116318

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

When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering what was the error.

If a normal user without admin access rights, makes an action that triggers the orderpoints, like confirming a MO, the activity schedule is not creating due to an access error on 'write' operation to a Product Template.

So, all activity schedules triggered from an orderpoint should be created without checking access rights.

closes odoo/odoo#118300

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

Steps to reproduce
==================

- Go to Inventory > Operations > Replenishment
- On the top right, set the pager to 1-1
- Select the only record
- Click on Select All
- Click on Order/snooze

The action is only called for the records in the current page

Cause of the issue
==================

The `getSelectedRecords` function only returns records on the current page
Use the `getSelectedIdsWIthDomain` function

opw-3259642

closes odoo/odoo#118577

X-original-commit: 32962841
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

When in a multi-step manufacturing scenario, if there is more than enough to complete one MO, the forecast shown is wrong as it looks like it is trying to reserve more than once the quantities in stock.

Steps to reproduce:

- Activate multi-step routes and set manufacturing in 3 steps (warehouse settings)
- Create a product (Component) with UOM kg and add 200kg in stock.
- Create another product (Final product) with a BoM.
- On the BoM, set that to manufacture 100 units, 51700g should be consumed.
- Create a MO for 210 units and confirm.
- Check the forecast of the Component.

OPW-3231092

closes odoo/odoo#117455

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

To reproduce the issue:
1. In Settings, enable:
   - Multi-Step Routes
   - Storage Categories
   - Packages
2. Create a Storage Category SC:
   - Allow New Product: same
   - Max Weight: 100 kg
   - Capacity by Package:
     - 2 x Pallet
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 a product P:
   - Type: Storable
   - Weight: 1 kg
7. Update L1:
   - There is 1 x P in a pallet
8. Create a planned receipt R:
   - To: WH/Input
   - Operations:
     - 2 x P
9. Mark R as Todo
10. Create two packages:
    - 1 x P in PK01 (! PK01 must be a Pallet)
    - 1 x P in PK02 (! PK02 must be a Pallet)
11. Validate R
12. Open the related internal transfer T

Error: Both packages are redirected to L2 but one of them should be
redirected to L1

When checking L1, we ensure that the policy 'all same products' is
respected. To do so, we compare the products of the quants of L1
with the given product. Here is the issue: when moving a package, we
don't provide any `product` value to the methods used in the putaway
rules process.

Note: There was also another issue with the 'all same products'
policy. Suppose L1 is empty, and we move a pallet with two different
products, the move line is redirected to L1, which breaks the 'all
same products' condition.

OPW-3204924

closes odoo/odoo#118361

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

To reproduce:
1. Manually create lot "0000001" for a lot product
2. Create a MO for this product and click generate-serial button.
Validation error raised since we are trying to generate lot/sn "0000001"
again.

When useing action_generate_serial, ir.sequence always try create a
lot/sn in form "00000dd". If user already created the same one, the
generation will fail.

We already tried to avoid this issue for sn in _get_next_serial() by
finding the latest sn and create new one base on it.

To fix, we also allow _get_next_serial to be applied to lot.

Part of Tast-3187003

closes odoo/odoo#117143

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

before this commit, on clicking the picking calendar view, it allows the quick adding from the calendar view and entered value is going to the name field of stock.picking model.

after this commit, quick adding will be disabled and on clicking form will be opened with selected date.

closes odoo/odoo#118175

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

Before this commit, in large database, openning a sale.order can take 3s.
Because in module sale_purchase_stock, _get_purchase_order use a On2many field : stock_move_ids, with inverse field group_id.

Now it takes 200 ms.

closes odoo/odoo#114709

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

Steps to reproduce:
- In inventory/replenishement
- edit a line (eg: prefered route) then click on reorder
- the edits are discarded

Fix:
the line is saved only when it gets unselected or manually saved
it more intuitive to also do it when a button is clicked on the line

opw-3125732

closes odoo/odoo#117324

X-original-commit: 8c48d4f2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Steps to reproduce the bug:
- Create a Storable product “C1” tracked by Lot:
    - Update the Qty to 10

- Create a Storable product “P1”:
    - Add a BoM:
        - add 1 unit of  “C1” as component

- Enable 3 steps for the manufacturing operation in warehouse settings

- Create a Mo to produce 1 unit of “P1”:
    - Confirm the MO
    - Click on related transfer:
        - Select the “Pick component”
        - check that the qty is reserved correctly
        - Try to validate it without setting Qty done
        - The immediate transfer is triggered, validate it

Problem:
The backorder's wizard triggers when it shouldn't

To know if we should create a backorder, we check if the qty reserved
is equal to the qty done, and as the qty done was not set correctly
during the validation of the immediate transfer, the two quantities
are not identical, therefore the widget is trigger:

https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_picking.py#L1128-L1132



opw-3240264

closes odoo/odoo#116196

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

On the form of a storage category, the UoM of the weight is
hardcoded. This is incorrect as it could be `lb` thanks to the
option in the Settings

OPW-3204924

closes odoo/odoo#117061

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

before this commit, there is typo in unit of measure

after this commit, the typo will be corrected and
unity of measure will be updated to unit of measure

closes odoo/odoo#116699

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

before this commit, for the company_id field
the user groups given was base.main_company,
such a group is not existing in the system

after this commit, the group will be changed
to base.group_multi_company from base.main_company

closes odoo/odoo#116853

X-original-commit: 59d0f7f4
Related: odoo/enterprise#38903
Signed-off-by: Tiffany Chang <tic@odoo.com>

Step to reproduce:

1. create a product
2. duplicate it and change its translation (but DO NOT change the product name)
3. create a transfer for that new product without a contact
4. print delivery slip

Bug:
the db's product name is used instead of the translated name
(i.e. "original product name (copy)")

FIX:
when partner id is not set in picking, then default to the user's language

opw-3141202

closes odoo/odoo#116527

X-original-commit: 6f9973f4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Steps to reproduce:
-Enable multistep routes for manufacturing
-create a MO for 50 products
-In internal transfers from Stock to Pre-production validate
part of the tansfer (20 units) and create a back order
for the remaining qty (30 units)
-create and validate another pertail transfer (3 units)with a back order
for the remaining quantity (27 units)
-create a return for the last validated transfers

Bug:
the default qty for the return is set to -20 where it should be 3
this commit[1] deducts the previous transfers from the returned amount

Fix:
only deduct returns from current transfer

opw-3104699
[1]:https://github.com/odoo/odoo/commit/7b08f0ae0a39e8f575b21e744de16264b6365704



closes odoo/odoo#115641

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

mrp_operation picking type is not handle by default in stock module get_description function.

Add default return to stock get_description function

opw-3232811

closes odoo/odoo#115488

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

Some users were updating their access rights to allow for direct
deletion of quants. This could lead to the infamous:

"It is not possible to unreserve more products of %s than you have in stock."

error since directly deleting a quant bypasses the flows of correctly
unreserving the amounts you are deleting. Therefore we now restrict
the unlinking to:
- when in sudo mode, since the automatic unlinking of zero quants always
  occurs in sudo mode.
- stock manager when unlink access right = True. Normally we would allow
  any user with the unlink access to do it, but since we are using the
  existing `_apply_inventory` to ensure that reserved qtys of the
  quant are correctly unreserved before the unlinking, only stock
  managers will correctly do this unreservation.

It is expected that some custom code may break due to this restriction,
but if custom code is directly unlinking quants without a sudo or with a
non-stock manager, then the code in these cases probably need to be
fixed anyways since this will cause inconsistent db data and lead to
the error above.

closes odoo/odoo#114991

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

Due to the domain dependancy of `product_uom_id` on
`product_uom_category_id`, a JS error was occurring since the field
wasn't available in the view.

Steps to reproduce:
- create a scrap
- select scrap in list view
- try to edit the UoM

Client Error occurs instead of allowing user to edit the UoM.

Fixes: odoo/odoo#92800
Part-of: odoo/odoo#114991

"Non-stored fields like product.template.location_id/warehouse_id cannot
be searched" log error is generated because the non-storable fields are
not searchable, so it shows a log error for those fields.

This commit added the blank filter_domain in the above fields to avoid
the log error in search.

This fix is for the "product.product" search view for the "product.template"
search view has already been fixed in https://github.com/odoo/odoo/commit/a5835a160ea3f7aea37644ed4e1a49e2e4a6effd



sentry-3933983991

closes odoo/odoo#115382

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

Steps to reproduce:
- enable PICK + PACK + SHIP
- in Inventory/Configuration/Operations Types
- check print label in PACK

Bug:
print label is already enabled by default in the SHIP Operation
and it's not possible for the user to edit it.

Fix:
allow the user to disable print label on the SHIP Operation

opw-3085428

closes odoo/odoo#115038

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

How to reproduce:
- Create a tracked product;
- In the receipt picking type form view, for the lot and serial numbers,
  uncheck "Create New" and "Use Existing ones";
- Create a planned receipt for some of this tracked product;
- Confirm and validate the receipt:
  It opens the "Immediate Transfer" wizard;
- Apply the immediate transfer:
  -> It asks if you want to create a backorder.

Since the picking type doesn't use new or existing LN/SN, it accepts to
be confirmed even if some move lines for tracked product have no
tracking numbers.
The issue was, when a `stock.move` sets its done quantity to its
reserved quantity, if its product is tracked, it doesn't change its done
quantity if it has no tracking number, regardless the picking type's
configuration.

OPW-3186155

closes odoo/odoo#114831

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

Backport of cbeab103342 to speed up MOs confirmation when
producing lots of quantity and when at least one component
is tracked by Unique SN.

closes odoo/odoo#112565

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

Current behaviour:
If you have a confirmed SO, with a `sale.order.line` that has a
`product_packaging_id`, and you write a new `product_packaging_id`,
the "Delivery Order" has 2 lines, 1 move with the old qty and the old
packaging, and another line with the difference of qty and the new packaging.
Same behaviour is present on purchase side.

Expected behaviour:
If you have multiple `stock.move.line` from the same `sale.order.line`,
they should be able to merge, when you changed the `product_packaging_id`.
Ex: If you edit an SOL from 1 pack of 10 to 1 pack of 20, we should have
1 move line with qty 20 in packs of 20, instead of 2 lines, one with qty 10
in packs of 10, and another line with qty 10 in packs of 20.
Same behaviour is expected on purchase side.

Steps to reproduce:
- Install Sales and Inventory
- Activate "Product Packaging" in Settings
- Create a new product with 2 types of packaging
  - PackOf10 with quantity of 10
  - PackOf20 with quantity of 20
- Create a SO with a new line that product, quantity 10
- Confirm the SO
- Edit the SOL with 1 pack of 20 (`product_uom_qty`=20)
- The "Delivery Order" has 2 lines, instead of 1 with the new packaging

Reason for the problem:
When saving the SO/PO, a new `procurement` is created which will create
a new `stock.move.line` with the new packaging. This will prevent the
lines to merge correctly, because they have different packaging.

Fix:
When writing the `product_packaging_id` on a `sale.order.line`/`purchase.order.line`,
we directly write the package on the `stock.move.line`,
before any `procurements` are created, so the generate move lines
can correctly be merged.

Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master

opw-3002612

closes odoo/odoo#107223

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

2-steps delivery. If there is already a backorder for the picking
out->customer, when decreasing the SOL qty, an unexpected picking
will be created

To reproduce the error:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
   - Outgoing: 2 steps
3. Create a storable product P
4. Update the on hand qty:
   - 10 x P at WH/Stock
5. Create and confirm a SO with 10 x P
6. Process the pickings with 6 x P (with backorders)
   - There should be 4 pickings
7. On the SO, decrease the quantity to 7

Error: an unexpected picking (customer -> out) is created for 3 x P

Step 6, when creating a backorder for 4 x P from out to customer,
we split the initial SM, and we force the `procure_method` to
`make_to_stock`
Step 7, when decreasing the qty, we create a negative procurement
and run the rules' system. Because of warehouse configuration, the
rule that links output location and customer one is based on an MTO
logic: the SM for -3 x P has the `procure_method` set to
`make_to_order`. As a result, that move will not be merged with the
one created during the split (step 6) and we will create the
unexpected picking for the move.

The SM generated by the split should keep the same procure method
logic as the initial one.

OPW-3141387

closes odoo/odoo#114686

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