Steps to reproduce:
1. Ensure you have a good amount of contacts set up in your database
2. Ensure that you have an IAP Account setup for the service "Partner Autocomplete"
3. Zoom in on your browser to at least 150% AND/OR make your browser window incredibly short
4. Go to the CRM app
5. Go into the form view of an opportunity
6. Type 3 characters or more into the 'Contact' field
7. Observe the error

An Unhandled Promise error could occur if, after typing more than 3 characters in an autocomplete field, the dropdown is scrollable, and Partner Autocomplete finishes loading before the normal autocomplete does. In this scenario, normal autocomplete is still loading and has not rendered it's options. This causes a `null` element to be passed [`scrollTo()`](https://github.com/odoo/odoo/blob/555df96ac87a51405767c32f0396f762d458fd29/addons/web/static/src/core/utils/scrolling.js#L80), which causes an error when it tries to access `element.parentElement`. This change ensures that this scenario is properly handled and does not cause the database to crash.

opw-5491270

Forward-Port-Of: odoo/odoo#247270

Description of the issue/feature this PR addresses:
This PR addressed two issues, one related to pos_sale, and the other related to l10n_gcc_invoice that was found during testing.

the first and main issue this PR addresses is that _get_downpayment_lines and _is_downpayment don't work properly on downpayment and final invoices generated in POS since there is no link formed between them through the sale order.

the second issue occurs during when printing downpayment invoices that were made through POS. since there is no line.name for the downpayment line. an error pops up due to the dual language logic in place.

To reproduce the issue:
- install pos_sale & l10n_sa_edi_pos.
- configure downpayment product on pos.config
- generate an SO and confirm it in the backend
- create a downpayment for that SO through POS
- settle the SO on the POS or through the backend.
- you'll find that the final invoice generated doesn't reference the downpayment invoice
- you'll also find that the downpayment invoice doesn't have the correct invoice type code indicating that it's a downpayment. 
- printing the invoice will also give an error when l10n_gcc_invoice is installed (for the downpayment invoice)

Current behavior before PR:
xml documents generated from l10n_sa_edi don't carry the correct reference to the downpayment invoice when it's the final invoice. they also don't have the correct invoice type code when it's a downpayment invoice if generated through POS

Desired behavior after PR is merged:
the methods _get_downpayment_lines and _is_downpayment now correctly identify the downpayment lines & if it's a downpayment respectively.
the dual language product name now shows on the invoice pdf without raising an error if line.name is undefined.

Task-5135918

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

Forward-Port-Of: odoo/odoo#247388
Forward-Port-Of: odoo/odoo#244443

Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.

Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)

When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17

This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.

OPW-5448916

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#244245

The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the tax-included amount, but `total_excluded` (used for the discounted amount) is tax-excluded.

This caused the tax amount to be incorrectly reported as an AllowanceCharge (discount) in the MyInvois XML, because:
  discount_amount = price_unit * qty - total_excluded
                  = tax_included - tax_excluded
                  = TAX AMOUNT (not a discount!)

Example: Product priced at 110 MYR with 10% tax included:
- price_unit = 110 (tax-included)
- total_excluded = 100 (tax-excluded: 110 / 1.10)
- discount_amount = 110 - 100 = 10 ← incorrectly reported as discount

refs:

The cac:AllowanceCharge element in UBL is specifically for discounts and surcharges, NOT for taxes. According to the Peppol Malaysia e-Invoice specification:

https://docs.peppol.eu/poac/my/pint-my-sb/bis/#_allowances_and_charges

https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL5189/ (For this case we are interested in code 95)

Steps to Reproduce:
1. Configure a tax as "Included in Price" with Malaysia tax type
2. Create a product with that tax.
3. Create POS orders without any discount
4. Generate consolidated invoice and XML
5. XML incorrectly shows <cac:AllowanceCharge> with tax amount as discount

The fix uses `raw_total_excluded / discount_factor` (always tax-excluded) instead of `price_unit * quantity` (may be tax-included), consistent with the parent method:
https://github.com/odoo/odoo/blob/d645361a95037ac580d55e80bcb61d1eeb293efd/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1846-L1876

