### Problem When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconcili

### Problem
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.

This PR covers versions 18 & 18.1, as reconciliation logic differs in later versions.

### How to reproduce
    * Open a PoS session.
    * Create an order and pay using customer account.
    * Settle this customer's account (inside PoS).
    * Create a Sale Order and invoice it (or just an invoice).
    * The amount settled can be used as outstanding amount and can be used to pay the created invoice. 
    
enterprise PR: https://github.com/odoo/enterprise/pull/86174
18.2 PR: https://github.com/odoo/odoo/pull/210619
opw-4794793

Forward-Port-Of: odoo/odoo#211166

In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms

In this commit, we have addressed a crucial issue related to translation. We discovered that certain key
terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe.

task:3358438

Forward-Port-Of: odoo/odoo#211023
Forward-Port-Of: odoo/odoo#127190

Problem: Bootstrap grid classes like `row` and `col` are not handled properly when placed inside an `o_text_columns` container. During processing (e.g., for email rendering), rows are expected to be converted to tables — but since `o_text_columns` is not included in the selector query, the transformation is skipped. As a result, when rendering the email, columns are not preserved and fall back to stacked layout. Solution: Update the container selection logic to include `o_text_columns` w

Problem:
Bootstrap grid classes like `row` and `col` are not handled properly when placed inside an `o_text_columns` container. During processing (e.g., for email rendering), rows are expected to be converted to tables — but since `o_text_columns` is not included in the selector query, the transformation is skipped.

As a result, when rendering the email, columns are not preserved and fall back to stacked layout.

Solution:
Update the container selection logic to include `o_text_columns` when querying Bootstrap-based containers that need to be transformed into tables.

Steps to reproduce:
1. Go to Email Marketing.
2. Create a new email.
3. Add a Text snippet.
4. Type `/col` and choose "2 Columns".
5. Add text to both columns.
6. Save and send the email. → In the received email, the two columns appear stacked
   vertically instead of side by side.

opw-4675310

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

Forward-Port-Of: odoo/odoo#211109

*: 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

Issue: In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. Solution: When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.co

Issue:
In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. 

Solution:
When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.company_registration field which is used for similar purposes for other locales, and the length of the number is used to determine the type.

Addresses ticket-4624350

task-4624366

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

Forward-Port-Of: odoo/odoo#211620
Forward-Port-Of: odoo/odoo#209875

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#211228 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#211228
Forward-Port-Of: odoo/odoo#187409

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

Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to reclaim past time off if it overlaps with one of the new public holidays. Currently this whole process is not properly batched. There is a single record creation in `hr_holidays:_reevaluate_leaves` and a single record write in `planning:_compute_allocated_hours`. This commit optimizes the Public Holidays creation by batching the two methods mentioned above. Batching the create call is

Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to
reclaim past time off if it overlaps with one of the new public holidays. Currently this whole process
is not properly batched. There is a single record
creation in `hr_holidays:_reevaluate_leaves` and a single record write in `planning:_compute_allocated_hours`.

This commit optimizes the Public Holidays creation by batching the two methods mentioned above. Batching the create call is straightforward. Batching the write might seem useless at first as UPDATE queries are already batched on the ORM level. But actually the performance bottleneck comes from the post-processing done after writing a new `planning_slot.allocated_hours` value. By grouping the slots by allocated_hours we can speed up this post-processing.

#### speedup

Trying to import 72 new Public Holidays that lead to writing allocated hours on 85 planning slots

 - 2min -> 4.76s

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

Forward-Port-Of: odoo/odoo#209846

**Steps to reproduce this issue:** 1) Install Time Off 2) Create an approved leave record 3) Click on the approved leave record in month mode(calendar view) 4) The Delete button appears instead of the Cancel button **Issue:-** In the Time off dashboard, in the year view, if I click on a leave and open the popup, I can click on “Cancel” to cancel my leave But this “Cancel” button appears as “Delete” in the month, week and day views. However, it does cancel the leave, not delet

**Steps to reproduce this issue:**

