Steps to reproduce:
- Install payroll, payroll Mexican localisation
- Switch to the Mexican company
- Choose an employee from the Mexican company
- Change the contract to be hourly waged instead of monthly
- Set a value for the wage/hour
- Create some work entries for that employee
- Generate a payslip for the employee in the duration you are testing
- Edit the work entries you have to have some unpaid leaves
- Generate another payslip for the employee

Current Behavior:
Payslip is generated without taking into consideration the number of hours actually worked and the unpaid leaves taken by the employee. It also generates the payslip with the value of the wage/month regardless of the value of the wage/hour you added.

Issue:
In df8f53b0cad4738537f18890e628c286dedaa141, Mexican localisation was implemented but with computing the amount of the `payslip_worked_days` using the `contract.wage` which is the fixed amount of wage/month.

https://github.com/odoo/enterprise/blob/25caeeab01abc0b47f6bd6b02658c3bbbe0aba96/l10n_mx_hr_payroll_localisation/models/hr_payslip_worked_days.py#L19-L20

opw-4604675

Forward-Port-Of: odoo/enterprise#83135

Before this commit, a "translation hash" was calculated and added to the
session_info. The method used to compute the hash needs to compute the
translations, which can be slow, and only the hash is cached. This hash is then
used by the client to fetch the translations twice. Once directly in the page
template, and once in the localization service. This is done to get the
translations as quickly as possible. Normally, the browser cache should prevent
from the second request from being made (since the hash is the same), but this
doesn't always seem to work as expected, as all requests are started as soon as
possible, so if there is a small delay in the first request the second is also
be made. So in the worst case scenario, translations are calculated 3 times by
the server, and the web client waits for them to finish before rendering.

Now, a translation hash is no longer calculated to be placed in session_info,
speeding up session_info and the page. The translation hash is sent to the web client
with the translations themselves.

Only the first time, the web client will waits for the translations to be
rendered. The next time the user accesses the web client, the cached
translations are used. Each time the user accesses the web client, the
translations are fetched. If a cached translation exists, the hash of the
cached translation is used to fetch the translations. The new route computes
the current hash of the translations, compares it with the one it received and
if it's the same simply replies that there has been no change; if the hash is
different, it replies with the computed translations and the new hash.
Note that when the hash is computed, the translations are kept in a cache to
avoid having to compute the translations twice.

opw-4737228

Co-authored-by: Rémy Voet <ryv@odoo.com>

A traceback occurs when attempting to view the 'Hierarchy and Subtotals' of an
Account Group with a Financial Budget set in the 'Profit and Loss' report.

Steps to reproduce:
-------------------
* Open Accounting in debug mode
* In Configuration > Accounting > Financial Budgets create a new budget
* In Configuration > Accounting > Account Groups  create a new group
* Open Reporting > Statement Report > Profit and Loss
* Select the budget and Hierarchy and Subtotals
* Click on Revenues
* Traceback

> Observation: 
  File '/home/odoo/src/enterprise/18.0/account_reports/models/account_report.py', line 1035, in compute_group_totals
  hierarchy_total + (column.get('no_format') or 0.0) if isinstance(hierarchy_total, float) else hierarchy_total
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  TypeError: unsupported operand type(s) for +: 'float' and 'str'


Why the fix:
------------
Add float verification to ensure valid operation in the hierarchy.

opw-4628498

Forward-Port-Of: odoo/enterprise#84564
Forward-Port-Of: odoo/enterprise#83302

MyDATA is a platform created by Greece's tax authority, The Independent Authority for Public Revenue (IAPR), to digitize business tax and accounting information declaration. All companies performing accounting, according to Greek accounting standards, will be required to transmit the information to the myDATA platform beginning in July of 2021.

- Customer Invoices

Customer Invoice form for Greece companies will now have a few fields required for specifying classification data to be send to MyDATA.

In the Send & Print Wizard, a checkbox "Send to MyDATA"is added, and when activated, Odoo will generate an XML of the selected invoice(s) and send them to the MyDATA API.

Any errors detected before and after the send will then be saved in a document object, displayed in the 'myDATA' tab in the move form view.

- Vendor Bills

In Greece, one's expense is another's invoice. When reporting to MyDATA for our expense classification, we need to fetch the invoice(s) issue by third-party issuer, fill the classification needed and send them back to MyDATA.

To implement this behavior, we created a daily cron to fetch xml data from MyDATA related to the designated Greece companies, and create draft vendor bills based on that data. The user can then fill the myDATA classification data needed and send them back to MyDATA via a button in vendor bills view form after confirming the bill.

