Tuesday, May 12, 2026
10 changes · saas-18.4
Resolved issues and error corrections
Sales users can now open project milestones created from milestone-based sales orders without seeing an access error. This keeps project follow-up smoother by ensuring milestone quantities can be calculated even when related sales order details are restricted.
Original PR description
Steps to reproduce: - Install the sale_project module - Create a sale order based on milestones - Create the project from the order - Open the project, click the three dots, and open a milestone Issue: Users are unable to open milestones and get an access error. Cause: Users in `sales_team.group_sale_salesman` lack read access to the related `sale.order.line`, causing an AccessError when `sale_line_id` is accessed during the computation of `product_uom_qty`. Fix: Compute `product_uom_qty` using `sudo()` to bypass record rule restrictions. task-5477304 Forward-Port-Of: odoo/odoo#263331 Forward-Port-Of: odoo/odoo#245392
New delivery batches created from the Barcode app now receive the expected batch reference instead of staying named "New". This makes batch records easier to identify and prevents confusion in warehouse operations.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to ``BATCH/<TYPE>/000NN``.
The barcode kanban "New" button calls ``open_new_batch_picking``, which
runs ``Batch.create({})`` while the action context carries
``default_picking_type_id`` (set by ``stock.picking.type._get_action``
at https://github.com/odoo/odoo/blob/4a632f57c51ed27aff534c215e479009ea21a414/addons/stock/models/stock_picking.py#L432).
Since ``vals`` doesn't carry ``picking_type_id``,
``self.env['stock.picking.type'].browse(vals.get('picking_type_id'))``
at https://github.com/odoo/odoo/blob/4a632f57c51ed27aff534c215e479009ea21a414/addons/stock_picking_batch/models/stock_picking_batch.py#L181
is an empty recordset, so the rename branch is skipped and the name
falls through to the field default ``'New'`` -- even though
``super().create`` then applies the context default and the batch
ends up correctly linked to a picking type.
opw-6168320The accounting logic now avoids wrongly applying an intra-EU tax position when a customer has a Dutch VAT number but a different main country and a Dutch delivery address. This helps sales orders use the correct domestic fiscal position, reducing tax classification errors.
Original PR description
With l10n_nl: - Set the fiscal positions in this order: 1. Domestic 2. EU Intra B2B - Create a contact with: - German address - Dutch delivery address - Dutch VAT - Create a second contact with: - German address - Dutch delivery address - No VAT - Create a Sales Order for each contact: - For the first contact, the applied fiscal position is EU Intra B2B - For the second contact, the applied fiscal position is Domestic The detected fiscal position should be Domestic in both cases In _get_fiscal_position vat_exclusion is computed using the VAT prefix of the partner and our company. But if the prefix of the VAT does not match the country of the partner, it's delivery address will still be overriden. opw-5892138 Forward-Port-Of: odoo/odoo#258899
Fixed an issue where adding a project to a purchase order could cause later order lines to lose the product’s predefined analytic distribution. This helps ensure purchase costs remain allocated correctly across both the selected project and the product’s accounting rules.
Original PR description
__ ## Short functional explanation of the error When creating a Purchase Order. We add a line containing a product that has an analytic distribution. After setting a project on this PO, when we add…
__ ## Short functional explanation of the error When creating a Purchase Order. We add a line containing a product that has an analytic distribution. After setting a project on this PO, when we add another line containing the same product, the analytic distribution of the product isn't added anymore, only leaving it with the analytic distribution of the project. ## Reproduction Steps 1. Go to settings and enable Analytic Accounting. 2. Go to Accounting > Configuration > Analytic Distribution model. Create a model with a product (prd) you remember, and add an analytic distribution (ad). 3. Go to Project. On a given project (p), select the Hamburger menu and click Settings. Then, in the Settings tab, under Analytic, make sure the Project field is filled. 4. Create a new Purchase Order. Select a vendor and add a line with the product (prd). On the top right of the Form, click on the view button and select Analytic Distribution to show it on the form. There, we should see the product (prd) with its corresponding Analytic Distribution (ad) on the form. 5. Click on the Other Information tab and select the project (p). Click on the Product tab. There, under Analytic Distribution field, you should see (ad) and the Analytic Distribution of the project (p). 6. Click on save and add another line with the exact same product. ### Expected behavior Under Analytic Distribution, we should see (ad) and the Analytic Distribution of the project (p), as for the first order line ### Unexpected behavior Under Analytic Distribution, we only see the Analytic Distribution of the project (p). ## Origin of the issue When we add another line, we trigger the compute method of the Analytic Distribution. However, due to this piece of code: https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/project_purchase/models/purchase_order_line.py#L14 when we create a new order line, we never compute its analytic distribution: `self` will contain only `project_lines`, and `empty_project_lines` is empty as well. Therefore, we call the super method with nothing, so when we get in the super method: https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/purchase/models/purchase_order_line.py#L249-L259 we never compute the analytic distribution of the newly created line. This piece of code was added in this commit: https://github.com/odoo/odoo/commit/c1ea8446259bd3338c004e88d48ad77ded7ef2ae to fix the issue that when a user enters manually an analytic distribution, this entry will be lost when triggering the compute of the analytic distribution. However, due to the agency of the code, we cannot prevent losing *both* manually added analytic distributions and product analytic distribution. After consulting the product owner, we concluded that there was no perfect solution in this case, but we'd rather keep the product analytic distribution, as it is much harder to add it again after its removal. Therefore, this commit reverts the previously mentioned commit, while keeping the refactor it introduced. __ opw-6063418 Forward-Port-Of: odoo/odoo#257558
Odoo now generates Peppol invoice files correctly when an invoice uses the out-of-scope tax category. This prevents validation failures for businesses issuing invoices for items or services that are outside VAT scope.
Original PR description
**PROBLEM** In peppol, there is a tax category 'O-service out of tax scope'. This tax category is used when what is invoice can't be tax (out of the tax scope). This is different from tax exemption: when using tax category O, there can't be any vat id on the invoice. This also means you can't use tax category O with other taxes, since other taxes need the vat id. Invoices generated by odoo with tax category O failed peppol validation. **STEP TO REPRODUCE** 1. install account_edi_ubl_cii_tax_extension. 2. Create a tax with tax category O. 3. Create an invoice and try validating using the file validator. 4. You should have error BR-O-02 and BR-O-05. opw-6012669 Forward-Port-Of: odoo/odoo#254645
The product margin report now uses net invoice amounts when calculating average sale prices, so tax-inclusive and tax-exclusive invoices are handled consistently. This prevents margins from being overstated or understated when products are sold with different tax configurations.
Original PR description
The price_unit of a account.move.line can be with or without tax. The sale_avg_price should be either incl. or excl. tax. To ensure the avg price is always excl. tax the price_subtotal can be used. Forward-Port-Of: odoo/odoo#226994 Forward-Port-Of: odoo/odoo#199209
Fixed an issue where creating an invoice after using a date filter could incorrectly exclude timesheet-based service lines from later invoices. This ensures sales orders with timesheeted work show the correct invoiceable items every time an invoice is created.
Original PR description
Steps --------- 1. Install Accounting, Sale and Timesheet 2. Create 2 product a. Product A - storable - invoiced on Ordered Quantity b. Product B - service - create a task on order - invoice on…
Steps
---------
1. Install Accounting, Sale and Timesheet
2. Create 2 product
a. Product A - storable - invoiced on Ordered Quantity
b. Product B - service - create a task on order - invoice on
timesheeted
3. Create an SO with 3 product A and 3 product B
4. Add a timesheet line for 1 hour of product A - can be done thanks to
the button appearing on the SO at confirmation
5. Create Invoice
6. Don't add dates to the wizard and confirm -> Both product appear
7. Add date range that do NOT include the timesheeted lines -> Only the
storable product appear
8. Repeat step 6 -> Only the storable product appear
Problem
---------
During the creation of the invoice, the invoiceable lines would get
computed dates where provided to the wizard
(`sale.order.line.qty_to_invoice`). When no dates were provided, we
would not manually trigger the invoiceable lines recomputation and were
relying one the data store in cache.
Solution
---------
Force the invoiceable quantity recomputation upon each invoice creation.
opw-6001094
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261062This update fixes an issue where partners sharing the same VAT number, but with individual turnovers below €250, were incorrectly excluded from VAT reports. The change groups partners by VAT number and includes them in the report if their combined turnover exceeds the threshold, ensuring accurate reporting of VAT obligations.
Original PR description
When having different partners with the same vat number and their individual turnover values are less than the threshold they were not included in the partner vat listing report even though if the total turnover for their vat number is above the threshold. This commit handles this case by grouping by vat number and if the total turnover for a vat number is above the threshold then it will be shown in the report with another level beneath it to show the partners having this vat number even if their individual turnovers are below the threshold. task-6133010 Forward-Port-Of: odoo/enterprise#116495 Forward-Port-Of: odoo/enterprise#115251
This update fixes an issue where the project timesheet forecast report incorrectly included public holidays from other companies, leading to inaccurate planned hour calculations. The fix ensures that only public holidays related to the specific company creating the planning slot are considered, improving forecast accuracy and reporting.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070 Forward-Port-Of: odoo/enterprise#116263
This update fixes an issue where importing changes to a sold subscription product bypassed a necessary warning. Now, when a product's subscription type is altered via import, a warning is automatically displayed, preventing unintended modifications to existing sales records. This ensures data integrity and prevents incorrect subscription settings.
Original PR description
__ ## Short functional explanation of the error When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription…
__ ## Short functional explanation of the error When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior: when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised. ## Reproduction Steps Make sure you have debug mode enabled. 1. Create a product, and check the Subscription box. 2. Click on Orders and create a Quotation with this product, then confirm. 3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export. 4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded. 5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes. 6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import. ### Expected behavior A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold. ### Unexpected behavior The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised. ## Origin of the issue Nothing prevents the import from occurring in that case. __ opw-6143789 Forward-Port-Of: odoo/enterprise#116922 Forward-Port-Of: odoo/enterprise#115046