**Problem:**
When a kit sale order is created with a package for the kit
product, inside the delivery for the component of the BOM
the package is the package of the kit product

**Steps to reproduce:**
- Inside Settings/Sales activate the "Product Packagings"
setting
- Create a new product (the final product)
- Inside the inventory tab add a packaging line for a pack of
9 units
- Create a new product (the comp product)
- In the general information tab, set a unit of mesure of g
- In the inventory tab add a packaging line for a pack of
0.9 g
- Set an on hand quantity for the comp product
- Create a new BOM for the final product
- Add a a line with the comp product for a quantity of 0.1 g
- Select kit
- Create a new quotation and select your kit product
- Select your packaging > Confirm
- Click on the delivery smart button
- In the operations tab change the packaging of the stock move
to the packaging of the comp
- validate and print

**Current behavior:**
An error message appears

**Cause of the issue:**

When _compute_packaging_qtys calls _compute_qty (the method of the
product.packaging model):
bom_id.product_uom_qty is the uom of the final product (here: Units)
but line['packaging'] is the packaging of the comp that
we set manually on the stock move
https://github.com/odoo/odoo/blob/8244b0bcdb470ff6eb95e2613903fb9175f2c435/addons/mrp/models/stock_move.py#L116
So inside _compute_qty, when _compute_qty (the method of the uom.uom model)
is called, qty_uom is Units and self.product_uom_id is g
https://github.com/odoo/odoo/blob/8244b0bcdb470ff6eb95e2613903fb9175f2c435/addons/product/models/product_packaging.py#L79
which triggers an error inside _compute_qty
https://github.com/odoo/odoo/blob/8244b0bcdb470ff6eb95e2613903fb9175f2c435/addons/uom/models/uom_uom.py#L223-L227

opw-4781180

Forward-Port-Of: odoo/odoo#210540

This error occurs when attempting to create a submenu item under a menu item.

Steps to reproduce:

 - Go to `menu items`.
 - Click `New` > In `Submenus` click `Add a line`

`TypeError: unsupported operand type(s) for +: 'bool' and 'str'`

This error occurs when attempting to create a submenu item under a menu item that does not have a name. Since the menu item record has not been saved yet, the system assigns a new ID to the menu item and sets its name to False. When computing the complete name for the submenu item, the menu(parent menu) item's name is False, which causes the error.

https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/odoo/addons/base/models/ir_ui_menu.py#L56

This commit ensures that if the parent menu item record has not been saved and its name is False, an empty string is used in its place.

sentry-6368548342

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

Forward-Port-Of: odoo/odoo#210291

**Steps to reproduce:**
- Install base_vat and website_sale
- Execute the following steps as a public user
- From website, go to the Shop
- Add a product to the cart
- Proceed to checkout
- Enter an address in Romania
- Enter a valid CUI as VAT (e.g. 8001011234567)
- Validate the address
- Edit the address to see the issue

**Issue:**
The country code (i.e. RO) has been prepended to the input VAT, which is not correct.
If the Romanian localization is installed and an invoice is created from the order and sent to the government, it will be rejected because of the incorrect VAT.

**Solution:**
Romania can accept the CUI as tax identifier.
The CUI only contains digits.
When formatting the VAT from Romania, the country code will not be prepended automatically.
To reduce the effect of the fix, the code prepend will only be skipped if the country of the customer is the same than the country of the website.

opw-4655064




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

Forward-Port-Of: odoo/odoo#211693

Problem:
When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field.

Cause:
The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As a result, the `-50%` margin shifts the video offscreen.

Solution:
Set both `left` and `right` to `0` in `.o-position-absolute` to ensure proper centering. Remove `margin-left: -50%` to prevent misalignment in non-editor contexts.

**Before**:
In website editor:
![image](https://github.com/user-attachments/assets/c8affa50-bc83-4f7f-ad24-df1c7dc882ca)
In contacts (html_field):
![image](https://github.com/user-attachments/assets/d77c23cf-7205-4ac4-943b-05c9291b3fe3)

**After**
In website editor:
![image](https://github.com/user-attachments/assets/814d3704-9f10-49f9-8b4d-04821c5ad5db)
In contacts (html_field):
![image](https://github.com/user-attachments/assets/816aec60-671f-468f-8d0a-0b1c5590f5cf)

Steps to reproduce:
- Go to Contacts > "Gemini Furniture".
- Add a video in the "Website Partner Full Description" field.
- Save and open the partner on the website (`partners/gemini-furniture-11`).
- Return to the Contacts page. → The video appears shifted 50% to the left.

opw-4752567

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

Forward-Port-Of: odoo/odoo#212344

Currently the signature of function `_notify_by_email_prepare_rendering_context` in `account_peppol` is not compatible with all ways to call the super function. This can lead to code breaking when `account_peppol` is installed (although it works fine without).

This is fixed in this commit.

Detail:

In module `mail` the (super) function has signature
```python
    def _notify_by_email_prepare_rendering_context(self, message, msg_vals=False,
                                                   model_description=False,
                                                   force_email_company=False,
                                                   force_email_lang=False):
```

Currently in `acccount_peppol` the signature is
```python
    def _notify_by_email_prepare_rendering_context(self, message, **kwargs):
```

The super function can be called as follows while the function in `account_peppol` can not.
```python
    _notify_by_email_prepare_rendering_context(self, message, msg_vals)
```

opw-4846106

Forward-Port-Of: odoo/odoo#213516

Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name.

Purpose: When changing the country on a salary structure, the rules that appears on the payroll reporting needs to unlink outdated fields and regenerate the fields based on the new country value. The salary rule fields are dependent on the country due to its naming convention.

Steps to Reproduce on Runbot:
1. Install Payroll
2. Create a new salary structure with no country
3. Create a new salary rule and enable "View in Payroll reporting"
4. Check fields and observe that a field prefixed by 'x_l10n_xx' was created
5. Change the country set on the salary structure
6. Try to access a payroll report record and a traceback is thrown

opw-4649030

Forward-Port-Of: odoo/enterprise#87057
Forward-Port-Of: odoo/enterprise#83749

The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body:

"Durante el año gravable de 2025..."

This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year.

This change ensures that the "año gravable" corresponds to the selected period year, taken from the date_from filter in the report wizard, which reflects the actual accounting or fiscal period being certified.

Justification
According to Colombian tax practices and DIAN guidelines, the "año gravable" mentioned in retention certificates must match the period in which the income or payment was made and the tax was withheld. Using the current date instead of the actual reporting period could lead to confusion or even legal inconsistencies during audits.

Reference:

Estatuto Tributario Art. 378: Certificates must include the fiscal year in which the withholding was applied.

Common practice requires companies to issue certificates reflecting the year of the transactions, not the year of report generation.

Forward-Port-Of: odoo/enterprise#86838