…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

## Issue:
- When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number.

## Steps To Reproduce:
- Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity.
- In the barcode app, adjust the inventory by adding the created product and then save the changes.
- Click on the small pen icon to modify the product's details.
- Observe that when adding the quantities with decimal values, they get rounded up to the nearest whole number.

## Solution:
- In the `_increment` function, when the initial `value` is not a decimal (it does not contain a '.'), the fraction variable is not set, and the rounding defaults to 0. It's important to note that this issue does not occur when the `value` is a decimal, as the split function operates correctly.
- To resolve this issue, instead of relying on the number of digits after the '.' in the `value`, we set the precision based on what is defined in the 'decimal.precision' model. This approach not only addresses the current issue but also resolves the underlying problem initially discussed in this PR https://github.com/odoo/enterprise/pull/53378

opw-3896929

Forward-Port-Of: odoo/enterprise#66535
Forward-Port-Of: odoo/enterprise#62505

**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

Fiscal position using 2 taxes including in price are not working in PoS. If you use the fiscal position only the tax should change, not the total price, as both tax are included in price.

Steps to reproduce:
-------------------
* Create two taxes that are included in price
* Create a fiscal position matching those 2 taxes
* Create a product using the first tax
* Open PoS session, and add the product to the order
* Price should be for example 100€
* Now change the fiscal position to the one you created
> Observation: Price of the product changed when it shouldn't have

Why the fix:
------------
When computing the price of the product with a fiscal position, if the previous tax is included in price and the new one is also included in price, the price of the product shouldn't change. So instead of recomputing the price of the product with the new tax based on the previous tax excluded price. We just use the price of the product

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

Forward-Port-Of: odoo/odoo#172487
Forward-Port-Of: odoo/odoo#169223

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#173728
Forward-Port-Of: odoo/odoo#165468

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

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