Issue:
-----------------------------------
At certain times of the day (e.g., around midnight UTC), the test would fail deterministically
```
test_allocation_stats_with_duplicate_leave_type_names
    self.assertEqual(leave_type_no_comp.with_context(employee_id=employee_id).max_leaves, 10)
AssertionError: 0.0 != 10
```

Cause:
-----------------------------------
This occurred due to a timezone mismatch during the test execution. When creating the `hr.leave.allocation`, `date_from` implicitly defaults to `fields.Date.context_today(self)` (which evaluates the date based on the test user's timezone, e.g., Europe/Brussels). However, the `max_leaves` computation in `hr.leave.type` evaluates valid allocations using `fields.Date.today()` as the target date (which strictly evaluates to the UTC date)

At certain times of day, this caused the allocation's `date_from` to evaluate to 'tomorrow' relative to the UTC `target_date`. Because the allocation was technically in the future relative to UTC, it was skipped during the computation causing `max_leaves` to return 0.0 instead of 10.

Solution:
-----------------------------------
Explicitly define `'date_from': date.today()` when creating the allocation in the test case. This perfectly aligns the allocation's starting date with the strict UTC evaluation used by the `max_leaves` computation under the hood.

Runbot Error: [937759](https://runbot.odoo.com/odoo/runbot.build.error/937759)
Related PR: https://github.com/odoo/odoo/pull/261680

Steps to reproduce:
----------------------------------------
- Install the l10N_ch localization.
- Create an 8.1% purchase tax (tax included).
- Add the tax created in step 2 to the credit account in wage type 1910.
- Create an employee in the Swiss company and create a certificate type in the wage statement tabulation of the employee record.
- Create a contract for the employee created in step 4.
- Ensure that wage type 1910 is present in the contract created in step 5 and set the contract's status to 'Running'.
- Generate a new payslip for the employee created in step 4.
- Compute the sheet and create the draft entry.
- The tax amount is not calculated correctly.

Cause:
----------------------------------------
In Swiss payslips taxes are always computed as excluded because of [`_prepare_product_base_line_for_taxes_computation()`](https://github.com/odoo/odoo/blob/30b525062fee48a453162e4f8087000b3c7dcd24/addons/account/models/account_move.py#L1510).

Solution:
----------------------------------------
Override `_prepare_product_base_line_for_taxes_computation` and remove the special mode.

opw-4997536

Steps to reproduce:
===================
1. Create 2 pricelists, pricelist 1 is backend-only (no website_id, not selectable), pricelists 2 have website_id set
2. Create a website form creating a customer with a pricelist field
3. Submit the form selecting pricelist 2 (first website-available one)

=> Pricelist reverts to pricelist 1 (the global default)

Cause:
======
When creating a partner via a website form with a specific pricelist, the inverse of `property_product_pricelist` calls
`_get_country_pricelist_multi` to determine the "default" pricelist and decide whether to store the value explicitly or store False (meaning "use the default"). With `website_sale` installed, the search domain hook adds website-availability filtering during website requests. This causes the inverse to compute a different "default" pricelist than what the compute uses outside the website context.

The inverse sees pricelist 2 as the "website default" (first by sequence matching the website domain) and stores False. The compute later runs without website context, finds pricelist 1 as the global default, and returns the wrong value.

Solution:
=========
The fix bypasses website filtering in the search domain hook when called from the inverse, ensuring the stored value is based on the context-independent default.

opw-6092161

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

**problem:**
When taxes are configured as tax-included and a fiscal position remaps them (for example from NL 21% ST to EU intra B2B 0% EX EU G), the computed unit price is stored with excessive decimal digits (e.g 82.644628099...)

**steps to reproduce:**
1. Install `l10n_nl`
2. Switch to the Dutch company/ NL company
3. Ensure fiscal position `EU intra B2B` maps `21% ST` to `0% EX EU G`
4. Set tax `21% ST` as tax included
5. Create a product with sales tax `21% ST`
6. Create a quotation/invoice, apply fiscal position `EU intra B2B`
7. Add the product line (or change fiscal position on an existing line and update taxes)
8. You will see `price_unit` displays too many decimals

**cause:**
In both `sale.order.line._reset_price_unit` and `account.move.line._compute_price_unit` unit prices coming from tax-included remapping are written directly to price_unit. https://github.com/odoo/odoo/blob/7302b504fc03583944f4dff947cf9725fec9a75b/addons/sale/models/sale_order_line.py#L598-L602 https://github.com/odoo/odoo/blob/7302b504fc03583944f4dff947cf9725fec9a75b/addons/account/models/account_move_line.py#L871-L878

The tax remapping path uses tax detail computations with 'global' rounding to preserve fiscal accuracy during conversion, but the resulting `price_unit` was written back without currency rounding. https://github.com/odoo/odoo/blob/7302b504fc03583944f4dff947cf9725fec9a75b/addons/account/models/account_tax.py#L1303-L1310

**fix:**
- Round computed `price_unit` with document currency precision before storing in both sale_order_line, account_move_line.
- In `account.move.action_update_fpos_values`, recompute from untaxed base when tax include mode changes, then round with currency precision. (We do this change to ensure behavior is consistent, when changing fiscal position and clicking "update taxes" on already existent quotations/invoices"

opw-6081856

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

Why this commit:
---

There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format.

Since Odoo already defines a standard date format, all toLocaleString() usages in pos should be replaced to ensure consistency.

Starting from version 17.0, cash in/out receipts and the sales report use the local device time format.

This commit updates those references and aligns them with the Odoo-configured date format. 
During forwardporting the fix in version 19.0 needs to be added to [base.js](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/models/related_models/base.js#L64-L69).
As formatDateOrTime function is used in the [reciept header](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L13) printing date on all reciepts. 

After this commit:
---

<img width="947" height="982" alt="image" src="https://github.com/user-attachments/assets/2d9e4199-75dd-40ea-aeb1-27401c9022f3" />


All date references consistently use the Odoo-configured date format.

OPW: 6087341





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

Forward-Port-Of: odoo/odoo#259112

Currently, error occurs when user removes date on Accrued Expense Entry wizard.

Steps to replicate:
- Install `purchase` and `accountant` with demo.
- Open any Purchase Order > Click on cog menu > Accrued Expense Entry.
- Remove value from `date` and click else where.

Error:
```
  File '/home/odoo/odoo19/community/addons/account/wizard/accrued_orders.py', line 67, in _compute_reversal_date
    if not record.reversal_date or record.reversal_date <= record.date:
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'

```

Cause:
- As the user removed value from `date`, [here] `record.date` is received as False.
- As a result the comparison `record.reversal_date <= record.date` causes this error to occur.

Solution:
- Added a conditional check for `date` before the date comparison.

[here]: https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/account/wizard/accrued_orders.py#L67

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

The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency

Steps to reproduce:
1. Install Sales
2. Go to Invoicing > Configuration > Accounting > Currencies and activate currency MXN
3. Go to Sales > Products > Pricelists and create a new pricelist for currency MXN
4. Go to Sales > Products and create a new combo product "test"
5. Create a combo choice "combo" with options "Large Cabinet" and extra price 10000$
6. Go to Sales and create a new quotation for customer Acme Corporation with product "test" (total is $10,001)
7. Change the pricelist to MXN and update prices
8. The total is ~MX$10,018 (it should be ~MX$186,682)

Issue:
The extra price of a combo product is not converted to the sale order's pricelist currency, so we end up adding the price of the product in the order's currency with the extra price not converted

Solution:
Convert the extra price of the combo product to the sale order's pricelist currency

opw-6192935

**Problem**:
When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few available serial numbers will be added to the move, which causes a mismatch of quantity and the number of serial numbers.

**Before this commit:**
If we have three serial number SN-001, SN-002, SN-003 created in order, and we set the quantity of the move to zero, then add SN-002 and SN-003 manually, SN-001 will be added automatically while saving.

**After this commit:**
Only SN-002 and SN-003 will be added to the move, which matches the quantity.

**Steps to reproduce:**
1. Create a product with tracking by unique serial number, and create 3 lots SN-001, SN-002, SN-003 for this product.
2. Create a picking and add a move for this product, set the demand to 3 and quantity to 0.
3. Set the quantity to 2, and add SN-002 and SN-003 to the move, then save the picking.
4. SN-001 will be added to the move automatically, but the quantity stays at 2.

opw-6121208

**Steps to reproduce:**
- Go to Documents app in mobile
- Go to the kanban view
- Add some files and select one
- Click on `Info & Tags` button in the control panel
- Reload the page
- Chatter is not displayed but the button is still enabled
- Switching to the list view properly shows it

**Issue:**
We have two conflicting css styling on mobile:
- `overflow-hidden` was added for mobile to avoid multiple scroll bars
- `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css

This means that the element is present at the bottom of the page, but we can't get to it manually.
When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top).

Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter.

**Fix:**
Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed.

original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd

opw-6061993