Problem: When there is a loyalty program with a reward on specific products and there is an error in the discount product domain or the domain is incompatible with the pos client, the pos session is unable to open and keeps loading with an error visible on the console. This is because when the session tries to open, the compute_discount_product_ids method is called which runs into an error because it cannot use the domain. Ideally, the pos screen should still load and give an alert message sayin

Problem: When there is a loyalty program with a reward on specific products and there is an error in the discount product domain or the domain is incompatible with the pos client, the pos session is unable to open and keeps loading with an error visible on the console. This is because when the session tries to open, the compute_discount_product_ids method is called which runs into an error because it cannot use the domain. Ideally, the pos screen should still load and give an alert message saying “The reward "xxx” contains an error in its domain, your domain must be compatible with the PoS client” and after closing the popup, the pos shop can be used however this does not happen as the code line for deleting the erroneous loyalty reward runs into an error because the delete method expects a record but receives an id. The alert message written before never appears because this delete statement runs into an error.

Purpose: Passing the correct argument to the delete function so that the loyalty program with issues in domain can be properly deleted from loaded models. After this correction, the pos session will load and there will be an alert warning the user of the reward error.

Steps to Reproduce on Runbot:
1. Choose any discount program for the pos shop. Open the reward pop up and choose to put the discount on specific products.
2. Edit domain in the “Discount Product Domain” and put <Products> <contains> <screen> in the rule `[("product_variant_ids", "ilike", "screen")]`. We can see 3 records here on the reward.
3. Save and close the program screen. Open the pos shop and check the console. The screen keeps loading and there is a traceback error in the console.

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

Forward-Port-Of: odoo/odoo#196875

Make the notification message searchable. Task-4828780 Forward-Port-Of: odoo/odoo#212285 Forward-Port-Of: odoo/odoo#212047

Make the notification message searchable.

Task-4828780

Forward-Port-Of: odoo/odoo#212285
Forward-Port-Of: odoo/odoo#212047

**Issue**: an error is thrown in debug mode when switching between calendar views ("year", "week", etc.) after changing the time format. **Steps to reproduce:** - ensure hr_homeworking_calendar is installed - activate debug mode - Calendar > change the time format opw-4684831 Forward-Port-Of: odoo/odoo#205937

**Issue**:
an error is thrown in debug mode when switching between calendar views ("year", "week", etc.) after changing the time format.

**Steps to reproduce:**
- ensure hr_homeworking_calendar is installed
- activate debug mode
- Calendar > change the time format

opw-4684831

Forward-Port-Of: odoo/odoo#205937

https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/error_event See also MDN's img, script and iframe docs. The error Event *doesn't* bubble. We sometimes reject a promise with the Event dispatched by the "error" handler of an HTMLElement. If the code throwing that at us doesn't wrap the event in an actual Error, there is no reason to do more than the spec: we do not handle this error bubbling to us via the Promise being rejected. This allows to silence errors coming from a failed

https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/error_event See also MDN's img, script and iframe docs. The error Event *doesn't* bubble.

We sometimes reject a promise with the Event dispatched by the "error" handler of an HTMLElement. If the code throwing that at us doesn't wrap the event in an actual Error, there is no reason to do more than the spec: we do not handle this error bubbling to us via the Promise being rejected.

This allows to silence errors coming from a failed load of an Element that was wrapped into a promise. Website uses that in image_processing for example.

runbot-error-70404

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#211827

Follow-up of https://github.com/odoo/odoo/pull/211720 PR above backport behaviour of (un)read conversations, i.e. mark as read on scroll bottom, new message separator, and unread message banner. One of the improvements are made possible thanks to adding concept of thread focused (without composer), which allow to mark as read even when focusing the thread without composer. The backport made a mistake in omitting onFocusin on thread in template, which made it not possible to mark as read

Follow-up of https://github.com/odoo/odoo/pull/211720

PR above backport behaviour of (un)read conversations, i.e. mark as read on scroll bottom, new message separator, and unread message banner.

One of the improvements are made possible thanks to adding concept of thread focused (without composer), which allow to mark as read even when focusing the thread without composer.

The backport made a mistake in omitting onFocusin on thread in template, which made it not possible to mark as read on scroll bottom with just focus on thread.

