Thursday, January 8, 2026
5 changes · saas-18.4
Enhancements to existing features
This update adds crucial data attributes to tax calculations and NFS-e submissions when the Brazilian fiscal reform is active. Specifically, the system now includes 'name', 'businessName', 'federalTaxId', and 'type' fields, ensuring accurate tax reporting and compliance with new regulations. This change supports the ongoing requirements of the Brazilian tax system.
Original PR description
Purpose: Additional attributes are required to be sent in the rendered node for tax calculation and NFS-e submission when the fiscal reform is enabled. The additional required attributes are: - name - businessName - federalTaxId - type task-5450129 Forward-Port-Of: odoo/enterprise#103438
Resolved issues and error corrections
This update prevents the loss of delivery orders when label creation fails during integration with Starshipit. Previously, a failed label attempt would delete the order, now users can correct the data and retry validation without losing their existing order information. This enhances the reliability of the delivery process.
Original PR description
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the…
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order. ## Steps to reproduce: 1. Validate a delivery order integrated with Starshipit. 2. Trigger a label generation failure (e.g., bad address). 3. Observe that the created Starshipit order is deleted. ## Cause of the issue: The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order. ## Fix: Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual. ## Additional note: The _() wrapper in the error line was removed because the Starshipit service has no env or language context. Since translations cannot be resolved there, Odoo raised a warning. Removing _() avoids this warning and keeps the error clean. opw-5306979 Forward-Port-Of: odoo/enterprise#103354 Forward-Port-Of: odoo/enterprise#101174
This update corrects a previous approach to handling tax information for Brazilian service invoices related to the recent fiscal reform. Now, all required tax details specific to the reform must be consistently included in the XML reports, ensuring accurate compliance. This change improves the reliability of tax reporting for our Brazilian customers.
Original PR description
Before the fiscal reform, we deliberately avoid sending back informative taxes for service invoices because they may change depending on how and when the invoice is paid and they only need to appear on the XML optionally. New informative taxes specific to the fiscal reform are required to appear on the XML and therefore we must always send them. task-5450142
This update fixes a problem where invoice names weren't correctly linked to Avalara transactions. By reverting to a previous method of recreating transactions after posting, Odoo ensures that Avalara receives the necessary invoice information for accurate tracking. This improves the reliability of tax processing and cross-referencing.
Original PR description
In the external tax refactor [1] I wanted to use the commit endpoint to commit transactions in Avalara after posting. It works, but now transactions on Avalara's side are missing the Odoo invoice name references. It's still possible to cross-reference transactions using avatax_unique_code, but it's less convenient. The reason is that we create transactions for draft invoices. They don't have a name yet. Avalara doesn't have a way to update just the code so we revert back to the pre-refactor approach of recreating the entire transaction right after posting with `'commit': True`. `account_external_tax` calculates the taxes right before `_post()`, so we're reasonably sure they should remain the same. In master we can remove all the commit-specific methods and code. [1] https://github.com/odoo/enterprise/pull/82623 opw-5382268
This update fixes an issue where changes to rental order dates weren't automatically reflected in the transfer schedule. The fix mimics the rescheduling behavior of purchase orders, ensuring rental transfers are updated accurately when a rental order's dates are adjusted. This improves the reliability of rental order management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#102437 Forward-Port-Of: odoo/enterprise#101334