When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.

Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me

Observed Behavior:
All the documents are fetched.

Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.

Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown

From:
`('need_my_signature', '=', True)]`

To:
`[('need_my_signature', 'in', [True])]`

This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.

As a result, instead of filtering documents, all documents are returned.

[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108

[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177

Fix:
Corrected the return domain logic to fetch the correct documents.

opw-6026935

Forward-Port-Of: odoo/enterprise#116985
Forward-Port-Of: odoo/enterprise#113760

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#117168
Forward-Port-Of: odoo/enterprise#110792

Issue before this commit:
=========================
For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report.

Steps to Reproduce:
=========================
1. Install stock and sale_management modules.
2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings.
3. Create a product with tracking by lot/serial number and configure a packaging unit.
4. Create a SO using this product with a packaging unit and confirm it.
5. Open the related transfer and print the delivery slip before and after validation.

Cause of the Issue:
=========================
The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure.

With This Commit:
=========================
This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing)

opw-6142052

Forward-Port-Of: odoo/odoo#262722

**Description of the issue/feature this PR addresses:**
The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage.

In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67).

**Steps to reproduce bug:**
1. Create an event website
2. Create an event and visit it
3. On the page click Site > Properties
4. Enable `Is Homepage`
5. Return to the homepage of the application and open the editor

https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link

**Current behavior before PR:**

https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link

**Desired behavior after PR is merged:**

https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link

opw-6101680

Forward-Port-Of: odoo/odoo#263548
Forward-Port-Of: odoo/odoo#258502

When applying a cash rounding with 'biggest tax' strategy, it happens
that we end up with a MissingError when the invoice's partner is not
defined as commercial_partner_id.

Steps:

- Install membership module
- Create a cash rounding with the 'biggest tax' strategy and 0.05
  rounding
- Enable customer addresses and create a partner P with an invoice
  address I
- Create an invoice, select I as customer (P will be assigned as
  delivery address but this is not relevant)
- Add an invoice line for 100.03 and any tax and apply the cash rounding
- Confirm
-> MissingError: record has been deleted

Cause:

- When creating the cash rounding lines, we set the `partner_id` from the
invoice's partner (in our case partner I, which has P as
`commercial_partner_id`).
- When posting the invoice we look for lines that have partner id
  different than the invoice's commercial partner id and we call the
  write method to set the commercial partner id instead
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239
- In some cases, for example in the `membership` module, the override of
  the write method calls the super() before using `self`.
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49
  But the super triggers the `_sync_tax_lines` mechanism, during which
  the rounding line in deleted
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114
  Therefore `self` doesn't exist anymore
  when comming back in the override

Fix:

Setting the commercial partner on the rounding line to avoid calling the write method

opw-6128868

Forward-Port-Of: odoo/odoo#262759

A traceback occurs when sending an invoice to Peru UBL if a combo product
invoice line does not have any taxes applied.

Steps to reproduce the error:
- Install ``l10n_pe_edi`` module with demo data
- Switch to PE Company
- Create an invoice > Add a Office Combo product > unset the taxes > Confirm
- Process now

https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552
Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line.
Normally, invoices without taxes are restricted at [1],
but combo products are excluded from this validation at [2].
As a result, combo product lines without taxes bypass the restriction and trigger a traceback.

[1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929

[2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434

sentry-7430552834

Forward-Port-Of: odoo/enterprise#114798