This commit fixes it by adding in template. Handler was already there. Test for scroll to bottom that marks unread is adapted to focus the thread without composer.

Forward-Port-Of: odoo/odoo#212172

As per RBI Notification RBI/2019-20/47, ensure a pre-debit notification is sent at least 24 hours before the actual debit for recurring payments. Prevent creation of duplicate pending transactions with token for the same document because every transactions confirm after 24 hours. task - 4678509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211012 Forward-Port-Of: odoo/odoo#209488

As per RBI Notification RBI/2019-20/47, ensure a pre-debit notification is sent at least 24 hours before the actual debit for recurring payments. Prevent creation of duplicate pending transactions with token for the same document because every transactions confirm after 24 hours.

task - 4678509

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

Forward-Port-Of: odoo/odoo#211012
Forward-Port-Of: odoo/odoo#209488

This commit updates the legacy dhl connector module title and description in the base POT file. Enterprise PR: odoo/enterprise#73908 Task-3759205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211672 Forward-Port-Of: odoo/odoo#187409

This commit updates the legacy dhl connector module title and description in the base POT file.

Enterprise PR: odoo/enterprise#73908

Task-3759205

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

Forward-Port-Of: odoo/odoo#211672
Forward-Port-Of: odoo/odoo#187409

Due to floating operation result of calculation might have "x.000000001" form. This will make user unable to submit efaktur to coretax platform. To prevent this, we use `float_repr` to ensure 2 decimal places. opw-4745508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212186

Due to floating operation result of calculation might have "x.000000001" form. This will make user unable to submit efaktur to coretax platform. To prevent this, we use `float_repr` to ensure 2 decimal places.

opw-4745508

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

Forward-Port-Of: odoo/odoo#212186

[FIX] calendar_sms: calendar reminder event matching The Issue SMS reminders are sent to customers for calendar events regardless of whether they are scheduled for 1 hour before or 24 hours before; both reminders are sent. Steps to Reproduce 1. Create two SMS reminders with different timings: one for 1 hour before the event and another for 24 hours before. 2. Create an attendee (since the calendar event administrator will not receive the SMS). Assign the attendee a phone number and an

[FIX] calendar_sms: calendar reminder event matching

The Issue
SMS reminders are sent to customers for calendar events regardless of whether they are scheduled for 1 hour before or 24 hours before; both reminders are sent.

Steps to Reproduce

1. Create two SMS reminders with different timings: one for 1 hour before the event and another for 24 hours before.
2. Create an attendee (since the calendar event administrator will not receive the SMS). Assign the attendee a phone number and an email.
3. Configure your SMS account to receive free credits (for local: create a SaaS and use its IAP token and UUID to link the IAP service).
4. Create two calendar events:
   - One that starts in 1 hour. (event_1h)
   - One that starts in 24 hours. (event_24h)
5. Add both reminders (1-hour and 24-hour reminders that we will call reminder_1h and reminder_24h) to each event and include the attendee you created. Accept the event invitation on behalf of the attendee.
6. Run the scheduled action that triggers event reminders.

Actual Behavior
For both events, both reminders are triggered.
for event_1h, reminder_1h and reminder_24h are sent.
for event_24h, reminder_1h and reminder_24h are sent.

Expected behavior:
For event_1h, reminder_1h is sent.
For event_24h, reminder_24h is sent.

Why Does This Happen?

After the SQL query, the result is a dictionary:

{"reminder_1h": "event_1h", "reminder_24h": "event_24h"}
(In reality, these should be IDs, but they are represented as strings for clarity.)

The code in the calendar_sms module retrieves all events from the dictionary, so we have a list with [event_1h, event_24h].
It also fetches the reminders that are in the keys of the dictionary (reminder_1h, reminder_24h).
Then it iterates through the events and for each event, checks if the reminders we have exist in the event.
If it exists, it sends an SMS.
(e.g., event_24h has both reminder_1h and reminder_24h linked to it, so it will send both reminders even if one states it starts in one hour, whereas it really starts in 24h).

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

Forward-Port-Of: odoo/odoo#212222
Forward-Port-Of: odoo/odoo#195782

