Thursday, June 25, 2026
9 changes · 18.0
Enhancements to existing features
The option to send a PDP response is no longer shown as a large button on the invoice/bill screen. It is now available in the settings menu, since canceling and reposting a document already triggers the same result and the interface is less cluttered.
Original PR description
No real need to show a big button for sending a response in PDP as cancelling and posting an invoice/bill would do the same, so we move it to the cog wheel menu task-6274220
Resolved issues and error corrections
This update corrects a test case that used an invalid Belgian VAT number, which started failing after a stricter validation update in a supporting library. The test still checks for a VAT mismatch, but now uses a valid VAT number so it remains reliable across environments.
Original PR description
This commit fixes a Belgian VAT validation check in `test_import_partner_retrieval_bank_account_number` as the provided vat number isn't a valid one. It keeps the spirit of the test by still having vat number mismatch, but with a valid value. The python-stdnum library used for this validation added a stricter check since version 2.2, which is used in Ubuntu Resolute 26.04. References: - https://github.com/arthurdejong/python-stdnum/commit/7ca9b6ce7b1f2b4d1bf164c2af83a8a77bc919d2 runbot-939796
This update resolves an issue where importing UBL files containing invoice lines with zero quantity and amount would cause a division-by-zero error, leading to import failures. The fix ensures the system handles these zero-value lines correctly, improving the reliability of UBL import processes.
Original PR description
**PROBLEM** When importing a ubl with a line with an invoiced qty of 0 and an amount of 0, there is division by zero. **STEP TO REPRODUCE** 1. upload a ubl file with an empty line as a vendor bill (there is one in the bugfix ticket). 2. notice the import fails because of a division by zero. The division by zero was introduced by https://github.com/odoo/odoo/pull/265261 opw-6260558
This update corrects a test failure within the French invoicing module (l10n_fr_pdp) that occurred when only the basic Invoicing module was installed. The fix adds the necessary 'in_payment' state, which was present in the full 'enterprise' version of the Accounting module. This ensures the test suite runs correctly and avoids potential disruptions.
Original PR description
The `in_payment` state does not exist in community with only the Invoicing module installed. It is added in `enterprise` in the Accounting module. runbot.build.error-939451
This update corrects a previous issue where the GT Document Type field was incorrectly required when creating vendor bills for vendors outside of Guatemala. The change ensures the field is only mandatory for Guatemalan vendors, streamlining the billing process and improving usability for international transactions. This resolves a user experience problem.
Original PR description
Currently, the GT Document Type field is required when creating vendor bills for non-Guatemalan vendors. **Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a GT Company. -…
Currently, the GT Document Type field is required when creating vendor bills for non-Guatemalan vendors. **Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a GT Company. - Create a new vendor bill for a vendor whose country is not Guatemala. **Observation:** The `GT Document Type` field is required even though the selected vendor is not based in Guatemala. **Root Cause:** At [1], `_compute_l10n_gt_edi_available_doc_types` only checks the company country and ignores the vendor's country, causing GT available document types to be computed for foreign vendors as well. As a result, `l10n_gt_edi_available_doc_types` is populated and the view at [2] incorrectly makes `l10n_gt_edi_doc_type` required. **Fix:** This commit ensures the GT Document Type field is only required for Guatemalan vendors. [1]: https://github.com/odoo/enterprise/blob/7a80db5b5550bf75e4ce5337e869c42386c8a71c/l10n_gt_edi/models/account_move.py#L144-L171 [2]: https://github.com/odoo/enterprise/blob/7a80db5b5550bf75e4ce5337e869c42386c8a71c/l10n_gt_edi/views/account_move_views.xml#L27 opw-6315872
This update resolves an issue where the system incorrectly imported invoice quantities from UBL files. Specifically, it ensures that the 'invoiced_quantity' and 'base_quantity' values in imported invoices accurately reflect the quantities specified in the original UBL document. This prevents discrepancies in order data.
Original PR description
…ase_quantity equal to zero **STEP TO REPRODUCE** 1. Import the 2fact ubl from the bugfix ticket. 2. Notice some line are imported with quantity = 1, but the quantity invoiced in the ubl is 0. opw-6260558
This update fixes a crash that occurred when Odoo's subscription module was run outside of its normal web environment (like in tests or cron jobs). The fix ensures the system correctly handles situations where an active HTTP request isn't present, preventing a runtime error.
Original PR description
When executing code outside of a web thread (such as in unit tests, cron jobs, or CLI commands), an actual HTTP request does not exist, leaving the global `request` proxy unbound. In these scenarios, the unbound proxy evaluates to False. Because of Python's `and` evaluation, the expression `request and request.params...` returned the unbound proxy itself instead of None. This caused a RuntimeError later when the proxy was compared to other values. We now explicitly check `request.env` to verify an active request exists, properly falling back to None when there is no HTTP context. runbot-938513
This update ensures that custom reports attached to invoices display their intended names in email attachments, rather than a default CFDI-based filename. The fix addresses an issue where localization overrides were preventing the correct report name from being used, leading to duplicate attachments. This improves the clarity and usability of invoice attachments.
Original PR description
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard…
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard **Invoice PDF** report. * Open the duplicated report and make any modification to it. * Enable **Developer Mode**. * Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**. * Go to **Settings → Technical → Email → Templates** and create a new invoice email template. * Add the custom report to the template's **Dynamic Reports**. * Create and confirm an invoice for a **Mexican company**. * Click **Send** and select the newly created email template. Observed behavior: * The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment. Cause: * `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`. However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated. Fix: * Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain. * Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call. This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic. opw-6228268
This update ensures that partner bank accounts are usable within all child companies, even if the partner is associated with a parent company. Previously, this restriction limited functionality. This change improves efficiency and simplifies processes for users managing multiple company branches.
Original PR description
Even when a partner has the 'company_id' filled with the parent company, his bank account should be usable in the child companies. This was done in odoo/odoo#262173 from 19.2 but we need to backport it in stable task-6309694 Forward-Port-Of: odoo/odoo#271470