Steps to reproduce
- open a record from Contacts app
- from chatter, click `send mail` , open full mail composer
- add a attachment
- schedule a message, by clicking '▼' on send message
- Again from chatter, click on edit the same message
- try to add another attachment

Observation:
A traceback is received

Issue:
Currently, `onFileUploaded` function attempts to get `res_ids` from `data`, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/static/src/core/web/mail_composer_attachment_selector.js#L25-L30

but in case message is scheduled, which is stored in `mail.scheduled.message` ,when editing it we do not have `res_ids` 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/wizard/mail_compose_message.py#L120

instead we have `res_id` field, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/models/mail_scheduled_message.py#L46
hence a traceback is received when trying to json parse a `undefined` value.

Fix:
Adapt the `onFileUploaded` function to consider both, `res_ids` and `res_id`

opw-4839926


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

Forward-Port-Of: odoo/odoo#212960

Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title)

With this change will show "% IVA" when printing in Spanish

### Description of the issue/feature this PR addresses:

Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report

1. Install Argentinean - Accounting module
2. Install Spanish language
3. Log into to one of the demo Argentinean Companys : (AR) Responsable Inscripto
4. Go to the Cutomer invoices menu and select any of the invoices already created in demo data
5. Go to the partner and change the Languaje to Spanish
6. Return to the invoice and print the PDF

### Current behavior before PR:

All the other terms are translated, but not the % VAT column
![image](https://github.com/user-attachments/assets/ba727710-5b15-45ed-83b6-fd285cf37697)

### Desired behavior after PR is merged:

All the terms are correctly translated
![image](https://github.com/user-attachments/assets/233ab5de-f00f-43df-aa24-3517f40cd5c7)


References LATM 1343 | ADHOC 50766
 
---
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: https://github.com/odoo/odoo/pull/206869

Forward-Port-Of: odoo/odoo#214143
Forward-Port-Of: odoo/odoo#213501

**Issue**
Duplicated Profit and Loss reports fail to open and raise an "invalid operation" error when accessed.

**Steps to Reproduce**
1. Install the Accounting module and French localization.
2. Go to Accounting > Configuration > Accounting > Accounting Reports.
3. Duplicate the "Profit and Loss (2024)" report.
4. Navigate to Accounting > Reporting > Profit and Loss.
5. Attempt to open the duplicated report.
6. An error occurs.

**Root Cause**
During duplication, the label field of expressions is altered to include a " (copy)" suffix. Some formula expressions rely on exact label matches (e.g., i_1_2024.balance), so when "balance" becomes "balance (copy)", the lookup fails. This mismatch causes a KeyError when resolving subformulas like line_code.balance, breaking the report evaluation.

**Fix**
Prevent the duplication process from altering the label of expressions. There is no functional need to add " (copy)" to these internal labels, as they are not user-facing and must remain stable for formula resolution to work.

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

Forward-Port-Of: odoo/odoo#212777

The Italian Law requires cash payments to be rounded up to 5 cents (art. 13 del D.Lgs. 231/2007, updated in 2018). The exported XML invoice didn't have any cash rounding lines and so the sum was wrong in ImportoTotaleDocumento. This was happening because cash rounding lines (`display_type == 'rounding'`) were excluded during the export function's computation.

This fix makes the function include `rounding` lines into the computation, making the invoice compliant.

Steps:
1. Activate cash rounding management.
2. Create a `0.05E` cash rounding.
3. Create an invoice with a total that is not rounded.
4. Set up the cash rounding on the invoice:
      Other information > Cash rounding method
   An invoice cash rounding line will be created, the total will be rounded.
5. Generate the XML and download it.
6. The amount in `ImportoTotaleDocumento` tag will not match the total of the invoice.  


Task [link](https://www.odoo.com/odoo/project/967/tasks/4816355)
task-4816355

Forward-Port-Of: odoo/odoo#213337

Currently, an error occurs when finding duplicate transactions in the bank.

Steps to Reproduce:

 - Install the `accountant` module.
 - In `Accounting Dashboard`, click on `Bank`.
 - In Actions, click `Find Duplicate Transactions`.
 - Clear the `Starting Date` field and click save.

`TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'`

This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transactions, it tries to calculate the `prior_date` using `date_from - relativedelta(months=3)` [1]. However, since `date_from` is `False`, this raises an error.

[1] https://github.com/odoo/enterprise/blob/acdba5ecf89ee8920f82e07e16fac2a0f9659b12/account_online_synchronization/models/account_journal.py#L314

This commit ensures that if the Starting Date is empty when finding duplicate transactions, it uses today’s date as the Starting Date.

sentry-6653835511

Forward-Port-Of: odoo/enterprise#87000

Bug:
1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top.

2. Casual loading rate applies to Overtime hours.

Steps to reproduce:
1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week.
2. The created payslip is of correct amount with the standard 40-hours work week.
3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts.

Current behavior:
The total remains 2000 and the computed hourly rate becomes 2000/44=45.45

Expected behavior:
The hourly rate should remain the same 50.
The total should increase to be:
fixed_wage + hourly_rate * overtime hours
2000 + 50 * 4 = 2200

Fix:
1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate.

2.The casual loading rate should not apply to Overtime work entry types.

task-4617681

Forward-Port-Of: odoo/enterprise#83171

### Issue:

Steps to reproduce:
- In the settings enable packagings
- Create a storable product P with Units as uom and a barcode
- Inventory > Configuration > Product > Units & Packagings
- Click on pack of 6 > Packaging Barcodes > New
- Create one for your product with a different barcode
- Go to barcode > Inventory count

#### Issue 1:

- Scan your packaging > It create a line for 1 Pack of 6
- Apply
#### > If you check on the product form you have 1 on Hand unit

#### Issue 2:

- Scan your packaging > It create a line for 1 Pack of 6
- Scan your product > Nothing happens rather than adding one unit

#### Issue 3:

- Scan your product > It create a line for 1 Unit
- Scan your packaging > Nothing happends rather than adding 6 units

### Cause of the issue:

The issue 1 is the most problematic as it introduce corrupted data. The issue has been introduced by Commit 188ad6980222a77168c462cf149cb79bf28ca2e6 where packagings have been merged with uoms. Prior to this commit, scanning a packaging would convert the barcodeData to to be expressed in the uom of the product:
https://github.com/odoo/enterprise/commit/188ad6980222a77168c462cf149cb79bf28ca2e6 The commit came with the additional feature of creating lines refering dirrectly to the packaging, for instance scanning a pack of 6 would create one line: 1 pack of 6. While this behavior make sense in the context of pickings since stock moves can bear different uoms than the product it self, it does not in the context of stock.quant's since the uom of the quant is necessarily the one of the product: https://github.com/odoo/odoo/blob/9f8e9ca2676f5e3ccc34522d444d1f02e2d21f92/addons/stock/models/stock_quant.py#L53-L55 
Now, the issue is that in inventory counts you edit quants via the barcode lines. When the barcode changes are applied in db, we provide the data's to write or create via these lines:
https://github.com/odoo/enterprise/blob/38e0ae75c2cfddfe76535847ff8b67823b0c6419/stock_barcode/static/src/models/barcode_model.js#L920-L928
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/static/src/models/barcode_quant_model.js#L307-L320
which can not provide to the backend the packaging uom in order to convert the related quantities (as it is not a quant field).
In particular, the Command.create and Command.update are simply populated expecting these qties to be expressed in the product_uom.

### Fix:

Converting the barcodeData's quantity in case a packaging is provided will solve all issues since all the save commands will be expressed in the expected uom and since the barcode machinery is already tailored to treat the addition of appropriate qties.

opw-4872894

Forward-Port-Of: odoo/enterprise#87999