task-id: 3358316

**Steps to reproduce:**
- Install Accounting and l10n_es_edi_sii
- Switch to a Spanish company (e.g. ES Company)
- Create an invoice:
  * Customer: [a Spanish customer] (e.g. Ayuntamiento De Bilbao)
  * 1 invoice line with a "Sujeto" type tax (e.g. "4% G") and a "Recargo de Equivalencia" type tax (e.g. "0.5% SE")
  * another invoice line with the same taxes
- Confirm the invoice
- Send the invoice to "SII IVA Llevanza de libros registro (ES)"
- Check the sent "jsondump.json" file in the attachments

**Issue:**
Value of "CuotaRecargoEquivalencia" in the json is incorrect. It only contains the tax amount of the "Recargo de Equivalencia" tax (i.e. "0.5% SE") of the second line, instead of the sum of the tax amount from both lines.

**Cause:**
When computing the details for the "Recargo de Equivalencia" taxes, each invoice line is grouped by their combination of taxes.
For each combination, we keep the tax details of the recargo tax of one line (the latest one) overriding the previous values, instead of summing them.

**Solution:**
Sum the tax amount for each group of taxes.

opw-4650892




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

## Version:
18.0 > 18.1 (test to fw up to master)
18.2+ fixed by https://github.com/odoo/odoo/pull/186649

## Issue:
Changing the `Quotation Template` on a quotation after

## Steps to reproduce:
*Ensure `PDF Quote builder` is checked in `Settings` app*
- In `Sales / Configuration / Sales Orders:Headers/Footers`:
  - Ensure there are at least 2 documents *(add them if needed)*;
  - Set their `Document type` to `Header`;
- Go to `Sales / Configuration / Sales Orders:Quotation Templates`:
  - Create 2 new templates (e.g. "test1" and "test2"):
    - In "test1", under the `Quote Builder`, add one of the documents;
    - In "test2", under the `Quote Builder`, add the second document;
- Create a new quote for any customer:
  - Select "test1" as `Quotation Template`;
  - Under the `Quote Builder`, select the header document;
  - Change the `Quotation Template` for "test2";
  - Select the header document;
  - Change back to "test1" and see the header document is still selected;
  - Print the quote via the action button;
  - The PDF contains both "test1" and "test2" document headers.

## Fix:
Partial backport of https://github.com/odoo/odoo/pull/186649

opw-4709144

Before PRs https://github.com/odoo/odoo/pull/154912 and https://github.com/odoo/odoo/pull/177079, _free_reservation preserved MTO links by
retaining move_orig_ids, allowing Manufacturing Orders (MOs) to reserve
components from replenishment pickings.
PR https://github.com/odoo/odoo/pull/149054 added replenishment moves to the MO’s procurement.group and
assigned move_dest_ids to link them to component moves, supporting 2-step
manufacturing flows.
PR https://github.com/odoo/odoo/pull/154912 introduced the stock.break_mto parameter to conditionally preserve
move_orig_ids, while PR https://github.com/odoo/odoo/pull/177079 removed it, making move_orig_ids clearing
unconditional for MTO-to-MTS transitions, reintroducing a regression due to
the move_dest_ids assignment.

Steps to Reproduce
===================
1. Create an MO with a component qty of 20 units and confirm it.
2. Scrap 5 units of the component with Replenish enabled.
3. Validate the replenishment transfer.
4. Check the MO component line. The component qty is reduced to 5.

