Daily updates from Odoo
Wednesday, February 18, 2026
14 changes · 17.0
Resolved issues and error corrections
This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to errors and inconsistencies when processing invoices between different companies. The fix ensures that invoices are processed with the correct company information, preventing data mismatches and improving data accuracy for cross-company transactions.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233 Forward-Port-Of: odoo/odoo#249059
This update corrects a problem where the e-dispatch XML generated by the Nilvera integration was failing validation due to a missing customer tax office. The fix adds this required information and includes a validation check to ensure it's present before the XML is created, preventing rejection by GIB validation.
Original PR description
Problem: - The generated e-dispatch XML was missing the customer tax office name, marking XML to be rejected or incomplete in GIB validation. After this commit: - Added the missing customer tax office name in the e-dispatch XML. - Introduced a validation check to ensure the tax office field is set before XML generation. task-5013706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that One Stop Shop (OSS) invoices for intra-EU B2C sales in Italy are correctly formatted for the Italian Revenue Agency (Agenzia delle Entrate). The change introduces a specific XML structure to accurately represent VAT amounts, resolving previous rejection issues by the SDI and ensuring compliance with FatturaPA regulations.
Original PR description
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior:…
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior: Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices. New behavior: The XML generation logic has been updated to follow the specific codification required for OSS operations: 1. Invoice Lines (`DettaglioLinee`): - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state). - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other). 2. Tax Summary (`DatiRiepilogo`): - The original foreign tax lines are excluded from the summary. - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories. Implementation details: - Added `_l10n_it_is_oss_tax` helper to identify OSS taxes. - Modified `_l10n_it_edi_get_line_values` to split OSS lines. - Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary. task-4711509 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
This update ensures that the Studio XML editor only translates views for the currently selected website, preventing unintended translations from other websites in the database. This improves the user experience by focusing translations on the relevant website content, resolving a previous issue where the default website's language was always used.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124
This update fixes a problem where large image uploads would fail, causing a confusing user experience. Now, uploads can be safely aborted, preventing errors and ensuring a smoother, more predictable process for users. The fix eliminates unexpected uploads after discarding the media dialog.
Original PR description
Steps to Reproduce: 1. Open the website module. 2. Open the media upload dialog to upload an image by either double-clicking the logo or replacing the existing image. 3. Upload a large file. 4. Abort the upload before it finishes by clicking the 'Discard' button in the media dialog box. After performing these steps, a traceback is observed. Before this commit: - Image upload failures would throw uncaught exceptions. - These exceptions would interrupt the flow and result in a poor user experience with no clear feedback. - Even after clicking the discard button the image was still getting uploaded. After this commit: - Uploads can be safely aborted when the media dialog is discarded. - Ongoing XHR requests and RPC calls are properly cancelled. - The upload loop stops immediately when an abort is triggered with no traceback. - Users get a predictable and clean exit instead of a broken state. - Files are no longer uploaded after clicking Discard. ### task-4752497
This update resolves a problem preventing Virtual IoT boxes from downloading handlers due to a limitation in Python's SSL verification process on Windows. The change ensures secure certificate validation by explicitly using a trusted certificate package, maintaining security while restoring functionality.
Original PR description
In PR #233423, we rightfully removed `cert_reqs='CERT_NONE'` to enforce secure certificate validation during IoT handler downloads. However, this exposed a blind spot in Python's `urllib3` library on Windows. Because `urllib3` defaults to the host's underlying certificate list (which is limited on Windows) instead of the installed `certifi` package, Virtual IoT boxes get the following error during handler downloads: `certificate verify failed: unable to get local issuer certificate` This commit restores the broken flow while maintaining security by explicitly passing `certifi.where()` to the `urllib3.PoolManager` via the `ca_certs` parameter. opw-5902549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test failure related to the eWallet checkout process has been fixed. The update ensures the system correctly applies the eWallet discount and updates the total amount before proceeding to the final payment step, preventing checkout errors.
Original PR description
In the `shop_sale_ewallet` tour, a Runbot error was triggered because the test would add a $50 product to the cart and immediately click the checkout button after selecting eWallet. This sometimes caused the eWallet to not be applied in time, leaving the total amount not updated to $0, and later the pay button could not be found. Solution: Ensure that after clicking on eWallet, the tour waits for the total amount to be $0 and for a success message confirming the code has been applied before proceeding to checkout. runbot-145574
This update ensures that invoice totals in the Italian e-invoice format (`l10n_it_edi`) are correctly expressed in EUR, as required by Italian tax regulations. Previously, the total was incorrectly using the invoice currency. This change aligns with government guidelines and avoids potential compliance issues.
Original PR description
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to…
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency. `ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document: https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b > L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che > “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”. > Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>` > deve essere obbligatoriamente “EUR”. > Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that > “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.” > Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>` > field must mandatorily be “EUR”. As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field (assuming the company currency is always EUR for `l10n_it`). Ticket [link](https://www.odoo.com/odoo/project.task/5913088) opw-5913088
This update fixes an issue where overtime calculations were incorrect after a leave request was re-evaluated or switched back to validated. The system now automatically recalculates overtimes whenever leave information is changed, ensuring accurate overtime reporting for employees. This improves the reliability of time tracking data.
Original PR description
When we re-evaluate leaves we update overtimes after switching to draft but we do not update the overtimes again after the leave is switched back to validated. This causes the overtimes from attendances that overlap with the leave to be miscalculated as if the leave was not validated. To rectify this issue, we recalculate the overtimes for the affected employees after every create/write/unlink of `resource.calendar.leaves`. opw-4844447
This update fixes an issue where the system incorrectly predicted taxes on imported invoices. Previously, it relied on customer history, even if the XML invoice only contained one tax rate. Now, the system accurately uses the tax information directly from the imported XML file, ensuring correct tax calculations.
Original PR description
Context: When importing an XML invoice or vendor bill, the tax prediction was based on the customer’s invoice history. Example: if the imported invoice contains an item found in the history with two taxes (6% and 21%), the prediction would return both taxes (6% and 21%), even though only one tax is present in the XML file. The actual tax data present in the imported XML was not taken into account. After this commit, the prediction is more rigorous and correctly relies on the tax information provided in the XML (restricted search domain) task-5503126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the ZATCA XML generation process would fail when an order had no payment due to full discounts. Now, the system correctly handles orders with zero payment, ensuring accurate ZATCA reporting. This prevents potential reporting errors and maintains data integrity.
Original PR description
Before this commit, when an order was fully discounted and therefore had no payment, the generation of the XML file for ZATCA would fail. opw-5928185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where `Image` and `Binary` objects were incorrectly linked. The fix ensures these object types maintain distinct type values, preventing potential data inconsistencies. This improves the stability and reliability of Odoo's image and binary management.
Original PR description
This fixes an oversight of 4840a6639deb171c28ae14b0269d420aa1503860 that `Image` and `Binary` objects have the same `self.type` value and thus an `Image` can relate to a `Binary`, after all. Forward-Port-Of: odoo/odoo#249260
This update ensures that Website Studio's translation terms are correctly applied only to views associated with the active website, resolving an issue where the default website's language was being used. This improves the accuracy and relevance of translations within the Studio interface, enhancing the user experience for website customization.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124
This update resolves an issue where Ecuadorian EDI reports generated duplicate headers, causing wasted space and inconsistent formatting. The fix ensures that only the required Ecuadorian header is displayed, aligning with legal requirements and improving report clarity. This change impacts reports for Ecuadorian companies.
Original PR description
**Steps to reproduce:** * Install the **l10n_ec_edi** module. * Use an **Ecuadorian company**. * Create and confirm a customer invoice, vendor bill, or delivery guide. * Print any Ecuadorian PDF…
**Steps to reproduce:** * Install the **l10n_ec_edi** module. * Use an **Ecuadorian company**. * Create and confirm a customer invoice, vendor bill, or delivery guide. * Print any Ecuadorian PDF report (invoice/credit note, purchase liquidation, withholding, or delivery guide). **Observed behavior:** * Generated PDFs display **two headers**: * The standard Odoo company header. * The legally required Ecuadorian EDI header. * This results in duplicated information and wasted space. **Cause:** * Ecuadorian report templates relied on `web.external_layout`, which automatically renders the Odoo company header. * A custom Ecuadorian header was added on top, instead of replacing the standard one. * Both headers were therefore rendered together. **Fix:** * Hide the standard Odoo header for **Ecuadorian companies** in `external_layout_standard`. * Use the Ecuadorian header as the document title for local EDI reports. **Before:** <img width="549" height="379" alt="image" src="https://github.com/user-attachments/assets/0352ddad-f4b5-4764-aed1-291f6f514f8d" /> **After:** <img width="606" height="516" alt="image" src="https://github.com/user-attachments/assets/2b491ffc-9430-4858-a25e-0423da59cfe5" /> opw-5414882