Issue:
============================
There is a missing synchronization between the stock move line and stock move
for manufacturing orders, by-products, and batch transfers. When clicking on
the list icon and making changes in quantity in the detailed operation modal,
the updates are not properly reflected.

Resolution:
============================
For manufacturing and by-products, add a "quantity" field in the 'detailed 
operation' view so that whenever the save button is clicked, all fields are 
updated properly. For batch transfers, save '_parentRecord' instead of
'model.root' when the save button is clicked.

Steps to Reproduce:
============================
1. Install the mrp and stock modules.
2. Navigate to the stock module.
3. For manufacturing, go to the manufacturing menu inside operations.
   For by-products, go to the by-products tab inside the manufacturing order
   form view.
   For batch transfers, go to the batch transfer menu inside operations.
4. In the form view of each, open the modal (Detailed Operations) and modify
   the quantity.
5. Notice the lack of synchronization between the stock move line and the
   stock move.

Expected Result:
=============================
After implementing the solution, changes in quantities should be synchronized
between the stock move line and the stock move in manufacturing orders,
by-products, and batch transfers. When clicking on the list icon, the
quantities should be updated accurately, reflecting any changes made.

Task: 3815521

Forward-Port-Of: odoo/odoo#160095

Steps to reproduce the bug:
- Create a storable product “P1”
- Go to Operation Type > Return > Enable "Create repair from return"
- Create a delivery order with one unit of "P1" and validate it
- Return the delivered "P1"
- Create a repair order from this return
- Select "P1" as the product to repair
- Save (important step)
- Add any product as a part of the repair, e.g., "Part 1”
- Save
- Go back to the return picking

Problem:
The product “Part 1” is linked to the return-picking.

When the "repair" button is clicked to create the repair order,
the function `action_repair_return` is triggered, adding
`default_picking_id` in the context to link the repair to the picking.
https://github.com/odoo/odoo/blob/bee32f88d42d9b945ec7216e2496e0167d3904b4/addons/repair/models/stock_picking.py#L40

However, this context is not cleared after the creation of the repair,
therefore, when creating the stock move, this picking is added to the
values of the moves due to the `_add_missing_default_values` function.
Despite attempting to set `default_picking_id = False` for these moves,
this will be ignored because the field `picking_id` is not present in
this list view.

**Solution:**
Using `default_picking_id` in the context to create the repair order
does not seem to be a good idea. This is the third issue related to this
problem; two other fixes have already been made to address the
propagation of these default keys. Therefore, it seems more logical to
use the `default_get` function instead to avoid bugs related to this.

https://github.com/odoo/odoo/commit/e822ec35c37237a9c137771d1d7266188a1877e8

https://github.com/odoo/odoo/commit/a32fb7b3e12ddae1ef7ebd78fa4877b2dbdbe6b1

opw-[4029460](https://www.odoo.com/web#id=4029460&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#172786

Before this commit, when calling `_getSaveLineCommand` to get the save commands for the move lines, we do each line one by one, in the order where they were marked as to save, which means we can have an update command followed by a create command, itself followed by another update command for example.

In the module `stock_barcode_picking_batch`, we add the test `test_barcode_batch_scan_lots`. In this test, we got a situation where we will write on the batch a command like that:

```python
{
    'move_line_ids': [
        [UPDATE command],
        [CREATE command],
        [UPDATE command],
        [CREATE command],
        [CREATE command]
]}
```
The 2 first commands are for the move lines in the first batch's picking. The 3 last commands are for the move lines i the second batch's picking.

The issue is, the first CREATE command won't happen. The two move lines for the second picking will be created but the move line who should be created for the first commit will not.

It fails because the compute has a depends on himself. And it's recomputed on picking_ids that have a different cache than the batch. So the second UPDATE will trigger the compute that will rewrite the move_line_ids fields and cancel the first CREATE. So it means every CREATE commands before the last UPDATE will be ignored

Enterprise PR: odoo/enterprise#65182

Forward-Port-Of: odoo/odoo#173521

Currently, when using a company with french localization, if you try deleting lines on a draft order in the session, a new line is created to make the correction.

Steps to reproduce:
-------------------
* Switch to a company with french localisation
* Open Pos shop session
* Add products to the cart
* Go to the backend
* Go back to the session
* Try deleting a line
> Observations: A new line is added with negative quantity to cancel out the line we wanted to delete. Instead of just removing the first line.

Why the fix:
------------
The line correction of the POS certification for the French localization is too restrictive. The law says that correction on validated orders should be made on new lines. For the order that are not validated, the lines can be changed normally.

This is a backport of what will be merged in master as it is a compatible change in stable versions.

This should not break the inalterability chain as you only pass through the functions `disallowLineQuantityChange()` and
`can_be_merged_with()` with orders that are not locked (i.e. they have not been paid yet).

Related ongoing task-id: 3874373

opw-3865724

Forward-Port-Of: odoo/odoo#165468

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, configure a separate discount account for invoices
- Create an invoice:
  * Customer: [any]
  * Currency: [a foreign currency] (e.g. EUR)
  * Invoice Lines: [Price: 100€ - Discount: 50%]
- Check the "Journal Items" tab => Amount in currency for the receivable account and the discount account should be 50. Debit and credit should be the corresponding amount in the currency of the company.
- Change the currency of the invoice to the currency of the company
- Save the invoice

**Issue:**
When the currency is changed, all the amounts in currency are simply converted to the currency of the company.
Upon save, the "payment_term" line is recomputed to match with the values on the invoice lines, resulting on an amount of $50 for amount in currency, debit and credit. Which is correct.
However, the recomputation doesn't occur for the discount lines, resulting to an incorrect discount amount.

**Solution:**
Recompute the discount lines if the currency rate is changed.

opw-3881661




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#173692

Steps to reproduce:
-------------------
1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan)
2. Create again a new analytic plan and set its parent to the one you have created in step 1.
3. Create a new analytic account linked to the plan you have just created in step 2.
4. Create a new project and a new task
5. Link the analytic account you have created in step 3. to the task
6. Create a new timesheet linked to the task
7. In Accounting > Analytic Items, the analytic account of the timesheet will not be reported in the plan you created in step 2.

