## Details:

The function get_link_preview_from_html is a common tool used in many modules, one of them documents.

When you add a link on a workspace that response with a content with a xml declaration (ex. "<!--?xml version="1.0" encoding="UTF-8"?-->"), this will raise the next ValueError:

"Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration."

At the moment that the string is being parsed as a html element, this string has been cleaned, to avoid the issue, we can only remove this xml declaration because this element is only being used to extract information about the page.

## Impacted versions:

18.0 and later

## Steps to reproduce:
1. Go to Documents App
2. Add a link in any workspace with xml declaration (ex. https://www.buffalo.jp/s3/guide/crmm/userguide/99/en/pc_index.html)

## Current behavior:
Raise Value Error "Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration."

## Expected behavior:
Link should be saved.

### Task
OPW-4675813

XLS(X) allows to store in cells date/datetimes values as date/datetime objects. Meaning, instead of having a string with the date in some format, the cell value can hold an actual date/datetime object, which are automatically converted into the `datetime.date`/`datetime.datetime` when the xls(x) file is parsed in python.

When an xls(X) file contains at the same time date values under date/datetime objects and under strings with the user format `%d/%m/%Y` (rather than the server format `%Y-%m-%d`),
the import was failing with the error
`time data '06/30/2025' does not match format '%Y-%m-%d'`

This error normally happens when the user tries to do an import with different kind of date formats under strings in the same file e.g. `06/30/2025` and `2025-07-01`
and this is understandable that Odoo doesn't know what to do in such a case.
But, if you stick to the same format, either only `%d/%m/%Y` either only '%Y-%m-%d'`, Odoo supports it.

However the case here is trickier: it's when the file contains at the same time dates under a string format, e.g. `06/30/2025` and under date objects, e.g. `datetime.date(2025, 6, 30)`. Which can happen quite easily, as Google Spreadsheet for instance tends to automatically convert the cells holding a date value into date object. And it's then easy to have a file containing both date objects and strings for date, which looks visually the same in the Google Spreadsheet interface.

In addition Google Spreadsheet tends to convert automatically only dates below the 12 of the month because of the american format. e.g.
if you set `01/06/2025`, it gets converted into a datetime object if you set `13/06/2025`, it doesn't get converted into a datetime object, the value stays as a string.

The goal of this revision is to support to have the possibility of having date values under date objects and string in a user format

The problem lied in the fact, during the xls parsing, date objects were converted into strings using the server date format. And then you could finish with data containing both the user format and the server format.

The idea is to no longer automatically convert date objects and to support having date objects in the import parsing. And when trying to guess the date/datetime format of the file, date objects are simply ignored, as they do not need to be parsed.

### Steps to reproduce:
- Accounting > Reporting > Partner Ledger
- Select multiple partners
- Select "Customer Statements" as report
- Click "Send"
- Go to the one of the partner in question an dopen the generated PDF
- All current companies show in the header and other currencies are present

### Cause:
When sending to multiple partners, the action is dispatched with to cron_threads so a new `env` is created. This `env` has a key `companies` containing all companies that exist in the DB. When the `_init_options_companies` is called for the report it adds `self.env.companies` to the option ([code](https://github.com/odoo/enterprise/blob/4ef74fd9527a28616bf81c9716d6000aa25b839e/account_reports/models/account_report.py#L1276)). So in the end all companies appear on the report.

### Solution:
Add 'forced_companies' in the options before calling the `cron`. 

The format of 'forced_companies' had to be changed to only contain ids because fields cannot be added in `send_and_print_values` as it's a JSON fields. 

opw-4635283

**Steps to reproduce:**
- Install Accounting
- In Bank journal settings, make sure that there's no Outstanding Payments account

- Create a bill for a customer
- Confirm it
- Create a second bill for the same customer
- Confirm it

- Go to the bills list
- Select the 2 created bills
- Create a payment via "Pay" button:
  * Journal: Bank
  * Payment Method: Manual Payment
  * Group Payments: [checked]
- Do not validate the payment
- Go to "Accounting / Vendors / Payments"
- Select the created payment and create a batch
- Validate the batch payment => The payment status of both bills is "In Payment"

- From Accounting dashboard, go to transactions of Bank journal (reconciliation widget)
- Create a new transaction for the previous customer with the amount of the batch payment
- In the reconciliation widget, go to "Batch Payments" tab
- Select the created batch payment
- Validate to reconcile
- Check the bills list

**Issue:**
Only one of the bills has its payment status set to "Paid", the other one staying in "In Payment" status.

**Cause:**
In the method that checks which account move lines are included in the batch payment, we loop on each linked move line and take the "min" between the remaining amount of the batch payment and the amount of the move line until the remaining amount reaches 0.
However, for vendor bills, these amounts are negative and taking the "min" amount returns the remaining amount directly, resulting in only having 1 move line set to reconcile.

opw-4595006

Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request.
This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test.

Checking the logs:

2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow
2025-04-11 04:56:57,155 13 INFO 78181121-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /test_sale_product_configurators/tests/test_sale_product_configurator.py:TestProductConfiguratorUi.test_02_product_configurator_advanced

That indicates that we are in the case where the request don't have a cookie, despite the route being called from a chrome.

It is most likely due to the fact that the browser cookie are cleared at the end of a browser js call, before navigating to about:blank

2025-04-11 04:56:57,119 13 INFO 78181121-16-0-all odoo.addons.test_sale_product_configurators.tests.test_sale_product_configurator.TestProductConfiguratorUi: Deleting cookies and clearing local storage

It is actually easy to reproduce by adding a sleep before navigating to about:blank in browser.clear(). We can see that the websocket route is still called periodically at the end of a test. This error will occur when this request is made just between
the cookies are cleared and the page navigates to about:blank.

One possibility is to avoid to clear the cookie since the user profile is deleted after the browser is stopped, but unfortunately in this version the browser is kept between tests of the same class.

It is maybe not sufficient but navigating to a blank page before removing the cookies should reduce the possibility of having a request without cookie reaching the server. In this case a sleep after about:blank, before clearing the cookie shows that we don't have repeated call to /websocket anymore.

Another possibility is to check if the request is a websocket request and to not open a cursor in that case if we don't have a cookie identifying the test. This cannot be done for all requests since it is possible that some call are made when generating a pdf, or any call that would open a TestCursor without being inside a browser_js or url_open

Combining both solution should hopefully highly reduce this error. 

A final decision was made to also forbid any request coming after a browser_js.
- browser_js is the main source of request reaching the server asynchronously. Other ways to create a request on the server is synchronous with the test and will wait for the result.
- After a browser js, it is unlikely to make another request outside an url_open or browser_js. It was the case for some xmlrpc requests, the dirty solution was to make the test non strict during this request. Those tests could still be a small cause of randomness.

Note: The explicit deletion of the session cookie is also removed, it is not  needed since all cookies are cleared just after, and having a request that could reach the server without session cookies feels a little like a good solution to have random access error.

Forward-Port-Of: odoo/odoo#206510
Forward-Port-Of: odoo/odoo#206006

The issue was introduced by:
https://github.com/odoo/odoo/commit/90158f647ba610b31499555641c9db8450b49c4c

The issue has been fixed by:
https://github.com/odoo/odoo/commit/b1666c61bbc9d7e7b920483e168c6048ecde011c

This commit is adding a test for it.

**Steps to reproduce:**
- Install Accounting and purchase_stock
- Activate a foreign currency (e.g. Euro)
- Create a PO:
  * Vendor: [any]
  * Currency: EUR
  * Product: [any with a Unit Price and a tax]
  * Payment Terms: [any] (e.g. 15 Days)
- Confirm the PO
- Validate the receipt order
- Go to "Accounting / Vendors / Bills"
- Create a new bill
- In "Auto-Complete" field, select the created PO

**Issue:**
A traceback is raised due to a division by zero.

**Cause:**
The bill and its lines are created from some information coming
from the PO.
In the computation of the needed terms of the bill, a computation
of the taxes is called on the lines (i.e. _compute_all_tax).
During that computation, the rate is computed as followed:

(*) rate = line.amount_currency / line.balance if line.balance else line.currency_rate

and later, rate is used as followed:

'balance': tax['amount'] / rate

When "purchase_stock" module is not installed, there is no issue
because "_prepare_account_move_line" method from "purchase.order.
line" model doesn't initialized "amount_currency" nor "balance".
Therefore, the result of (*) falls back on "line.currency_rate"
which is not zero.

However, when "purchase_stock" module is installed, "balance" is
initialized in "_prepare_account_move_line" but not "amount_currency",
leading a result of 0 for (*).

opw-4681735

Forward-Port-Of: odoo/odoo#205233

Unbuilding a returned product will break the stock valuations.

To reproduce the issue:
1. Create a FIFO product
2. Produce
3. Deliver
4. Return
5. Unbuild

Issue: Looking at the remaining qties of the SVL, we see that the
layer of the unbuild didn't consume the quantity of the return. This
may lead to more important issues in the stock valuation.

When processing the unbuild, we `_run_fifo` to consume the existing
SVLs. To do so, we first try to find the candidates. Here is the
problem: since [1], in case of an unbuild, we force to use the SVL
of the MO only. This will not work with the above use case: the SVL
of the MO has been consumed by the delivery. Therefore, we don't
find any candidate. This is the reason why we have some
inconsistencies on the layers.

Instead of getting the SVL of the MO only, we should simply give it
the priority and be able to find some other candidates.

[1] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c

OPW-4683083

Forward-Port-Of: odoo/odoo#206450

Steps to reproduce the issue:

- Add a popup with a 0.0001 days config.
- Visit the page as a non-connected user.
- The popup opens at some point.
- Close the popup.
- Wait 10 seconds.
- Refresh the page ---> The popup never reappears.

This issue comes from the fact that we were setting a non-integer value for the cookie expiration. The "max-age" attribute does not accept float values, so the cookie is treated as a "session" cookie. It only expires when the session ends, which can be effectively "never" on some browsers that keep sessions open indefinitely.

This used to work before commit [1] because we were also setting an "expires" attribute. When the "max-age" attribute was invalid, the browser would fallback to the "expires" attribute. Since that commit removed the "expires" attribute, the only remaining value (max-age) is invalid, and the popup never reappears as expected.

This fix ensures the value used in "max-age" is always an integer, avoiding any invalid cookie behavior.

[1]: https://github.com/odoo/odoo/commit/006ee1fc470eabdcbde68077259cf543633d6490

task-4690318

Forward-Port-Of: odoo/odoo#206429

According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it:

>3.º Principios contables
La contabilidad de la empresa y, en especial, el registro y la valoración de los elementos de las cuentas anuales, se desarrollarán aplicando obligatoriamente los principios contables que se indican a continuación:
>
>1. Empresa en funcionamiento. Se considerará, salvo prueba en contrario, que la gestión de la empresa continuará en un futuro previsible, por lo que la aplicación de los principios y criterios contables no tiene el propósito de determinar el valor del patrimonio neto a efectos de su transmisión global o parcial, ni el importe resultante en caso de liquidación.
>
>En aquellos casos en que no resulte de aplicación este principio, en los términos que se determinen en las normas de desarrollo de este Plan General de Contabilidad, la empresa aplicará las normas de valoración que resulten más adecuadas para reflejar la imagen fiel de las operaciones tendentes a realizar el activo, cancelar las deudas y, en su caso, repartir el patrimonio neto resultante, debiendo suministrar en la memoria de las cuentas anuales toda la información significativa sobre los criterios aplicados.
>
>2. Devengo. Los efectos de las transacciones o hechos económicos se registrarán cuando ocurran, imputándose al ejercicio al que las cuentas anuales se refieran, los gastos y los ingresos que afecten al mismo, con independencia de la fecha de su pago o de su cobro.
>
>3. Uniformidad. Adoptado un criterio dentro de las alternativas que, en su caso, se permitan, deberá mantenerse en el tiempo y aplicarse de manera uniforme para transacciones, otros eventos y condiciones que sean similares, en tanto no se alteren los supuestos que motivaron su elección. De alterarse estos supuestos podrá modificarse el criterio adoptado en su día; en tal caso, estas circunstancias se harán constar en la memoria, indicando la incidencia cuantitativa y cualitativa de la variación sobre las cuentas anuales.
>
> 4. Prudencia. Se deberá ser prudente en las estimaciones y valoraciones a realizar en condiciones de incertidumbre. La prudencia no justifica que la valoración de los elementos patrimoniales no responda a la imagen fiel que deben reflejar las cuentas anuales.
> 
> Asimismo, sin perjuicio de lo dispuesto en el artículo 38 bis del Código de Comercio, únicamente se contabilizarán los beneficios obtenidos hasta la fecha de cierre del ejercicio. Por el contrario, se deberán tener en cuenta todos los riesgos, con origen en el ejercicio o en otro anterior, tan pronto sean conocidos, incluso si sólo se conocieran entre la fecha de cierre de las cuentas anuales y la fecha en que éstas se formulen. En tales casos se dará cumplida información en la memoria, sin perjuicio de su reflejo, cuando se haya generado un pasivo y un gasto, en otros documentos integrantes de las cuentas anuales. Excepcionalmente, si los riesgos se conocieran entre la formulación y antes de la aprobación de las cuentas anuales y afectaran de forma muy significativa a la imagen fiel, las cuentas anuales deberán ser reformuladas.
> 
> Deberán tenerse en cuenta las amortizaciones y correcciones de valor por deterioro de los activos, tanto si el ejercicio se salda con beneficio como con pérdida.
> 
> 5. No compensación. Salvo que una norma disponga de forma expresa lo contrario, no podrán compensarse las partidas del activo y del pasivo o las de gastos e ingresos, y se valorarán separadamente los elementos integrantes de las cuentas anuales.
> 
> 6. Importancia relativa. Se admitirá la no aplicación estricta de algunos de los principios y criterios contables cuando la importancia relativa en términos cuantitativos o cualitativos de la variación que tal hecho produzca sea escasamente significativa y, en consecuencia, no altere la expresión de la imagen fiel. Las partidas o importes cuya importancia relativa sea escasamente significativa podrán aparecer agrupados con otros de similar naturaleza o función.
> 
> En los casos de conflicto entre principios contables, deberá prevalecer el que mejor conduzca a que las cuentas anuales expresen la imagen fiel del patrimonio, de la situación financiera y de los resultados de la empresa.

For item 5, assets and liabilities, income and expenses shall not be offset, unless required or permitted by a standard.

Therefore, group 55 accounts should be presented:

- On the assets side if they have a debit balance.
- On the liabilities side if they have a credit balance.
- Without offsetting each other.

@moduon MT-9820

@chklop @jco-odoo @rafaelbn

Forward-Port-Of: odoo/enterprise#82976