Daily updates from Odoo
Friday, October 17, 2025
21 changes · 18.0
Enhancements to existing features
Follow-up and customer statement reports now have a simplified header, centered title, and partner bank account details shown near the Tax ID. This makes the reports easier for customers to read and gives them key payment information in a clearer place.
Original PR description
This commit updates the layout for follow-up and customer statement reports. Changes made: --- **Follow-up & Customer Statement Reports:** - remove journal and filter details from header. - centered the title of the report. - Added the partner bank account display below the Tax ID. --- task-4823880
Swedish batch payments can now include both IBAN and BBAN, Bankgiro, or Plusgiro accounts in the same batch. When mixed account types are used, the system generates a ZIP file with separate XML payment files, reducing manual work and preventing blocked payment batches.
Original PR description
This commit add a new behaviour for batch payments in Sweden. Before this commit: batch payment with mixed payment for iban and bban/bankgiro/plusgiro wasn't allowed After this commit: now if the user create a batch payment with both type of account, we create a zip file with 2 xml files, one for iban and one for bban/bankgiro/plusgiro. Linked:https://github.com/odoo/odoo/pull/230104 [task-5107240](https://www.odoo.com/odoo/project/967/tasks/5107240)
This update adds the full set of 5% IGIC tax options and related fiscal positions for Spanish Canary Islands localization. It also corrects existing 5% tax records that were using an incorrect 3% rate or tax group, helping businesses apply the right tax treatment in accounting documents.
Original PR description
- Fix also some errors on the 5% taxes, where a 3 percent was applied or the group was not the right onw @jco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The project sharing customer preview now matches the real portal view when billing is based only on validated timesheets. This prevents customers and staff from seeing draft or unapproved time entries in the preview, reducing confusion around billable work.
Original PR description
Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. To reproduce: Cause: Fix: opw-5155281 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
Vendor bills now correctly create and retain analytic items when posted, even if Auto-check on Post is turned off for the journal. This ensures accounting analytics remain complete and reliable for cost tracking and reporting.
Original PR description
**Issue** When unchecking the *Auto-check on Post* option on a vendor bill journal, analytic items are not created when posting the invoice, even if analytic accounts were set on the bill lines.…
**Issue**
When unchecking the *Auto-check on Post* option on a vendor bill journal, analytic items are not created when posting the invoice, even if analytic accounts were set on the bill lines.
**Steps to Reproduce**
1. Navigate to *Accounting > Configuration > Journals > Vendor Bills*
2. Uncheck *Auto-Check on Post*
3. Activate *Analytic Accounting* in settings
4. Create a vendor bill with one line and set analytic accounts
5. Post the entry
6. Navigate to *Accounting > Accounting > Analytic Items*
7. No analytic items are created
**Root Cause**
When `autocheck_on_post` is disabled, the `account.move` is still in draft during the `write({'state': 'posted'})` call. In `account.move.line.write`, the following logic runs:
```python
if not self.env.context.get('skip_analytic_sync'):
self.filtered(lambda l: l.parent_state == 'draft').analytic_line_ids.with_context(skip_analytic_sync=True).unlink()
```
At this point, analytic lines were already created, but since the parent move is still in draft, they get incorrectly unlinked. This leads to posted vendor bills without analytic items.
**Fix**
Introduce a posting_move context flag when posting moves. Skip the unlinking of analytic lines if the move is in the process of posting (context.get('posting_move')). This prevents the accidental removal of freshly created analytic lines.
Opw-5053179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents Odoo from crashing when Documents references activities linked to records that have since been deleted, such as CRM leads. It improves reliability by handling missing records correctly instead of showing an error to users.
Original PR description
**Steps to reproduce:**
- Install `crm` and `documents`
- Go to CRM → Activity Types
- Set a 'folder' in the `Upload Document` activity
- Create a CRM lead and schedule an upload document activity
- Delete the created lead
- Open the Documents module
**Issue:**
- A `traceback` occurs because web_read tries to access all active records by `values_by_id[record.id]`, but some records are missing from values_list after `read_format` method filters out records with missing values.
- https://github.com/odoo/odoo/blob/3c62ca1eb96d571b2b686b5caee370324c589ab4/odoo/models.py#L3347-L3356
**Solution:**
- Use values_by_id.get(record.id, {}) to safely fetch values and avoid the KeyError.
opw-5080182The customer preview for shared projects now matches what portal customers actually see. When billing is based only on validated timesheets, draft or unapproved timesheets are no longer shown in the preview, reducing confusion and preventing misleading customer-facing information.
Original PR description
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is…
### Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. #### To reproduce: 1- Create a db with sale_project and sale_timesheet_enterprise 2- Configure invoicing policy to validated timesheets only 3- Create a service product: - Create on Order: Project & Task - Invoicing policy: Based on Timesheets 4- Create a Quotation for the product and confirm it 5- Open project from smart button 6- Share project with a portal user with Edit access 7- Open tasks, and add two timesheets to the task 8- Open timesheet app, and validate one of the timesheets 9- From project page, click on Customer preview 10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown. ### Cause: The timesheets are filtered here to only show validated timesheets: https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91 However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered. To fix that we can add a context in sharing project action and use it as a check to filter timesheets. opw-5093339
This fix restores a missing dependency needed for NACHA payment processing. Users can once again see and select the bank account field when preparing NACHA payments, preventing payment setup issues.
Original PR description
Accidentally removed in a061a2b82a967ca2 which caused the bank account selection field to not show when doing a NACHA payment. (Found when working on task 5052996)
This change prevents certain valid PDF font names from being corrupted when Odoo adds or rewrites PDF content. It helps avoid PDF generation failures for documents using fonts with special characters in their names.
Original PR description
Patch the following commit locally: https://github.com/py-pdf/pypdf/commit/8c542f331828c5839fda48442d89b8ac5d3984ac Issue: A PDF files contain `/FontName /TimesNewRomanGreek#5Bbold#5D`. While this is…
Patch the following commit locally: https://github.com/py-pdf/pypdf/commit/8c542f331828c5839fda48442d89b8ac5d3984ac Issue: A PDF files contain `/FontName /TimesNewRomanGreek#5Bbold#5D`. While this is a valid font descriptor, it gets converted to `/FontName /TimesNewRomanGreek[bold]` in `NameObject.read_from_stream` through `unhexlify` (see the complete call stack below) The converted value is not longer valid as `[` marks the start of a `ArrayObject`. The character should have been escaped back to `#5B` before being written in a new document. ```python /home/odoo/git/odoo/odoo/addons/account/models/ir_actions_report.py(37)_render_qweb_pdf_prepare_streams() -> stream = pdf.add_banner(stream, record.name or '', logo=True) /home/odoo/git/odoo/odoo/odoo/tools/pdf/__init__.py(288)add_banner() -> new_pdf.write(output) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(935)write() -> self.write_stream(stream) /home/odoo/git/odoo/odoo/odoo/tools/pdf/__init__.py(127)write_stream() -> super().write_stream(*args, **kwargs) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(908)write_stream() -> self._sweep_indirect_references(self._root) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(1057)_sweep_indirect_references() -> data = self._resolve_indirect_object(data) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(1102)_resolve_indirect_object() -> real_obj = data.pdf.get_object(data) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_reader.py(1256)get_object() -> retval = read_object(self.stream, self) # type: ignore /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(841)read_object() -> return DictionaryObject.read_from_stream(stream, pdf, forced_encoding) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(270)read_from_stream() -> value = read_object(stream, pdf, forced_encoding) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(834)read_object() -> return NameObject.read_from_stream(stream, pdf) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_base.py(469)read_from_stream() -> name = NameObject.unnumber(name) > /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_base.py(450)unnumber() -> while i >= 0: ``` opw-4991601
Fixed an issue in the German POS certification flow that could prevent a point-of-sale session from closing when an order included products without taxes. Tax-free order lines are now treated as 0% tax for Fiskaly reporting, helping affected businesses complete session closing normally.
Original PR description
Steps to reproduce: ------------------------- - Install the German localization with the POS module. - Register the company to fiskaly. - Create an order that includes a product with no taxes. - Attempt to close the POS session. Issue: ------- - There will be a traceback and session cannot be closed. Cause: --------- - While sending data to Fiskaly, the code references `l.tax_ids[0].amount`so If a line has no tax, this results in an error because there is no handling for an empty tax list. Fix: ----- - If a line has no tax, treat it as a 0% tax and fetch the corresponding `vat_definition_export_id` accordingly. opw- 5145258
This fixes an accounting calculation issue where distributed adjustment amounts could be matched to the wrong tax factors because their ordering no longer aligned. The change helps ensure tax-related rounding or delta amounts are applied consistently and accurately.
Original PR description
Before this commit, the factors were sorted and the amounts_to_distribute were build according this order. However, almost all calls to this method is zipping target_factors with amounts_to_distribute and both are no longer in the same order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Starshipit shipping requests now include the city or suburb information required by some carriers. This prevents valid delivery services such as NZ Post Domestic from being unavailable during shipping method setup.
Original PR description
Current behaviour: --- When using Starshipit, city is not included in the payload sent to the API. This causes an error for some delivery services. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method (using Starshipit API key) 3. Set up only "NZ Post Domestic" in Starshipit portal. 4. Click on "Select a service linked to your starshipit account" 5. Error: There are no shipping services available Cause of the issue: --- Some delivery services (like NZ Post Domestic) require a city/suburb field. In Australia/New Zealand suburb is used in the city field. opw-5155401
This fix prevents the Point of Sale loyalty program from adding an unintended extra product when customers use quantity controls. It also restores the intended reward behavior so eligible items are correctly discounted or made free according to the loyalty program rules.
Original PR description
After commit https://github.com/odoo/odoo/commit/b86dd8f0674f02a14f4aaa10db39bd4a1e8270f1, an extra order line could be added unintentionally. For example, in a "Buy X Get Y" loyalty program, if you add the product and press 3x on the numpad, the system would incorrectly add 3x + 1 products to the order. Moreover, the fix introduced in the above commit was not correct according to the program logic. For instance, if the configuration is set to "Grant: 1 credit per order" with a minimum quantity of 2, and the reward is for one point, then when ordering 2 products, one of them should indeed be free. The previous fix changed this intended behavior, resulting in incorrect reward application. opw-5151979 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users from opening the WIP accounting wizard while a manufacturing work order is still running. It ensures ongoing work orders without an end time are handled safely when production costs are calculated.
Original PR description
#### Issue: - Traceback when calculating the cost of a workorder #### Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post…
#### Issue: - Traceback when calculating the cost of a workorder #### Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" #### Current Behavior: - get a traceback #### Expected behaviour - open the WIP wizard #### Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. #### Solution: - check if the end date of the WO is defined In module mrp_workorder an override of [button_start](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L284-L295) change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Posting a work-in-progress accounting entry now works even when a manufacturing work order is still in progress. This prevents an error and lets users open the WIP wizard as expected, improving reliability for manufacturing accounting workflows.
Original PR description
Issue: - Traceback when calculating the cost of a workorder Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" Current Behavior: - get a traceback Expected behaviour - open the WIP wizard Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. Solution: - check if the end date of the WO is defined Test: - in module mrp_workorder an override of button_start change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873
Customers paying overdue invoices through the portal now see and pay only the remaining balance due, not the original invoice total. This prevents accidental overpayments when an invoice has already been partially paid and ensures related payment records use the correct amount.
Original PR description
Issue: When customer pays overdue amount from the portal, it shows the total amount of the overdue invoices. However, if overdue invoices are partially paid then the customer of the invoices would be overpaying. Purpose of this PR: We should display the residual amount of the overdue invoices so that when the transaction and payment records are created, they are created with the residual amounts of the overdue invoices and not the total amount of invoices. Steps to Reproduce on Runbot: create an invoice for Joel Willis that is overdue. partially pay for the invoice. go to the portal view with Joel Willis logged in and click 'Pay Overdue' the amount shown at the top and the corresponding transaction and payment records will have the total amount of the invoice. opw-4745031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where employee time off balances could be recalculated differently from the original approved duration, leading to incorrect remaining balances. The change restores the previous behavior so leave balances remain accurate and consistent for HR users and employees.
Original PR description
The commit [2d536ae](https://github.com/odoo/odoo/commit/2d536ae02d75d15fa81efa03c54d8ea5fde39902) changed the duration compute for leaves balances, recomputing from scratch the duration and sometimes giving off results different than the original duration, giving off a wrong balance This commit reverts it.
Fixed an issue in the Point of Sale where clicking details inside an order line could open and immediately close the numpad. Cashiers can now select order line details, such as eWallet balance information, without the numpad disappearing unexpectedly.
Original PR description
Steps to reproduce: =================== - Click on an orderline - Then click on a detail inside it (e.g., eWallet Balance line) - The numpad first opens and then closes right away Issue: ====== - Clicking on a detail inside the orderline makes the numpad open and close at the same time - This makes it impossible to use the numpad properly Cause: ====== - The click from the child element also reaches the main orderline click - Because of this, the numpad gets two clicks (open and close) Fix: ==== - Added `stopPropagation` in the click handler to block event bubbling - Now the numpad only reacts once and stays open as expected Task: 5000327
This fix ensures manually entered tax amounts in foreign currencies are converted correctly when company-currency values are not provided. It helps keep accounting and point-of-sale tax totals accurate in multi-currency transactions.
Original PR description
The 'manual_tax_amounts' were not well managed in the aggregators when the amount expressed in foreign currency was specified but not the amounts expressed in company currency. In that case, we were taking the raw amount instead of the rate applied on the manual amount in foreign currency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where partially paid subscription upsell orders could show a down payment invoice amount as zero. Businesses now see the correct invoiced amount after partial online payments, improving billing accuracy and customer transparency.
Original PR description
Version- 17.0 ### Issue: - When an upsell order is partially paid (e.g., 10% of the original amount), the generated downpayment invoice incorrectly displayed an invoiced amount of 0. ### Steps to reproduce: - Make an Upsell order of subscription. - Update the condition of Online Payment from 100% to 10% (in this case). - Make the payment of 10% from portal view. - The invoice amount will be shown as $0. ### Fix: - Updated `_prepare_invoice_line` to correctly assign the value of `qty_to_invoice` in the case of downpayment of upsell invoice. ### Impact: - The downpayment invoices for upsell orders now correctly reflect the actual invoiced amount. Forward-Port-Of: odoo/enterprise#96719
Fixes an issue where delivery shipping labels and documents might not print automatically after validating a delivery, especially when only one device was connected. The validation flow now includes those print actions directly, making warehouse and delivery operations more reliable.
Original PR description
The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads. This reload makes our broadcasted action not to be caught by the client if there is only one connected. Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it. Forward-Port-Of: odoo/enterprise#97462