Ticket [link](https://www.odoo.com/odoo/project.task/5476526) 
opw-5476526

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

Forward-Port-Of: odoo/odoo#247267
Forward-Port-Of: odoo/odoo#245535

Issue :
-
After commit odoo/odoo@6d7f4012cfa06b35089e7557522fcbf658978b37, the `employee_overtime` field in `hr_holidays_attendance` was converted to a computed field on `hr.leave` model to use the new overtime deduction logic. However, the same change was not applied to `hr.leave.allocation` model.

Steps to Reproduce:
-
1. Create a Leave Allocation for an employee who has extra overtime hours.
2. Set the allocation less than the available extra hours.
3. In 19.0, when saving the allocation and creating a new allocation for the same employee:
   - The `employee_overtime` value did not update.
   - Even though the actual extra hours were reduced, the field still showed the old value.

Fix:
-
After this fix, the `employee_overtime` field in `hr.leave.allocation` is computed correctly, reflecting the actual available overtime hours.
This commit updates `hr.leave.allocation` by:
   - Converting `employee_overtime` to a computed field.
   - Computing its value using `_get_deductible_employee_overtime`.
This aligns the overtime computation between leave requests (`hr.leave`) and leave allocations (`hr.leave.allocation`).

Before Fix:
-
<img width="1898" height="659" alt="before_fix" src="https://github.com/user-attachments/assets/e4797a17-1031-4ba7-81c8-9ab09494134d" />

After Fix:
-
<img width="1902" height="623" alt="after_fix" src="https://github.com/user-attachments/assets/9d592795-20f6-40ce-bf42-a157769589a5" />

opw-5479200

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#245881

## Versions
19.0+

## Issue
The website's pick-up in store dialog doesn't show up full opening days.

## Steps to reproduce
*Ensure "Click & Collect" is enabled in the Settings*
- Go to "Delivery Methods" and edit "Pick up in store":
  - Click on the warehouse under the "Stores" tab:
    - Change the "Opening Hours" values (set one if needed) by clicking on the internal link:
      - Under the "Working Hours" tab, change or add a line with its "Day Period" set to "Full Day" and save.
    - Save.
  - Ensure the method is "Published".
- Go to the website's shop:
  - Look for a product that can be retrieved from the store (e.g. "Chair floor protection");
  - Go to checkout and fill forms in until you arrive on the delivery form where you can select a store location:
    - Select the warehouse you changed:
      - Check the opening hours not displaying the full day's data.

## Cause
`full_day` has been introduced in the calendar via commit 77f860f5d3757e5a56861ac1de95b9ad29ea0dff but its retrieval in `website_sale_collect` was skipped du to `day_period` restrictions. These restrictions exist because we don't want to consider breaks in the opening hours

opw-5904377

Forward-Port-Of: odoo/odoo#247840

### Issue:

Due to recent [commit]
(https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.

Traceback on neutralizing:
```py
odoo.sql_db: bad query: b"-- disable_l10n_pl_edi_integration\n\n-- clear KSeF Credentials\nUPDATE res_company\n   SET l10n_pl_edi_certificate = NULL,\n       l10n_pl_edi_access_token = NULL,\n       l10n_pl_edi_refresh_token = NULL,\n       l10n_pl_edi_session_id = NULL,\n       l10n_pl_edi_session_key = NULL,\n       l10n_pl_edi_session_iv = NULL\n;\n\n-- set test environment parameter\n     INSERT INTO ir_config_parameter (key, value, create_date, write_date)\n          VALUES ('l10n_pl_edi_ksef.mode', 'test', NOW(), NOW())\n     ON CONFLICT (key)\n   DO UPDATE SET value = 'test',\n                 write_date = NOW()\n;"
ERROR: column "l10n_pl_edi_session_key" of relation "res_company" does not exist
LINE 9:        l10n_pl_edi_session_key = NULL,

```

Before this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(4 rows)
```

After this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
  AND column_name LIKE 'l10n_pl_edi%';
        column_name
---------------------------
 l10n_pl_edi_certificate
 l10n_pl_edi_session_iv
 l10n_pl_edi_session_key
 l10n_pl_edi_access_token
 l10n_pl_edi_refresh_token
 l10n_pl_edi_session_id
(6 rows)
```

### Solution:

Set attachment=False for the fields `l10n_pl_edi_session_key` and `l10n_pl_edi_session_iv`, ensuring that their columns are created directly on the  res.company model instead of being stored as attachments. Eventually, during [neutralizing]
(https://github.com/odoo/odoo/blob/18.0/addons/l10n_pl_edi/data/neutralize.sql#L4-#L10) there won't be any column missing error.

Ticket [link](https://www.odoo.com/odoo/project.task/5751411)
opw-5751411

Forward-Port-Of: odoo/odoo#247130

# Steps to reproduce:
* Install **Accounting** and **l10n_be_reports**.
* Enable **debug mode**.
* Go to **Accounting → Reporting → Belgium → Partner VAT Listing**.
* Create invoices with invoice lines with no product set on it, just a label, so that **more than 10 Belgian partners** appear in the report and ensure each partner has a **VAT number**.
* Open the report **Options** tab and set **Load More Limit** to **5**.
* Click **Load More** until all partners are visible.
* Click **Returns** and create a return for the month you have created invoices for, and submit it.
* Download the generated XML.

# Observed behavior:
* The XML file contains only the first batch of partners.
* Partners shown after clicking **Load More** are missing from the export.

# Cause:
* In v17, the XML export button was defined as:
https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/l10n_be_reports/models/partner_vat_listing.py#L53-L59
* This meant clicking the button would go through the [export_file](https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/account_reports/models/account_report.py#L4927)
 method, which sets `options['export_mode'] = 'file'` before calling the export function. The test in v17 explicitly sets `export_mode = 'file'` to simulate what `export_file` does in production.
 
* In v19, the architecture changed:
  - The XML export is now triggered via the account.return workflow and a submission wizard [1.](https://github.com/odoo/enterprise/blob/19.0/l10n_be_reports/wizard/vat_listing_submission_wizard.py)
  - The wizard's `print_xml` method calls [_get_closing_report_options()](https://github.com/odoo/enterprise/blob/19.0/account_reports/models/account_return.py#L1601) which does NOT set `export_mode = 'file'`.
  - The controller then calls `dispatch_report_action(options, file_generator)` directly, bypassing `export_file`.
 
* Why the test changed:
  - In v17 test: `export_mode = 'file'` was set to mimic the `export_file` →  `partner_vat_listing_export_to_xml` flow.
  - In v19 test: `export_mode = 'file'` should NOT be needed in the test because the fix is to set `export_mode = 'file'` inside `partner_vat_listing_export_to_xml` itself.


# Fix:
* Enable **export mode** when generating the XML.
* Ensures all partners are included regardless of the load limit.

opw-5494247

Forward-Port-Of: odoo/enterprise#106134