Odoo Changelog — 2026-03-18

Wednesday, March 18, 2026

10 changes · saas-18.4

Bug Fixes(10)

Resolved issues and error corrections

[FIX] pos_sale: add downpayment product in sol

Coresaas-18.4pos_saleMedium

Point of Sale down payments for draft sales orders now correctly include the configured down payment product on the related sales order line. This ensures the payment is recognized properly when reviewing or settling the sales order from the Point of Sale workflow.

Original PR description

Step to reproduce
- install pos_sale
- create a SO (make sure it is in draft)
- open pos, make sure it has downpayment product
- do a downpayment for that SO
- go to backend, open SO

Observation:
- The downpayment product is not linked to downpayment line

Cause:
- After refactor [1], downpayment product is not added in sale line
[1] https://github.com/odoo/odoo/commit/175daa5db6a3f16be6b636a36e2b8462306b2eb4

Fix:
- Added the product when creating downpayment line

**Note:**
- Actual issue reported was different, and was side effect of this issue
- there, the downpayment was not considered when trying to settle SO from pos

opw-5934461

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#250548

#point-of-sale#sales-orders#down-payments

[FIX] account_peppol: selfbilling added by default

PR #254488

Coresaas-18.4account_peppolaccount_peppol_selfbillingMedium

Companies can now receive self-billing invoices through the base Peppol accounting module without installing an extra add-on. The change also removes xRechnung receiving from the default services because it is intended for government recipients only.

Original PR description

Everybody is now able to receive self billing invoices even without the additional module.
So the service should be added to the base module.

Also remove xRechung because users are not supposed to receive it, only government.




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#254341

#peppol#self-billing#invoicing

[FIX] sale_timesheet: prevent invoicing for already invoiced timesheet

PR #251711

Coresaas-18.4sale_timesheetMedium

This fix stops Odoo from creating new invoices for timesheet hours that have already been invoiced. It helps businesses avoid accidental duplicate customer billing and repeated invoice corrections when using timesheet-based sales.

Original PR description

__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet…

## Short functional explanation of the error
When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month.
In the wizard, we set the timesheet period from the first to the last day of last month.
Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter.

## Reproduction Steps
1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded.
2. Record 2 hours with a random date for last month.
3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form,
set the invoice date to last month (after the day on which you
recorded the timesheet hours) and confirm.
4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month.
5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`.
6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February.
7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm.

### Expected behavior
The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced.

### Unexpected behavior
An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal).

## Origin of the issue
When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet.

__
opw-5426434

Forward-Port-Of: odoo/odoo#250946

[FIX] sale_stock_margin: incorrect company on _compute_average_price

PR #254467

Coresaas-18.4sale_stock_marginMedium

This fixes a multi-company issue where sales margins could use the wrong company's costing method when confirming a sales order. Margins now use the company linked to the sales order line, helping ensure more accurate profitability figures across companies.

Original PR description

Steps to reproduce:
- Have 2 companies:
	- Company A with a property_cost_method 'average'
	- Company B with a property_cost_method 'standard'
- Create a sales order in B
- Set the default company of the user to A.
- Under certain scenarios, when we confirm the sales order, there will be a `flush_all`.
- When that's the case, margins are recomputed with `line.product_id.categ_id.property_cost_method` as `average` instead of `standard`.
In other words, it will take the property_cost_method from the `user.company_id` (A), instead of the property_cost_method from the `line.company_id` (B).

This fix ensures the `property_cost_method` considered is the one related to the company of the sale order line.

A similar issue was fixed on https://github.com/odoo/odoo/pull/192890

OPW-5939464

Forward-Port-Of: odoo/odoo#253764
Forward-Port-Of: odoo/odoo#252161

#multi-company#sales margin#costing

[FIX] l10n_it_edi: update PA status after SDI validation

PR #254426

Coresaas-18.4l10n_it_ediMedium

This fixes Italian e-invoicing so invoices sent to Public Administration can still receive later status updates after SDI validation. Businesses will see invoice statuses that better reflect the actual outcome, including possible rejections after forwarding.

Original PR description

### Issue:
After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status

### Cause:
When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur
However, invoices sent to Public Administration can still be rejected after being forwarded

It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded`