1) Install Time Off
2) Create an approved leave record
3) Click on the approved leave record in month mode(calendar view) 
4) The Delete button appears instead of the Cancel button

**Issue:-**

In the Time off dashboard, in the year view, if I click on a leave and open the popup, 
I can click on “Cancel” to cancel my leave

But this “Cancel” button appears as “Delete” in the month, week and day views. 
However, it does cancel the leave, not delete it.

**Solution:-**

This button should be renamed “Cancel” to be consistent with the system.

opw-4782277

Forward-Port-Of: odoo/odoo#209285

Steps to reproduce =================== 1. Install l10n_pe or l10n_se 2. Switch to the newly installed company. 3. Open the contact form. The address fields are misaligned. Technical ========== With commit https://github.com/odoo/odoo/commit/4dd27bba346e50f40769d1412fbca0b5f65bb5a6, the contact form renders address fields dynamically based on the selected country. The `_view_get_address` method in the `format.address.mixin` replaces the default address `div` with the XML arch of the vi

Steps to reproduce
===================
1. Install l10n_pe or l10n_se
2. Switch to the newly installed company.
3. Open the contact form. The address fields are misaligned.

Technical
==========
With commit https://github.com/odoo/odoo/commit/4dd27bba346e50f40769d1412fbca0b5f65bb5a6, the contact form renders address fields dynamically based on
the selected country. The `_view_get_address` method in the `format.address.mixin`
replaces the default address `div` with the XML arch of the view linked in the
current company's `address_view_id` field. Since this arch is wrapped within the
`<form>` tags, the JS framework adds an extra div element and `o_form_nosheet` class,
causing layout misalignment.

After this commit
==============
This commit only includes address `div` element inside the `<form>` tag.

Task-4744412

Forward-Port-Of: odoo/odoo#208965

## Issue: Completing a flow from quotation to payment (down payment → settle) via Point of Sale does not properly update the sale order lines when settling. ## Reason: During the down payment process, the PoS adds new lines to the sale order. These are added during the order validation stage. However, the updated order lines are not written back to IndexedDB. If the user attempts to settle the order without reloading the session or clearing the cache, the PoS relies on stale data from In

## Issue:
Completing a flow from quotation to payment (down payment → settle) via Point of Sale does not properly update the sale order lines when settling.

## Reason:
During the down payment process, the PoS adds new lines to the sale order. These are added during the order validation stage. However, the updated order lines are not written back to IndexedDB.

If the user attempts to settle the order without reloading the session or clearing the cache, the PoS relies on stale data from IndexedDB. This causes Odoo to see outdated `order_lines`, usually only the original item(s), leading to incorrect behavior such as product quantities resetting to 0.

## Fix:
To ensure data consistency, we explicitly remove the affected sale orders from IndexedDB after the down payment is completed. This forces the PoS to re-fetch the updated order from the backend.

The re-fetch happens through the `missingRecursive` function, which will retrieve the complete and up-to-date sale order data, including the new order lines, ensuring accurate behavior during the settlement process.

## Steps to reproduce:
1. Create a service product with "Ordered quantities" as the invoicing policy.
2. Create a quotation using this product.
3. Open the PoS.
4. Click "Actions" → "Quotations" → select the quotation.
5. Choose the "Down Payment" option (any type) and set amount/percentage.
6. Pay the order.
7. Again, go to "Actions" → "Quotations" and select the same order.
8. Click "Settle the order".
9. At this point, Odoo will incorrectly reset product quantity to 0.


OPW-4811612

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

Forward-Port-Of: odoo/odoo#211139

Changed translations to use the legal term used in Mexico. This is done because "Cada dos semanas" and "Quincenal" don't have exactly the same meaning Forward-Port-Of: odoo/enterprise#86291 Forward-Port-Of: odoo/enterprise#83982

Changed translations to use the legal term used in Mexico. This is done because "Cada dos semanas" and "Quincenal" don't have exactly the same meaning

Forward-Port-Of: odoo/enterprise#86291
Forward-Port-Of: odoo/enterprise#83982

