Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

Forward-Port-Of: odoo/enterprise#95982
Forward-Port-Of: odoo/enterprise#94438

Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits

      - Basic:
      Salary Structure Type: US Employee
      Contract Related Field: Health Benefits Dental
      Display Type: Slider (1500, 6000)      
      - Housing:
      Salary Structure Type: US Employee
      Contract Related Field: Health Benefits Vision
      Display Type: Always Selected
      
      - Transport:
      Salary Structure Type: US Employee
      Contract Related Field: Health Benefits Vision
      Display Type: Manual
      Mandatory Benefits: Basic, Housing

3. Go to Employees > Contracts
4. Create a new contract:
   Set an employee
   Salary Structure Type = US Employee
   HR Responsible = Mitchell Admin

5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders

Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`

Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.

Solution:
Add a guard to check that target is not empty before accessing its elements.

opw-5058994

Forward-Port-Of: odoo/enterprise#94881

**PROBLEM**
Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg).

**STEP TO REPRODUCE**
1. create a product.
2. create a bom with:
 - a component tracked by lot, with kg as product uom, but g as the bom uom.
 - create a step, during which 50g of the component is consumed.
3. create two lots of the component, with 1kg each.
4. create a MO for the product with the bom.
5. in the shop floor, try consuming the component and select one of the lot as a source.
6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove).
7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g).

**CAUSE**
1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant.
2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g.
3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter).

opw-5136050

Forward-Port-Of: odoo/enterprise#100913
Forward-Port-Of: odoo/enterprise#97005

The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file.

This behavior is due to the Odoo community commit [3082d3b](https://github.com/odoo/odoo/commit/3082d3bd0d7a8b45e647c441ba48adcb84a7a070), which partially reversed an improvement to the group payment memo field.

- The original behavior was to concatenate the included invoices with spaces (e.g. 'INV/123 INV/124').
- The improvement replaced this with the batch payment reference (e.g. 'BATCH/IN/002').
- The behavior after 3082d3b is to concatenate the included invoices with a space and a comma (e.g. 'INV/123, INV/124'

This commit strips the commas from all generated EFT files, instead of further altering the group payment memo field. It also alters existing unit tests to check that commas are removed from payment memo fields.

While a fix that changes the memo generation would resolve some issues, this commit ensures that manually added commas will not cause rejected payments. 

[Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5099220)
opw-5099220

Forward-Port-Of: odoo/enterprise#100670
Forward-Port-Of: odoo/enterprise#98613

This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the corresponding handling of exempt and non-exempt balances in the query result processing. These change fixes an issue we encountered when checking the sales CSVs ('Débito' and 'Restitución de débito'). Before this change, the column "Monto Neto Exento o No Gravado"  was always filled, even when the operation was not exempt, and in that case it repeated the value of "Monto Neto Gravado".
Here is an example:
<img width="1654" height="187" alt="image" src="https://github.com/user-attachments/assets/578fa197-ab72-4801-b714-9c40ddff4b01" />

The correct behavior should be that for taxed operations, only  "Monto Neto Gravado" is filled with the 'balance' value, and for exempt operations only "Monto Neto Exento o No Gravado"  should have values.
Here is a screenshot of the 'Debito' CSV after the change:

<img width="1614" height="196" alt="image" src="https://github.com/user-attachments/assets/0a18cbe9-d878-4e37-9bb7-21dc8b5cda72" />


**Summary**

* Changed the column mapping for "Monto Neto Exento o No Gravado" from `balance` to `exempt_balance` in the `columns_map` dictionary in `_vat_simple_build_sale_query`.
* Updated the logic for populating values: added handling for `exempt_balance` and `balance` columns so that only exempt balances are shown in `exempt_balance` and non-exempt balances in `balance`, based on the `is_exempt` flag in the row.

Note: the files created were tested on ARCA environment and they could be uploaded without errors.

Forward-Port-Of: odoo/enterprise#97377