Friday, September 4, 2026
16 changes · saas-18.3
Resolved issues and error corrections
This fixes French PDP Flow 10 reports so VAT totals match invoice totals more reliably. Unsupported tax rates are now flagged before submission, untaxed invoice lines are included correctly, and exemption reasons are preserved in the generated report.
Original PR description
Flow 10 reports currently send unsupported custom tax rates without reporting an error on the related journal entry. Untaxed invoice lines also produce a zero taxable amount, which makes the VAT breakdown inconsistent with the invoice total. Exemption reasons without a code are omitted from the XML. Validate tax rates before sending. Include the base of untaxed lines in the tax summary and preserve exemption reasons so the generated totals and VAT breakdown remain consistent. No Task id Forward-Port-Of: odoo/odoo#286547
Fixes French electronic invoicing reports so vendor bills and credit notes are classified with the right document codes. This reduces the risk of purchase invoices being rejected because they were incorrectly reported as credit notes without a prior invoice reference.
Original PR description
Flow 10 used move.is_inbound() to distinguish invoices from credit notes. While this gives the expected result for sales documents, it reverses the codes for purchase documents. Vendor bills were therefore reported as credit notes and could be rejected for having no preceding invoice reference. Determine the document kind from move_type instead. Regular invoices now use code 380 and credit notes code 381. Self-billed invoices and credit notes use codes 389 and 261 respectively. No Task id Forward-Port-Of: odoo/odoo#286526
Customers can now complete checkout when their cart includes a legitimate free gift from a promotion, even if the store blocks regular zero-priced products. This prevents valid promotional orders from being sent back to the cart with a warning.
Original PR description
As of commit b8e790b2, a cart containing a product priced at 0 while the website forbids the sale of zero-priced products is no longer payable: the customer is redirected back to the cart with a warning. Reward lines were caught by that new rule. A promotion offering a free gift whose product has no sale price adds a reward line priced at 0 to the cart, so the whole cart became unpayable even though nothing was wrong with it. This commit excludes reward lines from the zero-priced rule, the same way delivery lines already are. opw-6526396 Forward-Port-Of: odoo/odoo#286464
This fix removes sample data that relied on a purchasing feature not always installed with project budgeting. It helps prevent setup or testing errors when using project budget features without the purchasing integration.
Original PR description
This commit removes demo data referencing the module `project_purchase` as there is no direct dependency chain from `project_account_budget` to `project_purchase`. [error-237905](https://runbot.odoo.com/odoo/error/237905) Forward-Port-Of: odoo/enterprise#125294
Odoo’s DHL REST shipping integration no longer creates a carrier pickup request when arranging shipments. This avoids confusing pickup scheduling steps and reduces DHL errors when pickup windows are not configured, making DHL behave like other shipping carriers in Odoo.
Original PR description
Before this commit, the DHL REST module had the pick-up request set, which led to an unnatural use flow, needing to set up an scheduled date for pick-up, and several errors from DHL when these were not properly configured. This feature was unique to this module among the shipping carriers as we don't normally request pick-up for packages and leave it to user to decide how to do it. This commit removes the request for pick up and the logic that was needed to make it work. This will make the behavior consistent with other carriers in Odoo, and avoids the need to set scheduled pick-up windows and having to deal with unnecessary errors. opw-6148927 Forward-Port-Of: odoo/enterprise#123773
Refunds for purchased stock items in a foreign currency now avoid posting currency exchange differences to the inventory valuation account. This keeps inventory values accurate when exchange rates change between the original purchase and the refund.
Original PR description
When refunding the purchase of a valued product that was received in a foreign currency. If the rate of the currency has changed between the purchase and the refund, the exchange difference line was impacting the valuation account. Steps to reproduce: ------------------- * Activate any other currency * Create a valued product and set a cost price * Create a purchase order in the foreign currency for the product * Confirm the purchase order and receive the product * Change the rate of the foreign currency * Create a return for the product and validate it > Observation: An exchange difference line is created and impacting the valuation account. Why the fix: ------------ When selecting the exchange account to use, we now check if we are in a return context. If it's he case we do not use the stock valuation account. opw-6313904 Forward-Port-Of: odoo/odoo#278047
Fixes a crash in Discuss that could occur after users selected emojis from search results and then cleared the emoji picker search field. This keeps chat interactions smooth and prevents an error from interrupting emoji selection.
Original PR description
Steps to reproduce: - open Discuss, open any chat, open the emoji picker (no 'Frequently used' emojis) - search a term and select emojis without closing the picker (shift+click on desktop, plain…
Steps to reproduce:
- open Discuss, open any chat, open the emoji picker (no 'Frequently used'
emojis)
- search a term and select emojis without closing the picker (shift+click on
desktop, plain click on mobile)
- clear the search with backspace
=> traceback: 'Cannot read properties of null (reading
`getBoundingClientRect`)' in adaptNavbar().
This happens because when we clear the search input it calls
`highlightActiveCategory()`, which sets `categoryId` to the topmost category of
the grid, which is now the 'Frequently used' category (sortId 0), added to the
picker since the emojis we just picked updated the recent state. To update the
navbar, `currentNavbarPanel` then looks for the panel holding it in
`emojiNavbarRepr`, but that representation is only built in `adaptNavbar()`,
which runs on mount and from the `ResizeObserver` only, so it was built without
the 'Frequently used' category and no panel contains it. It returns undefined,
the navbar renders empty, its size change wakes the `ResizeObserver`, and
`adaptNavbar()` crashes on querySelector('.o-Emoji').getBoundingClientRect()`.
This commit solves the issue by rendering the `recentEmojis` from a snapshot
taken when the picker is opened, so they are not added to the picker while the
while `emojiNavbarRepr` does not contain their category id.
partial backported PR: https://github.com/odoo/odoo/pull/281104
Task-[6204249](https://www.odoo.com/odoo/project/1519/tasks/6204249)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#284372The HTML editor now properly removes file-related event handlers when an editor is closed or destroyed. This prevents hidden leftover activity from building up over repeated editor use, helping keep the interface stable and responsive.
Original PR description
FilePlugin registered its click, keydown and pointerdown handlers with raw `addEventListener`, so they were never removed when the plugin was destroyed. The pointerdown one is bound to the document, which outlives the editable, leaking a handler per editor instance. Use `addDomListener` so Plugin.destroy() removes them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286144
The Mexico POS self-invoicing test was updated to match the new customer data flow. This helps ensure receipt QR code invoicing remains reliable now that public users can no longer edit existing customer records during self-invoicing.
Original PR description
Before the related pr commit: - Public users could update customer data during the self-invoicing flow. - The test_qr_code_receipt_mx test relied on this behavior when updating customer data. After the ref commit: - Public users can no longer update customer data during self-invoicing. - Update test_qr_code_receipt_mx to create a new partner with the required customer data when the order is not linked to a customer. Related PR: odoo/odoo#283470 Task-6272660
Corrects how Mexican CFDI payment complements calculate taxable base amounts for foreign-currency invoices paid in MXN. This prevents valid payment updates from being rejected by the certification provider due to tiny rounding differences.
Original PR description
**Steps to reproduce:** * Install the **l10n_mx** localization. * Enable **USD** and fetch the latest currency exchange rate from the settings. * Configure **Quadrum** as the **PAC** in the settings.…
**Steps to reproduce:**
* Install the **l10n_mx** localization.
* Enable **USD** and fetch the latest currency exchange rate from the settings.
* Configure **Quadrum** as the **PAC** in the settings.
* Create and sign a USD invoice with **16% IVA** (e.g. 4,500 USD + 720 USD tax = 5,220 USD total).
* Send the invoice to **CFDI**.
* Register a **partial MXN payment** that does not convert to a round USD amount (e.g. 30,000 MXN = 1,762.45 USD).
* Send the payment complement to the PAC by clicking **Update Payments** on the invoice.
**Observed behavior:**
The PAC rejects the CFDI with error **CRP20268**:
> El campo BaseP que corresponde a Traslado, no es igual a la suma de
> los importes de las bases registrados en los documentos relacionados
> donde el impuesto del documento relacionado sea igual al campo
> ImpuestoP de este elemento y la TasaOCuotaDR del documento
> relacionado sea igual al campo TasaOCuotaP de este elemento.
**Cause:**
* The SAT validator enforces a strict arithmetic relationship between three fields that are printed in the payment complement XML:
```
BaseP == round(BaseDR / EquivalenciaDR, 6)
```
* When `percentage_paid` is a non-terminating decimal (which happens for any partial MXN payment against a USD invoice), the internal `raw_base` float carries more precision than the 6-decimal-place `BaseDR` that is actually written to the XML:
```
percentage_paid = 1762.45 / 5220 = 0.33763409961685825...
raw_base = 4500 × 0.33763... = 1519.353448275862...
BaseDR (XML) = float_round(raw_base, 6) = 1519.353448
```
* The old code then used `raw_base` (the unrounded internal value) as the dividend when computing BaseP:
```
BaseP (old) = float_round(1519.353448275862... / 0.0587483333, 6)
= 25862.068980 ← written to <TrasladoP BaseP="...">
```
* The PAC performs the same division using only what it can read from the XML. The already-rounded BaseDR:
```
BaseP (PAC) = round(1519.353448 / 0.0587483333, 6)
= 25862.068975
```
* The 6th-decimal mismatch (25862.068980 ≠ 25862.068975) triggers CRP20268 and the document is rejected.
* The same issue occurs with a full MXN payment on a different date than the invoice when multiple invoice lines cause the rounded aggregate to diverge from the sum of per-line raw values.
**Fix:**
In `_l10n_mx_edi_add_payment_cfdi_values` (`account_move.py`), the block that builds the BaseP aggregation list was changed from iterating over raw per-`base_line` amounts to building a single synthetic entry per invoice using the already-rounded document-level `BaseDR` values (`tax_details['base']`) as the dividend:
- Before : wrong: raw_base ≠ BaseDR printed in the XML
'raw_base': tax_details['raw_base'] / inv_rate
- After : correct: 'base' == BaseDR, the exact value in the XML
'raw_base': tax_details['base'] / inv_rate
This guarantees that Odoo and the PAC divide the identical value, producing the identical 6-decimal result.
The `base_line_cfdi_values_mx_curr_list` path (used only for the `Totales` summary fields rounded to 2 dp) is left unchanged because the CRP20268 rule does not apply to that block.
opw-6468077
Forward-Port-Of: odoo/enterprise#128357The reference field now shows a placeholder for the required record selector, making it clearer that users must choose both a model and a specific record. This prevents incomplete links from being saved and then disappearing after the page is refreshed.
Original PR description
Steps to reproduce: 1. Install Sign. 2. Open the form view of a document. 3. Select a model in the "Link to" (Reference) field, but leave the record empty. 4. Save and refresh the page. Issue: -…
Steps to reproduce:
1. Install Sign.
2. Open the form view of a document.
3. Select a model in the "Link to" (Reference) field, but leave the record empty.
4. Save and refresh the page.
Issue:
- After refreshing, the selected model is cleared because the reference value is invalid.
Cause:
- A reference field is only valid when it contains both a model and a record ID. However, the record selector has no placeholder, making it easy to overlook and save an incomplete value.
Solution:
- Add a default placeholder to the record selector of reference fields to make it more visible.
<table>
<tr>
<th>Before</th>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/3ba34b77-f901-4d3e-9768-5acaf2e673b8" alt="Before" width="100%">
</td>
</tr>
<tr>
<th>After</th>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/1fe54b89-221f-4d28-bd2b-0a3c706d5746" alt="After" width="100%">
</td>
</tr>
</table>
opw-6426339
Forward-Port-Of: odoo/odoo#280266The Documents app spreadsheet template dialog now keeps the search bar visible even when no templates match the search. It also prevents a crash when users choose to add a custom filter, making template selection smoother and more reliable.
Original PR description
- templates searchbar disappear when the search has no match - Clicking "Add a custom filter' in the searchbar crashes Task-6526322 Forward-Port-Of: odoo/enterprise#130096
This fixes a crash that could happen when users dragged an image and dropped it back in the same spot in the HTML editor, especially in Chrome. The editor now handles that action safely, preventing interruptions while editing content.
Original PR description
Steps to reproduce: - Insert an image as the last child of a paragraph. - Drag and drop it below or after itself. Description of the issue: - A traceback occurs. Cause: - When dropping an image below or after itself `document.caretPositionFromPoint()` computes a drop offset equal to the current node size. - The image is then removed from the DOM before being reinserted. Since it is the last child of its parent, removing it shrinks the parent, making the previously computed offset out of bounds. - Restoring the selection at that stale offset results in a traceback. Solution: - Treat dropping the image at its current position as a no-op and skip the remove/reinsert process, since it would not change the DOM. - Clamp the drop offset to the current node size before restoring the selection preventing out-of-bounds offsets. task-6435091 Forward-Port-Of: odoo/odoo#280612
This fixes an issue where electronic invoice generation could crash in Community Edition when enterprise-only deferred billing fields were unavailable. The change safely checks for those fields before using them, keeping invoice exports working for customers without the enterprise accounting add-on.
Original PR description
The fields `deferred_start_date` and `deferred_end_date` are created by the enterprise addon `account_accountant`, so not having it installed, this crashes with:
```
File "/opt/odoo/auto/addons/account_edi_ubl_cii/models/account_edi_cii.py", line 684, in <listcomp>
billing_start_dates += [move_line.deferred_start_date for move_line in invoice.invoice_line_ids if move_line.deferred_start_date]
AttributeError: 'account.move.line' object has no attribute 'deferred_start_date'
```
This PR protects the access to these fields checking first if they exist.
Bug introduced in the refactoring in #261572.
@Tecnativa TT64359
Forward-Port-Of: odoo/odoo#286245Fixed an issue where text entered with a phone or virtual keyboard in rich text fields could be lost if the user saved immediately. This ensures notes and similar HTML content are committed before saving, preventing empty activity notes and improving reliability on mobile devices.
Original PR description
On a virtual keyboard the editor handles typing as a composition and only commits its history step on a later interaction. The html field marks itself dirty from that step, so right after typing the…
On a virtual keyboard the editor handles typing as a composition and only commits its history step on a later interaction. The html field marks itself dirty from that step, so right after typing the field is not dirty. On save the form calls commitChanges, but it only writes the value when the field is dirty, or on an urgent or inline-style save. None of those hold for a plain sanitized html field, so the typed content is not written to the record. Finalize the pending composition in commitChanges by calling the editor _compositionStep() before that check. commitChanges is the single point every save path goes through, so committing the pending step there marks the field dirty and the content is saved. It does nothing on a physical keyboard, where the composition flag is cleared after each keystroke. Steps to reproduce: 1. Open the Sales app and a quotation. 2. In the chatter, click Activities then Schedule Activity. 3. On a phone, or a browser with a virtual keyboard, fill Summary, tap the note field and type a note. 4. Tap Schedule while the note field still has focus. 5. Open the created activity. => the note is empty Ticket [link](https://www.odoo.com/odoo/project.task/6331719) opw-6331719 Forward-Port-Of: odoo/odoo#284495 Forward-Port-Of: odoo/odoo#274465
French electronic invoice exports now automatically include the due date when an invoice is marked as paid. This keeps exports compliant with the latest French validation rules and helps avoid rejected invoice submissions.
Original PR description
According the schematron v1.4, the cbc:DueDate is required when the move is PAID. "[BR-FR-CO-09/BT-23] : Si le cadre de facturation (BT-23) est B2, S2 ou M2, alors la date d’échéance (BT-9) doit être renseignée et correspondre à la date de paiement." no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286263