### Issue:
EU vat fix cause address submission to fail.

#### Steps to reproduce:
1- `base_vat` should be installed.
2- In portal contact, set the country to BE and VAT to `0477472701`.
3- Create an invoice for portal user.
4- Navigate to shop and add a product to cart, then checkout.
5- Edit address.
6- After filling, click on save address.

Even though the VAT is not modified in form, and it is not modifiable
the address fails to save with error:
`Changing VAT Number is not allowed.`

### Cause:
After address submission The vat is fixed in here:
https://github.com/odoo/odoo/blob/82a2c5305d65027ffb263f90c4e00f7e95f98b05/addons/website_sale/controllers/main.py#L1396-L1406

This converts given vat `0477472701` to `BE0477472701`.

Which makes `address_values['vat'] != partner_sudo.vat`:
https://github.com/odoo/odoo/blob/82a2c5305d65027ffb263f90c4e00f7e95f98b05/addons/website_sale/controllers/main.py#L1472-L1482

opw-5437586

Forward-Port-Of: odoo/odoo#246850
Forward-Port-Of: odoo/odoo#245940

Step to reproduce:
- install `l10n_es_edi_verifactu_pos` and open POS
- finalize 2 order with same customer (do not invoive it)
- close session
- go to pos orders, select both order and try to create consolidated invoice

Traceback:
```
File "/home/odoo/addons/l10n_es_edi_verifactu_pos/models/pos_order.py", line 293, in _prepare_invoice_vals
    res['l10n_es_edi_verifactu_refund_reason'] = self.l10n_es_edi_verifactu_refund_reason
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/orm/fields.py", line 1365, in __get__
    record.ensure_one()
```

Cause:
- `_prepare_invoice_vals` is written to accept only one order at time but it can contain multiple orders

Fix:
- we now do not allow invoice consolidation for Veri*Factu
- the consolidation flag has been made invisible so every order now has
to be invoiced individually.

opw-5379577

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

Forward-Port-Of: odoo/odoo#239391

### Issue:
Attendances overlapping on two days are ignored for hourly accrual plans based on attendances.

### Steps to reproduce:
- Install 'hr_holidays_attendance'
- In Time Off > Configuration > Accrual Plan, create a new plan
	- Based on worked time
	- Hourly rule
	- Attendances as Source
- In Management > Allocations, create an allocation for an employee using the new accrual plan
- Create an Attendance for this employee in the period of the Accrual Plan
	- Check-in at 22pm for example
	- Check-out at 7am
- Run the cron "Accrual Time Off: Updates the number of time off"
- The Allocation ignores the worked time from the attendance

### Cause:
`_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days.

https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83

### Solution:
To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight.

First we get all attendances overlapping with the day by changing the domain in the search.

Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value.

opw-5172669

Forward-Port-Of: odoo/odoo#246598
Forward-Port-Of: odoo/odoo#246270

**Steps to reproduce:**
- Install Email Marketing app
- Create a new campaign with Subject and Recipients
- Set plain text mail body
- Add one image using /img or /image command
- Save the template
- Remove the image
- Save the template
- Try to re-add an image, on save it will be deleted everytime

**Issue:**
During `commitChanges`, the history of the editor is in a wrong state which triggers a cleanup on
`this.wysiwyg.odooEditor.historyRevertCurrentStep();`.

This is caused by the `await saveCallback(element);` of `_onMediaDialogSave` which never resolve and never call its follow-up:
```js
this.odooEditor.historyUnpauseSteps();
this.odooEditor.historyStep();
```
The resolve is event-dependent and doesn't seem to be triggered in current versions:
`const event = $.Event("image_changed", {_complete: resolve});`

**Fix:**
Check that the current element is listening to the given event.
Might not be the proper fix as I wasn't able to reproduce the expected behavior with `image_changed` event.

related PR: https://github.com/odoo/odoo/pull/205594

opw-5245367

Forward-Port-Of: odoo/odoo#244396

### Issue:
When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date.

### Steps to reproduce:
- Install 'sale_subscription'
- Create a new Subscription with two lines and a tart data several months in the past
- One with a quantity of 1 and a higher price
- The other with a quantity of -1
- It can be the same service product with invoicing based on ordered quantity
- Confirm the Subscription
- Click "Create Invoice" and confirm the invoice
- Back to the Subscription, the next invoice date was not updated.

### Cause:
In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131

So the method will return not return the date in `invoice_dates`.

Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67

### Solution:
The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds.

To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund.

opw-5360930

Forward-Port-Of: odoo/enterprise#106226
Forward-Port-Of: odoo/enterprise#103705

For old databases that were created before 16.0, existing sign request might not have a communication company set.

Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:

```
Traceback:
  ...
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
    context = self.get_document_qweb_context(request_id, token)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
    date_format = posix_to_ldml(lang.date_format, locale=locale)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
    for c in fmt:
TypeError: 'bool' object is not iterable
```

This commit fallback to the create user's company to determine the date language when there is not communication company set.

no-task (from feedback pad)

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#105893
Forward-Port-Of: odoo/enterprise#100749

The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured.

https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151

Steps To Reproduce:
1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped".
2. Go to Accounting Dashboard and create a new Miscellaneous Operation.
3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries).
4. Try to post the entry.
5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..."

The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types.

Commit that caused the issue:
https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b

Ticket [link](https://www.odoo.com/odoo/project.task/5486114)
opw-5486114