**Current behavior:**
When adding an unplanned move line to a transfer in barcode, if the line is added to an existing move which is a subcontract transfer, it will not take the subcontract location as its source location value. Rather, it will use whatever value is defined on the picking.

**Expected behavior:**
Use the more precise location defined on the move rather than the picking.

**Steps to reproduce:**
1. Create a product with a subcontract BOM

2. Create a receipt for that product from the subcontractor

3. Open the transfer in Barcode and manually add another line for the same product -> validate

4. In the receipt form, look at the move lines (detailed operations) and group by location to see the discrepancy

**Cause of the issue:**
When creating a move line here, it does not initially get a `move_id` value. Later when the move is written to the line, we would not generally want to override whatever value is on the line already because it (normally) is more precise/was purposely changed later than what value is on the move.

**Fix:**
In the case of lines which are created and then linked to a subcontract move, take the `location_id` of the move rather than whatever value is on the MoveLine.

opw-4007423

Forward-Port-Of: odoo/enterprise#68032

Before this PR:
There are two problems: first, if you have a line discount like this:
<img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55" src="https://github.com/odoo/enterprise/assets/382893/7564b133-c6e9-4bab-97f3-d8a0a2634fe5">

The calculation made by Odoo is: 319319 * 21.35 / 100 = 68175 which does not match the amount placed in "DescuentoMonto". In this case, it is 68173 (difference of 2 CLP) which is why it is better to prioritize the discount amount instead of the percentage in the XML, which is already rounding, leading to a problem.

The second: if you have a surcharge in the line, like this:
<img width="354" alt="Captura de pantalla 2024-03-27 a la(s) 09 52 40" src="https://github.com/odoo/enterprise/assets/382893/5a7ffa96-a2d9-498f-acf3-7003c95aa789">

Odoo ignores it.


After the PR:
The first issue is fixed by giving priority to the "DescuentoMonto" tag. 
The second issue is added as an improvement.
Since Odoo does not have a column to show the surcharge separated in the line, we are taking advantage of the feature that supports negative discounts in the line to put that surcharge as negative.

Forward-Port-Of: odoo/enterprise#65842
Forward-Port-Of: odoo/enterprise#59532

**Current behavior:**
Having a batch transfer with 2+ delivery pickings, opening the choose package wizard and filling out the package type will not accurately display the shipping weight for the whole batch.

**Expected behavior:**
The weight displayed on the wizard form should reflect the weight of the package plus all product that will be put inside it from the batch.

**Steps to reproduce:**
1. Enable packs in settings, create a package type with a base weight of 1 unit and some product with a weight of 1 unit

2. Create two delivery transfers with some carrier (e.g, local delivery) each with 1 of the created product

3. Add the two pickings to a new batch, on the batch click the `Put in Pack` button and select the created package type

4. Observe that in the form, only one of the products from the batch transfer has been used to calculate the shipping weight

**Cause of the issue:**
In `shipping_weight`'s compute function in the
`ChooseDeliveryPackage` wizard, we don't account for a batch package (like what is done in `action_put_in_pack()` defined on this wizard). Thus, one of the move lines in the batch is not used in the weight calculation.

**Fix:**
Look at the context to see if the user is packing a batch and if so, get all the involved move lines from it.

opw-4077546

Forward-Port-Of: odoo/odoo#177952
Forward-Port-Of: odoo/odoo#177022

Stock quants are not meant to be duplicated. This commit ensures that it is not possible to copy such records.

opw-4035690

(cherry picked from commit 044210f6c7c4e539b8ebd41082c737e8bc91fd4e)

---

In PR https://github.com/odoo/odoo/pull/172376 it was decided to not completely forbid quant duplication due to potential third party modules that could potentially use this feature.

However, we see an increment of customer with an incorrect quantity in past history, or a discrepancy in valuation and accounting because of this error.
Unfortunately, it is incredibly easy to duplicate the quants by mistake, for example by miss-clicking when trying to export or update the inventory qty to 0 ...

![image](https://github.com/user-attachments/assets/ef74c5fa-16f4-4532-a5ac-686c32056f29)

Hence, even if it breaks some third party modules, it is imperative to prevent further quants duplication.

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

Forward-Port-Of: odoo/odoo#177796
Forward-Port-Of: odoo/odoo#177584

**Description of the issue/feature this PR addresses:**
There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Steps to reproduce:**

1) With a database in v16 onwards, install the account_check_printing module.

2) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal bank with more than one outgoing payment with "Checks" Payment Method.

3) Go to "Accounting / Vendor / Payments" and create a new payment with journal created on step 1 and "Checks" payment method and confirm.

4) Go to "Accounting" and on "Accounting dashboard" click on "Check to print" on Journal created on step 1 and then a bug with traceback is raised.

**Current behavior before PR:**
There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Desired behavior after PR is merged:**
There is not a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Video/Screenshot link:**
https://drive.google.com/file/d/1r6A3uMkFv2nIDZ1HYJLgj6e18pNH1P67/view

Ticket Adhoc side: 75606
Task latam: 1217

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

Forward-Port-Of: odoo/odoo#168383

To reproduce the bug, follow these steps:

1. Create a new time off type.
2. Create a new accrual plan.
3. Set the "Accrued Gain Time" field to “At the start of the accrual period.”
4. Create a new milestone with a cap.
5. Create a new allocation set its type to accrual then link it to our accrual plan.
6. Set the start date in the past so that the accrued days reach the cap.
7. Create a new leave in the past related to the allocation.
8. Check your balance for a future date in the Time Off app.

Normally, with accrual allocation, we should see the allocation increase. The problem here is that in the future, the
allocation decreases.

This issue arises due to the way the `leaves_taken` field is computed.

https://github.com/odoo/odoo/blob/08a4b9d78addeefde24b189f0066540e0dcee4c4/addons/hr_holidays/models/hr_leave_allocation.py#L215-L220

The value is retrieved from a default dictionary, which is processed based on existing records in the database. When we
attempt to fetch the value using a new instance that only exists in memory, the key returns the default value of 0.

Additionally, if we modify step 7 to set the leave in the future, the accrual value caps out at a level below the
intended maximum. In some cases, if the data-fetching function is called with the same parameters consecutively, we
receive different outputs.

These issues arise because the new record persists as a cache. When we retrieve a new record with the same origin as a
previous call, we receive the previously processed data. This also leads to a problem with recursion in the function
`_get_future_leaves_on`. This commit addresses and resolves these issues.

opw-4040882

Forward-Port-Of: odoo/odoo#174354

Since the rule refactor, additional byproducts are not considered in the post production picking. The problem is when we add a new byproduct, the backend do not add the warehouse_id on the stock move, and without a warehouse id, it was impossible to find a stock rule for it. Now, with the correct warehouse and stock rule, the stock move is added on the transfers.

Testing steps:
---------------------
- go to configuration > settings > enable Multi-step routes 
- go to configuration > warehouses and enable either 2 or 3 step manufacture
- go to configuration > enable byproducts
- create a BOM with some components/byproducts
- create a MO with the BOM above, confirm it.
Now, we can see the 'transfers' button with 2 transfers, one by the components and another one for the final products and the byproducts.
- add a new byproduct with some produced quantity.

Problem:
-------------
No picking for the new byproduct when clicking on the transfer button

Expected behaviour:
------------------------------
The byproduct should be in the list

task: 3982566

Forward-Port-Of: odoo/odoo#170280

- Have an one2may or a many2many on a setting (with some data in them);
- Edit/toggle any setting;
- Click on an action button or navigate to another view;
- On the "Unsaved changes" dialog, select "Discard".

Before this commit, the `discard` function of the relational model,
didn't take into account the initial commands, and replace the x2many
with an empty list of commands.
The issue is that the settings need to be saved (after discarding the
changes) when leaving, throws an action's button. This is done, to
create a res_id, that is most of the time mandatory to perform the
action (see [1])
 So if the `discard` function, empty the x2many, the setting will be
 modified, and the x2many will be emptied.

Now, the `discard` function of the relational model take into account
the x2many initial commands, therefore the x2many setting will stay
unchanged.

[1] : https://github.com/odoo/odoo/commit/9b81ddb993e4d56aba5aae637d160522d3af1d30

opw-4050990
opw-4092267
opw-4100926

Co-authored-by: Aaron Bohy <aab@odoo.com>

Forward-Port-Of: odoo/odoo#178039
Forward-Port-Of: odoo/odoo#177883