Wednesday, September 17, 2025
13 changes · saas-18.4
Resolved issues and error corrections
EU OSS taxes now receive the correct Spanish tax classification when tax mappings are refreshed. This helps businesses using Spanish localization report cross-border distance sales correctly and reduces the risk of inaccurate tax records.
Original PR description
The EU OSS taxes were generated with the wrong l10n_es_type. - Install l10n_es and l10n_eu_oss. Then go to Settings and refresh the tax mapping in “EU Intra-community Distance Selling.” - In Taxes, filter by tax group containing “OSS.” All OSS taxes appear with l10n_es_type = sujeto. This is incorrect. The correct type should be “No Sujeto por reglas de localización” (see section 2): https://a3responde.wolterskluwer.com/es/s/article/version-3-05-del-moduloticketbai-batuz-de-a3erp-mejoras#OSS This commit adds the possibility of adding country specific field during the account_tax creation using chart_template -> fields mapping. opw-5009180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227238 Forward-Port-Of: odoo/odoo#224192
The Sign app now lets users drag and place fields correctly when several documents are uploaded at the same time. This removes a workflow blocker for preparing multi-document signature requests and helps users complete signing setup without interruption.
Original PR description
Version: - saas-18.3 Steps to reproduce: - install sign - upload multiple documents - try to drag the field Issue: - Fields cannot be dragged when multiple documents are uploaded. Solution: - update the condition to check if !acive then return no need to preventdefault. Impact: - Users can now upload multiple documents and drag/drop fields without issues. Forward-Port-Of: odoo/enterprise#94882
Subscription invoices that include combo products can now be created and confirmed without triggering an accounting error. This prevents failed invoice generation both when users create invoices manually and when automatic payment processing creates them in the background.
Original PR description
Currently, an error is produced while creating an invoice for a subscription order with combo products, and it can be triggered in two different ways. 1. Directly create an invoice. - Create and…
Currently, an error is produced while creating an invoice for a subscription order
with combo products, and it can be triggered in two different ways.
1. Directly create an invoice.
- Create and confirm a subscription with a combo product.
- Create an invoice for this subscription and try to confirm it.
- Validation error shown in display and error generated in log
2. When cron "Payment: Post-process transactions" trigger:
- Enable the Automatic Invoice option in the Subscription settings.
- Activate a demo payment provider (e.g. Demo: Payment Provider).
- Create and confirm a subscription that includes a combo product.
- Click on "Pay" to process the subscription payment.
- An error occurs when the above-mentioned cron is triggered, and it
tries to create an invoice for a subscription order.
Error: `new row for relation "account_move_line" violates check constraint
"account_move_line_check_accountable_....`
This issue arises during the creation of an account move line for deferred entries for
the 'Combo Product' column of the original invoice (subscription):
- At [1], `deferred_start_date` and `deferred_end_date` were added to all invoice line values within `_prepare_invoice_line` used to create the original invoice
- Then, at [2], during confirmation of the `original invoice`, the code attempts to generate `deferred entries` for for move where any move lines that has a `deferred_start_date`
- At code line [3], during the generation of deferred entries, an account move line is created without an associated `account_id`
- During `display_type` computation at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L480-L484), `line.move_id.is_invoice()` evaluates to `False`. As a result, the line is assigned a `display_type` as a 'product'.
- Since `display_type` is 'product' and `account_id` is missing, it violates the following check constraint at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L451): `CHECK(display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL)`
This commit fixes the issue by preventing the addition of the `deferred_start_date` and `deferred_end_date` keys for invoice lines whose corresponding sale order lines have products of type 'combo' at [1].
[1]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/sale_subscription/models/sale_order_line.py#L448-L449
[2]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L113-L114
[3]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L309
sentry-6763423503
Forward-Port-Of: odoo/enterprise#90989Purchase order lines no longer allow users to create new units of measure directly from the order form. This prevents confirmation errors when a newly created unit is later deleted, improving reliability for purchase workflows.
Original PR description
When users create a new UoM from order lines, and after deleting the newly created UoM, they try to confirm the order. Steps to reproduce: --- - Install `purchase_stock` module - Create a New PO - Add an order line -> Remove its `Unit` and create a New one - Delete newly created UoM from `Units & Packagings` - Now Confirm Order Traceback: --- - `ValueError: Expected singleton: uom.uom()` - `ZeroDivisionError: float division by zero` This error occurs because, after deleting the newly created UoM, the `product_uom_id` becomes empty, which leads to errors in multiple lines. Solution: --- We are restricting users from creating a UoM from purchase order lines, as already done in other modules (e.g., stock, account, …). sentry-6746792383, 6853969554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225475
This fix prevents certain business-critical attachments from being moved to external cloud storage when those files are needed directly by Odoo processes. It helps avoid issues in workflows such as invoicing or expense reporting where attached data is used to generate documents or reports.
Original PR description
some models use attachments for data for business logics for example, ``account_move.message_main_attachment_id.datas`` ``hr_expense_sheet`` will use all bounded attachments to generate report This commit prevents uploading attachments to cloud storage for some models if they ``_inherit`` or ``_inherits`` model ``mail.thread.main.attachment`` This PR is also a supplement for https://github.com/odoo/odoo/pull/226094 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 Forward-Port-Of: odoo/odoo#227165
Ecuadorian vendor bill uploads now correctly read invoice XML files downloaded from the SRI when they are wrapped in CDATA. This lets Odoo populate bill details automatically instead of leaving the form empty.
Original PR description
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill…
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill the vendor bill form view. #### Steps to reproduce: - Install "l10n_ec_edi" and switch to an Ecuadorian company - Have a file downloaded from the SRI. - Go to Accounting > Vendor > Bills - Click "Upload" and select the file - The generated move is not populated with the data ### Cause: We are expecting the XML to not be in the tag `CDATA` and it gets ignored. ### Solution: The change is in `_get_import_file_type` to detect the new type of file as `'l10n_ec.factura'`. The CDATA content can be fetched by getting the content of the tag `comprobante`. We then try to convert the content of `comprobante` to XML. If it's possible, we have an XML on which we can do the same check as before to know if it's an Ecuadorian invoice. We then replace the `file_data['xml_tree']` by the content of `CDATA` to have the correct XML for the data extraction. opw-5004636
The purchase product catalog now keeps the unit of measure shown to buyers aligned with the unit used when creating purchase order lines. This prevents accidental ordering of vendor packs when the buyer selected individual units, improving purchase accuracy and reducing correction work.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: unit
- Purchase tab:
- Vendor: Azure interior
- UoM: Pack of 6
- Create a purchase order:
- Vendor: Azure interior
- Click the Catalog button:
- Select 1 unit of P1 (note: UoM cannot be changed in the catalog)
Problem:
The purchase order line is created, but with 1 pack of 6 instead of 1 unit
Fix:
Ensure the selected product quantity and UoM from the catalog are correctly applied to the PO line.
Opw-4794362
Forward-Port-Of: odoo/odoo#226647
Forward-Port-Of: odoo/odoo#224231This fix prevents an error when users log time on projects that are shared across multiple companies. It ensures the correct current company is used when no company is set on the project, so employees with access to multiple companies can record timesheets normally.
Original PR description
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without…
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without setting a company (making it a global project). 5. Enable both companies in the systray 6. Try to log a timesheet on the global project. issue: ------ A ValidationError is raised: "Timesheets must be created with an active employee in the selected companies." cause: ------ During `vals_list` preparation, the `company_id` value is overwritten here: https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/hr_timesheet/models/hr_timesheet.py#L381 If the project has no company set, `company_id `becomes **False**. This condition fails if the user has two employees and no company set (or if it is missing): https://github.com/odoo/odoo/blob/d3c7e51e94d98da9086a3817b157c4e125c80790/addons/hr_timesheet/models/hr_timesheet.py#L211-L215 solution: --------- Use `self.env.company` if company_id is missing(or False) in the vals. opw-4892449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227268 Forward-Port-Of: odoo/odoo#223846
When an employee's check-in or check-out time is edited, Odoo now recalculates extra hours unless the user has explicitly changed that value. This prevents incorrect zero extra hours and keeps attendance records aligned with actual worked time.
Original PR description
**Steps to reproduce** - Automatically approved attendances. - Create an attendance and save it. - Note the "Extra hours" displayed. - From the form view, change the check in or check out and save…
**Steps to reproduce** - Automatically approved attendances. - Create an attendance and save it. - Note the "Extra hours" displayed. - From the form view, change the check in or check out and save it. - Issue: "Extra hours" are 0. Expected: they should be the same as "Worked extra hours", as the user has not manually modified the field. **Cause** Issue since cc81bb59f87540cf4dd8da65510417d8023ef65b The problem is that a 0 value for `overtime_hours` was computed for the `NewId` record used during edition in the interface. This meant `validated_overtime_hours` was also set to this value https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L171 and sent on save, which meant the value was not further recomputed in `_update_overtime`. https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L408 **Change** We avoid a recomputation of `validated_overtime_hours` in the interface (which wasn't useful anyway, it was set to 0) to avoid it being interpreted as a manual change by the user. opw-5003488 Forward-Port-Of: odoo/odoo#226393 Forward-Port-Of: odoo/odoo#222689
Creating a project from a template now assigns the right users to parent and child tasks based on the intended role mapping. This prevents users from being placed on the wrong tasks, improving data accuracy when teams start new projects from templates.
Original PR description
Before this commit, when we created a project from a template with task with subtask, the mapping of the role/user was not correctly applied. This lead to inconsistent data at the project creation such as setting users on the child tasks randomly instead of correctly setting it on the parent task Source of the issue: We wrongly assumed that the task order of the project copied was the same as the original project and thus used the original project task's list in order to set the user on the copied tasks. Solution: Keep the role_ids on the copied tasks and use that data to set the correct user using the wizard mapping. The role_ids are set to False once the data are correctly set. task-5094321
Customer invoices using European payment references can now be confirmed even when a journal sequence includes non-alphanumeric characters such as hyphens. This prevents an accounting configuration from causing invoice confirmation errors and improves reliability for affected businesses.
Original PR description
Currently, an error occurs when confirming a customer invoice that uses a journal with an invalid configuration. **Steps to Reproduce:** 1) Install Accounting app.(with Demo) 2) Navigate to…
Currently, an error occurs when confirming a customer invoice that uses a journal with an invalid configuration. **Steps to Reproduce:** 1) Install Accounting app.(with Demo) 2) Navigate to Accounting>Configuration>Journals 3) Open existing 'Sales' journal and make following changes: - set Sequence Prefix: INV- - In the Advanced Settings Page, set 'Communication Standard' as 'European' and save the journal. 4) Create a Customer Invoice with this Sales Journal and click on `Confirm`. **Error :** `ValueError: invalid literal for int() with base 36: '-'` **Root Cause:** Since [this commit](https://github.com/odoo/odoo/pull/212169/commits/e4a09467a20f282d28baa09091c10a6aea6d0094#diff-cc13d9842e166c12738b659e0478ceb8b1b15734442c1e090252919e7efb6ed7), On following above steps, The value of 'number' received at [1] looks like 'INV-000003' due to which on further computation of this value at [1] causing an error. **Fix:** prevent crash by adding a additional check on methods `_get_invoice_reference_euro_invoice` and `_get_invoice_reference_euro_partner` to validate the journal's short code. [1]- https://github.com/odoo/odoo/blob/2646790e7e31b4c600e39f2d5c87f0744b1578b0/addons/account/tools/structured_reference.py#L20-L26 **sentry-6860586611** Forward-Port-Of: odoo/odoo#225987
PDF reports for vendor bills and expense sheets now correctly retrieve files stored as remote links or cloud resources before generating the report. This prevents report failures when businesses use external or cloud-based attachments, improving reliability for accounting and expense workflows.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments,…
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports - `account.report_original_vendor_bill` - Vendor bill reports - `hr_expense.report_expense_sheet` - Expense sheet reports ### Affected Versions - 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense) ### Reproduction Steps #### Option A: HR Expense Report 1. Create HR expense record 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to hr.expense record 4. Generate expense report → TypeError occurs #### Option B: Vendor Bill Report 1. Create vendor bill (account.move) 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to account.move record 4. Print Original Vendor Bill → TypeError occurs ### Error Details ```python TypeError: a bytes-like object is required, not 'bool' at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream from /odoo/addons/hr_expense/models/ir_actions_report.py:29 ``` #### Reference Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view OPW-5036638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227571 Forward-Port-Of: odoo/odoo#226094
Follow-up PDF reports now handle attachments stored as remote links or in cloud storage by retrieving them before generating the report. This prevents report failures and helps users consistently produce customer follow-up documents regardless of where attachments are stored.
Original PR description
### Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The to_pdf_stream() method expects local file data but receives boolean values from remote attachments, causing a TypeError. ### Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. ### Affected Reports (enterprise): - account_followup.report_followup_print_all [Community PR](https://github.com/odoo/odoo/pull/226094) OPW-5036638 Forward-Port-Of: odoo/enterprise#94975 Forward-Port-Of: odoo/enterprise#94477