### The communication between the IoT Box and a DB can be done using:

- Longpolling,
- Websocket,
- Simple fetch from one side or the other.

### Problems:

- The longpolling and the websocket can theorically be substituted but don't have a common API,
- The websocket service is currently designed to handle ONLY printing jobs,
- The longpolling is barely used, often replaced by a simple "action", but never polling 
(~never listening for response from the IoT Box),

### Solution:

We refactored all this in order to simplify the communication.

- `iot_longpolling` and `iot_websocket` services are replaced by a single `iot_http` service 
exposing available methods,
- Websocket can now call every IoT Box _action method_,
- Longpolling and Websocket now have a common simple API (`sendMessage`/`onMessage`),
- Longpolling can now fallback to websocket on every call (via `action` method),

#### List of the methods:

- `get`/`post`: base http methods to properly contact an IoT Box from the db client,
- `websocket.sendMessage`/`websocket.onMessage`: websocket methods,
- `longpolling.sendMessage`/`lonpolling.onMessage`: longpolling methods 
(+ `lonpolling.addListener`/`lonpolling.removeListener` kept for compatibility),
- `action`: general method to properly handle a simple communication between the db and 
the IoT Box, 

Community PR: [https://github.com/odoo/odoo/pull/185506](https://github.com/odoo/odoo/pull/185506)
Task: 4283647

Context:
The Belgian localisation has two Intrastat report handlers:

- Goods: `l10n_be_intrastat.models.account_intrastat_report`
- Services: `l10n_be_intrastat_services.models.account_intrastat_services_report`

`account_intrastat_report.be_intrastat_export_to_xml()` is the single export entry-point for both. It always calls an internal helper named `_be_intrastat_get_xml_file_content(options, results, company)` and then serialises the returned string.

Why it failed:
1. Signature drift The services override expected a fourth positional argument (`date`), so the shared entry-point raised a `TypeError`.

2. Wrong template prefix The helper tried to render `l10n_be_intrastat.intrastat_services_report_export_xml`, but the template is stored under `l10n_be_intrastat_services`, leading to a `ValueError`.

This commit drop the unused `date` parameter and compute the period from options the same way we do in the other function.

opw-4834279

Forward-Port-Of: odoo/enterprise#86759

[FIX] account_online_synchronization: currencies symbol missing

Before this commit when doing a bank synchronization with a currency that wasn't
enabled, the currency was not reloaded in the session and so the getCurrency
function was not working properly. The symbol was not displayed.

task-4749335

This commit will change a bit the display of statement line with multi currency.
A popover has been added when clicking on the amount to have extra line info
like the exchange difference and when we have a partial reconcile.

- Correcting a bug where the amount currency of the suspense was wrong when
dealing with currencies (delete or adding lines). For example when dealing with
JPY currency (that have a rounding of 1). Making an invoice for 100 yen and a
statement line of 50 yen. When adding the line and removing it, we could have
rounding issue since we calculate the amount currency by multiplying the balance
and the currency rate. In this example we achieve a suspense line of 49 when it
should be 50.

- Correcting another bug with exchange diff. In the same case, we had an
exchange
difference value of 0.01 in _lines_get_account_balance_exchange_diff which
shouldn't be there. In prior version of 18.3 we checked that the origin_balance
minus move_line.balance was zero in the currency of the move line as well as
the one from the company and if that was the case no exchange move line were
created. And since there were no exchange move line the exchange move was not created.
In this commit, I reintroduce the logic of checking the move line currency to
return 0.0 but that was not enough since the reconcile_plan function would still
create the exchange move since we were not using the context key anymore. So
now if the exchange value is 0 then we pass the context key to avoid having an
exchange move.

- Also doing some formatting because the linter was not correctly applied.

- Correcting also a case where the reconciled_lines_ids has multiple line in
case of exchange diff, which cased a traceback since is_invoice needs a
singleton.

- When having a foreign currency, the suspense amount is displayed in the
foreign currency but when adding move line with the same currency, due to the
computation on the amount_currency we could have situation where the amounts
don't add up. We decided that if there is a foreign currency and that all the
lines are in the foreign currency we do an addition of the amount currency
otherwise we display the suspense in journal currency. For this we had to use
the self.amount_currency because the liquidity line is not modified when
modifying the amount currency of the statement line itself. (Tried to synchro
the move and more in particular the liquidity line but had a constraint failing)

- When doing an apply amount of a line that has multiple value in the
reconcilied_lines_ids, it gives a traceback because we want to get the
current_ids of a dict of multiple values

task-4749335

Forward-Port-Of: odoo/enterprise#86519

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

When a signed document is moved to trash in the documents app, when the cron tries to delete the said document it should raise a foreign key violation error in the terminal not in UI.

**Steps to reproduce:**
* Install document and sign
* Document App> all> click `Employment contract.pdf`.
* Select sign>drag and drop Signature>Sign now
* Sign the document>validate and send completed document
* Documents>certificate of completion or the signed document>actions>trash
* The error will be produced when cron deletes the document.
* You can delete the document from trash to see what error will be displayed by cron.
  
 `ERROR: update or delete on table "ir_attachment" violates foreign key constraint "sign_request_completed_document_rel_ir_attachment_id_fkey" on table "sign_request_completed_document_rel"`
 
**Solution:**
* Modifying the domain for `_gc_clear_bin` via a new function called overridden `_gc_documents_domain` in `documents_sign` this will allow for cron to skip over signed required document during unlink process.
* This will still throw an `Validation Error` when the user tries to delete it from the GUI letting them know it cannot be deleted.

Sentry-6225030131

Forward-Port-Of: odoo/enterprise#86382
Forward-Port-Of: odoo/enterprise#83765

### Steps to reproduce:
- Have an overdue invoice
- Go to Accounting > Customers > Follow-up Reports and click the partner
- Change the state of the report to something different than the first state
- Click "Follow-up", select "By post" and send
- Settings > technical > Email > Snailmail Letters find the letter corresponding to the report
- Check the PDF, it is using the mail template of the first followup level

### Cause:
When sending a followup report, the followup level of the report is recomputed for it to have the correct value.
Then the report is generated.
But the option to send a letter uses methods from the module `snailmail` for example `` which don't have options. The options are then recomputed to generate the report, reading [`partner.followup_line_id`](https://github.com/odoo/enterprise/blob/c8dac822cf3df23922488f33c07a114bbea05198/account_followup/models/account_followup_report.py#L42) so getting the wrong value.

### Solution:
Add a context key to pass the value of `followup_line` to the report generation after snailmail.

opw-4766804

Forward-Port-Of: odoo/enterprise#86706
Forward-Port-Of: odoo/enterprise#85717

The system will crash with an error when we `fetch transactions` and then click on the total amount in the top right corner, because the method `action_open_bank_balance_in_gl` expects `exactly one journal record` (self.ensure_one()), but receives an empty recordset.

**Steps to Produce:-**

1. Install the `Accounting` module.
2. Navigate to `Invoicing > Bank`, then click on "Search Banks" and connect with the `Odoo Bank Sync Demo`.
3. Click on `Fetch Transactions` and wait for the process to complete.
4. In the new view, click on the `total amount` located in the `top right corner`.

**Error:-**
`ValueError: Expected singleton: account.journal()`

**Solution:-**
- At [1], in `default_context` we can see that `active_id` is not given.

 [1] https://github.com/odoo/enterprise/blob/4b8edc19dbece15f7843ec3647c464307e165906/account_online_synchronization/models/account_online.py#L878-L882

- So, in this commit now active_id is added in default_context to prevent the error

**Sentry - 6644825437**

Forward-Port-Of: odoo/enterprise#86896

The system crashed because it expected the information from the card to be in `dictionary` format, but it came in the `list of dictionaries`. Usually, when there is only one contact on the card, the system retrieves the details as a `Dictionary`. But if the card has details of more than one person, it receives a `list of dictionaries`.

When the `extracted_data` comes as list of dictionaries, then at [1], it raises the `TypeError`.

[1]
https://github.com/odoo/enterprise/blob/e5b21d77b6dfff2b1371909c3c1e17cecee43a19/crm_enterprise/tools/business_card_scanner.py#L85

**Steps to produce:-**
1. Install `CRM` and make sure you have iap tokens for `Lead generation`.
2. Go to CRM and click on gear icon and click on Import Business Cards.
3. Then upload this [image](https://drive.google.com/file/d/1wKONdUEAMQptNU8cUeZsUY1xVJBpD8Dk/view?usp=sharing).

**Traceback:-**
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/http.py", line 2467, in __call__
    response = request._serve_db()
  File "/home/odoo/odoo18/community/odoo/http.py", line 1970, in _serve_db
    return self._transactioning(
  File "/home/odoo/odoo18/community/odoo/http.py", line 2034, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "/home/odoo/odoo18/community/odoo/service/model.py", line 164, in retrying
    result = func()
  File "/home/odoo/odoo18/community/odoo/http.py", line 2001, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo18/community/odoo/http.py", line 2263, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo18/community/odoo/addons/base/models/ir_http.py", line 349, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo18/community/odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo18/community/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo18/community/odoo/service/model.py", line 84, in call_kw
    result = method(recs, *args, **kwargs)
  File "/home/odoo/odoo18/enterprise/crm_enterprise/models/crm_lead.py", line 34, in action_ocr_business_cards
    leads = card_scanner.business_cards_to_leads(attachments)
  File "/home/odoo/odoo18/enterprise/crm_enterprise/tools/business_card_scanner.py", line 82, in business_cards_to_leads
    lead_values = {
  File "/home/odoo/odoo18/enterprise/crm_enterprise/tools/business_card_scanner.py", line 85, in <dictcomp>
    if extracted_data.get(field)
AttributeError: 'list' object has no attribute 'get'
```

**Solution:-**
- We first checked whether the data returned from the OCR was a dictionary or a list of dictionaries (multiple contacts).
    - If it was just a dictionary, **we wrapped it in a list** so that we could handle everything the same way.
    - Then, we looped through each dictionary, picked out the allowed fields, and **created a lead for each one**.

**Sentry - 6658829547**

Forward-Port-Of: odoo/enterprise#87159

**Issue**
The "Terms and Conditions" section in the invoice report only takes up half of the page, leaving unnecessary blank space on the other half.

**Steps to Reproduce:**
1. Install the Accounting app.
2. Navigate to Accounting > Customers > Invoices.
3. Create or open an invoice.
4. Add a multiline text in the "Terms and Conditions" field.
5. Confirm and print the invoice report.
6. Observe that the content only fills half the available width.

**Expected Behavior:**
The "Terms and Conditions" text should utilize the full width of the report layout if needed, especially for multiline entries.

**Actual Behavior:**
The text is constrained to half the page, reducing readability and leaving unused space.

**Root Cause**

The issue was introduced by PR #193399, which added the `overflow-auto` class to address a display bug from ticket 4416845. However, this class was applied too broadly, affecting the layout of the "Terms and Conditions" block.

**Fix**
To address this issue, a class is added specifically to the terms and conditions div to control its display.

opw-4698250

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

<b>Steps to reproduce:</b>

1) Create a flexible working schedule
2) Assign this working schedule to one of the employees 
3) Create a public holiday with no calendar
4) Create a leave for the flexible employee where the public holiday
   will be during his leave
5) Notice the duration of the leave

<b>Issue:</b>
Previously, leave duration did not exclude public holidays without calendars
or holidays associated with a different company than the employee's
when using flexible schedules.

For example, if an employee took 5 days off and one of those days was
a public holiday without a calendar, the system would incorrectly count
all 5 days instead of excluding the public holiday.

<b>Cause:</b>
This issue occurs because the system only checks for public holidays
with calendars during the leave period and excludes those days from
the leave duration.

However, if the public holiday does not have a calendar or is assigned
to a different company than the employee's, it is not excluded from
the leave days/hours.
https://github.com/odoo/odoo/blob/7293a04bd90c26cb27669f5a1c9edd45c7e5c96c/addons/hr_holidays/models/hr_leave.py#L428-L438

<b>Fix:</b>
We now exclude public holidays from the leave duration even if they do
not have a calendar, as long as the holiday belongs to the same company
as the leave request.

opw-4711942

**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