Daily updates from Odoo
Wednesday, April 22, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This update fixes an error that could stop the General Ledger report from exporting when draft invoices or other draft entries were included. Users in Peruvian companies can now generate the report normally, improving reliability for accounting teams.
Original PR description
**Steps to reproduce:** - Install the `l10n_pe_reports_lib` module and switch to a `PE company`. - Create a draft invoice. - Navigate to Reporting > General Ledger. - Click the gear icon and select `Inventory and Balance`. **Error:** AttributeError: 'NoneType' object has no attribute 'replace' **Root Cause:** For draft entries, `move_name` is `None`, and calling `.replace()` on it causes an error at [1]. **Fix:** This commit prevents errors and ensures users can export the general ledger even when draft entries are included. [1]: https://github.com/odoo/enterprise/blob/5babcb5cb951e0e7beebdbef0781a20a7a19c319/l10n_pe_reports_lib/models/account_general_ledger.py#L168 opw-6104117 Forward-Port-Of: odoo/enterprise#113405
When an approval request does not have a contact linked, the printed report now falls back to the request owner’s language instead of stopping translation. This ensures the document is shown in the expected language even when the contact field is optional.
Original PR description
Steps to reproduce: ------------------ 1. Install Approvals. 2. Select an approval type from Approvals > Configuration and ensure the 'Contact' field is not required. 3. Install a second language (e.g., Arabic) and switch the user's language. 4. Create a new approval request with this approval type and set user as the request owner. 5. Try to print the approval request. Current behavior: ----------------- The report is only translated when partner is present because it translates using `partner_id.lang`. Since the partner is not required in all cases, `lang` can evaluate to False when it is missing, causing the report to bypass translations. Expected behavior: ------------------ The report should fall back to the request owner's language or the system's default language if the partner is not available. opw-6010222 Forward-Port-Of: odoo/enterprise#112476
The system now lets administrators adjust the timeout used when fetching exchange rates from mindicador.cl. This helps prevent daily currency rate updates from being skipped when the external service is slow, avoiding gaps in stored exchange rates.
Original PR description
The mindicador.cl provider had a hardcoded 30s timeout on its HTTP requests. The mindicador.cl service is sometimes slow around rate publication time, causing read timeouts that make the cron silently skip currency rate creation for the day due to HTTP Timeouts, leaving permanent gaps in res.currency.rate. Make the timeout configurable through the `mindicador_api_timeout` system parameter (defaults to the previous 30s). opw-6126027 Forward-Port-Of: odoo/enterprise#114153
This update adds an Odoo partner key to Sendcloud requests so Sendcloud can recognize traffic coming from Odoo and continue supporting the older API during their transition. It helps keep shipping integrations working smoothly for new and existing customers while Sendcloud completes its API changes.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#114441
This update corrects a test for Mexican electronic invoices so it matches the current rounding behavior again. It helps keep invoice validation reliable after the rounding mode was changed back to mixed.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114081
The tax return list opened from the Accounting dashboard now expands all expected groups, instead of stopping after the first few and showing blank sections. This makes the list easier to read and ensures users can review all tax return entries from the dashboard view.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978
This fix corrects how activity filters are combined in Studio-created apps. Previously, selecting “My Activities” together with “Late Activities” could return too many records; now the filters work together as intended, making the list view more accurate.
Original PR description
Follow-up of 475a9efe0bde7515c9d5bf6ec6c8aefd4c71975e Steps to reproduce ================== - Create an app with studio and use_mail - Create three records, one with an activity in the past, one today and one in the future - Click on the clock status icon in the top right - There should be a section with the new model - Click on 1 Late => every records is displayed The filters "My Activities" is combined with "Late Activities" with and OR. It should use the AND operator. Solution ======== Add a separator after the "My Activities" filter. The same is done in xml for standard models. opw-6069150 Forward-Port-Of: odoo/enterprise#114347
This change corrects the XML namespace used when sending Colombian credit notes to DIAN. It prevents validation errors during submission and helps ensure these documents are accepted correctly.
Original PR description
Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050 Forward-Port-Of: odoo/enterprise#113643