**Steps to reproduce:**

- Install `sale_subscription`
- Create a recurring product (P1) and a non-recurring product (P2)
- Create a Sale Order (S1) with P1 (quantity > 0) and confirm it
- Create an upsell of S1 (new child order S2)
- In S2, edit the P1 line, and select P2
- Set quantity > 0 for P2
- Confirm S2

**Issue:**

After confirming the upsell order (S2), the quantity of P1 on the
original subscription (S1) is incorrectly increased by the quantity of
P2 from S2. The _compute_parent_line_id method did not reset the
parent_line_id when the product was not a subscription Product,
which caused it to incorrectly update the subscription

This issue is present in all three versions: **16.0, 17.0, and 18.0**.

**Solution:**

Reset parent_line_id to False if the product is not a subscription
product to prevent incorrect subscription updates.

[opw-4638955](https://www.odoo.com/odoo/project.task/project.task/4638955)

Forward-Port-Of: odoo/enterprise#90848
Forward-Port-Of: odoo/enterprise#88282

Steps to reproduce the issue:

0. Set work_entry_source to "attendance" on the running contract 
   of the employee.
1. Create an attendance for yesterday 23:00:00 UTC to today 
   06:00:00 UTC.
2. Create an attendance today from 08:00:00 UTC to 16:00:00 UTC.

Current behavior before PR:
Odoo will create a conflicting work entry with the one created 
in step 1, because the logic recreates all work entries in a 
timeframe between the start date at 00:00:00 and end date at 
23:59:59. The first entry started before this timeframe, so the 
recreated work entry does not align with the existing one, 
causing a conflict.

Desired behavior after PR is merged:
The work entries now span a single day at a time. If an 
attendance starts at night and ends the next morning, two 
entries will be created: one from the start time to end of day, 
and another from the start of the next day to the end time.

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

Forward-Port-Of: odoo/enterprise#90588

The system will crash when we receive nothing in `response` and also tryig to retrieve values from response.

**Error:-**
`TypeError: 'NoneType' object is not subscriptable`

**Root Cause:-**
- While we are in `EC Company`.
- When we click `Process Now` on the invoice. It will call `button_process_edi_web_services` method. And while in execution when at [1], `move.company_id._l10n_ec_is_demo_environment()` is `False`, then it calls `_l10n_ec_send_document` method.
- While submitting electronic invoices to SRI, the method `_l10n_ec_get_client_service_response_new()` sometimes returns `None` .
- It may also lack expected keys like 'estado' or 'comprobantes', depending on SRI’s behavior.

[1]
https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_ec_edi/models/account_edi_format.py#L425-L428

**Solution:-**
- Wrapped the access to response and its keys inside a `try...except` block that catches:- 
   - `TypeError`: for cases where the response is `None`.


**Sentry - 6708486009, 6728767866**

Forward-Port-Of: odoo/enterprise#88611

### Issue

Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests that are in the 'shared' state. However this compute method fails for requests not in the 'shared' state leading to a traceback error. This commit fixes it by setting the default as False for the sign.request records that do not have state='shared' so the traceback error is handled.

This can be reproduced in v17 and above by:
1. Open any sign.request record that isn't in the shared state
2. Enable Developer Mode
3. Using the debug icon, click on view record data

The traceback will be visible here which mentions that the compute method failed to assign
It can also be re-produced by using an xml-rpc / json-rpc ORM call to search_read the sign.request records that does not have state = 'shared'

### Before

https://github.com/user-attachments/assets/24c07f2a-2398-44b4-8969-30abb576876a



### After


https://github.com/user-attachments/assets/e92b1212-5405-4b98-ba41-c81b2ac547d7


[opw-4864159](https://www.odoo.com/odoo/project/49/tasks/4864159)

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

Forward-Port-Of: odoo/enterprise#90576

#### Issue:
This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns #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.

Also the l10n_om is a community module, because of that, we need to add a new enterprise module to add the related data for the tax returns.

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

Steps to reproduce:
- Have the main company in USD
- Have 3 different currency rates in date 1, 2 and today
- Create a Vendor Bill in EUR in date 1
- Make Payment (EUR) in date 1, it should not have an associated move
- Create a Bank transaction, at date 2, matching the payment amount in EUR Bank Journal
- Make a batch payment including the created payment
- Open bank reconciliation of EUR Bank journal
- Select the transaction and the batch payment
- Validate

Issue: User Error will raise
```
The move (OTR/2017/00001) is not balanced.
The total of debits equals $ aaa and the total of credits equals $ bbb
You might want to specify a default account on journal "Bank other currency" to automatically balance each move.
```

This occurs because when retrieving the exchange rate values, amounts are converted using the payment values, computed at payment date. Later on, when we aggregate payment amounts, we convert manually the result without specifying a date, creating an issue in case the reconciliation date occurs after a rate change

Forward-Port-Of: odoo/enterprise#88299

**Steps to reproduce**:
1. Install `l10n_cz` and `l10n_cz_reports_2025`.
2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill.
3. Go to Reporting → Tax Return → VAT Control Statement (CZ).
4. You will see the bill listed under section B2. Now export the XML.
5. In the exported XML, the field `dan_dppd` is present.

**Observations**:
When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`.
According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized.

**Issue**:
The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section.

**Solution**:
The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation.

opw-4868515

Forward-Port-Of: odoo/enterprise#90394