Daily updates from Odoo
Friday, July 25, 2025
14 changes · master
Resolved issues and error corrections
The point of sale customer display now opens more reliably even when the IoT Box cannot be reached. This prevents error screens during checkout and keeps the customer-facing display available by using an alternate connection method when needed.
Original PR description
We fixed the customer display not opening and displaying a traceback when the Iot Box was not reachable, by calling the action via iot_http, fallbacking on websocket when needed. We also removed the "customer display with IoT Box" logic from the PoS to the module pos_iot. Community PR: odoo/odoo#219917 Forward-Port-Of: odoo/enterprise#90657
This fixes an error that could prevent employees from clocking out in restaurants using the Belgian blackbox POS setup. The POS now receives the required employee identification data during synchronization, so clock-in and clock-out actions work reliably.
Original PR description
How to reproduce: - Set up a restaurant with a Belgian blackbox - Create employees - Enable the POS setting "Log in with Employees" - Open the POS configuration - Select an employee - Click "Clock Out" - The following error is displayed:TypeError: Cannot read properties of undefined The required employee '_insz_or_bis_number' data was not properly transferred to the POS during incoming synchronization, causing undefined references when performing clock-in/clock-out actions.
Ecuador electronic invoice processing now handles empty or incomplete responses from the tax authority without crashing. This helps users continue processing invoices more reliably when the external service returns unexpected data.
Original PR description
The system will crash when we receive nothing in `response` and also tryig to retrieve values from response. **Error:-** `TypeError: 'NoneType' object is not subscriptable` **Root Cause:-** - While…
The system will crash when we receive nothing in `response` and also tryig to retrieve values from response. **Error:-** `TypeError: 'NoneType' object is not subscriptable` **Root Cause:-** - While we are in `EC Company`. - When we click `Process Now` on the invoice. It will call `button_process_edi_web_services` method. And while in execution when at [1], `move.company_id._l10n_ec_is_demo_environment()` is `False`, then it calls `_l10n_ec_send_document` method. - While submitting electronic invoices to SRI, the method `_l10n_ec_get_client_service_response_new()` sometimes returns `None` . - It may also lack expected keys like 'estado' or 'comprobantes', depending on SRI’s behavior. [1] https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_ec_edi/models/account_edi_format.py#L425-L428 **Solution:-** - Wrapped the access to response and its keys inside a `try...except` block that catches:- - `TypeError`: for cases where the response is `None`. **Sentry - 6708486009, 6728767866** Forward-Port-Of: odoo/enterprise#88611
Belgian point-of-sale receipts are adjusted to meet blackbox certification requirements after recent receipt layout changes. Receipts now more clearly show whether a ticket is valid and whether it is a refund, while removing duplicated date and address details.
Original PR description
Since this revmap of the POS receipt (https://github.com/odoo/odoo/pull/201105), we have to make some changes on the receipt when using `pos_blackbox_be`: - Display if the ticket is valid or not (Pro Format) & increase its size. - Display if the order was a refund or not. - No need to display the `blackbox_date` since we now have the `date_order` inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml``. - No need to display the `order.company.street` since the whole adress is now displayed inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml`. task-id: 4848882 community PR: https://github.com/odoo/odoo/pull/214394 Forward-Port-Of: odoo/enterprise#90180 Forward-Port-Of: odoo/enterprise#87759
This update fixes issues that could prevent Gemini-based AI features from working correctly and improves how attachments are processed for AI use. It also prevents AI search data from different models being mixed, making results more reliable for users.
Original PR description
- Use correct gemini model names (gemini-2.5-flash instead of just gemini) - Fix google API endpoint to use openAI-compatible path (/v1beta/openai) - Introduce embedding_model field in ai.embedding to prevent cross-model mixing - Fix attachment processing percentage calculation to count unprocessed embeddings - Add proper provider detection and embedding model mapping - Handle None responses from embedding API gracefully - Fix AI agent duplication with proper name suffix - Add comprehensive gemini integration tests - Update settings UI labels for clarity Task-ID: 4778862
Fixes an error that could stop users from reconfirming a loan after cancellation when Accounting Audit Trail is enabled. This ensures loan workflows remain usable even when past accounting entries must be preserved for compliance.
Original PR description
Steps: - Activate Audit Trail in Accounting configuration - Create and confirm a loan, having some moves posted in the past - Cancel it, reset it to draft the re-confirm it again -> ValueError: Expected singleton This is because posted moves can not be unlinked when canceling/closing the loan if audit trail is activated. Therefore we try to access the `state` field from a recordset instead of a singleton. With this commit, we filter the generated move to get the newly created one. opw-4834361 Forward-Port-Of: odoo/enterprise#90578 Forward-Port-Of: odoo/enterprise#88286
Fixes formatting issues when inserting fields and records into AI prompts, making them easier to delete and edit. It also reduces unnecessary prompt update calls when the content has not changed.
Original PR description
Purpose: -------- Currently records and fields inserted in AI prompts are badly formatted, making it sometimes impossible to delete an inserted field or to place the cursor after a field or a record. This commit fixes their format: For standalone fields, we do not insert divs inside a span anymore For grouped fields, the container is now a div instead of a t (which was set as inlined by the qweb plugin while the group shouldn't) For records, the container is now a span instead of a div, since we want the records to be inlined. Also, ai prompt widget now only calls onChange when the prompt content changed (to not make useless calls to it) Task-4780975 Forward-Port-Of: odoo/enterprise#90774
This fixes issues in the salary package configurator and offer signing flow that could save employee details on the wrong record or select an archived contract version. It improves reliability when HR teams generate, sign, and countersign offers, especially for Belgian salary configuration data.
Original PR description
Forward-Port-Of: odoo/enterprise#90307
Worksheet fields on the customer portal now respect visibility rules configured in worksheet templates. This helps customers see only the relevant fields and keeps worksheet layouts clearer when answers or conditions change.
Original PR description
When the user configures the field in the worksheet template to be visible based on a
condition, but it is not applied in the portal because the 'invisible' attribute is not
working. We have used 't-if'.
Technical:
1) Due to dynamic row visibility, the server-side cannot determine if the row is odd or even,
so I have implemented it in SCSS.
2) When the value of the field changes, `_add_field_node_to_container()` method is not triggered. Hence, we cannot
evaluate the domain.
task-3686737Fixed an issue where confirming an upsell with a non-recurring product could incorrectly increase the quantity on the original subscription. This prevents subscription records from being changed by unrelated products, helping keep customer billing and subscription quantities accurate.
Original PR description
**Steps to reproduce:** - Install `sale_subscription` - Create a recurring product (P1) and a non-recurring product (P2) - Create a Sale Order (S1) with P1 (quantity > 0) and confirm it - Create an…
**Steps to reproduce:** - Install `sale_subscription` - Create a recurring product (P1) and a non-recurring product (P2) - Create a Sale Order (S1) with P1 (quantity > 0) and confirm it - Create an upsell of S1 (new child order S2) - In S2, edit the P1 line, and select P2 - Set quantity > 0 for P2 - Confirm S2 **Issue:** After confirming the upsell order (S2), the quantity of P1 on the original subscription (S1) is incorrectly increased by the quantity of P2 from S2. The _compute_parent_line_id method did not reset the parent_line_id when the product was not a subscription Product, which caused it to incorrectly update the subscription This issue is present in all three versions: **16.0, 17.0, and 18.0**. **Solution:** Reset parent_line_id to False if the product is not a subscription product to prevent incorrect subscription updates. [opw-4638955](https://www.odoo.com/odoo/project.task/project.task/4638955) Forward-Port-Of: odoo/enterprise#90871 Forward-Port-Of: odoo/enterprise#88282
Brazilian POS orders with a zero total now still send the required payment information to Avalara. This prevents invoice submission errors for free or fully discounted sales, helping affected businesses complete compliant electronic receipts without manual intervention.
Original PR description
Right now, for 0 cost POS orders no `paymentMode` section is sent to Avalara, which leads to an error from them when trying to submit the invoice: Code 899: incorrectly entered payment method field The proper fix is to always send `paymentMode` with a value of 0.00 and mode of `Other`. (Note that there is a payment mode that corresponds to no payment, 90, but it only available for NF-e not NFC-e so we use 99) opw-4874094 Forward-Port-Of: odoo/enterprise#90960 Forward-Port-Of: odoo/enterprise#90724
Chilean factoring AEC files now always report the total amount in Chilean pesos, even when the original invoice uses another currency. This prevents incorrect values in regulatory export files and helps ensure submissions match local requirements.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MntTotal tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on Send Now to SII and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MntTotal is in selected currency which is wrong related: https://github.com/odoo/enterprise/commit/4e97c5d008c2879c5d014203fafc2c125d6c5ae7 opw-4830957 Forward-Port-Of: odoo/enterprise#90858 Forward-Port-Of: odoo/enterprise#90232
When users generate an electronic invoice XML from the send and print flow and choose to download it instead of emailing it, Odoo now creates the matching Documents entry. This keeps accounting documents complete and consistent regardless of whether the invoice attachment is sent by email or only downloaded.
Original PR description
Event with the document integration correctly setup, e-invoice xml generated in the send&print wizard will not create an associated document unless the attachment is actually sent via mail Steps to reproduce: - Have a EU Company setup - Enable and configure Peppol Electronic Invoicing - Enable documents integration with accounting - Create an invoice to a Peppol enabled customer, confirm - Open send&print wizard, enable only 'Download' and 'BIS Billing 3.0' Issue: Document related to the xml attachment is not created. This will work as expected when the message is sent to the customer It occurs because, in case of xml attachment, we don't create an associated document until some attachment have been registered on the move, effectively delaying document creation until the mail attachments are created opw-4720588 Forward-Port-Of: odoo/enterprise#90475 Forward-Port-Of: odoo/enterprise#88746
Belgian Intrastat XML exports now follow the same 'Hide lines at 0' option shown on the report screen. This prevents zero-cost transactions from being included in official XML exports, reducing reporting errors and manual cleanup for accounting teams.
Original PR description
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide…
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide lines at 0'. Doing this will prevent 0 cost transactions from appearing in the report. However, when exporting to XML, such transactions are still displayed. Note: this is related to Belgian companies only. ## Reproduction Steps 1. Go to settings and make sure the company you're operating with is Belgian. Then, in accounting, under the Custmer Invoices section, check the 'Intrastat' option. 2. Go to products and create a new product of type 'Goods'. Then, in the 'Accounting' tab, click on a random commodity code. Set the country of origin as a country belonging to the European Union (for example, Austria). Click on save. You should see a field named 'Intrastat Supplementary Unit Amount' appear. 3. Go to accounting. Click on the 'Vendors' tab and 'Bills'. Click on New. Select a random vendor, and add a line containing the product you just created. Add the column 'Intrastat' and set the corresponding field at '11 outright...'. Then, set a price. In the 'Other Info' tab, set the field 'Intrastat Country' as a random country in the European Union (for example, Australia). Set the fiscal position at 'Import/Export' and set the 'Intrastat Transport Mode' field at '1. Sea transport'. Finally, click on confirm. 4. Duplicate the vendor bill you just created. On this new vendor bill, set the Intrastat at '12 Direct trade...'. Display the column 'Disc.%' and set the field at 100. Then click confirm. 5. Click on the 'Reporting' tab, and under 'Audit Reports', click on 'Intrastat Report'. Set the month to the current month, then click on 'Report: Intrastat(Services....)' and select 'Intrastat (Goods)'. You should be able to see the 2 vendor bills you just created. Click on 'Options' then 'Hide lines at 0': you should see the bill having a 0 cost disappear. Finally, click on the cog on the top left next to 'Intrastat Report' and click on 'XML'. 6. Once the XML file has finished downloading, open it. ### Expected behavior The transaction having a 0 cost shouldn't appear. ### Unexpected behavior The transaction having a 0 cost appears. ## Origin of the issue In the code responsible for the display of the XML report, there isn't any condition responsible for checking if the transaction should be displayed or not. _________________________________________ opw-4464123 --- Forward-Port-Of: odoo/enterprise#90193 Forward-Port-Of: odoo/enterprise#89285