Tuesday, November 25, 2025
6 changes · saas-18.2
Enhancements to existing features
This update automatically notifies users when invoices are canceled due to DGI rejections, preventing unnoticed cancellations and ensuring timely corrections. It also allows users to easily update invoice statuses when DGI acceptance is received, resolving inconsistencies and improving data accuracy.
Original PR description
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify…
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify relevant users when an electronic invoice (CFE) is rejected by the DGI and, as a result, canceled in the system. The goal is to ensure that there is always someone responsible who is informed to correct and resend the receipt. - Added logs in the terminal to make the debug easier in case we want to identify rejected invoices. **Particular case of an invoice that had been rejected by DGI but the user somehow fixes it and then DGI accepts it:** - Added logic to verify both DGI state and Invoice state and adjust it accordingly when updating invoice DGI status. - Make 'Update DGI status' button always visible to be able to adjust invoices states. **== Context of the Problem ==** Previously, when Odoo detected that a CFE had been rejected by the DGI, the system proceeded to cancel the invoice automatically. However, this process was carried out silently, without generating any notification. This could mean that if no user or salesperson was actively monitoring the status of the receipts, the cancellation would go unnoticed, resulting in invoices that were never corrected or reissued. For the case of a previously rejected and then accepted invoice, we always thought that 'Rejected' state in DGI was a definite state and could not suffer any change. But recently it has been a case that this state changed, creating inconsistencies in Odoo invoices states as they appear as cancelled. With these changes, the user can adjust the invoices state by clicking 'Update DGI status' button. **== Automatic Notification Logic ==** With the new functionality, every time an invoice is automatically canceled due to a DGI rejection, the system posts a message in the document chatter to report the situation. The logic for determining who is notified is as follows: _Scenario 1: Invoice with Internal Followers_ - If the canceled invoice has at least one internal follower (an Odoo user), the system will perform the following actions: - It will post a message in the invoice chatter. - It will tag (@) all internal followers to notify them directly. _Scenario 2: Invoice without Internal Followers_ - If the invoice does not have any internal followers, the system will search for a more general but relevant audience to ensure that the notification is addressed: - It will post a message in the invoice chat. - It will tag (@) all users who belong to the “Accounting Manager” permission group (technical name: group_account_manager). Task ODOO: #[1362](https://latam-localizations.odoo.com/web?debug=1#id=1362&cids=1&menu_id=88&action=131&active_id=16&model=project.task&view_type=form) Task ADHOC: #[54799](https://www.adhoc.inc/odoo//project.task/54799) Forward-Port-Of: odoo/enterprise#94502
Resolved issues and error corrections
This update resolves an error that occurred when the system automatically cleaned up data related to withhold payments. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update automatically registers products with eTIMS before invoice submission, ensuring accurate data transmission. It also fixes the display of product information, now showing eTIMS-specific fields. Crucially, it corrects a multi-company issue where product registration was using the wrong company's eTIMS system.
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
This update resolves an issue where CFE PDFs weren't being generated correctly for Uruguayan invoices. The fix ensures that the PDF from Uruway is properly linked to the invoice data, allowing users to access and download the required documents. This improves the accuracy of invoice processing for our Uruguayan clients.
Original PR description
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the…
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the Settings change 'UCFE Web Services' to 'Testing' and input credentials - Create a new invoice, confirm and send, click 'Generate CFE' - The CFE status is accepted but the PDF from Uruware is not on the record ### Cause: This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set. In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same. Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)). ### Solution: We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`. opw-5272776 Forward-Port-Of: odoo/enterprise#100128
This update resolves an issue where creating annotations in Arabic language reports would cause errors due to incorrect date formatting. The fix ensures dates are formatted correctly for PostgreSQL, preventing the application from crashing and allowing users to accurately add annotations to their financial reports. This improves the reliability of the reporting system for all users, regardless of their language settings.
Original PR description
Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656 Forward-Port-Of: odoo/enterprise#99493
This update fixes an issue where time logs were incorrectly assigned to the current user instead of the assigned employee when marking work orders as complete. This ensures accurate tracking of labor hours and eliminates user confusion regarding who is working on each order. The fix improves data integrity and reporting accuracy.
Original PR description
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the…
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the current user’s employee instead of the assigned one. This behavior caused confusion for the user as the wrong person was shown as working on the order. ## **Steps to Reproduce:** - Create an MO with work orders and confirm it. - Assign another employee to a work order. - Mark the work order as done with the current user from the work order line. - Open the workorder and notice that the time log is created for the current user’s employee. ## **Cause of the Issue:** The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790), where the logic for assigning the main employee was overridden, ignoring the case of an already assigned employee. ## **With This Commit:** The time log is now created for the assigned employee, This resolves the confusion by ensuring the right person is tracked on the work order. TaskID: 4983514