When a combo contained a product that had variant with type 'no_variant' and 'always', if you added the product to the cart the product configuration popup would not open. Also, in the combo you can only select product_product and not product_template, so the product configuration popup should not propose the variant linked to the 'always' type, as you already selected a product template in the combo configuration popup.

Steps to reproduce:
-------------------
* Create a product attribute PA1 with type 'no_variant' and 2 values V1 and V2
* Create a product attribute PA2 with type 'always' and 2 values V3 and V4
* Create a product template PT1 with PA1 and PA2
* Create a combo choice PC1 with the 2 variants of PT1
* Create a combo product CP1 with PC1
* Open PoS and add CP1 to the cart
* The combo configurator popup opens, click on the version with V2
> Observation: The product configurator popup does not open
> Second fix: The product configurator allows you to select the
  variant linked to the 'always' type, which is not correct as you already selected it through the combo configurator popup

Why the fix:
------------
The first fix just make sure that the product configuration popup opens when it is necessary.
The second fix filters the variants proposed in the product configuration popup to only show the variants that are not linked to the 'always' type. But this only happens when we do it from the combo configuration popup.

opw-4719258

Forward-Port-Of: odoo/odoo#220994
Forward-Port-Of: odoo/odoo#215603

Issue description:
The profitability items for projects were not matching the numbers from analytic accounting reports due to discrepancies in currency rate calculations. This issue was traced to two main causes:

1. Profitability items were using the currency rate of today, even for old move lines.
```rates = self.env['res.currency'].browse(list(currency_ids))._get_rates(self.company_id, date.today())```
 While this was deemed acceptable for performance reasons in #113146,
 it caused mismatches with analytic accounting reports.

2. Some move lines use a changed currency rate that differs from
the rate stored in the currency table for the same date
(due to manual change in the currency rate), leading to further mismatches.

To resolve this:
- The `balance` is now used instead of `price_subtotal` for calculations.
This ensures accurate amounts without relying on conversion rates
when the project currency matches the company currency.

Steps to Reproduce:
1. Create a project with an associated analytic account.
2. Enable any foreign currency and add different rates for it for today and yesterday.
3. Create a new vendor bill with:
   - Date = yesterday
   - Currency = the new foreign currency
   - Analytic distribution set to the created project's analytic account.
4. Check the project dashboard profitability. You will see the numbers
are incorrect because it uses the currency rate of today.

opw - 4881380

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

Forward-Port-Of: odoo/odoo#222388
Forward-Port-Of: odoo/odoo#217337

Steps to reproduce:
- Go to Invoicing > Configuration > Accounting > Currencies:
    - Enable the Euro currency
- Set company currency to USD
- Go to any partner form (e.g. Azure Interior):
    - In Sales & Purchase tab: - Set Supplier Currency to Euro
- Create a purchase order from the UI:
    - Select Azure Interior → Currency is correctly updated to Euro (via onchange)

- Install the Approvals module
- Create a storable product "P1":
    - Under Purchase tab: - Vendor: Azure Interior - Price unit: 5 EUR
- Create an approval request:
    - Request Owner: Marc Demo
    - Product: P1
    - Approver: Mitchel Admin
- Submit and approve the request
- Click on "Create Purchase Order"

Issue:
The purchase order is created with the correct partner and product. But the currency is incorrectly set to the company currency (USD), instead of the supplier's currency (Euro).

Cause:
The currency was updated via an `@onchange`, which is only triggered in the UI.
When creating a PO programmatically (e.g. via approvals or in a test), the onchange is not executed and the currency falls back to the company default.

Solution:
Replace the `@onchange` logic for `currency_id` with a stored compute field.
This ensures that the correct currency is always computed, regardless of how the purchase order is created.

opw-4938390

Forward-Port-Of: odoo/odoo#222044
Forward-Port-Of: odoo/odoo#221907

Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Google, when the synchronization of user A starts or resumes, the event will be synchronized with the user A as organizer in Google. In the meanwhile, in Odoo, the event ownership will be shown as user B, mismatching the organizer field between the two ends. This is problematic because the ownership of the event will be forever wrong in Google.

After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Google, it will be correctly synchronized in Google as well.

Recently, we had to revert this PR due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back.

task-4269432

Forward-Port-Of: odoo/odoo#219178
Forward-Port-Of: odoo/odoo#218856

