Friday, December 12, 2025
10 changes · 19.0
Enhancements to existing features
This update ensures Odoo correctly handles negative invoice lines in Mexico's CFDI e-invoicing format. Previously, the system struggled when negative line amounts exceeded the total of multiple positive lines. This change improves compliance with Mexican regulations and prevents potential invoicing errors.
Original PR description
In mexico, you cannot send any negative lines in the CFDI (Mexican e-invoicing). The negative lines are distributed accross the positive ones in _dispatch_global_discount_lines. This test ensures the negative line is well distributed when its amount is higher than the sum of multiple positive lines. Forward-Port-Of: odoo/enterprise#101888
This update enhances the clarity of financial reports, particularly the Trial Balance and General Ledger, by displaying unaffected earnings as separate lines for each company. It also addresses several localization issues and introduces a warning for unallocated earnings when generating reports like SAF-T. This ensures more accurate and understandable financial data.
Original PR description
This commit changes the way the Unaffected Earnings are displayed in the Trial Balance. Instead of allocating unaffected earnings to the equity_unaffected account when the report is rendered, we now showcase the earnings to an additional line per company, with no relation to an account. In this commit, we also add the account type 'expenses_other' which was missing from the line 'Less Other Expenses' in the Generic P&L. Task [link](https://www.odoo.com/odoo/project.task/5153168) task-5153168
Resolved issues and error corrections
This update restores the missing email templates required for sending invoices and credit notes in compliance with DIAN regulations within the l10n_co_dian module. The previous removal of these templates was corrected, ensuring proper functionality for Colombian businesses using Odoo Enterprise. This fix addresses a critical requirement for accurate tax reporting.
Original PR description
**Steps to reproduce:** - Create a database with l10n_co module - "Invoice (DIAN): Sending" and "Credit Note (DIAN): Sending" are missing in the available templates **Issue:** Xml line which added "l10n_co_dian.email_template_edi_invoice" and "l10n_co_dian.email_template_edi_credit_note" templates was removed in https://github.com/odoo/enterprise/commit/7add9dbface8e67dd25b05653d514d5f8c2cfa38 **Fix:** Re-add the `<function>` to `_create_dian_mail_templates` in the `.xml`. opw-5385848
This update addresses a performance issue in the sign module related to corrupted PDF files. By updating the PDF.js library, Odoo now avoids an infinite loop and potential traceback errors when handling problematic uploads, ensuring smoother document processing. This improves the reliability of the sign workflow.
Original PR description
Modification of module to align it with the newer version This commit updates the PDF.js library to patch the issue related to: mozilla/pdf.js#18878 In Odoo this issue raises a performance issue that makes a infinite loop when you upload a corrupted file and Odoo tries to upload a traceback. OPW-5214755 Forward-Port-Of: odoo/enterprise#101551 Forward-Port-Of: odoo/enterprise#99912
This update fixes a bug where vendor bills incorrectly used the company's bank account instead of the vendor's. Previously, selecting a payment method automatically populated the partner_bank_id field with the company's account. This change ensures the partner_bank_id always reflects the vendor's bank account, improving accuracy in billing records. This resolves bug #239249.
Original PR description
Description of the issue/feature this PR addresses: fixes bug #239249 See the bug report for full details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately reflects the foreign currency rates set on invoices, ensuring accurate reporting for German clients. This improves the reliability of financial data exports.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816
This update resolves an issue where attachment files for returns weren't being generated correctly, and ensures consistent behavior when resetting return reports. The fix standardizes how attachments are created and resets, leading to more reliable reporting and data management.
Original PR description
[FIX] account_reports: returns: fix generations of files as attachments _generate_submission_attachments does not exist anymore ; it's been renamed to _generate_locking_attachments. Because of that,…
[FIX] account_reports: returns: fix generations of files as attachments _generate_submission_attachments does not exist anymore ; it's been renamed to _generate_locking_attachments. Because of that, some intended overrides were not executed properly, and several XML/CSV export files were not generated and added as attachments to the return. Moreover, the functions generating export files used to be called by account.report's export_file function (from a button defined in options['buttons']). export_file always forced the 'export_mode' key into the options it passed tp those file generators; we reintroduce this behavior for consistency, to avoid messy situations due to forward-port or functions being converted from the former paradigm to the new one. Note, however, it's always better to fully regenerate the options from such a generator. ================================================================================= [FIX] account_reports: returns: homogenize the reset behavior Before this fix, resetting a tax report deleted all the attachments of the return, while resetting for example the Partner VAT Listing (in Belgium), left them untouched. We now introduce a common helper for all reset functions, defining the behaviors they should share.
This update ensures that the status of Brazilian e-invoices is accurately reflected as 'Cancelled' after a cancellation request is processed. Previously, the status field was left blank, causing confusion. The fix correctly updates the status within the EDI system, aligning with the expected e-invoice cancellation process.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_br_edi** modules. * Create and post a Brazilian customer invoice using an **Avatax fiscal position** * [Guide to setup EDI for…
**Steps to reproduce:** * Install the **Accounting** and **l10n_br_edi** modules. * Create and post a Brazilian customer invoice using an **Avatax fiscal position** * [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0) * Confirm the invoice and **send it to e-invoice (Brazil)**. * Confirm the **Brazil E-Invoice Status** shows **'Accepted'**. * Click **Request Cancellation**, enter a cancellation reason, and submit the request. **Observed behavior:** * The invoice moves to **Cancelled** state. * The cancellation XML is generated and attached in the chatter. * SEFAZ returns a successful cancellation response. * However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**. **Cause:** * In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`. * `button_cancel()` internally triggers `button_draft()` for posted invoices. * The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`. * This clears the status that was just set, leaving the field blank. **Fix:** * move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method. opw-5378542 Forward-Port-Of: odoo/enterprise#101438
This update resolves a bug that prevented refunds from being processed correctly for orders created with 'Consumidor Final Anónimo' customers in the Point of Sale system. The fix ensures proper error dialog display and prevents crashes, improving the refund process for this customer segment.
Original PR description
We had a bug when attempting to refund orders that were created with the "Consumidor Final Anónimo" customer. The refund validation would crash with a TypeError instead of showing the proper error…
We had a bug when attempting to refund orders that were created with the "Consumidor Final Anónimo" customer. The refund validation would crash with a TypeError instead of showing the proper error message. Steps to reproduce: ------------------- In POS with l10n_cl_edi module activated: * Create a new order with "Consumidor Final Anónimo" as customer * Add products and pay the order * Validate the order * Attempt to refund this order > Observation: The refund validation would crash with: TypeError: Cannot read properties of undefined (reading 'add') at OrderPaymentValidation.isOrderValid Why the fix: ------------ The code was trying to access `this.dialog` which is undefined in the OrderPaymentValidation class context. The dialog service should be accessed via `this.pos.dialog`, which is the correct pattern used throughout the base OrderPaymentValidation class. This fix ensures the error dialog is properly displayed when attempting to refund orders for the anonymous final consumer, instead of crashing with a TypeError.
This update ensures that the visitor's country is always displayed on the live chat information panel for all users with access to the conversation, not just the initial agent. This provides a more complete view of the conversation context, improving communication and support efficiency.
Original PR description
Before this PR, the visitor country flag was only shown to the agent who was first assigned to the conversation. In practice, country should always be displayed on the info panel. Users that have the rights to see the conversation should have every information available as well. 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