The aim of this PR is to prevent errors in the account_followup tests because of the symbol on the company currency. If the company currency is changed for some reason (for example USD dollar to "USD" instead of "$" as typically used in Odoo), the test will fail raising an error similar to the following:
`[odoo.addons.account_followup.tests.test_followup_report:184](https://github.com/adhoc-cicd/odoo-enterprise/blob/74a5097e1d6ab79eb31ed302865aa075162494c2/account_followup/tests/test_followup_report.py#L184)
FAIL: TestAccountFollowupReports.test_followup_lines_branches
Traceback (most recent call last):
  File "/data/build/adhoc-cicd-odoo-enterprise/account_followup/tests/test_followup_report.py", line 184, in test_followup_lines_branches
    self.assertLinesValues(
  File "/data/build/adhoc-cicd-odoo-enterprise/account_reports/tests/common.py", line 273, in assertLinesValues
    self.fail('\n'.join(errors))
AssertionError: 
==== Differences at index 0 ====
Current Values:  ['INV/2016/00001', '01/01/2016', '01/01/2016', '', 'USD\xa0500.00']
Expected Values: ['INV/2016/00001', '01/01/2016', '01/01/2016', '', '$\xa0500.00']
==== Differences at index 1 ====
Current Values:  ['', '', '', '', 'USD\xa0500.00']
Expected Values: ['', '', '', '', '$\xa0500.00']
==== Differences at index 2 ====
Current Values:  ['', '', '', '', 'USD\xa0500.00']
Expected Values: ['', '', '', '', '$\xa0500.00']`
That's the reason why I refactor the test to first fetch the company currency symbol and then used it in the test assertions.

Steps:
------
1. Create a combo product and make it available in restaurant
2. In PoS, add this product to an order
3. Click the product line, and set the quantity to 2 let's
4. Click split button, it takes you to the split screen

Observation: We can not select one of these 2 combos to split, it's either all of them, or none.

Reason:
-------
That's because combos are considered as non groupable in pos, see `is_pos_groupable` [1]. And then, when splitting a combo in `_splitQuantity` [2], we either take all the quantity or 0.

Fix:
----
We update the split logic to account for special combo cases.

[1]: https://github.com/odoo/odoo/blob/bee8b55d7783ea11f2362990cd9d7695b877b8e9/addons/point_of_sale/static/src/app/store/models.js#L829
[2]: https://github.com/odoo/odoo/blob/bee8b55d7783ea11f2362990cd9d7695b877b8e9/addons/pos_restaurant/static/src/app/split_bill_screen/split_bill_screen.js#L124-L127

opw-4737788

Forward-Port-Of: odoo/odoo#208266
Forward-Port-Of: odoo/odoo#208055

PROBLEM 1:

Steps to reproduce:
- Create branch company
- Create a user for the branch company and assign the bookkeeper role
- Log in as the newly created user
- Inside accounting module navigate to Vendor menu -> Payment
- Create a payment and set the amount
- Attempt to edit the payment

Error:- Access Error: Access to unauthorized or invalid companies.

Cause:
Before this pr, the context passed during the accessible branches
calculation included 'journal_id.company_id' (i.e., the parent company_id). This
led to an error during validation in the companies method of the env class,
since the parent company_id is not valid for branch-specific operations/users.

Solution:
After this pr, remove the context modification introduced by the
'with_company()' method during the invocation of '_accessible_branches()',
ensuring that the correct branch context is used for access validation.

PROBLEM 2:

Steps to reproduce:
- First 3 steps are same as problem 1
- Inside accounting module navigate to bank reconciliation list view
- Create new bank statement line
- Attempt to edit the bank statement line

Error:- Access Error: because of company rule employee

Cause:
Before this pr, in the '_synchronize_to_moves' method the 'company_currency'
calculation   included 'journal.company_id.currency_id' in which
'journal.company_id' is the parent company_id to which the user does not have
access.

Solution:
After this pr, adding 'sudo()' method call at the time of accessing
'journal.comapny_id' (i.e., parent company_id) for bypassing the access rights.

Task - 4654866

