Monday, January 19, 2026
11 changes · 17.0
Resolved issues and error corrections
This update ensures Odoo continues to work seamlessly with the latest itsme API version (v2). By updating the API route, the system now correctly processes itsme requests, maintaining reliable identity verification for users. This change is a routine maintenance update.
Original PR description
After this commit, the route of the itsme gets updated from "v1" to "v2" in the `sign_identity_request` call, in order to follow the new api. task-5499804
This update resolves a technical error within the `l10n_ro_saft` module that was preventing accurate reporting for Romanian Standardized Accounting Forms (SAFT). The fix ensures the system correctly handles different unit of measure categories, avoiding a 'singleton error' that impacted report generation. This improves the reliability of SAFT reporting for Romanian businesses.
Original PR description
`saft_template` in `l10n_ro_saft` adds a table that loops over the different Unit of Measures (`uoms`) available. The issue is that if the `uoms` are part of different categories (ie: Length and Weight) we get a singleton error as we're trying to access a non-relational field of a recordset with multiple records. The commit fixes the error by using the already defined variable `uom` OPW-5499918
This update fixes an error in the Swiss VAT reporting module that was incorrectly displaying reverse charge tax amounts as negative. The fix ensures accurate VAT reporting by properly handling negative tax rates used to model reverse charge transactions, preventing incorrect VAT calculations.
Original PR description
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) or **382a** (7.7% reverse charge) is reported as **negative**. * This leads to incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The Swiss tax report formulas for figures **383a** and **382a** applied an additional negative sign. **Fix:** * Override the tax-tag aggregation logic to invert the sign for these figures only for Swiss companies (CH). opw-5257445
This update prevents errors when creating inter-company invoices by ensuring payment terms are compatible with the receiving company. Previously, payment terms were incorrectly applied, causing invoice posting to fail. Now, only company-specific payment terms are used, streamlining inter-company transactions.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both…
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies. * Create a **payment term** assigned to **Company A**. * Create a **sale order** from Company A to Company B using that payment term. * Confirm the sale order and create the **invoice**. * Post the invoice to trigger the inter-company vendor bill. **Observed behavior:** * The generated **vendor bill** for Company B uses **Company A’s payment term**. * Posting fails because the payment term is incompatible with Company B. **Cause:** * Inter-company document creation reuses payment terms without checking whether they belong to the **target company**. * Payment terms from the source company can be propagated to the destination document. **Fix:** * Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices. * Payment terms belonging to a different company are now ignored. **NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution. opw-5392745
This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for major carriers like UPS, FedEx, USPS, and DHL. By mapping these modules, the connector now functions reliably with these carriers, ensuring accurate order processing and fulfillment within the Amazon integration.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings.
This update resolves an issue where the 'Month 13' column in the Mexican Trial Balance report incorrectly displayed data. The fix removed a redundant 'balance' column and corrected a hardcoded value, ensuring accurate reporting for Mexican companies. This improves the reliability of financial reports.
Original PR description
With l10n_mx company: 1 - Add the balance column to the “Trial Balance” accounting report 2 - Create a journal entry for the date 12/31/2024 for 5000 as a credit on the account 119.01.01 VAT due and balance it with 5000 as a debit on another account 3 - Open the Trial Balance report and click on the “Month 13” filter as well as the year 2024. Notice that the “Month 13” column has some numbers when there should not be a number in that column. Delete the balance column from the “Trial Balance” accounting report and notice that the numbers now appear in their appropriate columns. In the _l10n_mx_set_options_month_13 the way to find the initial value, month 13 and end value columns was hardcoded. opw-5222117
This update fixes a technical issue that caused errors during server shutdowns. Specifically, the server stop process was incorrectly closing database connections before the system was ready, leading to errors. This change ensures a smoother and more reliable shutdown process, preventing these errors from occurring.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A test was failing in the website sale module due to a sale order not requiring payment. This update forces the sale order to always require a payment, resolving the test failure and ensuring consistent functionality. This ensures the website sale process functions correctly.
Original PR description
version: 17.0+e Why ? --------------- test_payment_provider_visibility_with_portal didn't pass on runbot because the sale order used doesn't reqire payment. The fix --------------- Force the sale order to require a payment. runbot-237786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a discrepancy in how holiday allocations are calculated when employees have different working schedules. Previously, the system produced inconsistent hour counts for related allocations. The fix ensures that all child allocations accurately reflect the total hours defined in the parent allocation, improving allocation accuracy and reporting.
Original PR description
### Steps to reproduce: - Create two employees with two different working schedule - Create a multi employee allocation for the created employees with 40 hours - Validate the allocation you created - Notice the number of hours is differenc between the two allocations ### Cause: When validating the multi employee allocation and while creating the children allocations we compute the number_of_hours_display and since we calculate it with number of days * hours per day it will result into two different values for the number of hours as the hours per day is different for each working schedule. ### Fix: To fix this we check if the allocation is an hourly one we change the number of days depending on the number of hours that we already got from the parent allocation. So when computing the number of hours for the children allocations we get the same value opw-5232797
This update resolves an issue where the UBL export incorrectly interpreted VAT information represented with a forward slash ('/'). The change ensures that VAT is properly handled when a partner doesn't have VAT, and the CompanyID field is correctly required in those cases, aligning with PEPPOL standards. This improves the accuracy of electronic invoices.
Original PR description
To signify that you know a partner does not have vat, we advise using '/'. But we should take care of that in the UBL export, to not consider it a real vat Also, in the cases where we don't have the vat, the CompanyID is supposed to be mandatory. https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-TaxRepresentativeParty/cac-PartyTaxScheme/ So, remove the whole PartyTaxScheme if vat is not present. Zatca does not override that rule (except enforcing that seller must have vat, which raises a constraint), so we modify the tests for the simplified documents. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that prevented users from correctly selecting a company after it had been unarchived. The problem stemmed from a timing conflict in the system's data processing, which caused incorrect company access permissions. This change ensures a smoother and more reliable unarchiving process.
Original PR description
**Steps to reproduce** - Have at least two active companies - Archive one company - Unarchive the company - Select the just unarchived company in the company selector - `Access Error: Access to unauthorized or invalid companies.` **Cause** There was a timing issue between the cache invalidation and the call to super. After the cache invalidation, if `_get_company_ids` of `res.users` was called before the call to `super` in the `write`, it would not return the just unarchived company. opw-5449925