Daily updates from Odoo
Friday, October 17, 2025
13 changes · master
Resolved issues and error corrections
Shipping label printing can now use a printer selected for each delivery operation type instead of automatically choosing the first available compatible printer. This helps warehouses route labels to the right printer by default, reducing manual work and printing mistakes.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. Task: 4792491 Forward-Port-Of: odoo/enterprise#97034 Forward-Port-Of: odoo/enterprise#86818
Customer statement emails sent from a child contact now generate the correct PDF attachment instead of an empty statement. The Customer Statement button is also hidden when there are no transactions or no amount due, reducing confusion for accounting users.
Original PR description
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and…
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and confirm it. 3. Go to the child contact and open the Customer Statement smart button. 4. Download the PDF → data is shown correctly. 5. Send the statement → the attachment in the sent mail is empty. **Issue:** - When sending customer statements via email from a child contact, the generated PDF attachment contains no data, showing empty amounts and transactions. - Additionally, the "Customer Statement" button was still visible even when the total due was zero. **Cause:** - The button visibility condition checks for `total_due == 0.0 and not has_moves`, which didn’t properly cover all use cases. **Solution:** - Update button visibility condition to: `invisible="not has_moves or total_due == 0"` ensuring it is hidden when there are no moves or the total due is zero. **opw-5009182** Forward-Port-Of: odoo/enterprise#96017 Forward-Port-Of: odoo/enterprise#93162
This fix corrects how bank synchronization actions are triggered from the bank journal status area. As a result, customer-facing actions that previously failed to be sent should now work as intended.
Original PR description
The aim of this commit is fixing the usage of doActionButton. In this commit [[1]], we added two usages of doActionButton but it was wrongly done. It means, for a functional POV, that the action is never send to the customer. [1]: https://github.com/odoo/enterprise/commit/379f8bf0d9f55dda1998750fd5cbe48a2d84b00e
Argentina VAT report exports now generate both required text files for Type C vendor bills and invoices without taxes. This helps businesses meet AFIP filing requirements and avoids incomplete report downloads.
Original PR description
…afip code '0' **Description of the issue/feature this PR addresses:** This PR addresses an issue identified in the generation of .txt files for invoices that utilize AFIP tax code '0' **Current behavior before PR:** The system is only generating one of the two .txt files required by AFIP for specific invoice types. Affected Cases: - Invoices of type 'C'. - Invoices that have no taxes. **Desired behavior after PR is merged:** Two .txt files should be generated for all invoice types, as per AFIP requirements. [HERE](https://app.screencastify.com/watch/2mtioGVxEOwW0rAHJS2v) is a video replicating the issue: 1. In localization Argentina, create a vendor bill type 'C' 2. In 'Tax Return' report, filter by date and 'Tax Type: Purchase' 3. Download .ZIP file and see only one .txt Forward-Port-Of: odoo/enterprise#96052
Shipping label printing through IoT can now use a selected printer for each picking type instead of automatically choosing the first matching printer. If a shipping label or document is printed without a linked IoT printer, users now receive a clear error message instead of a technical traceback.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. backport of odoo/enterprise#86818 Task: 4792491 Forward-Port-Of: odoo/enterprise#97396 Forward-Port-Of: odoo/enterprise#95794
The AI live chat website block now behaves more consistently with website themes and editing tools. This improves the visitor experience with cleaner design, better readability, smoother fullscreen behavior, and stronger accessibility support.
Original PR description
Resolve theme options compatibility, editing behavior, accessibility and design problems affecting UX and standards compliance. Adherence to theme options: - Apply border-radius correctly to target…
Resolve theme options compatibility, editing behavior, accessibility and design problems affecting UX and standards compliance. Adherence to theme options: - Apply border-radius correctly to target elements - Fix bg-color applying to text-area instead of intended container Edition: - Remove resize/style options on the column since these are not retained on save - Fix the preview that mismatch with actual rendered result - Resolve title/form misalignment in edit mode - Ensure "OR" text readability across different background colors - Preserve container size when the "fullscreen" feature is activated Accessibility: - Add missing focus state for form fields - Add role="presentation" to icons - Add role="button" to anchor tags functioning as buttons Design: - Reduce oversized title font size - Adjust container width on xl and xxl breakpoints - Smooth fullscreen transition to prevent abrupt activation | 19.0 | this PR | |--------|--------| | <img width="1092" height="424" alt="image" src="https://github.com/user-attachments/assets/5cd85204-b9af-4810-9458-c4c96dad562d" /> | <img width="1083" height="409" alt="image" src="https://github.com/user-attachments/assets/b83f2d18-0135-4f5d-b420-11f58070c8a3" /> | task-5089787 Forward-Port-Of: odoo/enterprise#94767
The General Ledger now shows the Initial Balance line first when using the Load more option. This prevents missing or duplicated ledger entries when users load account lines in smaller batches.
Original PR description
### Issue: The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option ### Steps to reproduce: - Accounting > Configuration > Accounting Reports > General…
### Issue: The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option ### Steps to reproduce: - Accounting > Configuration > Accounting Reports > General Ledger - Change the Load more limit in the options to a small number, i.e. 4 - Open the General Ledger and unfold an account with more than 10 lines - There is no Initial Balance line, it appears when clicking "Load more" ### Cause: The General Ledger query have this line `ORDER BY 2, move_name, 1`. Here 2 refers to the date and 1to the `account_move_line.id`. But the initial balance line has these columns equal to `NULL` so this ORDER BY will place it at the end of the results. When the limit is smaller than the total number of lines, the initial balance is not fetched by the query. **Additional issue** The limit is incremented several times. In our case, we set the option at 4. It gets incremented [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_report.py#L7172) because the load more option is triggered, and also [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L239) for no apparent reason (it is not needed "for the Initial balance"). So the query is called with `limit=6`, six lines are retrieved when clicking on "Load more". Considering a scenario where there are 10 lines for the account (with the initial balance) and "Load more limit" set to 4: - The first query gets the lines 1-6 but only 1-4 are displayed. - Clicking "Load more", the offset is 4, the query gets the lines 5-10. 10 being the initial balance, it is put in first position by [this piece of code](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L79-L91). So the lines displayed are 10, 5, 6, 7 - Last click on "Load more", offset is 8, query gets 9 and 10, displays 10, 9. In the end, one line is not displayed, and the initial balance is displayed twice. ### Solution: Add `NULLS FIRST` in `ORDER BY` to always have the Initial Balance as the first line returned by the query. Also remove the unnecessary `limit+1`. opw-5105652 Forward-Port-Of: odoo/enterprise#96136
SAF-T reports now show the required tax payable amount when reverse charge taxes are used, instead of reporting zero. This helps ensure Romanian tax filings match authority expectations and reduces the risk of incorrect compliance reporting.
Original PR description
When a reverse charge tax is used, we export a `TaxInformation` with a zero amount instead of the real amount of the tax. The tax authority requires to show the tax to pay and doesn't care about the tax to receive... In order to fix this, we only sum the tax details of lines having positive repartition lines. opw-5125678 Forward-Port-Of: odoo/enterprise#97315 Forward-Port-Of: odoo/enterprise#97117
Fixes a bank reconciliation issue where choosing a write-off account with a default tax could remove an already matched bill or invoice. Users can now add the account without losing existing reconciliation work, reducing manual rework and errors.
Original PR description
In the Bank reconciliation widget, users can click a button to set the account to write off the remaining balance. However, if the chosen account has a default tax set, the widget will lose any existing matches with invoices. Steps to reproduce: - Have an account with a default tax - Create a bill with a total - Create a bank statement for a greater amount - Open the bank reconciliation widget - In the created statement, first add the bill, then click 'Set Account,' and choose the account with tax Issue: Bill matching will be lost. This occurs because we remove and recreate the matching line, but we don't keep the line to be reconciled. opw-5002624 Forward-Port-Of: odoo/enterprise#96006
Spreadsheet pivots now let users drill into related fields even when a dimension is already selected, while still preventing duplicate selections of the exact same dimension. Date and datetime fields can also be selected again with different granularities, making analysis by day, month, or year more flexible.
Original PR description
Before this commit: - Once a dimension (e.g, 'Customer') was selected in a pivot, it could not be used for drilling into related fields, preventing cross-model exploration. - Date and datetime fields could not be re-selected to use different granularities (day, month, year, etc.). After this commit: - The pivot forbids re-selecting the exact same dimension but still allows users to drill and select fields from related models. - Date and datetime fields remain selectable to allow choosing different granularities, improving flexibility in pivot analysis. Task: [5114511](https://www.odoo.com/odoo/2328/tasks/5114511) Forward-Port-Of: odoo/enterprise#95898
Uruguayan electronic invoices now include zero-value lines in the official CFE submission as free delivery items. This prevents missing invoice details when reporting free products, deliveries, or fully discounted lines to the tax authority.
Original PR description
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by…
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount ## Steps to reproduce 1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 2. Add a line with quantity 1. price 0 3. Add a second line with quantity 1, price 500 and discount 100% ## Before this PR 1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery. 4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all ## After this PR Both lines are informed to DGI using the invoice indicator 5 (Free Delivery) You can check this on to generate CFE XML in demo mode (not need to connect to UCFE) If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file. References [Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691) LATAM 1350 / ADHOC task 53445 Forward-Port-Of: odoo/enterprise#89808
Creating a vendor bill from an IRN now correctly looks for a purchase journal across all companies in the tax unit, not just the main company. This prevents bill creation failures for multi-company tax units when the main company lacks a purchase journal.
Original PR description
Before this PR: - The system searched for a purchase journal only in `company_id`. - In a tax unit with multiple companies, if the main company had no purchase journal configured, record creation failed with a 'NOT NULL constraint violated' error. After this PR: - The journal search now checks all companies in `company_ids` (or falls back to `company_id`), - allowing the system to find a valid purchase journal across the tax unit. Forward-Port-Of: odoo/enterprise#97255
This fix ensures Mexican electronic invoice XML attachments are created with the correct file type even when the user has limited permissions. It prevents related accounting documents from being missed when document centralization is enabled.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038 Forward-Port-Of: odoo/enterprise#97325 Forward-Port-Of: odoo/enterprise#95197