Ticket [link](https://www.odoo.com/odoo/project.task/5391891)
opw-5391891

Forward-Port-Of: odoo/odoo#254406
Forward-Port-Of: odoo/odoo#253525

#italy#e-invoicing#public-administration#invoice-status

[FIX] html_builder, website: filter dropzones on snippet group click

PR #250613

Coresaas-18.4html_builderwebsiteMedium

This fixes an issue where selecting certain website content blocks, such as countdowns, could place them in the wrong area of a page. The website editor now limits available drop locations more accurately, making page building more predictable and reducing layout mistakes.

Original PR description

After https://github.com/odoo/odoo/pull/240547 was merged, an issue appeared with the snippets that could also be dropped as inner content. Instead of only having the dropzones for sections, all…

After https://github.com/odoo/odoo/pull/240547 was merged, an issue appeared with the snippets that could also be dropped as inner content. Instead of only having the dropzones for sections, all dropzones were activated, meaning that snippets such as countdown would sometimes be dropped as inner content.

Steps to reproduce the issue:
- Go to Website
- Go to Edit mode
- From an empty website, click on the snippet group "Content"
- Select the countdown
=> The countdown was dropped in the footer instead of the main

To fix this issue, this commit restores the missing filter (removed when the new builder was added). However, since the drag and drop was updated to only display dropzones of the "active" element, there is no need to filter the dropzones within #website_cookies_bar. Finally, the filter is no longer based on the s_popup snippet, as the drag and drop mechanic was moved outside of the website module.

This commit also partially reverts the commit 5cb4f5c, since it made the tour fail with the changes of this PR (s_banner snippets can no longer be dropped inside of the s_table_of_content)

The tour testing the Countdown was updated since it did not fail prior to saas-19.2, because it was not precise enough.

Related to task-5428387

[FIX] project_mrp_workcenter_account : Update AAL amount when employee change

PR #111027

Enterprisesaas-18.4mrp_workorder_accountMedium

This update fixes a bug where project timesheets didn't accurately reflect labor costs when changing the employee assigned to a manufacturing order. The fix automatically updates the AAL (analytic accounting line) linked to the work center, ensuring accurate timesheet calculations and reporting. This ensures project costs are correctly tracked.

Original PR description

### Steps to reproduce:
	- Create an MTO product and another Service product that create a project and task
	- Create a quotation with both products
	- Create two employees with different hourly cost
	- Go to Manufacturing order
	- Configure an employee to manufacture the product at a work station.
	- Observe the project dashboard
	- Go back to the MO and change the employee on the work station
	- Notice the project dashboard Timesheets section doesn't have any change on the amount

### Cause:
This is happening because when changing the employee we don't modify anything in the AAL linked to the
work station.
As we only modify the AAL when the duration change.

### Fix:
We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL.

opw-5939321

Forward-Port-Of: odoo/enterprise#109695

#timesheet#manufacturing#analytics

[FIX] sale_amazon: wrong fulfillment channel

PR #110772

Enterprisesaas-18.4sale_amazonMedium

This update fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The fix allows users to manually specify the fulfillment channel (FBA or FBM) for listings, resolving a known Amazon issue and improving order accuracy. This ensures correct inventory management and prevents revenue loss.

Original PR description

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

See also:
- https://github.com/odoo/upgrade/pull/9692

Forward-Port-Of: odoo/enterprise#106662

[FIX] social_push_notifications: fix various errors with push notifications

PR #111016

Enterprisesaas-18.4social_push_notificationsMedium

This update fixes a problem causing users to receive duplicate push notifications from Social Marketing. The fix ensures the Firebase SDK and service worker work together correctly, preventing redundant popup displays. It also resolves a subscription error, improving push notification reliability across browsers.

Original PR description

When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the…

When the user sends a push notification through Social Marketing, the application displays two notification popups because:

1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field.
2. Our service worker displays a notification popup when receiving a background message from Firebase.

To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us.

Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications.

To fix that issue, we will:
1. Ensure that the service worker reaches the `ready` state before communicating with it.
2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page.

Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers.

Task-5124645

Forward-Port-Of: odoo/enterprise#110823
Forward-Port-Of: odoo/enterprise#96029

[FIX] account-accountant: prevent wrong invert tag / rev amount

PR #110560

Enterprisesaas-18.4accountMedium

This update resolves an issue where tax calculations were incorrect during the reconciliation process for certain journal entries, specifically those involving reverse charges. The fix ensures that tax amounts are accurately reflected in the resulting accounting entries, improving data integrity and financial reporting. This impacts users utilizing the reconciliation feature with specific tax configurations.

Original PR description

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

Step to reproduce - install pos_sale - create a SO (make sure it is in draft) - open pos, make sure it has downpayment product - do a downpayment for that SO - go to backend, open SO Observation: - The downpayment product is not linked to downpayment line Cause: - After refactor [1], downpayment product is not added in sale line [1] https://github.com/odoo/odoo/commit/175daa5db6a3f16be6b636a36e2b8462306b2eb4 Fix: - Added the product when creating downpayment line **Note:** - Actual issue reported was different, and was side effect of this issue - there, the downpayment was not considered when trying to settle SO from pos opw-5934461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250548

Everybody is now able to receive self billing invoices even without the additional module. So the service should be added to the base module. Also remove xRechung because users are not supposed to receive it, only government. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254341

__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet period from the first to the last day of last month. Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter. ## Reproduction Steps 1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded. 2. Record 2 hours with a random date for last month. 3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form, set the invoice date to last month (after the day on which you recorded the timesheet hours) and confirm. 4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month. 5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`. 6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February. 7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm. ### Expected behavior The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced. ### Unexpected behavior An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal). ## Origin of the issue When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet. __ opw-5426434 Forward-Port-Of: odoo/odoo#250946

Steps to reproduce: - Have 2 companies: - Company A with a property_cost_method 'average' - Company B with a property_cost_method 'standard' - Create a sales order in B - Set the default company of the user to A. - Under certain scenarios, when we confirm the sales order, there will be a `flush_all`. - When that's the case, margins are recomputed with `line.product_id.categ_id.property_cost_method` as `average` instead of `standard`. In other words, it will take the property_cost_method from the `user.company_id` (A), instead of the property_cost_method from the `line.company_id` (B). This fix ensures the `property_cost_method` considered is the one related to the company of the sale order line. A similar issue was fixed on https://github.com/odoo/odoo/pull/192890 OPW-5939464 Forward-Port-Of: odoo/odoo#253764 Forward-Port-Of: odoo/odoo#252161

### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891 Forward-Port-Of: odoo/odoo#254406 Forward-Port-Of: odoo/odoo#253525

After https://github.com/odoo/odoo/pull/240547 was merged, an issue appeared with the snippets that could also be dropped as inner content. Instead of only having the dropzones for sections, all dropzones were activated, meaning that snippets such as countdown would sometimes be dropped as inner content. Steps to reproduce the issue: - Go to Website - Go to Edit mode - From an empty website, click on the snippet group "Content" - Select the countdown => The countdown was dropped in the footer instead of the main To fix this issue, this commit restores the missing filter (removed when the new builder was added). However, since the drag and drop was updated to only display dropzones of the "active" element, there is no need to filter the dropzones within #website_cookies_bar. Finally, the filter is no longer based on the s_popup snippet, as the drag and drop mechanic was moved outside of the website module. This commit also partially reverts the commit 5cb4f5c, since it made the tour fail with the changes of this PR (s_banner snippets can no longer be dropped inside of the s_table_of_content) The tour testing the Countdown was updated since it did not fail prior to saas-19.2, because it was not precise enough. Related to task-5428387

### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#109695

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662

When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field. 2. Our service worker displays a notification popup when receiving a background message from Firebase. To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us. Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications. To fix that issue, we will: 1. Ensure that the service worker reaches the `ready` state before communicating with it. 2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page. Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers. Task-5124645 Forward-Port-Of: odoo/enterprise#110823 Forward-Port-Of: odoo/enterprise#96029

## ISSUE 1: **Steps to reproduce [l10n_be easier]:** - Create a journal entry: ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 12% (purchase) - Validate - Check the last entry created **Issue:** There is no invert tag set on the tax line **Cause:** The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815 The line was never set to properly (same of is_refund) ## ISSUE2: **Steps to reproduce:** - create a journal entry ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 21% EU M (Purchases) - Validate - Check the last entry created **Issue:** No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0. opw-4976780 Forward-Port-Of: odoo/enterprise#93839 Forward-Port-Of: odoo/enterprise#92556