Daily updates from Odoo
Tuesday, February 3, 2026
12 changes · saas-18.2
Resolved issues and error corrections
This update resolves a test failure within the Web Studio module's export functionality. The change prevents unintended modifications to a key configuration setting, ensuring test stability and preventing disruptions during the full enterprise test run. This improves the reliability of our core export processes.
Original PR description
Updating the fieldsets of `DEFAULT_FIELDS_TO_EXECUTE` in place changes the behaviour of `test_23_export_hardcoded_models_and_fields` if that test runs after `_compute_excluded_fields` has been executed for one reason or an other, which apparently does not occur during post_install but *does* occur during at_install, and so fails in the "full" enterprise test running everything in a single job. https://runbot.odoo.com/odoo/error/238451 https://runbot.odoo.com/odoo/error/238449 https://runbot.odoo.com/odoo/error/238497
This update resolves an issue where the FAIA report incorrectly classified partners as suppliers instead of customers, particularly when credit notes were involved. The change allows a partner to be both a customer and supplier, ensuring accurate reporting of balances and improving the reliability of the SAFT report.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#105405 Forward-Port-Of: odoo/enterprise#100749
This update fixes an issue where outdated account synchronization links could cause problems, preventing new connections. By ensuring only clean, uninitialized links are reused, the system is now more reliable and stable for account synchronization.
Original PR description
Prevent reusing stale account.online.link records that have a provider_type set, which can leave an unusable row and block new connections. By adjusting the search domain in action_new_synchronization, we only reuse clean, uninitialized links. opw-5868438 opw-5867799 Forward-Port-Of: odoo/enterprise#105187
A recent error message appearing during payment processing for Avatax-enabled Point of Sale (POS) orders has been resolved. This was caused by an outdated method that no longer existed. The fix removes this unused method, ensuring smooth and reliable payment processing for Avatax users.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - open pos and settle a order - notice a error message on payment page Cause: - error is due to usage of `replaceDataByKey` which is removed in [1] [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Fix: - we removed the method as now we do not rely on it. opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#102101
This update fixes a bug that occurred when users copied and then undid copying planning slots. The issue arose because the system incorrectly reported a record as missing after a deletion. The fix ensures the system verifies record existence before attempting to delete, preventing the error and improving stability.
Original PR description
### Steps to reproduce: - Install Planning - Navigate to the gantt view for planning slots - Copy previous week's slots - Delete one of the newly copied records - Undo the copying action - Notice an Error is raised that a record doesn't exist ### Cause: When undoing the copy process we unlink all the newly created records but if the user has already deleted one of them it will trigger an error that this record doesn't exist and it has already been deleted ### Fix: We check the existence of the records before deleting them. opw-5490327 Forward-Port-Of: odoo/enterprise#105530
This update resolves an issue where subscriptions with zero-quantity lines resulted in invoices being incorrectly set to the subscription's start date. The fix ensures that invoice dates are accurately calculated, even when subscriptions include both positive and negative quantities, preventing delayed invoicing.
Original PR description
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install…
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install 'sale_subscription' - Create a new Subscription with two lines and a tart data several months in the past - One with a quantity of 1 and a higher price - The other with a quantity of -1 - It can be the same service product with invoicing based on ordered quantity - Confirm the Subscription - Click "Create Invoice" and confirm the invoice - Back to the Subscription, the next invoice date was not updated. ### Cause: In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131 So the method will return not return the date in `invoice_dates`. Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67 ### Solution: The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds. To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund. opw-5360930 Forward-Port-Of: odoo/enterprise#103705
This update fixes an issue where the 'Next Booking Start' field for rooms was incorrectly empty when bookings existed. The change removes a filter that excluded occupied rooms from availability calculations, ensuring the field accurately reflects upcoming booking times. This improves the user experience when viewing room availability.
Original PR description
Steps to reproduce:
1. Install `room`
2. Create a room.
3. Create a booking for the current time (so the room becomes occupied).
4. Create another booking for tomorrow.
5. Open the list view of rooms.
Current Behavior:
- The `Next Booking Start` field is empty for the created room, despite Having future bookings.
Cause:
- The method `_compute_next_booking_start` filters the rooms using `self.filtered('is_available')`. Since the room is currently occupied (due to the active booking), the room is excluded from the query entirely.
Solution:
- Remove the `is_available` filter from the search domain. The next booking start time is now calculated for all rooms, regardless of whether they are currently available or occupied.
opw-5360101
Forward-Port-Of: odoo/enterprise#102129This update resolves rounding errors that were causing invoices to be rejected by the Mexican Electronic Domicile Identification (EDI) system. The fix involves changes to how discounts, taxes, and line items are calculated, particularly for combined invoices, ensuring accurate EDI compliance. Multiple related fixes were backported from version 18.3.
Original PR description
l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended **STEP TO REPRODUCE** 1. Create a invoice with: - product price = 72.89 - discount = 10% - tax = 16% 2. Duplicate the invoice until…
l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended
**STEP TO REPRODUCE**
1. Create a invoice with:
- product price = 72.89
- discount = 10%
- tax = 16%
2. Duplicate the invoice until you have 5 of them.
3. Create a global invoice with the 5 invoices, and send it.
4. The invoice will be refused by the EDI due to rounding issue.
This PR is a backport of multiples fixes done in 18.3 in which all rounding errors are fixed.
Each of them iterate upon the previous one, so they are all needed. The most important changes in thoses fixes are:
- for global invoices, deduce the discount on the base line instead of creating a 'descuento' (to avoid any problem with rounding when combining multiples invoices).
- changes in how the negative lines are dispatched.
- using raw values for 'conceptos' and 'impuestos' (5 digit precision) and changing how we compute things to solve rounding issue.
Tests files are modified accordingly, you can launch the tests with the external flag (need to be set in tests/common.py).
Backported PR (non-exhaustive):
https://github.com/odoo/enterprise/pull/92727
https://github.com/odoo/enterprise/pull/99395
https://github.com/odoo/enterprise/pull/90434
opw-5382423
Forward-Port-Of: odoo/enterprise#105615This update resolves an error in the calculation of secondary contract payslips for Kenyan companies. The fix replaces a missing variable with the total taxable gross, ensuring accurate payroll processing for employees on secondary contracts. This improves the reliability of payroll reporting for our Kenyan clients.
Original PR description
Steps to reproduce: With a Kenyan company, create an employee. Check the "Secondary Contract" on the employee form view. Create a payslip and compute. There is an error in the payslip computation. Cause: There is an undefined variable "remaining_gross". Fix: Replace it by the total taxable gross. Task: 5462310 Forward-Port-Of: odoo/enterprise#103229
This update resolves an issue caused by recent changes to the Swiss Federal Tax Administration's website. The PR adjusts the URLs used to download tax rates for the l10n_ch_hr_payroll module, ensuring the import feature continues to function correctly.
Original PR description
Due to recent updates on the Federal Tax Administration website, the single-canton import feature was made temporarly unavailable, this PR adjusts the new URLs for downloading the tax rates Forward-Port-Of: odoo/enterprise#106288
This update corrects a minor error in the XML code for the invoice and withhold views, specifically a misplaced closing tag. This ensures the system generates invoices and withhold documents correctly, preventing potential processing issues. The fix improves the stability and reliability of the accounting module.
Original PR description
Currently, the `account_move_form_invoice_and_withhold_view` contains an invalid closing group tag (`</group>>`) introduced by PR [1], at [2]. The extra `>` results in malformed XML. This commit removes the stray character and restores a properly closed `</group>` tag. [1]: https://github.com/odoo/enterprise/pull/77592 [2]: https://github.com/odoo/enterprise/blob/7c574d758ff5b1404b808cc647d4a2ae40f5f0c0/l10n_ec_edi/views/account_move_views.xml#L79 **No task Id** Forward-Port-Of: odoo/enterprise#106104
This update fixes an issue where subscription invoices were being generated prematurely when a section or note was added to the subscription. The fix ensures that invoice dates align with the expected end-of-period billing, regardless of whether a section or note is present. This improves accuracy and consistency in subscription billing.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394 Forward-Port-Of: odoo/enterprise#104892