Issue
=====
The move_dest_ids assignment to replenishment moves (from https://github.com/odoo/odoo/pull/149054) prevents
 _trigger_assign from reserving correct MO component quantities when
move_orig_ids are cleared (per https://github.com/odoo/odoo/pull/177079), as the link to the original MO
requirements is broken.

Fix
===
Removed the move_dest_ids assignment for replenish moves enabling trigger_assign
to automatically reserve the correct component quantities, while maintaining the
MTO-to-MTS transition (cleared move_orig_ids) and the procurement.group
assignment.

Task: https://github.com/odoo/odoo/commit/44437975bdaf1e7c4f5540a5cb789d9db0ec0b0b

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.

Currently the reconciliation may create unnecessary exchange difference entries or have unnecessary residual amounts.
This can happen in case we try to reconcile lines with multiple currencies.

Consider e.g. the following case (c.f. the added test cases in the code):
company currency: EUR
foreign currency: USD
rate: 1 EUR = 18.8777 USD (1 USD = 0.052972554919 EUR)
rounding: Both EUR and USD are rounded to 2 decimal places (to 0.01)

Lines to reconicle:
line0 |   20000.00 USD |  377554.00 EUR
line1 | -372239.38 EUR | -372239.38 EUR

Perfect write-off line for a full reconciliation (w/o exchange difference or remaining residuals)
line2 |    -281.53 USD |   -5314.62 EUR

Since
EUR: 377554.00 + -372239.38 = 5314.62
USD: 200000.00 + USD.round(-372239.38 * 0.052972554919) = 200000.00 + USD.round(-19718.47100006451) = 281.53

Note the actually used exchange rates during the reconciliation are not necessarily the ones from the currencies.
They could also be (re)computed from the lines.

Note that the "reconciliation currency" may be choosen differently in the following cases
- the reconciled account is a payable (`liability_payable`) or receivable (`asset_receivable`) account
- the reconciled account has another type

In the code see
- `recon_currency` in `_prepare_reconciliation_single_partial`
- `is_rec_pay_account` in `_prepare_move_line_residual_amounts`

#### Problem (1); receivable / payable account & partial reconciliation
In this case we reconcile line0 and line1 and the account on the lines is either a payable or a receivable account.

The following happens
1. Due to the account type we try to match the foreign currency (USD) amounts.
   line1: 20000.00 USD
   line2: 19718.47 USD (= USD.round(-372239.38 * ≈0.052972554919) = USD.round(-19718.47100006451))
   USD: 19718.47 (= min(20000.00, 19718.47))
2. Use the exchange rate (from line0) to compute the value in EUR (company currency)
   EUR: 372239.36 (= EUR.round(19718.47 * ≈18.8777) = EUR.round(372239.36111900007))
3. We still have a residual of 0.02 EUR on line1.
   But since line2 was fully matched in step 1 we create an exchange difference entry
   (to cover for the residual in company currency)

Issue:
We could have matched 372239.38 EUR on both lines since the difference (0.02 EUR) is just a rounding error.
Here 372239.38 EUR represents the full remaining amount in company currency on line1.
Then there would have been no residual (and thus no need for an exchange difference entry)

#### Problem (2); other account type & try full reconciliation with correct write-off line
In this case we reconcile line0 and line1 and line2 and the account on the lines is neither payable nor receivable.

First the reconciliation will reconcile line0 and line2 (roughly speaking since they have the same foreign currency).
1. Since both are in foreign currency we try to match these amounts first:
   USD: 281.53 (= min(20000.00, 281.53))
2. We then use the exchange rate to compute the value in EUR (company currency)
   line0, EUR: 5314.64 (= EUR.round(281.53 * ≈18.8777) = EUR.round(5314.638881))
   line2, EUR: 5314.62 (281.53 converted via the "custom" rate on line2)
3. We now have the following residuals
   line0 (residuals) |   19718.47 USD |  372239.36 EUR
   line2 (residuals) |       0.00 USD |       0.00 EUR
   We substracted 5314.64 EUR from line0 but only 5314.62 EUR from line2.
4. To account for the difference we create an exchange difference entry

We could have matched 5314.62 EUR on both lines (since the difference is just a rounding error)
This way we could void the exchange difference entry.
And we would also have a "correct" residual on line0.
The residuals on line0 will cause the full reconciliation to fail (see below).

Next the reconciliation will match line1 with the residuals of line0
The following happens.
1. We try to match company currency amounts first (due to the account type)
   line0, EUR: 372239.36
   line1, EUR: 372239.38
   EUR: 372239.36 = min(372239.38, 372239.36)
2. Compute the amounts in currency
   line0, USD:  19718.47 (= USD.round(372239.36 * ≈0.052972554919))
   line1, EUR: 372239.36 (= 372239.36 * 1)
3. We now have the following residuals
   line0 (residuals) |       0.00 USD |       0.02 EUR
   line1 (residuals) |       0.00 USD |       0.00 EUR
4. The reconciliation ends without creating an exchange difference entry

#### Solution

Problem (1)
In case the remaining amount (in company currency) could be fully matched if not for rounding issues
we will just match the full remaining amount.

Problem (2)
We match the company currency amounts of the individual lines to a common value if they are the same up to exchange rounding issues.

#### References

opw-4438542

Forward-Port-Of: odoo/odoo#208371
Forward-Port-Of: odoo/odoo#204746

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