Forward-Port-Of: odoo/odoo#205548

## Description
I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records.

Currently, my company has around 20 million `stock.valuation.layer` records. As a result, any transaction involving incoming stock takes approximately 5–21 seconds to complete, even for a small number of products (around 1–5 products).

Through profiling, I have identified that the root cause is the compute function `_compute_value_svl`. This computed field is always triggered during incoming stock transactions when calculating the average cost or fixing rounding errors.

## Proposal
To improve performance, I propose implementing a Parallel Index-Only Scan. This method is effective for grouping large datasets while retrieving only fixed columns, optimizing query execution.

## Benchmark
| Before | After | Speedup |
|--------|--------|--------|
| 1.1 s| 97.8 ms | 11x| 

### Before
```
Finalize GroupAggregate  (cost=1000.56..397852.39 rows=538 width=80) (actual time=1040.355..1114.694 rows=1 loops=1)
  Group Key: product_id
  Buffers: shared hit=227534 read=330906 dirtied=83 written=683
  ->  Gather  (cost=1000.56..397825.49 rows=1076 width=80) (actual time=1039.900..1114.679 rows=3 loops=1)
        Workers Planned: 2
        Workers Launched: 2
        Buffers: shared hit=227534 read=330906 dirtied=83 written=683
        ->  Partial GroupAggregate  (cost=0.56..396717.89 rows=538 width=80) (actual time=1036.758..1036.759 rows=1 loops=3)
              Group Key: product_id
              Buffers: shared hit=227534 read=330906 dirtied=83 written=683
              ->  Parallel Index Scan using stock_valuation_layer_index on stock_valuation_layer  
                    (cost=0.56..392927.16 rows=302613 width=20) (actual time=0.608..975.431 rows=247487 loops=3)
                    Index Cond: ((product_id = 140) AND (company_id = 1))
                    Buffers: shared hit=227534 read=330906 dirtied=83 written=683
Planning:
  Buffers: shared hit=9 dirtied=1
Planning Time: 0.139 ms
Execution Time: 1114.732 ms
``` 

### After
```
Finalize GroupAggregate  (cost=1000.56..21876.83 rows=538 width=80) (actual time=91.888..97.719 rows=1 loops=1)
  Group Key: product_id
  Buffers: shared hit=12889 read=7121
  ->  Gather  (cost=1000.56..21849.93 rows=1076 width=80) (actual time=91.636..97.704 rows=3 loops=1)
        Workers Planned: 2
        Workers Launched: 2
        Buffers: shared hit=12889 read=7121
        ->  Partial GroupAggregate  (cost=0.56..20742.33 rows=538 width=80) (actual time=87.579..87.580 rows=1 loops=3)
              Group Key: product_id
              Buffers: shared hit=12889 read=7121
              ->  Parallel Index Only Scan using idx_svl_company_product on stock_valuation_layer  
                    (cost=0.56..16951.60 rows=302613 width=20) (actual time=0.044..46.642 rows=247487 loops=3)
                    Index Cond: ((company_id = 1) AND (product_id = 140))
                    Heap Fetches: 9188
                    Buffers: shared hit=12889 read=7121
Planning Time: 0.107 ms
Execution Time: 97.751 ms
``` 
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#206587
Forward-Port-Of: odoo/odoo#203038

#### [FIX] account_accountant: reco wizard: exchange rate rounding
In the related community commit we improved the reconciliation
behavior with regards to exchange rate and rounding issues.
See there for more details.

For one of the tests there we manually created the write-off line with the
correct amount.
Here we add a test to check that the wizard computes the right amounts
for the write-off line / entry.

opw-4438542

#### [FIX] account_accountant: reco wizard: show company amount
The reconciliation wizard may create a write-off line / entry.
Roughly speaking this happens in case
- the amount of the input lines does not sum to 0
- and the "Allow partials" option is not ticked

The write-off line can be in foreign currency.
Currently the wizard only displays the amount in foreign currency but
not the amount in company currency.
So currently the company currency amount can not be checked before reconciling.

After this commit the wizard also displays the amount in company currency.

