Wednesday, March 18, 2026
5 changes · saas-18.4
New functionality added to Odoo
This update introduces a new report for Polish businesses that still need to generate JPK_FA XML reports even when using the KSeF online invoicing platform. This report ensures compliance with Polish tax regulations by listing invoices and lines not yet validated by KSeF, aligning with JPK-FA(4) standards.
Original PR description
In Poland, if a business chooses to keep B2C invoicing outside of KSeF (online platform), the JPK_FA obligation remains. It is a XML report that lists all the invoices and the invoice lines that have not been validated by KSeF during a desired period of time. The report follows the JPK-FA(4) norms. task-5166047 Forward-Port-Of: odoo/enterprise#103000
Resolved issues and error corrections
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
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
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…
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
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
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…
## 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