Steps to reproduce:
- Time off > Configuration > Time off types > New
- Set 'Requires Allocation' to 'No Limit'
- Takes leaves of this type
- Set 'Requires Allocation' to 'Yes'
- Approvals > Allocations > New > Select your time off type
- Edit validity period to start after the leaves you took
- Confirm > Click on the newly created allocation
- Displays -X remaining out of Y

The allocations try to cover leaves taken before the requirement was changed, when we'd expect leaves taken under No Limit mode not to require any. This is problematic because it can happen with past leaves as well, which we cannot get rid of on production databases.

Since Odoo does not track which allocation requirement mode leave are taken under nor the date and content of edits to that parameter, we cannot tell apart leaves of the same type when distributing allocated days. Tracking either would certainly require edits to the model which rules out stable versions, so instead the edits to allocation requirement should be restricted in favor of creating new time off types when we want to switch that parameter.

opw-3919886

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

Forward-Port-Of: odoo/odoo#180773
Forward-Port-Of: odoo/odoo#180566

Avoid sending more emails than necessary at events

We want to make sure that in all mails sent from the calendar event, the recipients are only the ones we want and avoid sending them to 'indirect' followers. 

Examples use case:
- Subtype Notes with Default checked.
- Several Attendees set (including several users).
- Each invitation email must be sent only to the corresponding attendee, no one else.
- Each event reminder email must reach only the corresponding attendee, no one else.

