Daily updates from Odoo
Tuesday, September 30, 2025
14 changes · master
Resolved issues and error corrections
Mexican electronic invoicing now handles cases where the US dollar currency has been deactivated. This prevents invoice confirmation and sending from failing for companies using Mexico localization and external trade documents.
Original PR description
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI…
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI Certificate and activate Testing mode in PAC. 5. Create a new product with "UNSPSC Category". 6. Create an invoice with CFDI to the public and "Definitive" in External Trade. 7. Confirm and send the invoice. **Sample certificate:** Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link Private key password: 12345678a **Error:** `ValueError - Expected singleton: res.currency()` **Cause:** When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation. **Fix:** This commit handles the case when USD currency is deactivated. sentry-6860601127 Forward-Port-Of: odoo/enterprise#94179
Orders from self-service or kiosk online payments now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring confirmed orders reach the kitchen display, including when customers leave through the payment portal exit flow.
Original PR description
pos_*= pos_online_payment_self_order_preparation_display, pos_self_order_iot Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Community PR: https://github.com/odoo/enterprise/pull/87173 Backport of https://github.com/odoo/odoo/pull/87173, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal Forward-Port-Of: odoo/enterprise#95583 Forward-Port-Of: odoo/enterprise#95312
The Australian Taxable Payments Annual Report now excludes unrelated customer payments from the Gross Paid amount. This makes TPAR figures more accurate by counting only relevant supplier payment lines for report calculations.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95592 Forward-Port-Of: odoo/enterprise#95029
This change corrects how Mexican electronic invoices are calculated so totals match the official XML validation rules. It helps prevent valid invoices from being rejected because of tiny rounding differences in decimal amounts.
Original PR description
The validation in the XML are made based on values rounded to 6 digits. However in Odoo, we do the computation without any rounding. 352.2413793103448 + 876.7435344827586 + 162.92327586206898 + 198.73706896551727 + 526.0383620689655 + 17.241379310344826 = 2133.925 ~= 2133.93 352.241379 + 876.743534 + 162.923276 + 198.737069 + 526.038362 + 17.241379 = 2133.924999 ~= 2133.92 != 2133.93 opw-5096249 Forward-Port-Of: odoo/enterprise#95555 Forward-Port-Of: odoo/enterprise#95413
Rental orders are no longer blocked by unavailable planning resources when shift synchronization is disabled. This prevents unnecessary confirmation failures in the portal and rental app, making rentals proceed as expected when planning shifts are not being synced.
Original PR description
Step to reproduce: - Set up a role with a resource not available this week - Not activate the option to sync Rental order - Shift - Set up a rental-service product, with an auto-plan for this role Issue: - Rental orders could not be confirmed from the portal or the rental app if the required resource was unavailable, even when the `sync_shift_rental` option was not disabled. Cause: - The logic in `_planning_slot_vals_list_per_sol` treated all unavailable resources as problematic, without checking whether the shift synchronization was enabled (`sync_shift_rental`), resulting in unnecessary blocking of the order confirmation. Solution: - Added a condition to check if `sync_shift_rental` is enabled before marking a service as problematic. This allows rental orders to be confirmed when shift sync is disabled. task-5072920 Forward-Port-Of: odoo/enterprise#95745 Forward-Port-Of: odoo/enterprise#94176
Fixed an issue where the download menu for a signature request could appear empty when the request was opened from a record's chatter. Users can now reliably access the related documents from the download dropdown, reducing confusion and extra navigation.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign request from 'request signature' activity. - From the chatter of the related record, open the sign request. - It will redirect to form view of that sign request. - click on download dropdown button. Before: - The download dropdown was empty. - This happened because the 'sign_request_documents_dropdown' widget tried to use 'active_id' from the context, but 'active_id' was missing when the sign request was opened from chatter. After: - The download dropdown correctly shows the related documents. - When active_id is not in the context, the widget now uses the sign request id from evalcontext, so it can fetch the right documents. Impact: - Users will always see the correct documents in the download dropdown, even when opening a sign request from chatter. task-5089829 Forward-Port-Of: odoo/enterprise#94885
The AI service now handles invalid tool requests and usage limits more clearly, preventing conversations from stalling or failing silently. This makes AI-powered features more dependable and helps the system recover gracefully when the model makes an unsupported request.
Original PR description
This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures. - **Unknown Tool Calls**: When an LLM requests a tool with an…
This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures. - **Unknown Tool Calls**: When an LLM requests a tool with an invalid or unknown name, it previously resulted in an empty response, causing the conversation to stall. This change ensures that a proper error message is now returned to the LLM for the invalid tool call. This allows the LLM to process the failure and continue the conversation. - **Failing on Limits**: The query processing loop in `_request_llm` has limits for both successive API calls and the number of tool calls per request. Previously, these limits would be reached silently. - **API Call Limit**: If the `AI_MAX_SUCCESSIVE_CALLS` limit is reached without the LLM providing a final answer, a `ValueError` is now raised. This prevents silent failures and makes it clear to the calling code that the request could not be completed. - **Tool Call Limit**: If the number of tool calls in a single response exceeds `AI_MAX_TOOL_CALLS_PER_CALL`, any calls beyond the limit are now provided with a result stating that the limit was reached. This gives the LLM the opportunity to try the unprocessed tool calls again in a subsequent turn. - **Ignore Explanatory Text**: The text that LLMs often include alongside a tool call request (the "thinking" text) is now ignored to provide a cleaner and more concise final response to the user. Forward-Port-Of: odoo/enterprise#94413
Creating a related monetary field in Studio now also creates the matching related currency field, so the amount can be used correctly. This prevents unusable monetary fields and helps ensure values display and calculate with the right currency.
Original PR description
Before this commit, when creating a related field to a monetary, the created currency field was not stored and not related either, so the monetary was unusable. This was because of 5cf5a35a0a8f78655989009d0eddcf39f8430965 , b177b058be1531c3d2af2b591c22591c19240d33 and in general the changes in read_group that largely improve the situation. After this commit, we create a currency field related to the currency field of the related monetary to ensure that the monetary's value is coherent. This is made possible by the above mentionned improvements in read_group opw-5094619 Forward-Port-Of: odoo/enterprise#95407
Carbon emissions calculations now convert quantities using the unit of measure expected by the emission factor, rather than the invoice line. This fixes incorrect emissions values and improves the reliability of ESG reporting.
Original PR description
Prior to this commit, the UoM conversion in the carbon emissions calculation was done by targeting the UoM of the account move line instead of the UoM of the emission factor. Which led to incorrect emissions values calculations. task-5107685 Forward-Port-Of: odoo/enterprise#95468
Invoices from Point of Sale can once again be sent directly to configured IoT printers instead of only being downloaded as PDFs. This fixes a regression and reuses the printer selection flow so printing behavior stays consistent across reports and invoices.
Original PR description
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself. - **[REF] iot: extract printer select into separate function** Before this commit, the printer…
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.
- **[REF] iot: extract printer select into separate function**
Before this commit, the printer selection wizard was tightly coupled to
the IoT report handler, and the call to send to the printer was
duplicated in the wizard and the handler.
After this commit, the printer selection wizard is contained in a
function that will always return the selected printers directly to the
caller, whether the dialog needs to be opened or not. The wizard is
simplified as a result and the print call always occurs in the handler.
This refactoring will allow other places to use the printer selection
wizard, namely for invoice printing.
- **[FIX] pos_iot: print invoices via IoT**
In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
bypass the `ir.actions.report` model, instead working directly via an
action on the invoice model. A side effect of this is that it broke
printing invoices via the IoT, as it relies on the report printing
action to function.
To fix this, this commit introduces an override in `pos_iot` for the
`account_move_service`, which will print the invoice PDF via the IoT
instead of downloading it directly (if a printer is associated with the
report).
task-5109814
Forward-Port-Of: odoo/enterprise#95689
Forward-Port-Of: odoo/enterprise#95586Fixed an issue that could cause an error when users viewed the General Ledger from the Trial Balance while working with multiple selected companies. This prevents interruptions for accounting users, especially when account codes are hidden and Developer Mode is enabled.
Original PR description
**Issue** When multiple companies are selected and Developer Mode is enabled, clicking "View General Ledger" for an account in the Trial Balance leads to a traceback. This affects accounts whose code is hidden. **Steps to Reproduce** 1. Go to Accounting > Reporting > Trial Balance. 2. Select multiple companies. 3. Click on an account where the account code is not visible. 4. From the three-dot menu, select "View General Ledger". 5. Observe the traceback error. **Root Cause** The error occurs because the `AccountReportSearchBar` component expects a string `initialQuery` prop, but in the multi-company scenario with developer mode enabled, the value passed can be `undefined` or non-string. Owl's strict prop validation then throws an `OwlError`, leading to the traceback. **Fix** Ensure that `initialQuery` is always a string when passed to `AccountReportSearchBar`. Opw-5050843 Forward-Port-Of: odoo/enterprise#94104
Peruvian electronic invoices now show the invoice currency for deducted down payments instead of defaulting to the company's currency. This prevents foreign-currency invoices from displaying PEN incorrectly, reducing compliance and customer-facing document errors.
Original PR description
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to…
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to reproduce: 1. Install l10n_pe_edi 2. Sell a product to "Comercial Constructora los Patitos" through the sales app and make sure you use USD (or a different currency than PEN). 3. Create a downpayment invoice, could be any percentage. 4. To make sure it works correctly, add a random document number on the invoice with the format ABC-01234567. 5. Confirm this invoice. 6. Now go back to the sale order and deliver your product. 7. Create the final invoice, where the downpayment will be deducted. Make sure it is also in USD (or whatever currency you chose). 8. Confirm the invoice. #### Current behavior: - Display "PEN" in the attribute currencyID of tag PaidAmount in a PrepaidPayment: <cbc:PaidAmount currencyID=PEN> #### Expected behavior: - The currency displayed should match the invoice currency #### Cause of the issue: - the currency of the company emitting the invoice was used instead of the currency of the invoice. opw-5061019 Forward-Port-Of: odoo/enterprise#93885
This fixes an error that could occur when generating tax return checks for a non-empty EC Sales List with VAT number verification enabled. Businesses can now use the VAT verification option without the process failing because of duplicate check entries.
Original PR description
Create tax return checks for a non-empty EC Sales List report when the option "Verify VAT Numbers" (vat_check_vies) is enabled implies to create 2 checks with the same code (check_partner_vies). This is forbidden and raises a traceback. opw-5079474 opw-5090602 opw-5094853 opw-5103611 Forward-Port-Of: odoo/enterprise#95551
ESG account assignment now only allows accounts that are appropriate for emissions tracking, reducing confusion and incorrect data entry. If an account is changed to an unsupported type, users are warned and related ESG assignment or emission data is cleaned up to keep reports accurate.
Original PR description
Before this PR, it was possible to create on the fly an account from the assignation lines list view of another type than "Expense" or "Fixed Assets". This is not desired, as this type of account is not part of the domain of the `account_id` field of the `esg.emission.factor.line` model. We prevent creation of such accounts from ESG in general, to avoid confusion and ensure data integrity. Moreover, when changing the account type of an existing account, if this one is changed to a type other than "Expense" or "Fixed Assets", we verify if there are some assignation lines linked to this account and/or journal items linked to that account. If so, we raise a warning to the user and if he wants to proceed, we remove the assignation lines linked to this account and remove the emission factors of journal entries linked to that account. task-4859806 Forward-Port-Of: odoo/enterprise#95833 Forward-Port-Of: odoo/enterprise#87295