opw-4623933

Forward-Port-Of: odoo/enterprise#84652
Forward-Port-Of: odoo/enterprise#82865

If you have a company A that has a journal set up with bank synchronization, and a company B that is a branch of company A, you have access to the journal and the bank synchronization (account.online.link) of company A in company B.

This causes an issue when fetching the transactions from the context of company B, as that will create the fetched transactions with a `company_id` set to B, which will cascade on the journal entries and items linked to these transactions.

To ensure the correct company is set on the transactions, we force the company in the context when creating them.

As a result:
- When only company A is selected, transactions are correctly created in company A.
- When both company are selected, no matter if the transactions are fetched from A or B, the transactions are correctly created in company A.
- When only company B is selected, the user is faced with an access error, as Odoo is trying to open a view with the fecthed transaction, which belong to company A.

To prevent this access error, it was decided that the "Fetch Transaction" buttons should not appear when the company owning the bank synchronization is not selected.

A new computed field was then introduced on the account.online.account to check if we should allow fetching given the currenctly selected companies. That field is also added on the account.online.link as a logical conjunction of its account.online.account values of the field.

These fields are then used to decide whether if we show the transaction fetching buttons on the dashboard and on the online link form view.

Another issue with branches is the 'connect bank' button.

With the same configuration as above, let's have companies A and B enabled, with B as the selected company.

If you connect a bank to a journal belonging to company A by clicking on the 'connect bank' button on the dashboard, it will successfully connect, but the account.online.link will belong to company B.
Then, if you try to access the accounting dashboard with only company A enabled, you will be faced with an access error, as the journal from company A tries to diplay informations computed with the above account.online.link of company B.

To prevent this, we only make the 'connect bank' button appear if company A (i.e. the company owning the journal) is selected as the active company.

This did not require a new field, and was done by adding an entry in the dashboard data.

opw-4515862

Forward-Port-Of: odoo/enterprise#84363
Forward-Port-Of: odoo/enterprise#83134

Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both `l10n_ke_edi_oscu` and and `l10n_br_edi_pos` recent mock setup as an example, this PR aims to mock the soap requests sent in the module.

Notes:
- As of now this is only one individual test case. More tests will come as there is time, but having 1 will prevent errors from happening again.

- Within this module, when the first record within an EDI journal is created, it will try to pull the sequence from the database, and if it can't find a suitable last sequence, it will query the API. This means that any onchange on the first journal entry that will recompute the name or sequence leads to the `_get_last_sequence` function being called and making an API request as the sequence isn't stored in the database yet.

  The point of this appears to be convenience when transfering from another system to odoo and pulling the latest invoice number they had. The main downside of this feature is that creating the first record now
has around 5 API calls returning the same value due to different onchanges on the record.

  The main calls come from `_compute_name` in the base account module but the rest are from other methods that use the sequence or call `_compute_name` (like `_onchange_l10n_latam_document_type_id`)

  As this PR is only intended to write tests for the module, the test file matches what occurs in the front-end but future PRs can look into if there are improvements that can be made on stable to simplify this.

task-4714096

Forward-Port-Of: odoo/enterprise#84704
Forward-Port-Of: odoo/enterprise#83553

Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order.

**Steps to reproduce:**
- Open a POS session for the **Restaurant** shop.
- Select a table, add the food (e.g., "Cheese Burger") and place the order.
- Add an `Internal Note` to the ordered food item.
- Remove the food item and click the `Order` button (it shows '-1 Food').
- Observe the error.

**Error:**
`KeyError: 'qty'`

The issue occurs because when all food items are removed, `note_history` does not contain the `qty` key and it attempts to access `qty` from `note` at [1].

This commit resolves the issue by adding an additional check to ensure that 'qty' is in `note` before accessing the `qty` key.

[1] - https://github.com/odoo/enterprise/blob/f1615134029860d32b95ade09738549a7bb1632d/pos_preparation_display/models/pos_order.py#L79-L80

Sentry - 6303446407

Forward-Port-Of: odoo/enterprise#80924
Forward-Port-Of: odoo/enterprise#79685