Before this commit: - A warning was shown in the TDS payment wizard when the base amount used for TDS calculation was greater than the amount being paid. - However, this warning was misleading, as the TDS base amount can exceed the paid amount. After this commit: - The warning has been removed from the TDS payment wizard. task-4787113 Forward-Port-Of: odoo/odoo#212210 Forward-Port-Of: odoo/odoo#209823

Before this commit:
- A warning was shown in the TDS payment wizard when the base amount used for TDS calculation was greater than the amount being paid.
- However, this warning was misleading, as the TDS base amount can exceed the paid amount.

After this commit:
- The warning has been removed from the TDS payment wizard.

task-4787113

Forward-Port-Of: odoo/odoo#212210
Forward-Port-Of: odoo/odoo#209823

Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `accoun

Upgrading from 16 to 17 causes issues with demo data.
It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines).

To reproduce:
- initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`)
- install demo data (the `post_install` hook in `account` is then not fired, still no `l10n_generic_coa`)
- upgrade to Odoo 17.0

By creating the demo data in Python instead of the XML, we can put the condition to avoid creating the move if we do not have a chart template on the company.

Enterprise PR: odoo/enterprise#80812

opw-4781045

Forward-Port-Of: odoo/odoo#211526
Forward-Port-Of: odoo/odoo#200420

1. lower opacity on pinned message cards 2. show low opacity separator above discuss app 3. better spacing between msg bubble and next msg notification Forward-Port-Of: odoo/odoo#212179

1.  lower opacity on pinned message cards
2. show low opacity separator above discuss app
3. better spacing between msg bubble and next msg notification

Forward-Port-Of: odoo/odoo#212179

**Current behavior before PR**: Reply backlink doesn't work for deleted parent message **Desired behavior after PR is merged**: Reply backlink works for deleted parent message task:4593352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212224 Forward-Port-Of: odoo/odoo#202993

**Current behavior before PR**:

Reply backlink doesn't work for deleted parent message

**Desired behavior after PR is merged**:

Reply backlink works for deleted parent message

task:4593352

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

Forward-Port-Of: odoo/odoo#212224
Forward-Port-Of: odoo/odoo#202993

This reverts commit 2094747717be Versions -------- - 18.0+ Steps ----- 1. Create a service product that creates a task on order confirmation; 2. add an attribute that does not create variants; 3. add the product to an order; 4. confirm the order. Issue ----- 1. The task is named as the attribute. 2. The line's `display_name` shows the attribute instead of the product. Cause ----- Commit 2094747717be removed the extra new line that was added before attribute-based line des

This reverts commit 2094747717be

Versions
--------
- 18.0+

Steps
-----
1. Create a service product that creates a task on order confirmation;
2. add an attribute that does not create variants;
3. add the product to an order;
4. confirm the order.

Issue
-----
1. The task is named as the attribute.
2. The line's `display_name` shows the attribute instead of the product.

Cause
-----
Commit 2094747717be removed the extra new line that was added before attribute-based line descriptions for custom attributes and attributes that create no variants.

This did not impact the task or display name in previous versions, as the default sale order description started with the product name, and could be replaced.
But as of 18.0, while the default sale order description still starts with the product name, it's no longer possible to replace it, hence it gets skipped to get the first line of the editable description, which in this case is the attribute name.

Solution
--------
By re-adding the empty line before the attribute descriptions, the display & task names will fall back on the product name.

See commit 47d223759f07 for display name & c3877b2acd74 for task names.

Also adds a test to prevent regression.

opw-4792351

Forward-Port-Of: odoo/odoo#211867

