Friday, February 27, 2026
10 changes · saas-18.4
Resolved issues and error corrections
This update fixes the XML templates used for Dutch SBR and ICP reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch clients, complying with local tax regulations and improving data consistency.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed in section 10. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108575 Forward-Port-Of: odoo/enterprise#107949
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The fix clears the employee's work_email field during the contract signing process, ensuring it reflects the intended work email. This prevents data inconsistencies and improves the accuracy of employee records.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108769 Forward-Port-Of: odoo/enterprise#106974
This update fixes an issue where the correct currency wasn't being applied when transferring CODA payments to multiple journals with the same IBAN but different currencies. The change ensures payments are routed to the correct journal based on its currency, improving financial accuracy and reducing the risk of errors.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108677
This update resolves a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This improves the stability and accuracy of the document processing features.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update makes the Gantt chart's date selection more immediate, providing a smoother user experience. Previously, date changes required clicking 'Apply' to update the display. Now, selections update instantly, improving efficiency and reducing delays when adjusting the chart's timeframe.
Original PR description
- Previously, the Gantt scale selector only updated the displayed date range after the "Apply" button was clicked. This was because the template was bound to the component props rather than the local state. - This commit binds the date picker display to the local pickerValues state. Now, when a user selects a date in the picker, the UI updates immediately, while the actual data fetch remains deferred until "Apply" is clicked. Task: 5932671 Forward-Port-Of: odoo/enterprise#107380
This update fixes a potential issue with after departure payments to work. Now, if a previous payslip isn't selected, the system displays a clear error message to the user instead of a technical traceback. This ensures smoother and more accurate processing of these payments.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107386
This update fixes an issue where manually invoicing subscription upsells didn't correctly update their invoice status. The fix ensures that upsells are marked as 'Fully Invoiced' after invoicing, resolving a discrepancy in the system's tracking of payment status. This improves the accuracy of subscription billing reports.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#108614
Forward-Port-Of: odoo/enterprise#107967This update resolves a technical problem where keydown events were incorrectly targeting the wrong element in the Hoot component. This fix ensures that Hoot functions reliably, improving the user experience. The change was made to stabilize the application and prevent unexpected behavior.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#108835 Forward-Port-Of: odoo/enterprise#107286
This update resolves an issue where Avatax taxes weren't correctly calculated during Stripe Express Checkout, leading to inaccurate order totals. The fix ensures that Avatax is now accurately applied when using Google Pay, aligning payment amounts with the final sales price including taxes. This improves payment accuracy and customer satisfaction.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#108957
Forward-Port-Of: odoo/enterprise#101579