Thursday, November 27, 2025
6 changes · saas-18.3
Enhancements to existing features
This update automatically notifies users when invoices are canceled due to DGI rejections, ensuring someone is responsible for correcting and resending receipts. It also addresses a previous inconsistency where rejected invoices could unexpectedly change state, now allowing users to manually update the DGI status via a new button.
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#98210 Forward-Port-Of: odoo/enterprise#94502
This update simplifies UBL invoice generation by automatically using the latest helpers for BIS3 and related formats. Previously, these helpers were only used for BIS3, but now they're enabled by default, ensuring consistent and reliable UBL invoice creation across various accounting systems. This change improves data accuracy and streamlines the process for generating UBL invoices.
Original PR description
Since commit 52e984037 we have enabled the new helpers by default for generating BIS3 UBLs. But we didn't enable them in the UBL formats that depend on BIS3 (NLCIUS, XRechnung, Chorus Pro etc). That was to first fix any issues in BIS3 in case the new helpers had broken something. Since the new helpers seem to be working fine for BIS3, we are now making them the default for all the formats that depend on BIS3 as well. We also add comments in the old helper methods to indicate that they are no longer used by default for BIS3 and its extensions. task-none Forward-Port-Of: odoo/odoo#237198 Forward-Port-Of: odoo/odoo#229231
Resolved issues and error corrections
This update fixes an issue where signature fields added to views within Odoo's Studio were not correctly configured. The signature widget was missing from the available options. Now, signature fields added to views will correctly display the signature widget, ensuring accurate field configuration and functionality.
Original PR description
Before this commit: ------------------- When a user added an existing signature field to a view, Studio automatically assigned the default binary widget. The expected signature widget did not appear…
Before this commit: ------------------- When a user added an existing signature field to a view, Studio automatically assigned the default binary widget. The expected signature widget did not appear in the widget selection list. As a result, users could not configure the field as a signature input. <img width="1920" height="938" alt="image" src="https://github.com/user-attachments/assets/35893235-2541-4bd5-a7a5-4feab562acb2" /> Cause: ----- Studio builds the dropdown of available widgets by computing a [widgetKey](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/utils.js#L132) based on the field type. Because the signature widget did not declare binary as a supported field type, it was always filtered out for fields of type binary. Thus Studio treated the field like any normal binary field and excluded the signature option. After this commit: ------------------ The signature widget is correctly exposed as a supported widget for fields of type binary. When adding an existing signature field to the view (with developer mode enabled), Studio now shows signature in the widget list. <img width="1917" height="934" alt="image" src="https://github.com/user-attachments/assets/079e0a17-ff5a-4dc6-a12d-e02b9cad013e" /> Why this fix is needed: ---------------------- Signature fields are stored as binary, but they require the dedicated signature widget to render correctly. By marking binary as a supported field type for the signature widget, Studio can properly detect and offer the widget during field configuration. Given that this widget is very domain-specific and not intended for general binary fields, it was not added to [web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js) though this may be reconsidered after this fix the option is accessible only when the debugger mode is on, if want to show this widget to all the binary type fields even when the debugger mode is off the we'll have to add it to this file. OPW : 5260188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237287
This update resolves an issue where invoices weren't being created for alternative sale orders generated from upsells. The fix ensures the correct invoice date is calculated by copying the previous upsell order's invoice date, now allowing invoices to be created successfully after confirming the alternative order.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99831 Forward-Port-Of: odoo/enterprise#98983
This update fixes an issue where documents and moves were incorrectly linked across companies in a multi-company setup. By adding the company ID during attachment creation and searches, the system now accurately assigns documents to the correct company, preventing errors and ensuring data integrity. This improves the reliability of financial reporting and move management.
Original PR description
Behavior before: In a multi-company setup, fetching documents could include records from different companies based on VAT numbers. When creating attachments or searching for existing moves, the company ID was not properly considered, leading to incorrect company assignments and failed move creation. Behavior after: Documents and moves are now created and searched within the correct company context by explicitly including the company ID. Root Cause: The company ID was missing in both the attachment creation and the domain used to search for existing moves, causing cross-company mismatches. opw-4929985 Forward-Port-Of: odoo/enterprise#99192
This update fixes a delay in receiving payment notifications for online PoS transactions. Previously, if a customer closed the payment page before confirmation, the PoS would wait up to 10 minutes. The fix triggers a process to ensure immediate notification, improving the order processing flow and preventing delays.
Original PR description
When paying online with the PoS if for some reason the client closes the web page before receiving the payment confirmation, the PoS would not be notified that the payment was successful. Steps to…
When paying online with the PoS if for some reason the client closes the web page before receiving the payment confirmation, the PoS would not be notified that the payment was successful. Steps to reproduce: ------------------- * Setup any online payment method in the PoS. * Open the PoS and create an order. * Proceed to payment and choose the online payment method. * Scan the QR code and close the page before receiving the payment confirmation. > Observation: The PoS will need to wait atleast 10 minutes to receive the payment notification. Why the fix: ------------ When using the online payment method, the user that scans the QR code will open a web page to complete the payment. This webpage is also responsible to poll the status of the payment. When polling the status of the payment, if the payment is successful, the server will send a notification to the PoS to update the order status. If the user closes the web page before the payment is confirmed, the PoS will not receive the notification. We will need to wait for the payment transaction `_cron_post_process` to be executed, which happens every 10 minutes. So the solution is to trigger the cron when the payment is set as done to ensure that the PoS receives the payment notification as soon as possible. opw-4925349