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

getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days.

So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1.

The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week.

### Current behavior before PR:

At the end of 2026, this will cause problems because the week number will run as:

* 2026, week 52 (all days in 2026, OK)
* 2027, week 53 (most days in 2026, last day in 2027, Not OK)
* 2027, week 1 (all days in 2027, OK)

### Desired behavior after PR is merged:

This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as:

* 2026, week 52 (no changes)
* 2026, week 53 (year is not incremented if week number is not reset)
* 2027, week 1 (no changes, but year is incremented when week number is reset)

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

Forward-Port-Of: odoo/odoo#267656

**Steps to reproduce:**
- Install Accounting and l10n_ro_edi
- Switch to a Romanian localization (e.g. RO Company)
- Configure Romanian E-Factura

- Create an invoice with a product having a name longer than 100 chars
- Confirm the invoice
- Send E-Factura to SPV
- Fetch E-Factura status

**Issue:**
The invoice is rejected with the following error:
"[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100."

**Similar issue with the product description:**
"[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200."

**Similar issue with the note (i.e. Terms and Conditions):**
"[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300."

**Solution:**
Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300.

opw-5964904




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

Forward-Port-Of: odoo/odoo#265811

Problem:
When the selection is inside a `contenteditable="true"` element that is not the root editable, focusing away does not trigger a save.

Cause:
When the DOM contains a nested contenteditable structure like:

```html
<div class="odoo-editor-editable" contenteditable="true">
  abc
  <div contenteditable="false">
    ac
    <div contenteditable="true">a</div>
  </div>
</div>
```

With the selection inside the inner `contenteditable="true"`, the `blur` event is not triggered on `.odoo-editor-editable` when focusing away, because the active element is the inner div and `blur` does not bubble.

Solution:
Replace the `blur` listener with `focusout`, which bubbles from the inner `contenteditable="true"` up to `.odoo-editor-editable`, allowing `onBlur` to be called correctly.

Steps to reproduce:
- Open Project > Task.
- Add a `/column` block in the description.
- Focus inside any column and write some text.
- Click away to change tab.
- Reopen the description tab.
- The latest changes inside the columns were not saved.

opw-6227922

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

Forward-Port-Of: odoo/odoo#266367

Steps to reproduce:
===================
1. Edit a page, add a Cover/Banner block.
2. Set its background to a video, paste an Instagram URL
3. Save and open the published page.

=> Instagram embed is broken (iframe shows nothing / error).

Cause:
=======
Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render.

The unconditional append is itself a regression from the public-widget → interaction refactor in [2].
The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram.

Solution:
=========
remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction

[1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492
[2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4

opw-6233081

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

Forward-Port-Of: odoo/odoo#267016

When a user installs only the Invoicing app and creates a new purchase journal, no default_account_id is set on the journal. The Invoicing app does not expose account configuration, so the user cannot fix this manually. As a result, importing a Peppol XML invoice through that journal fails with a database constraint error because the generated account.move.line has a null account_id.

https://github.com/odoo/odoo/blob/16245530f0e3e9be21c8b96baaecd3a679420cac/addons/account/models/account_journal.py#L776-L805 This already auto-creates accounts for bank/cash journals, but does nothing for sale/purchase journals.

Steps to reproduce:
- Install the Invoicing app (no full Accounting)
- Create a new purchase journal with type 'purchase'
- Go to Vendors -> Bills and Upload a Peppol XML file
- Error importing attachment as invoice (decoder=_import_invoice_ubl_cii)

Ticket [link](https://www.odoo.com/odoo/action-4043/6014363)
opw-6014363

Forward-Port-Of: odoo/odoo#267552
Forward-Port-Of: odoo/odoo#252859

**Steps to reproduce:**

- Setup a Verifactu installation and a Spanish company
- Go to the PoS, make a Sale
- Keep the ticket
- Go to the /pos/ticket URL and enter the ticket informations
- Last step also works when requesting an invoice in the backend on the order
- Go to the order in the backend, an error is shown, the cancellation didn't go through
**Veri*Factu documents can only be generated for paid or posted Point of Sale Orders.**

**Why the fix:**

When we directly invoice an order, we do not go through the verification of being paid and done. This is why is works, but when making the invoice after the sale is done, we cancel the order first, then we register the invoice instead. When trying to cancel the order, we check if the order is either paid or done, but it is currently invoiced as we just generated the invoice.

We now allow no errors if the order is in the invoiced state, and let it pass through.
With this flow we get the same result as the direct invoice from the PoS.

The new cancellation on the order  and submission on the invoice may take a bit of time to get accepted but they will be eventually.

opw-6139200

Forward-Port-Of: odoo/odoo#266383
Forward-Port-Of: odoo/odoo#264272

### Description of the issue/feature this PR addresses:
**Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor.

**Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records.

### Current behavior before PR: 
When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback.

### Desired behavior after PR is merged: 
The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected.

opw-6174628

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

Forward-Port-Of: odoo/odoo#266224