Daily updates from Odoo
Saturday, November 8, 2025
6 changes · saas-18.3
Resolved issues and error corrections
This change fixes the printed Carta Porte so its CCP ID and QR code always match the official CFDI already sent to the government. It prevents a new identifier from being generated each time the document is printed, ensuring the printed copy stays consistent and reliable.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a…
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a product: * Product Name: XYZ * Product Type: Storable Product * UNSPSC Category: 25101929 Mobile office van * Tariff Fraction: 0101299999 Los demás. * UMT Aduana: Units * Weight: 1.00 - Go to "Inventory / Operations / Transfers / Deliveries" - Create a delivery: * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA) * Product: Product XYZ * Transport Type: Federal Transport * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT) * Gross Vehicle Weight: [anything] * Distance to Destination (KM): [anything] - Validate the delivery - Generate Delivery Guide => CFDI document should be created and signed by the government - Print Carta Porte **Issue:** The "CCP ID" in the PDF is different than the one in the CFDI sent to the government. Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF. This also leads to a different QR-code in each PDF. **Cause:** When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed. The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier. Each time the compute method is called, a new identifier is generated. **Solution:** When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document. opw-5208648 Forward-Port-Of: odoo/enterprise#99034 Forward-Port-Of: odoo/enterprise#98920
This update corrects how credit note totals are prepared before being sent to ECPay. It prevents mismatched amounts when the original invoice has already been paid, avoiding API errors and ensuring credit notes can be transmitted successfully.
Original PR description
When invoice is reconciled and credit note is issued, amount_residual_signed is not zero. By doing sale_amount += self.amount_residual_signed, TotalAmount is not match with the original sale amount and ECPay API returns error. task-5230384 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#234468
This update fixes an issue where vendor credit notes could be rejected by MyInvois when the original bill had a custom reference. The system now uses the reference stored with the submitted e-invoice, helping ensure the reversal document matches what the tax authority expects.
Original PR description
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference…
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference document UUID [...] does not exist. The internal ID for DocumentUUID [...] does not match. ``` Steps to reproduce: - With an MY company setup - Create a bill and add a custom reference - Send Bill to MyInvois - Create credit note for the Bill - Send Credit note to MyInvoice Issue: Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used. Analysis: A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice. opw-5057050 Forward-Port-Of: odoo/odoo#234762 Forward-Port-Of: odoo/odoo#234199
This change prevents an internal error that could appear when a browser’s service worker for Odoo is manually removed. It makes push notifications reconnect more reliably, so users are less likely to see a failed notification message after refreshing the page.
Original PR description
When you manually unregister the ServiceWorker linked to your Odoo,
you may receive a notification "Failed to enable push notifications".
This occurs because the ServiceWorker associated with the previous
subscription is gone and the browser has lost the link between the
subscription and the Odoo instance.
To handle this case, we ensure waiting the activated state of the
registration of the service worker before subscribing to the web push
notification.
Steps to reproduce:
- In Odoo, enable push notifications.
- Inside another tab, go to the internal Chrome URL:
chrome://serviceworker-internals/?devtools
- Unsubscribe the ServiceWorker linked to your Odoo instance.
- In the Odoo instance tab, press F5.
=> You will see an internal notification stating
"Failed to enable push notifications" => BUG.
Forward-Port-Of: odoo/odoo#235005
Forward-Port-Of: odoo/odoo#234930This change corrects how Peppol verification updates are applied when several fields are written in sequence. It prevents inconsistent data from being temporarily created, which could otherwise cause validation errors for some partners.
Original PR description
In some cases, when doing two consequent writes instead of one batch, the ORM will trigger the dependencies needlessly, and it can end up to discrepancies like: EAS=0208, endpoint=BE... which lead to a validation error. opw-5228670 opw-5225590 opw-5228716 opw-5229057 opw-5232276 Forward-Port-Of: odoo/odoo#234581 Forward-Port-Of: odoo/odoo#234290
Editing a message with the ArrowUp shortcut now restores previously mentioned channels, just like using the Edit action. This keeps message edits consistent and helps prevent mentions from being accidentally lost.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When editing a message via the ArrowUp shortcut, any previously mentioned channels (e.g., `#general`)…
**Description of the issue this PR addresses:** ------------------------------------------------ When editing a message via the ArrowUp shortcut, any previously mentioned channels (e.g., `#general`) were not restored in the composer. This happened because the logic to restore mentions was only applied in the `onClick()` handler of the Edit message action. **Current behavior before PR:** --------------------------------- - Editing a message using ArrowUp does not restore mentioned channels - Editing via the Edit message action still works correctly **Desired behavior after PR is merged:** ----------------------------------------- - Mentioned channels are restored when entering edit mode via ArrowUp - Behavior is consistent with editing through the Edit message action - No mentions are lost in any edit scenario **Important: This PR should only be merged for versions saas-18.2, saas-18.3, and saas-18.4.** **Backport of https://github.com/odoo/odoo/pull/229546/commits/5878e398615596adcf09eef8acbbe5aa739918f3** **Task:** 5133698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231192