After a recent change in German EDI, the data exported in CSV from the EC Sales List can no longer be uploaded because the expected structure has changed Steps to reproduce (with a DE Company): - Make an invoice to an EU Partner - Open EC Sales List - Export CSV When uploading the file on the Elster portal it will be rejected with an explicit error message, saying that we're using an old CSV format now deprecated, and prompts the user to refer to the new specifications Original mes

After a recent change in German EDI, the data exported in CSV from the EC Sales List
can no longer be uploaded because the expected structure has changed

Steps to reproduce (with a DE Company):
- Make an invoice to an EU Partner
- Open EC Sales List
- Export CSV

When uploading the file on the Elster portal it will be rejected with an explicit error message,
saying that we're using an old CSV format now deprecated, and prompts the user to refer to the new specifications

Original message:
Ihre CSV-Datei wurde für eine ältere Version der CSV-Schnittstelle erstellt.
Bitte informieren Sie sich in der Versionstabelle der Importhilfe über die aktuellste Version der Schnittstelle sowie Änderungen.
Sind die Versionsangaben korrekt, prüfen Sie bitte das Encoding Ihrer CSV-Datei. Das zulässige Encoding ist UTF-8.

Sources:
https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop
https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079

opw-4751667
opw-4674533

Forward-Port-Of: odoo/enterprise#85992

