Daily updates from Odoo
Monday, June 8, 2026
13 changes · 17.0
Resolved issues and error corrections
This update fixes a bug where untaxed invoice lines were incorrectly inheriting the Datev code from the previous line. The fix ensures that untaxed lines now properly have an empty Datev code, resolving a discrepancy in the Datev export file. This ensures accurate reporting for German tax compliance.
Original PR description
**PROBLEM** Untaxed move lines would take the datev code of the previous line instead of having no datev code like they should. **STEP TO REPRODUCE** 1. On a german company, create an invoice with a line with tax 19% I, and a line that is untaxed (with a non-null price). 2. On the general ledger, generate the datev zip. 3. Unzip, and open the account entries csv, and notice the 2nd line of the invoice as the datev code set to something instead of it being empty (column BU-Schlüssel). opw-6141003
This update resolves a test failure caused by incorrectly passing raw PDF data as base64 encoded information. The fix ensures that the correct base64 format is used, preventing errors during testing. This improves the reliability of the payroll accounting tests.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173
This update resolves an issue where users without write access to invoice sequences would receive an error when generating global invoices in the Point of Sale (PoS) module. The fix ensures that invoices can be generated correctly, even if the user doesn't have direct write permissions to the underlying sequence, improving the user experience for Mexican CFDI invoicing.
Original PR description
When generating a global invoice, if the user has no write access to the sequence, an access error is triggered even though he can generate the invoice correctly. Steps to reproduce: ------------------- * Create some order in the PoS * Try to generate the global invoice with Marc Demo > Observation: You get an access error. * Create an invoice with CFDI to public checked * Add any product and validate the invoice * Try to generate the global invoice with Marc Demo > Observation: You get an access error. opw-6041291
This update addresses a warning related to how Odoo uses the PyPDF library to merge pages in PDF documents. The change ensures stability and prevents potential errors by adjusting the order of operations when modifying PDF pages, improving the reliability of PDF generation.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669
This update fixes an issue where users without HR access rights on the timesheet grid view were seeing a placeholder image instead of their avatar. The fix ensures that all users can see their avatar in the timesheet grid, improving the user experience and visual consistency.
Original PR description
Steps to reproduce: ------------------- - Install the hr_timesheet module - Create a user without HR access rights - Create a timesheet - Log in with the above user - Open the kanban view Issue: ------- Instead of showing the employee's avatar, a placeholder image is displayed. Reason: ---------- The user does not have access to the hr.employee model. Fix: ----- In this commit, if the user does not have access to hr.employee,we fetch the image from the hr.employee.public model. task: 4461272
This update fixes a bug that occurred when adding recurring products to confirmed sales orders without a linked subscription plan. The fix prevents a traceback error by validating the subscription plan before generating recurring tasks, improving the user experience and preventing data inconsistencies.
Original PR description
Steps to reproduce: - Go to Sales → Products. - Create a Service product and enable the Recurring option. - Open an already confirmed Sales Order that does not contain any recurring products. - Add the newly created recurring product to the confirmed order. - Click Save. - Observe that a traceback occurs. Cause: - When adding a recurring product without a subscription plan to a confirmed Sale Order, _timesheet_create_task() attempts to compute a start date using order.next_invoice_date, which is not set. - This leads to a TypeError when `order.next_invoice_date` receives `False`. Solution: - Add a validation to prevent adding recurring products without a subscription plan and raise a proper `UserError` instead of allowing the code to reach task generation logic. task-5932700
This update resolves an issue where international UPS shipments were failing due to incorrect commercial invoice addresses. The fix now uses the delivery address for the invoice, but a fallback mechanism is in place to handle country mismatches, along with a user warning to ensure accuracy. This ensures compliant UPS shipments and avoids delivery delays.
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
This update removes a specific message from invoices when they aren't sent via PEPPOL, which was inappropriate for Business-to-Consumer (B2C) customers. By removing this footer for invoices with empty or '/' VAT numbers, we ensure a cleaner and more professional experience for our B2C clients.
Original PR description
Currently, if the invoice was not sent through PEPPOL, it is indicated in the mail footer. However, this message is not appropriate for B2C customers. To avoid this, we remove this footer for customers with empty or '/' VAT (B2C). task-6167439
This update simplifies invoice sending by no longer automatically selecting the 'By Peppol' method for customers in Greece, Italy, Poland, Puerto Rico, and Romania. Previously, this setting was incorrectly applied to these countries, causing unnecessary complexity for users. Now, the 'By Peppol' method will only be used for customers in designated default countries.
Original PR description
Current behavior before PR: - If the customer has a valid Peppol endpoint, the 'By Peppol' invoice sending method is selected by default. - For countries like 'GR,' 'IT,' 'PL,' 'PO,' and 'RO,' peppol is not mandatory or not used for sending invoice. It brings noise and it bothers the users. Desired behavior after PR is merged: - The 'By Peppol' invoice sending method is set to true by default only for customers from PEPPOL_DEFAULT_COUNTRIES. Changes Implemented: - Moved the countries 'GR', 'IT, 'PL', 'PO', and 'RO' from PEPPOL_DEFAULT_COUNTRIES to PEPPOL_LIST. - Added condition to set 'By Peppol' invoice sending method to true when customer is from PEPPOL_DEFAULT_COUNTRIES. task-6072935
This update fixes a warning related to how Odoo generates PDFs using the PyPDF library. The change ensures the PDF generation process is compatible with newer versions of PyPDF, preventing potential errors and maintaining stable PDF output. This improves the reliability of our PDF reports.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669
This update fixes a bug that caused duplicate vendor bills to be created when importing XML bills with identical filenames. The issue stemmed from incorrect attachment linking during the initial document creation process. This ensures accurate bill generation and avoids redundant records.
Original PR description
Fixup of https://github.com/odoo-dev/odoo/commit/3fc85b6ed7936956abbaf8e8364bb2b288cbe289 Issue 1 - Import XML bill into documents app - Create vendor bill from the document Issue: Only the main attachment would be found in the created bill opw-6267888 Issue 2 - From the accounting app import XML bill containing two identically named documents Issue: Two bills were created opw-6231265
This update fixes an issue where users without HR access rights were seeing a placeholder image instead of their avatar in the timesheet kanban view. The fix ensures all users can see their avatar, improving the user experience and visual consistency within the HR timesheet module.
Original PR description
Steps to reproduce: ------ - Install the hr_timesheet module - Create a user without HR access rights - Create a timesheet - Log in with the above user - Open the kanban view Issue: ------- Instead of showing the employee's avatar, a placeholder image is displayed. Reason: --- The user does not have access to the hr.employee model. Fix: -------- In this commit, if the user does not have access to hr.employee, we fetch the image from the hr.employee.public model. task: 4461272
This update resolves an issue preventing users from sending Peppol invoices in demo mode. The change allows the system to assume any document type is acceptable during demo, bypassing the usual partner acceptance checks. This ensures seamless testing and demonstration of the Peppol integration.
Original PR description
1. Activate Peppol Demo; 2. Enable "Self-Billing" on the purchase journal; 3. Create a bill and send it via Peppol; 4. Error message: "The partner has indicated it does not accept this document type, so you cannot send this invoice via Peppol". In _peppol_lookup_participant we always return None if we are in demo mode. For the _can_receive_self_billing, we will assume that in demo mode, the partner can accept any document type. opw-6250067 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