Fix:
-------------------
The 'Projects' plan (the default one) represents the 'account_id' field of analytic.account.line, other plans have names with the following format: 'x_plan{plan.id}_id' (they are fields created on the fly).
When creating a timesheet we were always setting its account.analytic.account to the 'account_id' field by default and ignoring the other plans.
The fix we propose is to look at the top-level plan of the account.analytic.account of the timesheet being created or modified, and link it to the plan it belongs to.
Note that we keep the 'account_id' ('Projects' plan) updated even if the account does not belong to this plan because this field is used in other parts of the code.

Linked PR: https://github.com/odoo/odoo/pull/139225

task-3820916

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#162213

**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings**
> How to reproduce:
> - Create a product tracked by lots and set a barcode for this product;
> - Create a receipt for this product, with at least 2 quantities and confirm it;
> - Create a second similar receipt (you can duplicate the first one) and confirm it;
> - Add these two receipt in a new batch and confirm the batch;
> - Go in the Barcode App and open the batch, you should have two lines, one for each picking;
> - Scan the product -> the first line should be selected;
> - Scan a lot -> the lot is set on the first line and its qty is incremented;
> - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue.
> 
> Expected behavior:
When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed.
To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. 

**[FIX] stock_barcode: increment right qty**
> When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity.
That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore.
> 
> How to reproduce:
> - Create a product tracked by lots and set a barcode;
> - Update the quantity on hand for this product like following:
>   - 3x lot1
>   - 3x lot2
>   - 3x lot3
> - Create a delivery for 6x this product and confirm it;
> - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have:
>   - 0/3 lot1, [+3]
>   - 0/3 lot2, [+3]
> - Scan lot1 one time and lot3 three times, you now have:
>   - 3 lot3, [+1]
>   - 1/3 lot1, [+2]
>   - 0/3 lot2, [+3]
> -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity.
> 
> To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity.

task-3688770

Forward-Port-Of: odoo/enterprise#65182
Forward-Port-Of: odoo/enterprise#54589

…invoices

Steps to Reproduce on Runbot:

1. Set up AvaTax in Accounting settings
2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)”
3. Go to “Tax Groups” and for the record called “Tax 15%”, add “Test” to the field called “Preceding Subtotal”
4. Go to the Product Category called “All” and choose any selection for the field called “AvaTax Category”
5. Make an invoice and add the fiscal position named “Automatic Tax Mapping (AvaTax)”
6. Save then print the invoice. Notice on the printed invoice that above the box called “Total”, the box called “Untaxed Amount” shows up with no tax box.
7. Uncheck the “Use AvaTax API” field for the fiscal position named “Automatic Tax Mapping (AvaTax)” (This step is basically the inverse of step 2)
8. Print the invoice again and notice this time that the box will instead be called “Test” (which we set in step 3) and that a box showing the tax amount will show up.

This commit fixes the issue so that the value in "Preceding subtotal" is shown for printed Avatax invoices too.

opw-4027280

Forward-Port-Of: odoo/enterprise#66932

**Steps to reproduce:**
- Install Accounting, Sales, l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create a SO:
  * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
  * Order Lines:

       Product   |   Quantity   |   Unit Price   |   Taxes
    ---------------|----------------|----------------|----------
      Product A  |     1.00     |     1000.00    |    16%
      Product B  |     1.00     |     1500.00    |    16%
      Product C  |     1.00     |     3000.00    |    16%

- Confirm the SO
- Create a 90% down payment
- Confirm down payment and generate CFDI via "Send & Print" button
- Create a regular invoice for the remaining amount
- Confirm the invoice and generate CFDI

**Issue:**
The verification of the CDFI fails because there is one line with a negative base amount.

**Cause:**
The down payment line has a negative amount.
This negative amount is dispatched between the other lines and the "base" and "importe" values of these other lines are recomputed depending on the amount that is deducted from it.
However, the computation is based on a ratio computed from the price subtotal of the negative line, but the ratio is then applied to the remaining "base" amount of the negative line, which decreases for each deducted line.
This generates incorrect values in "transferred_values_list" field for the the second line and the following ones on which some amount is dispatched.
The issue only happens on the last line on which some amount has been dispatched because it receives the remaining amount that is too high due to the values deducted by the other lines being lower than what it should has been.

**Solution:**
The ratio should be computed from the remaining "base" amount of the negative line.

opw-4033979

Forward-Port-Of: odoo/enterprise#66715