Currently a traceback is occurring when the user tries to generate a payslip report. To reproduce this issue: 1) Install `l10n_in_hr_payroll` and shift to Indian company 2) Create an employee and a bank account in the private information of employee 3) Remove the `Bank Identifier Code` from the `Bank` while creating a bank record 4) Create a new `payslip` record with a `running contract` 5) Confirm the payslip and click the `Create Payment Report` Error:- ``` TypeError: expect

Currently a traceback is occurring when the user tries to generate a payslip report.

To reproduce this issue:

1) Install `l10n_in_hr_payroll` and shift to Indian company 
2) Create an employee and a bank account in the private information of employee
3) Remove the `Bank Identifier Code` from the `Bank` while creating a bank record 
4) Create a new `payslip` record with a `running contract` 
5) Confirm the payslip and click the `Create Payment Report`

Error:- 
```
TypeError: expected string or bytes-like object, got 'bool'
```

As the `bank_bic` is not a required field, user can removes it. 

if there is no `bank_bic`, it leads to the above traceback from the below line.

https://github.com/odoo/enterprise/blob/e2a9442ac33579c9833f65f59cf8341b3c6eafc8/l10n_in_hr_payroll/models/hr_employee.py#L24

sentry-6199042870

Forward-Port-Of: odoo/enterprise#81682

Related to odoo/odoo#209846 Forward-Port-Of: odoo/enterprise#85454

Related to odoo/odoo#209846

Forward-Port-Of: odoo/enterprise#85454

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#86290 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#86290
Forward-Port-Of: odoo/enterprise#73908

*: 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#86471
Forward-Port-Of: odoo/enterprise#86397

In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms

In this commit, we have addressed a crucial issue related to translation. We discovered that certain key
terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe.

task:3358438

Forward-Port-Of: odoo/enterprise#86078
Forward-Port-Of: odoo/enterprise#43574

This PR updates the `l10n_pe_withhold_code` field in the `product.template` model for the Peruvian localization (`l10n_pe_edi`) to reflect the latest official SUNAT withholding catalog (as of April 2025). Changes were made directly in the `fields.Selection`, maintaining compatibility with existing data by preserving obsolete values used in previous versions. This update helps ensure consistency with current SUNAT requirements while avoiding potential issues in existing databases. Refere

This PR updates the `l10n_pe_withhold_code` field in the `product.template` model for the Peruvian localization (`l10n_pe_edi`) to reflect the latest official SUNAT withholding catalog (as of April 2025).

Changes were made directly in the `fields.Selection`, maintaining compatibility with existing data by preserving obsolete values used in previous versions.

This update helps ensure consistency with current SUNAT requirements while avoiding potential issues in existing databases.

Reference: [Reglas de Validación actualizado al 21/04/2025 (Nuevo)](https://cpe.sunat.gob.pe/sites/default/files/inline-files/AjustesValidacionesCPEv20250421.xlsx)

Forward-Port-Of: odoo/enterprise#85917

In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271 Forward-Port-Of: odoo/enterprise#85575

In this PR:
- Added Bank of Slovenia to the list of currency providers.
- Fetches exchange rates using the official API and updates the rates.

Task-4794271

Forward-Port-Of: odoo/enterprise#85575

- This commit ensures that when settling due amounts in the Point of Sale (POS), the account move lines (aml) are automatically reconciled. This is particularly important for customer accounts, where due amounts need to be accurately reflected in the financial records. - This commit also adds a test to ensure that account move lines (aml) are properly reconciled when settling due amounts in the POS. ### Problem When paying a PoS order using customer account, an account move line debiting Ac

- This commit ensures that when settling due amounts in the Point of Sale (POS), the account move lines (aml) are automatically reconciled. This is particularly important for customer accounts, where due amounts need to be accurately reflected in the financial records.
- This commit also adds a test to ensure that account move lines (aml) are properly reconciled when settling due amounts in the POS.

### Problem
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.

### How to reproduce
    * Open a PoS session.
    * Create an order and pay using customer account.
    * Settle this customer's account (inside PoS).
    * Create a Sale Order and invoice it (or just an invoice).
    * The amount settled can be used as outstanding amount and can be used to pay the created invoice. 

Community PR: https://github.com/odoo/odoo/pull/211166

 opw-4794793
 
 Co-authored-by: Majed Alhanash (malh) <malh@odoo.com>

Forward-Port-Of: odoo/enterprise#86174

Before this PR: When generating the Libro Giornale Journal Audit report as PDF, journal items with long descriptions would cause rendering issues. The Name column would expand excessively to accommodate the long text, resulting in the Debit and Credit columns being cropped or completely missing from the printed report as seen in below image.  After this PR: The Libro Giornale Journal Audit report no

Before this PR:
When generating the Libro Giornale Journal Audit report as PDF, journal items with long descriptions would cause rendering issues. The Name column would expand excessively to accommodate the long text, resulting in the Debit and Credit columns being cropped or completely missing from the printed report as seen in below image.
![image](https://github.com/user-attachments/assets/3344129c-458e-4271-aef7-392bef8f2e48)


After this PR:
The Libro Giornale  Journal Audit report now correctly handles journal items with long descriptions. The report template has been modified to ensure proper column width distribution, preventing the Name column from expanding excessively. The Debit and Credit columns are now consistently displayed in the PDF report regardless of description length.
![image](https://github.com/user-attachments/assets/c75233b7-e630-4320-808d-6f972f86f267)



OPW-4788257

Forward-Port-Of: odoo/enterprise#86049

Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This is misleading, as by-products are outputs of a production process and should reference a destination location. Steps to Reproduce: ============================ - Install the stock_barcode_mrp module. - Activate multi-step routes and By-Products. - Create a Manufacturing Order with by

Issue Before This Commit:
============================

In MO barcode interface, the by-products section displays the
source location instead of the destination location for each by-product line.
This is misleading, as by-products are outputs of a production
process and should reference a destination location.

Steps to Reproduce:
============================

- Install the stock_barcode_mrp module.
- Activate multi-step routes and By-Products.
- Create a Manufacturing Order with by-products.
- Open the MO using the barcode app.
- In the by-product section notice that:
  - The lines are grouped by Source Location.
  - If you edit by-product line then user has option to edit source location.
  - If the MO operation type has Source Location scan as mandatory,
    user can't edit by-product line.

With This Commit:
============================

- By-product lines are now grouped by their destination location.
- The destination location is displayed for each by-product line.
- The source location field is hidden when editing by-product lines.
- Even if the MO operation type has Source Location scan as mandatory,
  users can still edit by-product lines.

This fix improves clarity and usability for production operators by ensuring
that the appropriate location context is accurately displayed and
can be edited when necessary.

task - [4654161](https://www.odoo.com/odoo/my-tasks/4654161)

Forward-Port-Of: odoo/enterprise#83617