Example use case in runbot v16 **before** this change.
![ejemplo-antes](https://github.com/user-attachments/assets/f3987730-324f-4699-9e10-f8226cf92657)

Example use case **after** this change.
![ejemplo-despues](https://github.com/user-attachments/assets/f4eb797e-cd06-4fac-8561-479fd51406aa)

@Tecnativa TT50302

Ping @pedrobaeza and @carlosdauden 

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

Forward-Port-Of: odoo/odoo#180164
Forward-Port-Of: odoo/odoo#174494

Steps
---
* install `stock`, `sale_management`
* configure reception in 2 steps
  (*Setting > Multi-step routes* + *Configure Warehouse Routes*)
* make *Stock/Input* a return location
  (*Inventory* > *Configuration* > *Stock/Input* form)
* create an SO for 5 units of a storable product (say P)
* (put at least 5 of P available in stock)
* confirm it > go to the delivery > validate
* *Return* > from the wizard set *Stock/Input* as the return location
* validate the `Customers -> Input` receipt
* validate the `Input -> Stock` internal transfer
* => on the orignal SO the delivered quantity is now -5 instead of 0

Cause
---
When generating moves in a push rules, we copy the fields of the
generating move, including `to_refund`, so both moves affect the
delivered quantity.
But when we check if a return move should affect the delivered/received
qty on SO/POs, we only check the `usage` of the destination location;
so in the case of multi-step routes, moves further down the chain
will affect the qty twice or more, and we will have a negative
delivered quantity

Fix
---
Use a stricter check to determined which moves should affect SO
quantities

opw-4129497

Forward-Port-Of: odoo/odoo#180048
Forward-Port-Of: odoo/odoo#178392

### Steps to reproduce the issue:

1. Create a Customer Invoice with two product lines
2. Give a negative price to one of those lines, the total must remain positive
3. Add distinct analytic accounts to each line's analytic_distribution
4. Add a payment term with applicable early discount
5. Confirm and Register Payment
6. Go to the Journal Entry related to the Invoice
7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case

### Explanation:

In the current situation, `_compute_is_refund` and `_compute_tax_tag_invert` will assign a value to `tax_tag_invert` depending on the `account.move.line.balance`. Because of the distinct analytic accounts, the negative line is separated from the others and because of the logic behind the computes, `tax_tag_invert` is set to the opposite value.

### Fix reasoning:

While `account.payment` are restricted to `account.move` with the same direction, `account.bank.statement.line` are not. In the current case, the affected lines all have `tax_ids` values. Thanks to this, we can use `account.tax.type_tax_use` independently of the line's balance to differentiate in and out transactions and assign `tax_tag_invert` consistently.
We must also consider the case where `account.bank.statement.line`. To target the Early Payment Discount lines, we will separate them from the other values using `display_type`.

opw-3989174

Forward-Port-Of: odoo/odoo#180797
Forward-Port-Of: odoo/odoo#170499

### Steps to reproduce the issue:

1. Activate Colombian localization
2. Create an Invoice and Confirm
3. Go to _Accounting > Configuration > Journals_
4. Select Customer Invoices, set Nota de Débito to True and Save
5. Go back to your Invoice, its Electronic Invoice Type is now "Nota Débito"
6. Set Nota de Débito to False in the Customer Invoices Journal
7. Return once again to you Invoice, its Electronic Invoice Type did not change

### Explanation:

When the user changes `l10n_co_edi_debit_note` in an `account.journal`, it changes this value for all entries in said `account.journal`, not only the ones in draft state.
https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L65
`_compute_l10n_co_edi_type` depending on `l10n_co_edi_debit_note`, it is called and, if the change is from False to True, `l10n_co_edi_type` is changed to a specific value.
https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L72-L81
If `l10n_co_edi_debit_note` is set back to False, `l10n_co_edi_type` is not reverted to its previous value and the user can not manually change this field for posted or cancelled entries.

### Fix reasoning:

To avoid such situation from happening, the field will be restricted for journals with entries in a non draft state.

opw-4174980

Forward-Port-Of: odoo/enterprise#70330
Forward-Port-Of: odoo/enterprise#70133

### Steps to reproduce the issue:

1. Create a Customer Invoice with two product lines
2. Give a negative price to one of those lines, the total must remain positive
3. Add distinct analytic accounts to each line's analytic_distribution
4. Add a payment term with applicable early discount
5. Confirm and Register Payment
6. Go to the Journal Entry related to the Invoice
7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case

### Explanation:

In the current situation, `_compute_is_refund` and `_compute_tax_tag_invert` will assign a value to `tax_tag_invert` depending on the `account.move.line.balance`. Because of the distinct analytic accounts, the negative line is separated from the others and because of the logic behind the computes, `tax_tag_invert` is set to the opposite value.

### Fix reasoning:

While `account.payment` are restricted to `account.move` with the same direction, `account.bank.statement.line` are not. In the current case, the affected lines all have `tax_ids` values. Thanks to this, we can use `account.tax.type_tax_use` independently of the line's balance to differentiate in and out transactions and assign `tax_tag_invert` consistently.
We must also consider the case where `account.bank.statement.line`. To target the Early Payment Discount lines, we will separate them from the other values using `display_type`.

opw-3989174

Forward-Port-Of: odoo/enterprise#70328
Forward-Port-Of: odoo/enterprise#69835

### Issue

Invoices using consumable intra-community taxes are currently counted twice in the EC Sales Report.

### Steps to Reproduce

1. Install `l10n_at_reports`.
2. Switch to an Austrian company.
3. Create and post an invoice using a consumable intra-community tax (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)').
4. Open the EC Sales Report.

You will observe that the invoice amount is counted twice.

### Cause

The system groups values in the EC Sales Report by tax tags. A previous commit (odoo/odoo@f937e915dfd64a9b66dd9f7d7e3d19607d088f28) introduced changes to certain taxes (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)'), which caused multiple tax tags counted in the EC Sales report to be applied to the same line. This grouping behavior leads to double counting.

### Fix

Repartition lines with the `tax_report_line_l10n_at_tva_line_4_8_tag` also contain the `tax_report_line_l10n_at_tva_line_3_zm_igl_tag`. To avoid double counting, the EC Sales Report now only checks for the latter tag.

opw-4174429

Forward-Port-Of: odoo/enterprise#69941