Before this commit, the bus GC would remove every message older than 120 seconds. This could lead to missed messages if a disconnection occurred during the GC process. To minimize the impact of GC, the retention window should be extended. This commit introduces the `bus.gc_retention_seconds` config parameter, which allows customizing this window. The default is set to 24 hours, which seems reasonable (messages won't be cleared overnight). Since the GC will now process larger batches,

Before this commit, the bus GC would remove every message
older than 120 seconds. This could lead to missed messages
if a disconnection occurred during the GC process.

To minimize the impact of GC, the retention window should be extended.
This commit introduces the `bus.gc_retention_seconds` config parameter,
which allows customizing this window. The default is set to 24 hours,
which seems reasonable (messages won't be cleared overnight).

Since the GC will now process larger batches, the deletion is not made
with a direct query: no need to fetch all records before calling `unlink`,
no need to schedule other vacuums when the batch is too big.

Forward-Port-Of: odoo/odoo#212106
Forward-Port-Of: odoo/odoo#211806

Before this commit, if the search term was included in a product's internal reference (default_code), the search results would only return products with an exact match on default_code, and would exclude other products that matched the search term in their name. This was due to default_code being included in the exact match logic. opw-4778729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211067

Before this commit, if the search term was included in a product's internal reference (default_code), the search results would only return products with an exact match on default_code, and would exclude other products that matched the search term in their name. This was due to default_code being included in the exact match logic.

opw-4778729


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

Forward-Port-Of: odoo/odoo#211067

Before this commit, scanning a product with a dynamic attribute, an existing variant, and an assigned barcode in the PoS would still trigger the configuration popup unnecessarily. opw-4779504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208988

Before this commit, scanning a product with a dynamic attribute, an existing variant, and an assigned barcode in the PoS would still trigger the configuration popup unnecessarily.

opw-4779504

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

Forward-Port-Of: odoo/odoo#208988

The search field dropdown was being rendered behind the orders list in mobile view, making it unusable. This commit adds a higher z-index to the search field dropdown to ensure it's rendered above the orders list. opw-4654710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203083

The search field dropdown was being rendered behind the orders list in mobile view, making it unusable. This commit adds a higher z-index to the search field dropdown to ensure it's rendered above the orders list.

opw-4654710

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

Forward-Port-Of: odoo/odoo#203083

When a numeric field (float, integer, monetary) had a value of 0, it was evaluated to an empty string when called through an `odoo.list` formula. Task: 4805167 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#211854 Forward-Port-Of: odoo/odoo#210757

When a numeric field (float, integer, monetary) had a value of 0, it was evaluated to an empty string when called through an `odoo.list` formula.

Task: 4805167

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#211854
Forward-Port-Of: odoo/odoo#210757

*: l10n_cl, l10n_nz, sale_expense --- Description of the issue this commit addresses: [This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been

*: l10n_cl, l10n_nz, sale_expense

---

Description of the issue this commit addresses:

[This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest.

---

Desired behavior after this commit is merged:

Unused useless files have been removed from the codebase.
Unused useful files have been added to their module's manifest.

---

task-4822341

---

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

Forward-Port-Of: odoo/odoo#211762
Forward-Port-Of: odoo/odoo#211609

Currently, an error occurs when loading sample data for **Attendances** if a referenced employee record has been deleted by the user. **Steps to reproduce:** - Install the `hr_appraisal` module without demo data. - Load sample data for **Appraisals**. - Navigate to **Employees** and delete record for **Emma Granger**. - Install `hr_attendance` module and load sample data for **Attendances**. - Observe the error. **Error:** `ValueError - ParseError('while parsing /home/odoo/src/odoo/s

Currently, an error occurs when loading sample data for **Attendances** if a referenced employee record has been deleted by the user.

**Steps to reproduce:**
- Install the `hr_appraisal` module without demo data.
- Load sample data for **Appraisals**.
- Navigate to **Employees** and delete record for **Emma Granger**.
- Install `hr_attendance` module and load sample data for **Attendances**.
- Observe the error.

**Error:**
`ValueError - ParseError('while parsing /home/odoo/src/odoo/saas-18.2/addons/hr_skills/data/scenarios/hr_skills_scenario.xml:209, ...`

The error occurs because the method at [1] tries to load the `hr_skills_scenario.xml` file, which references a deleted `employee_id` [2], resulting in a parsing failure.

[1] - https://github.com/odoo/odoo/blob/547327f30d2d4bf778b9d358dbea4b133d55188a/addons/hr_skills/models/hr_employee.py#L49
[2] - https://github.com/odoo/odoo/blob/5c1db495828a7fe8c6ec987de432b1916ad32922/addons/hr_skills/data/scenarios/hr_skills_scenario.xml#L210

This commit ensures that all the referenced data is loaded properly, preventing errors due to missing references.

Sentry - 6426462322

Forward-Port-Of: odoo/odoo#207737

Fixes two issues with the customs form and the partner ref. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212265 Forward-Port-Of: odoo/odoo#211837

Fixes two issues with the customs form and the partner ref.

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

Forward-Port-Of: odoo/odoo#212265
Forward-Port-Of: odoo/odoo#211837

Before this commit: - Vehicle number, document number, and date were rendered together without spacing, reducing readability. After this commit: - These fields are now separated by `&` for improved clarity in the vehicle details section. task-4807692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210830

Before this commit:
- Vehicle number, document number, and date were rendered together without spacing, reducing readability.

After this commit:
- These fields are now separated by `&` for improved clarity in the vehicle details section.

task-4807692

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

Forward-Port-Of: odoo/odoo#210830

Issue: ------------------------------------------ When we create MO having one picking, open this picking via Studio and switching to other view giving a ValidationError: `The modes in view_mode must not be duplicated: ['tree', 'kanban', 'form', 'calendar', 'map', 'kanban']` instead of switching to the selected view. How to reproduce: ------------------------------------------ 1.Install Manufacturing, 2.Enable 2-step manufacturing, 3.Create MO for any product, e.g.Wood Panel 4.Go

Issue:
------------------------------------------
When we create MO having one picking, open this picking via Studio and switching 
to other view giving a ValidationError: `The modes in view_mode must not be 
duplicated: ['tree', 'kanban', 'form', 'calendar', 'map', 'kanban']` instead of 
switching to the selected view.

How to reproduce:
------------------------------------------
1.Install Manufacturing,
2.Enable 2-step manufacturing,
3.Create MO for any product, e.g.Wood Panel
4.Go to the Transfers(having 1 picking),
5.Open Studio -> views -> Activate list view,
Switching to Studio list view giving a ValidationError.

Cause of the issue:
------------------------------------------
In the `action_view_mo_delivery` method when there is a single picking for the MO, only form 
view is passed in views, so it is not able to open other views.

Solution:
------------------------------------------
In action_view_mo_delivery for single picking passes the form view and append
the other views. This prevents the ValidationError and opens the 
selected view in Studio.

This is similar to the issue previously fixed in:
https://github.com/odoo/odoo/pull/37582

Forward-Port-Of: odoo/odoo#206269

Issue: ------------------------- In a Manufacturing Order, when a lot number is assigned to a product and then removed, the components are consumed automatically. Steps to Reproduce: ------------------------- - Create an MO for a lot-tracked product. - Assign a lot number to the product, then remove the assigned lot number. - Notice that the component is automatically marked as Consumed. With this commit: ------------------------- Previously, removing the lot number triggered an `o

Issue:
-------------------------
In a Manufacturing Order, when a lot number is assigned to a product and then removed, the components are consumed automatically.

Steps to Reproduce:
-------------------------
- Create an MO for a lot-tracked product.
- Assign a lot number to the product, then remove the assigned lot number.
- Notice that the component is automatically marked as Consumed.

With this commit:
-------------------------
Previously, removing the lot number triggered an `onchange`, which called `_set_qty_producing`. This method auto-marked the component as consumed. As a result, users cannot re-reserve the components using the Check Availability button unless they manually uncheck the Consumed field.

This commit updates the logic to ensure that removing an assigned lot does not trigger component consumption. This allows users to reassign and re-reserve components smoothly in the production flow.

Task ID: [4797711](https://www.odoo.com/odoo/all-tasks/4797711)

Forward-Port-Of: odoo/odoo#210571

Description of the issue/feature this PR addresses: Replace all usages of `mapped('id')` by `ids`. The former is slower and does not work in domains because NewId is not a valid value for psycopg. Current behavior before PR: The `mapped` call returns `.id` for each record, which on new records returns a NewId. That value is not supported in domains or as SQL parameters. (impacted modules: at least l10n_uk*) Desired behavior after PR is merged: Simply use `.ids`. odoo/enterprise#8627

Description of the issue/feature this PR addresses:
Replace all usages of `mapped('id')` by `ids`.
The former is slower and does not work in domains because NewId is not a valid value for psycopg.

Current behavior before PR:
The `mapped` call returns `.id` for each record, which on new records returns a NewId. That value is not supported in domains or as SQL parameters. (impacted modules: at least l10n_uk*)

Desired behavior after PR is merged:
Simply use `.ids`.

odoo/enterprise#86275


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

Forward-Port-Of: odoo/odoo#212108
Forward-Port-Of: odoo/odoo#211391

- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86678 Forward-Port-Of: odoo/enterprise#86499

- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes

Task: 4720126

Forward-Port-Of: odoo/enterprise#86678
Forward-Port-Of: odoo/enterprise#86499

**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. R

**Steps to reproduce:**
- Install l10n_cz_reports_2025
- Switch to a Czech company (e.g. CZ Company)

- Create a bill:
  * Customer: [a Czech customer]
  * Bill Reference: [any] (e.g. XYZ)
  * Invoice Lines: [a line with an amount higher than 10000 and a tax]
- Confirm the bill

- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Select "VAT Control Statement (CZ)" as Report
- Select a period covering the bill date

The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section.

**Issue:**
The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill.

According to the documentation:
https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 
For purchase-type documents, this field should have the bill reference as value.
It should identify the original reference coming from the vendor.
If there is no bill reference, the field should be empty.

opw-4737630

Forward-Port-Of: odoo/enterprise#85005

This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST. Community PR: odoo/odoo#187409 Task-3759205 Forward-Port-Of: odoo/enterprise#86426 Forward-Port-Of: odoo/enterprise#73908

This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap)" which is based on REST.

Community PR: odoo/odoo#187409

Task-3759205

Forward-Port-Of: odoo/enterprise#86426
Forward-Port-Of: odoo/enterprise#73908

After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42 computation of residual amounts is wrong when the payment is linked to a journal entry no-opw Forward-Port-Of: odoo/enterprise#86434

After 233c75ae6aaac4b7109483cab8fbfc4253a6dd42
computation of residual amounts is wrong when the payment is linked to a journal entry

no-opw

Forward-Port-Of: odoo/enterprise#86434

If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error. Steps to reproduce: ------------------- * Head to the sign app. * Upload a document or use pre-existing document * Click on the 3 dots and click on details. * Add a validity date save and then attempt to remove it. > Observation: TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' Why the fix: ------------ When removing the date, `write(

If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error.

Steps to reproduce:
-------------------
* Head to the sign app.
* Upload a document or use pre-existing document
* Click on the 3 dots and click on details.
* Add a validity date save and then attempt to remove it.

> Observation:
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'

Why the fix:
------------
When removing the date, `write()` gets `vals{'validity': False}` `fields.Date.from_string(False)` returns `<class 'NoneType'>` which can not be compared with the operator `<`

opw-4795212

Forward-Port-Of: odoo/enterprise#86532
Forward-Port-Of: odoo/enterprise#85891

*: account_sepa_direct_debit, l10n_ec, l10n_nl_reports --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to

*: account_sepa_direct_debit, l10n_ec, l10n_nl_reports

---

Description of the issue this commit addresses:

[This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest.

---

Desired behavior after this commit is merged:

Unused useless files have been removed from the codebase.
Unused useful files have been added to their module's manifest.

---

task-4822341

Forward-Port-Of: odoo/enterprise#86513
Forward-Port-Of: odoo/enterprise#86397

When clicking on the `Request Signature` button after creating a new application a traceback would occur due to missing record data. Steps to reproduce: --- - Install `hr_recruitment_sign` module - Recruitment > Applications > All Applications - Create New and in action button `Request Signature` Traceback: --- ``ValueError: Invalid field 'mobile' on model 'res.partner'`` The `mobile` field was removed from `res.partner` (see related commit), but it was not removed from this modul

When clicking on the `Request Signature` button after creating a new application a traceback would occur due to missing record data.

Steps to reproduce:
---
- Install `hr_recruitment_sign` module
- Recruitment > Applications > All Applications
- Create New and in action button `Request Signature`

Traceback:
---
``ValueError: Invalid field 'mobile' on model 'res.partner'``

The `mobile` field was removed from `res.partner` (see related commit), but it was not removed from this module. This commit cleans it up to avoid referencing a non-existent field.

commit- https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be

sentry-6588612861

Forward-Port-Of: odoo/enterprise#84784

odoo/odoo#211391 Forward-Port-Of: odoo/enterprise#86624 Forward-Port-Of: odoo/enterprise#86275

odoo/odoo#211391

Forward-Port-Of: odoo/enterprise#86624
Forward-Port-Of: odoo/enterprise#86275