In expenses, we want to keep the tax included in price. Even if the tax
is defined as not included in price we force the computation to be price
included. However, with specific combination of price and tax amount,
the computation result in amount not rounded correctly.
As result, users trying to post journal entry from expense report may face an
"Unbalanced Entry" error.
Steps to reproduce:
- With Canadian accounting set up in Canadian company
- Set rounding method to "Round globally"
- Create an expense:
  - Add total: 77.87 CAD
  - Use tax: 14.975 GST+QST
  - Paid By: Company
- Create Report > Submit to manager > Approve

Error will raise
```
The move (Draft Entry  (test)) is not balanced.
The total of debits equals 77.87 $ and the total of credits equals 77.87 $.
You might want to specify a default account on journal "Bank" to automatically balance each move.
```

In this specific configuration, we get tax values from unrounded computations, i.e. we set `amount_currency`
to 67.72776690584911, that will be stored as 67.73. However, from the expense report
we compute a (correct) balance of 67.72, when the move line is created the balance will be
updated from this amount (currency is company currency), so the move balance will be off, raising the error

opw-4148134

The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at the end of the fiscal year the operation was made in.

Current rate currency translation is still applied like before when CTA is not enabled on the report.

task-4270102

==========================================================================

[IMP] account_reports: currency table: add test case
If a period containing some res.currency.rate object starts by some sub-period without any range, the average rate computation considered this sub-period as having a rate of 0. It's wrong; it should be 1.

The fix itself is in the corresponding community commit ; this one adds a check ensuring this doesn't break again in the future.

Fixing this also revealed an issue in the Trial Balance, where the initial balance column group was computed with different rates than the rest of the report, which is not what we want for this instance. We fix that by properly setting the period_key on all of its column groups and ensuring the initial balance dates have no impact on the currency table.

Steps to reproduce:

- Open Firefox.
- Type a few characters.
- Add a space after the characters.
- Press backspace.
- Observe that both the space and the last visible character are removed.

Description of the issue/feature this PR addresses:

- In Chrome, pressing space inserts a `&nbsp` (non-breaking space, `U+00A0`), which is treated as a visible character by `isVisibleChar`. Thus, only the whitespace is removed when backspace is pressed.

- In Firefox, pressing space inserts a regular space (`U+0020`), which `isVisibleChar` identifies as invisible. As a result, the backspace action incorrectly calculates the range and removes both the space and the preceding character.

Character details:

- Chrome: `char.charCodeAt(0).toString(16)` → `U+00A0`
- Firefox: `char.charCodeAt(0).toString(16)` → `U+0020`

Desired behavior after PR is merged:

- In Firefox, pressing backspace after a whitespace removes only the invisible character without affecting the preceding visible character.

task-4363847

Problem
---------
1 - Open Odoo 18.0
2 - install l10n_hu_edi
3 - switch to "HU Company"
4 - create an outgoing normal invoice with other than HUF currency
5 - put items, taxes, select partner, etc.
6 - print the invoice
-> KeyError: 'formatted_total_vat_amount_in_huf'

The issue occurs because, in multi-currency, the method
`_l10n_hu_get_invoice_totals_for_report` is expected to add
`total_vat_amount_in_huf` to the tax dictionary as required by the 
invoice template.

However, currently, the said method only adds `total_vat_amount_in_huf`
for credit notes / refunds, in other cases, it stops early and does not
add the required key-value pair in the dictionary.

Solution
---------
Make sure the method always adds `total_vat_amount_in_huf` to the tax
dictionary, while making sure that it only reverses the tax values when
it is rendering a credit note / refund like before.

task-4391659

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

Versions
--------
- 18.0+

Steps
-----
1. Go to eCommerce;
2. go to a product with attributes;
3. open the editor;
4. set specification to display in accordion;
5. enable "Compare" option on Cart.

Issue
-----
> 500: Internal Server Error
> Error while render the template
> TypeError: tuple indices must be integers or slices, not product.public.category
> Template: website_sale_comparison.specifications_table

Cause
-----
The `categories` value set in this template contains an ordered dict with `product.attribute.category` records as keys, and `product.template.attribute.line` records as values.

When inserting its logic into the `website_sale` template, its variable name conlficts with the `categories` value returned by the `WebsiteSale` controller, which contains `product.public.category` records.

The issue occurs when it tries to use a `product.attribute.category` record to index a `product.public.category` recordset.

Solution
--------
Rename the `categories` variable to `attrib_categories` in the `website_sale_comparison` template.

opw-4356669

In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.:

```
Charleston Co Educational Capital Improvements Tax (Special) at 1%
Charleston Co Tt (Special) at 1%
```

But `find_or_create_tax()` maps both of them to SC SPECIAL 1%.

This doesn't cause issues for invoice_line_ids, those amounts are correct. But the journal items are not because there's only one tax journal item for this tax and its summary total gets overwritten instead of added to. This leads to the total on the invoice not matching the sum of debits/credits in the journal items tab.

Fix it by adding to the summary total instead of overwriting it.

PS. An alternative solution is to create unique tax names by incorporating the jurisCode and possibly other relevant fields. This approach would enhance the accuracy of tax representation on invoices. However, historically, we have prioritized brevity over accuracy [1].

[1] https://github.com/odoo/enterprise/pull/68549

### Steps to Reproduce
* Navigate to the Employees app and set a PIN code for Mark Demo
* In the Manufacturing app, assing a work order to Mark Demo and another to Michael Admin
* Open the Shop Floor interface, adding Michael Admin and Mark Demo as active employees
* Click on the My WO filter and select Michael
* Switch to Mark Demo and enter his PIN code

### Current Behavior
* The work orders assigned to Michael are displayed for Mark, even with the My WO filter enabled.

### Expected Behavior
Only the work orders assigned to Mark should be
displayed

### Reason
This issue occurs when a PIN is activated for an employee. When the PIN validation pop-up is displayed, the cache cleanup is performed for the previously logged-in user rather than the newly connected user. Consequently, the old user's workorders remain visible because the cache is not refreshed correctly.

### Fix
Ensure that the cache is cleared only after the PIN is successfully validated and the user is connected. Additionally, verify that the My WO filter corresponds to the newly connected user before updating the cache. This will ensure that only the relevant work orders are displayed.

opw-4256568

In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed.

Steps to reproduce:

1.  In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order.
2.  Add another order with the same product and internal note but with a quantity of 5.
3.  In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready."
4.  In the POS, reduce the quantity of the second order line (quantity 5) to 4.

Issue: The system reduces the quantity of the first display line (the one in the "Ready" stage).

Cause: In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. However, since there is no 1-to-1 relation between display lines and order lines, it is impossible to directly target specific display lines.

Fix: After this commit, display lines are now sorted based on their stage. Priority for quantity reduction is given to the line in the earliest stage. 

opw-4354093