### Issue:
This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns [feature](https://github.com/odoo/enterprise/pull/81569).

The l10n_om module did not include an account.return.type record, which prevents the "Returns" button (linked to the action_open_returns) from appearing in the Tax Report. As a result, users in Oman are unable to access the Tax Closing form.

### Issue:
This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns feature (#81569).

The l10n_om module did not include an account.return.type record, which prevents the "Returns" button (linked to the action_open_returns) from appearing in the Tax Report. As a result, users in Oman are unable to access the Tax Closing form.

The visibility of the button is controlled by the following condition: [Code](https://github.com/odoo/enterprise/blob/f924f120cbd04002e21c78b081e1c8006b56a4b6/account_reports/models/account_report.py#L1776)

#### Affected Versions:
18.3 and later

### Steps to reproduce:

1.Install the l10n_om module
2.Switch to the Oman company
3.Go to Accounting > Reporting > Tax Report
4.The "Returns" button is not visible

### Expected behavior
The "Returns" button should be visible, allowing the user to generate the closing tax form.

### Current behavior
The button is hidden due to missing account.return.type data in the Oman localization.

OPW-4943024

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

### Steps to reproduce:

- In the settings enable Multi-Steps routes
- Put your warehouse in delivery in 2 steps
- Create and confirm a sale order for 1 units of a storable product
#### > While the pick move was created and confirmed the forecast is still at 0 even tho it should be at -1 and the outgoing pick move should be matched with the SO line in the forecast report.

### Cause of the issue:

The issue has been introduced by commit 5b40fb086a0e5677678c312b42dc1f2c8991dc9e The issue being that since the `location_final_id` should not have been considered for the past forecast based on done move chains (because each done move of the chain will refer to the same external `final_dest_id`). The proposed fix was therefore to change the dest_loc_domain as such:
https://github.com/odoo/odoo/commit/5b40fb086a0e5677678c312b42dc1f2c8991dc9e#diff-1f24ce9f94c5795040749acca5924384d7d17c0ac39b1993cef3b484e4bd30afR324-R326 
However, the new domain:
https://github.com/odoo/odoo/blob/995a7072cb3315fc03544b281b1ed5ca4e81e901/addons/stock/models/product.py#L322-L326 ignores completely the part of the condition refering to `final_dest_id` for outgoing moves since the condition is negated here: https://github.com/odoo/odoo/blob/995a7072cb3315fc03544b281b1ed5ca4e81e901/addons/stock/models/product.py#L328-L333 The logical `OR` (`|`) becoming an `AND` (`&`) for the `domain_move_out_loc`.

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

Forward-Port-Of: odoo/odoo#222241

### Issue

When "Add QR-code link on PDF" is enabled, printing an invoice in a regular Sales → Accounting flow raises an error.

The report printing process internally calls
`_generate_portal_payment_qr`, which creates a `payment.link.wizard` record. This model overrides `default_get` and reads `self.env.context.get('active_model')`.

At that moment, the context still contains `'sale.advance.payment.inv'`, a model that does not implement `_get_default_payment_link_values`. This causes:

AttributeError: 'sale.advance.payment.inv' object has no attribute '_get_default_payment_link_values'

#### Affected versions
- saas-18.3 and later

### Steps to reproduce
1. Install `account_accountant`, `sale_management`
2. Go to Settings
3. Enable "Invoice Online Payment" and "Add QR-code link on PDF"
4. Go to Sales → Quotations
5. Create any quotation
6. Confirm quotation
7. Create invoice (full)
8. Confirm invoice
9. Click "Print"

#### Current behavior
- Error is raised

#### Expected behavior
- Invoice prints with QR code without error

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

**Issue**:
The expiration date displayed in the barcode app's scan screen may appear incorrect.

**Steps to reproduce**:

- Go to Settings > Inventory, and enable the `Expiration Date` field
- Open the Purchase app
- Create a new Request For Quotation
- Select a product that:
	- is a good tracked by lot
	- has the `Expiration Date` field enabled (Inventory tab > Traceability)
- Confirm the RFQ
- Click the `Receipt` smart button
- Click the `hamburger button` and enter an expiration date at midnight.
- Go to the Barcode application > Operation > Receipts
- Open the corresponding RFQ
- Click Edit and increase the quantity to 1, then Validate
- Observe that the date is displayed as one day earlier

**Cause**:
The code https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L17 assumes that the date is encoded using the local while the date comes from the server https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L13, and thus is utc encoded. So for example, if the user's timezone is `Europe/Brussels`, a midnight timestamp will appear as 10 PM the previous day.

**Solution**:
To solve this issue, use this method https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L619-L622 instead of https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L514-L516. This way, it would parse the utc-base server date as a utc-base date.

opw-4865513

Forward-Port-Of: odoo/enterprise#91517
Forward-Port-Of: odoo/enterprise#88526

Steps to reproduce:
- Do not enable “Rental Transfer” in settings
- Create a storable product “P1”:
    - Enable “Can be rented”
    - update available quantity to 10 units

- Create a first rental order for 24h:
    - 9 units of P1
    - Confirm the order

- Create a second rental order for the same 24h period:
   - 1 unit of P1

-> Expected: The availability widget is green and indicates 1 unit available (correct).

Problem:
After picking up the first order, the widget on the second order turns red and incorrectly shows no availability.
The current logic checks virtual_available (1 unit) and subtracts rented_qty_during_period (9 units), resulting in -8. It then takes max(0, -8) → 0. However, the actual picked quantity should be taken into account, regardless of whether “Rental Transfer” is enabled, since disabling it merely omits the creation of a picking—not the move itself.

opw-4901017
opw-4906162

Forward-Port-Of: odoo/enterprise#92056
Forward-Port-Of: odoo/enterprise#91155