Daily updates from Odoo
Monday, June 22, 2026
23 changes · saas-18.3
Enhancements to existing features
This update improves the Odoo payment process by adding debtor and creditor information to the data sent to Odoofin, a payment processing partner. This change is necessary to successfully initiate payments using Powens and Saltedge, ensuring smoother and more accurate payment transactions.
Original PR description
In order to be able to initiate payments using Powens and Saltedge, we need to include debtor information in the payload sent to Odoofin. This commit adds the necessary fields and updates the tests accordingly. Task ID: 5977148, 6095729 Forward-Port-Of: odoo/enterprise#119843
Resolved issues and error corrections
This update resolves an error that prevented users from sending SMS messages to website visitors. The fix corrects how the system accesses visitor phone numbers, ensuring compatibility with the latest website configuration changes. This ensures SMS functionality works as expected for all visitors.
Original PR description
Currently, an error occurs when a user tries to send an sms to a visitor. **Steps to Reproduce:** - Install `website_crm_sms` without demo data. - Go to `Website` > `Edit`, drag and drop another…
Currently, an error occurs when a user tries to send an sms to a visitor. **Steps to Reproduce:** - Install `website_crm_sms` without demo data. - Go to `Website` > `Edit`, drag and drop another `Form` block. - Configure the form action to `Create an Opportunity` and `save`. - Fill in the required fields, including phone number and `Submit` the form. - Go to `Website` > `Reporting` > `Visitors` and click the `SMS` button on the visitor record. `AttributeError: 'website.visitor' object has no attribute 'phone'` After [this commit], which removed the mobile field from res.partner along with all related views, then it was updated to access the phone number from the website visitor. When a user creates an opportunity through the website and then tries to send an sms from the corresponding visitor record, it raises an error [1] because it attempts to access the phone field on website.visitor. when an anonymous (non-logged-in) user creates an opportunity, clicking the sms button on the corresponding visitor record triggers error here [2]. This commit ensures that the correct mobile field is accessed from the website visitor. [this commit]: https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be [1]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L13 [2]- https://github.com/odoo/odoo/blob/6a0e6443951053f8361e97f42e5e45c32bb73656/addons/website_crm_sms/models/website_visitor.py#L20 sentry-7550340909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270118
This update fixes a minor issue within the Odoo composer (email creation tool) that was causing text editing to behave unexpectedly. Specifically, it addressed a problem where inserting mentions created a formatting error, leading to incorrect cursor placement. Adding a special character ensures proper text editing functionality and a better user experience.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269699
This update corrects a technical issue in the UBL BIS3 generation process for Debit Notes. Currently, the system incorrectly used 'LegalMonetaryTotal' instead of the required 'RequestedMonetaryTotal' node, leading to errors in UBL file creation. This change ensures Debit Notes are formatted correctly for UBL BIS3 compliance, improving data accuracy and export functionality.
Original PR description
Problem --------- Debit note should have the node `RequestedMonetaryTotal` instead of `LegalMonetaryTotal`. Solution --------- Add a conditional depending on the document type. opw-6295897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270238
This update fixes an issue where the partner associated with an invoice was incorrectly overridden by the purchase order during UBL (Universal Business Language) XML imports. The change ensures the purchase order is the definitive source for partner information on invoices, improving data accuracy and consistency. This resolves a potential discrepancy between purchase and billing records.
Original PR description
Fix a bug where the partner of a bill is overriden by the PO matching The chosen logic here is to say that in the context of a purchase, the purchase order is the single source of truth to set the partner on a bill Steps to reproduce: - Create a partner with is_company = True - Create a contact type 'invoice' for this partner - Create a purchase order for the first partner - Import an XML (UBL) that matches this PO - You can see in the import logs that the partner was correctly found first, and then the PO matching override it to set the contact as the partner task-6289358 Forward-Port-Of: odoo/odoo#270780 Forward-Port-Of: odoo/odoo#269223
This update fixes an issue where the Luxembourg eCDF XML export incorrectly reported financial year data. Specifically, it addressed an error caused by an automated entry from account 142, ensuring the data aligns with the Odoo Profit & Loss view. The fix removes unnecessary mappings and adds a test to guarantee accurate reporting.
Original PR description
Issue: Users reported that the financial year result in the XML export for the Luxembourg eCDF platform is incorrect, despite being correct in the Odoo Profit and Loss visualization. The exported XML populated incorrect amounts in cell 0161 under certain circumstances (namely, in the case of an explicit entry from account 999999 to account 142000). Solution: * Removed account 142 entirely from both the `ACCOUNTS_2019` and `ACCOUNTS_2020` dictionaries so it no longer auto-populates cells 0161/0162 (up to 2019 included) and 2955/2956 (from 2020 onward). * Removed the 2019 threshold condition in the loop bypass for account 142. * Removed the hard-coded manual pop for cell 2955 since it has been removed from the mapping. * Deleted the redundant reassignment of `net142` in the loss calculation block. Ticket [link](https://www.odoo.com/odoo/project.task/6059571) opw-6059571 Forward-Port-Of: odoo/enterprise#121010
This update resolves a problem where the PDP identifier field in the company registration process was left blank when using non-0225 PEPPOL EAS. It now displays a user error message if an invalid identifier is entered, preventing silent failures and ensuring accurate registration. This improves the reliability of the registration process.
Original PR description
Currently when the company partner uses non 0225 peppol EAS the `pdp_identifier` field is `False`. Thus the (related) identifier field on the registration wizard is left empty. Also add a UserError when writing an invalid identifier to the `pdp_identifier` field instead of just silently failing. That way an error ill pop up in the registration wizard when trying to register with an invalid identifier. task-6307489 Forward-Port-Of: odoo/odoo#270915 Forward-Port-Of: odoo/odoo#270330
This update corrects a requirement in the Danish Nemhandel system for Universal Business Language (UBL) invoices. Specifically, it adds a 'TaxCategory' node to the 'AllowanceCharge' element, resolving a previously identified issue. This ensures proper invoice formatting and compliance with Nemhandel's specifications.
Original PR description
Add the TaxCategory node in AllowanceCharge node as it's a requirement for some UBL format. It has been spoted with Nemhandel, as it requires a single tax category in the AllowanceCharge. no-task Forward-Port-Of: odoo/odoo#270351
This update prevents errors in e-Waybill requests when the dispatch and delivery locations share the same pin code. Previously, the system couldn't automatically calculate the distance in these cases, leading to incomplete requests. Now, a distance must be provided, ensuring accurate e-Waybill generation and avoiding server issues.
Original PR description
Prevent sending incomplete e-Waybill requests to the GSP server when the dispatch and delivery pincodes are identical. In such cases, the distance cannot be automatically determined and must be provided explicitly. This commit adds a validation to ensure a distance is set before generating the e-Waybill, avoiding incomplete requests and subsequent server-side errors. task-6234343 Forward-Port-Of: odoo/odoo#270495 Forward-Port-Of: odoo/odoo#268497
This update resolves an issue where payments to the DIAN (Colombian tax authority) were failing due to incorrect XML formatting. The fix combines payment amounts into a single tag, ensuring accurate calculations and preventing errors related to negative payment amounts.
Original PR description
**Steps to reproduce:** To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN. - Setup the DIAN in a colombian company - Open the…
**Steps to reproduce:** To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN. - Setup the DIAN in a colombian company - Open the PoS - Order a product - Before paying, make the amount we are paying bigger than the amount due - We get an error response from the API, the error is saying that the total due does not match what we paid **Why the fix:** Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for. This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive. The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive. This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it. To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line. opw-6232575 Forward-Port-Of: odoo/enterprise#121075 Forward-Port-Of: odoo/enterprise#119255
This update resolves a technical issue impacting how Odoo handles Mexican tax invoices (CFDI). The system was struggling to process invoices with many related documents due to a database index limitation. Switching to a different index type ensures smoother processing and improved performance for complex cancellation scenarios.
Original PR description
The field `l10n_mx_edi_cfdi_origin` can contain a large number of associated UUIDs, especially in complex cancellation scenarios. The default B-tree index fails when this field exceeds 2704 bytes, which occurs after approximately 20 UUIDs. By switching to a trigram index, we avoid the entry size limit of PostgreSQL's B-tree nodes. This ensures that invoices with many related documents can be processed while maintaining efficient search performance for partial matches on this field. **Video before the fix:** https://youtu.be/24u0HbxwIH8 **Video after the fix:** https://youtu.be/sUelv1HZMvI Forward-Port-Of: odoo/enterprise#118868
This update resolves an issue where the XML generated for Polish e-invoices (FA3) with reverse charge taxes was incorrectly formatted. Specifically, the XML fields related to reverse charge were not accurately reflected, leading to potential errors in tax reporting. This fix ensures accurate data transmission to the KSEF system.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice with a tax with reverse charge (0% EU G for example). 2. Send the invoice to ksef. 3. Open the generated xml, and notice field P_18 is 2 while it should be 1 (because there is reverse charge). Also, there is not P13_10 indicated the total value of sale to which the reverse charge applies. opw-6041836 Forward-Port-Of: odoo/odoo#263764
This update resolves a critical issue where paying with an Adyen terminal could cause the POS system to crash due to duplicate notifications from Adyen. The fix ensures that the system only processes each payment line once, preventing errors and improving payment reliability.
Original PR description
The following error is raised in the POS when paying with an Adyen terminal: ``` TypeError: Cannot read properties of undefined (reading 'uuid') at Proxy.handleAdyenStatusResponse ``` Adyen delivers…
The following error is raised in the POS when paying with an Adyen terminal: ``` TypeError: Cannot read properties of undefined (reading 'uuid') at Proxy.handleAdyenStatusResponse ``` Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so getPendingPaymentLine no longer returns it and the subsequent line.uuid dereference crashes. opw-6237987 patched the same root cause on a single line by adding an optional chaining operator in isPaymentSuccessful, which only moved the crash to the next dereference. Fetch the pending line once at the start of handleAdyenStatusResponse and bail out when it is gone, so every dereference below is safe. The same guard is added to the remaining branches of _adyen_handle_response for consistency with the existing Reject branch. opw-6237987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270880 Forward-Port-Of: odoo/odoo#269720
This update corrects an issue where emojis, particularly complex ones like `👨🚒`, were being displayed incorrectly due to how they were encoded. The fix backports a more robust regex pattern from a recent version of Odoo that properly handles these variations in emoji formatting, ensuring emojis are displayed correctly.
Original PR description
Bug === Some emoji like `👨🚒` are separated, because they are built using `👨 + Emoji_Modifier + 🚒` (`\uFE0F` can also be used to get the variant of the emoji). Adapt the regex to take into account those Unicode variations. Task-5491124 Forward-Port-Of: odoo/odoo#270779 Forward-Port-Of: odoo/odoo#269719
This update resolves an issue where international UPS shipments were failing due to incorrect commercial invoice addresses. The fix initially used the delivery address, but this caused further problems. Now, the system defaults back to the delivery address if country codes don't match, with a warning displayed to the user to ensure accurate invoice information.
Original PR description
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- -…
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- - Create a belgian company - Setup UPS - Create a French customer - Add a different french delivery address - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > Commercial invoice `Sold To` uses the delivery address Solution for case 1 ----- Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases... Problematic case 2 (caused by case 1 fix) ----- - Create a belgian company - Setup UPS - Create a French customer - Add a delivery address in Switzerland - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.` Solution for case 2 ----- Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO). Warning looks like this (on SO): <img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" /> ----- Ticket: opw-6200263 Forward-Port-Of: odoo/enterprise#119747 Forward-Port-Of: odoo/enterprise#118031
This update resolves a bug that previously prevented the system from correctly calculating bill addresses when address fields were empty. The fix ensures that empty address fields are now handled gracefully, preventing errors and improving the reliability of payment authorization processes. This change ensures accurate billing information is consistently processed.
Original PR description
Fix bug introduced by commit https://github.com/odoo/odoo/pull/267592/changes/c4556637e8eeef07ce6e3cc3b3b4cf28fa10e468 that caused an error if an address field was not set, due to trying to cut a False field. Now, unset fields are set to empty strings. Forward-Port-Of: odoo/odoo#270295
This update resolves a problem where Italian fiscal printers would intermittently stop printing receipts due to unsupported characters in product or payment method names. The fix replaces these characters with spaces, aligning with Epson's official documentation to ensure proper receipt generation. This prevents lost sales and data discrepancies.
Original PR description
Steps to reproduce: - Setup an Italian fiscal printer - Modify the name of a product to use the non-blocking space character "\ "; - In the POS, create an order with the product. Error: the fiscal device will stop midway in the printing process and return an incomplete response to the frontend. The issue can also be reproduce if the character is included in the payment method name or the POS config name. Solution: When formating the xml command, replace all non-supported character by a space character. The non-supported character list is provided by the official [EPSON fiscal printer documentation](https://support.epson.net/setupnavi/?PINF=bsmanual&OSC=WS&LG2=EN&MKN=FP-90III%20RT) in the document "ePOS Fiscal Print Solution Development Guide". Other: Rename the file "dispaly_text.xml" to "display_text.xml". [opw-6244089](https://www.odoo.com/odoo/project/49/tasks/6244089) Forward-Port-Of: odoo/enterprise#120169
This update resolves an issue where the table of contents would obscure headings when the status bar was made sticky. The fix ensures headings remain visible by intelligently accounting for sticky elements during scrolling within the table of contents, improving usability.
Original PR description
Since [1] when the `o_form_statusbar` status bar was made `sticky` the table of content scrolls to a given heading without taking it into account. Because of this, when scrolling upwards the heading ends up behind the status bar. This commit fixes this by finding top-aligned sticky elements within the closest scrollable element impacted by the table of content. Steps to reproduce: - Go to a To do note - Define some headings - Have sufficient content so that reaching a heading requires scrolling - Define a table of content with `/toc` - Click on a heading => The heading ended up behind the status bar. [1]: https://github.com/odoo/odoo/commit/a3c63413825cf3492a10ade77a2c571c4eeb33a6 task-6302762 Forward-Port-Of: odoo/odoo#270043
This update removes a redundant step in a test related to bank account matching. Previously, the test required manually unlinking a bank account to prevent incorrect partner identification. Now that the system correctly identifies partners using VAT numbers, this step is no longer needed, streamlining the testing process.
Original PR description
Since `saas-18.3`, the partner is correctly found using the VAT number, so the test no longer needs to remove `partner_1`'s bank account to avoid a wrong match. Remove the unnecessary `self.partner_1.bank_ids.unlink()` from `test_xml_ubl_au.py`.
This update resolves a technical issue that caused the restaurant order tour to fail intermittently. The fix ensures the system waits for order processing to complete before proceeding, preventing duplicate requests and improving the reliability of the tour. This enhances the user experience for restaurant order setup.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846 Forward-Port-Of: odoo/enterprise#120910 Forward-Port-Of: odoo/enterprise#110909
This update fixes an issue where CFDI payment documents incorrectly displayed rates when payments were made in foreign currencies (like USD). The fix ensures the correct payment amount and exchange rate are used, accurately reflecting transactions for Mexican tax reporting. This improves the reliability of our CFDI generation process.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519 Forward-Port-Of: odoo/enterprise#115779
This update fixes an issue where preparation times weren't accurately calculated when order stages changed, and reports incorrectly combined data across all companies. The changes ensure preparation times are correctly updated and that reports now display data specific to the active company, leading to more accurate order time estimations and reporting.
Original PR description
Issues: - Preparation time for order lines was not computed when the preparation order stage changed. - Preparation time report aggregated orders across all companies instead of showing records for the active company only. Fixes: - Ensure preparation time is properly recomputed when the order stage changes. - Add company domain filtering to the preparation time report. Task-6250974
Documentation and clarification updates
This pull request formally records Adrien Didot's signature on the Odoo Individual Contributor License Agreement. It adds documentation confirming the CLA signing, ensuring compliance with Odoo's licensing terms. This update is a standard legal step for contributions to the Odoo project.
Original PR description
Individual Contributor License Agreement signature. Adds `doc/cla/individual/adridot.md` per the CLA signing instructions. Related contribution: #270196 Forward-Port-Of: odoo/odoo#270411 Forward-Port-Of: odoo/odoo#270197