Thursday, March 19, 2026
19 changes · saas-19.1
New functionality added to Odoo
This update introduces a new report for Polish businesses to generate the JPK_FA XML report. This report is required for businesses choosing not to use the KSeF online platform for B2C invoicing, ensuring compliance with Polish tax regulations. It simplifies the process of fulfilling reporting obligations.
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
This update enables direct electronic invoicing for POS sales and returns in Colombia, streamlining the process for businesses. It adapts existing DIAN EDI functionality to work within the POS store, eliminating the need to manage invoices in the Accounting App. This improves efficiency and compliance with Colombian regulations.
Original PR description
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App.…
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App. This pr adds the possibility to generate and send the electronic documents directly to DIAN without leaving the POS store. This pr will not create intermediate invoices/credit notes that are supposed to be sent to DIAN, instead we adapted the already existing ubl-generation implementation (in `l10n_co_dian`) to be able to generate the correct files using data from `pos.order` models (implementation can be found in `models/account_edi_xml_ubl_dian.py`). During this process we created some 'common' functions that generate data for the ubl file independent of what model is used (`account.move` or `pos.order`), these common functions are a first step for the future refactoring of the ubl models. An important thing to note here is that the common functions are only used for the pos orders, generating documents for invoices is still done using the original implementation. Another important feature of this implementation is the possibility to share a single sequence, defined on the journal, between pos orders and account moves. This was implemented because in Colombia (and other latam countries) the sequence gets assigned to a company by the government, and can therefore be expensive. Important to note is that sharing a sequence is only possible if the company has never sent documents to DIAN before (~ no existing edi documents). task-4038651 Forward-Port-Of: odoo/enterprise#78742
This update enables the generation of UBL (Universal Business Language) receipts from Point of Sale (PoS) orders, supporting compliance with local tax regulations. The changes include adding UBL 2.1 invoice templates and preparing the system for use with l10n_co POS, improving reporting capabilities for businesses operating in Colombia.
Original PR description
task: 4038651 Forward-Port-Of: odoo/odoo#209578
Enhancements to existing features
This update improves the accuracy of Taiwan's tax calculations by refining fiscal positions and tax mappings, particularly for common document types like invoices. The changes better align with local tax regulations and simplify the chart of accounts by removing outdated tax configurations. This ensures more precise financial reporting for Odoo users in Taiwan.
Original PR description
This commit updates the Taiwan localization to provide a more granular and accurate set of fiscal positions and tax mappings, specifically focusing on document types (Triplicate, Duplicate, and Cash Register). Key changes: - Refactored fiscal positions to differentiate between document types for Export Sales and VAT Exempt transactions. - Split purchase-related fiscal positions into P C (Product/Consumable) and F A (Fixed Asset) categories to better handle tax deduction rules. - Updated `original_tax_ids` on sale and purchase taxes to ensure correct tax substitution when switching fiscal positions. - Cleaned up the tax template by removing redundant or less commonly used taxes (GBRT, Withholding, Deemed Sales, and specific Fixed Asset sale taxes) to simplify the default chart of accounts. - Updated localized names and translations for clarity. Task-6007589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update corrects a bug in the DIAN invoice processing workflow. Previously, the system could unintentionally delete original invoices, leading to data loss. The fix ensures the correct invoice document is protected during the update process, maintaining data integrity.
Original PR description
**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147 Forward-Port-Of: odoo/enterprise#110455
This update reactivates all Belgian taxes within the Odoo accounting system. This change was necessary due to a recent update to the core Odoo code, which previously disabled these taxes. Now, businesses using the Belgian localization module will correctly calculate and manage their Belgian taxes.
Original PR description
Due to an intended change in this PR : https://github.com/odoo/odoo/commit/6e555b74f457ef54318845e3e84f3873e982a0b9, All the belgian taxes were deactivated, This commit activates all the taxes. task-5902000 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253718 Forward-Port-Of: odoo/odoo#253036
This update fixes an issue where bank statement reconciliations in foreign currency journals were incorrectly using the invoice currency instead of the payment currency. This resulted in inaccurate balance conversions during batch reconciliation processes. The fix ensures correct currency conversion for improved financial reporting accuracy.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218 Forward-Port-Of: odoo/enterprise#108745
Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was delivered. This update fixes a bug where the WhatsApp API limitation was silently discarding subsequent attachments. The change ensures all uploaded files are sent, improving the reliability of file sharing within WhatsApp.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#110657 Forward-Port-Of: odoo/enterprise#107424
This update fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The solution allows users to manually specify the fulfillment channel (FBA or FBM) for each listing, resolving a known 'ghost listing' issue. This ensures accurate stock management and order fulfillment.
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 resolves a performance issue in the Followup Report that was causing slow loading times in Odoo 19.1. The fix utilizes a more efficient filtering method, aligning with previous performance practices, to speed up report generation, particularly on large databases.
Original PR description
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1…
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1 than it used to in 19.0. This is a problem when processing the followup with the cron, as it can cause it to time out. This situation happens because we now use a subquery computing the partner from the account.partial.reconcile objects linked the the move lines (because the Partner Ledger needs to consider move lines made without any partner as well). in 19.0, a domain on the partner_id field was directly executed, taking hence advantage of the index existing for that field. While this makes sense for the Partner Ledger, it's not relevant for the Followup Report. Indeed, in that report, when filtering on a single partner, we only want to show the open invoices and unreconciled payments made for that partner, so we'll never need to consider the lines without partner. We can therefore use the standard domain on partner_id in that case, like before, solving the perf issue in the meantime.
This update ensures that PIN codes are now displayed for both physical and virtual expense cards. Previously, users were blocked from completing transactions using virtual cards (digital wallets) because they couldn't access their PIN. This change improves the user experience and allows for seamless transactions.
Original PR description
Before this commit: - Currently, we show the PIN code for physical expense cards only, not for virtual cards. - In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information. After this commit: - Now we show the PIN code for both physical and virtual cards. task-5926462 Forward-Port-Of: odoo/enterprise#107231
This update resolves a problem where the system incorrectly flagged invoices for EC Sales List compliance when customers were located within the EU. The fix ensures that the 'Only intra-EU customers' check accurately identifies invoices that violate EU regulations, improving data accuracy and reducing potential reporting errors.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly. Forward-Port-Of: odoo/enterprise#107137
This update resolves an issue where the Public Administration (PA) invoice status wasn't correctly updated after SDI validation, leading to potential rejection of invoices. The fix ensures the system accurately reflects the PA's state, improving invoice processing accuracy for Italian tax compliance. This change was triggered by a bug fix within the l10n_it_edi module.
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
This update resolves an issue where ZATCA invoicing was incorrectly applied to ‘Settle Due’ orders in Point of Sale. The change adjusts how the system identifies these orders, ensuring that invoicing is skipped for ‘Settle Due’ transactions while maintaining correct invoicing for standard deposit flows. This prevents duplicate invoicing and simplifies ZATCA reporting for POS transactions.
Original PR description
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both…
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag. From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders. # Current behavior before PR With ZATCA enabled on saas-18.2: - Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account. - Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines. - This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported. - Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported. # Desired behavior after PR is merged After this fix: - ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag. - Even if invoice is checked, the invoice is not sent to ZATCA - Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing. - Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting. This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252984 Forward-Port-Of: odoo/odoo#244712
This update fixes an issue where table menus would overlap or not appear when hovering over list items within table cells. The change now correctly displays table menus on list hover and prevents overflow, ensuring a smoother user experience when working with complex tables. This improves the overall usability of the HTML editor.
Original PR description
**Current behavior before PR:** - Table menu handlers could overflow into adjacent table areas when the targeted part of the table was only partially visible within the container. - When a table cell contained a list, hovering over the list element did not display the table UI menus, even though the mouse was inside the cell. **Desired behavior after PR is merged:** - Use a local overlay for the table menu to prevent overflow into adjacent cells. - Table UI menus are now correctly displayed when hovering over list elements inside a table cell. task-5353518 Forward-Port-Of: odoo/odoo#251977 Forward-Port-Of: odoo/odoo#240342
This update ensures that phone numbers entered through the takeaway preset in the Odoo POS system are now correctly recorded on the order itself. Previously, this information was lost, making it difficult to contact customers. This fix improves order management and customer service.
Original PR description
Currently, when using the takeaway preset, the phone information filled in is not registered on the order. Steps to reproduce: ------------------- * Change restaurant setting to enable self order * Open mobile menu (make sure session is opened prior) * Select takeout preset * Place an order * Fill in all information, time, name, email & phone * Validate order * Go to the orders in the backend > Observe that the contact info does not register the phone (mobile) Why the fix: ------------ Nothing was done with the phone information so we now register it on the order. opw-6014340 Forward-Port-Of: odoo/odoo#253610
This update resolves a memory issue that occurred when propagating deliveries across multiple lots, particularly when dealing with large numbers of picking IDs. The fix ensures the system can handle larger datasets without running out of memory, improving stability and performance for users with extensive inventory.
Original PR description
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents. - Updating parent sets in a single operation caused a MemoryError for large datasets. ```sql…
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.
```sql
Traceback (most recent call last):
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
MemoryError
(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682
Lot_id 11412: delivery_by_lot size = 7420, parents = 3
Lot_id 11753: delivery_by_lot size = 0, parents = 7
Lot_id 12845: delivery_by_lot size = 11, parents = 5
Lot_id 14646: delivery_by_lot size = 12, parents = 2
Lot_id 15801: delivery_by_lot size = 1700, parents = 3
Lot_id 19817: delivery_by_lot size = 0, parents = 4
Lot_id 22370: delivery_by_lot size = 0, parents = 1
Lot_id 25072: delivery_by_lot size = 6827, parents = 2
Lot_id 25134: delivery_by_lot size = 3, parents = 2
Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones
UPG - 3869661
OPW - 5900313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248826This update fixes an issue where the Field Service onboarding tour would stop prematurely after redirects. By adding tour information to the user's session, the tour now seamlessly resumes across different parts of the portal, providing a smoother and more complete onboarding experience for users.
Original PR description
**Steps to reproduce:**
1. Go to Field Service app.
2. Check the worksheet template in settings and start the onboarding tour
of Field Service.
**Issue:**
The backend tour is not resuming on the frontend side.
**Fix:**
This commit ensures the tour is enabled and the current tour is added to the frontend session. When the tour resumes, it will fetch the tour enabled and current tour details from the session.
**Technical:**
In the tour service, the tour resumes only if the mode is set to "auto" or toursEnabled is present in the session. To handle this, we added the tour details to the session.
tour_service.js
``` js
if (tourState.getCurrentConfig().mode === "auto" || toursEnabled) {
resumeTour();
}
````
task-4489657
Forward-Port-Of: odoo/odoo#254600
Forward-Port-Of: odoo/odoo#202484This update fixes an issue where unbuilding a manufacturing order resulted in invalid stock move lines. The fix ensures accurate quantity calculations during unbuild processes, preventing backorders and validation errors. This improves the reliability of inventory management.
Original PR description
# How to reproduce - Create a BOM for a product - Create a MO for a set quantity (Exemple: 1) for that product - Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3) -…
# How to reproduce - Create a BOM for a product - Create a MO for a set quantity (Exemple: 1) for that product - Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3) - Confirm the unbuild - Go to the stock moves of that unbuild via the smart button # The problem 3 stock move lines are created, 2 in the 'Done' state and 1 in the 'Available' state. This last move line is stuck and cannot be validated # Why The cause of this issue is due to a discrepency between the quantity set for the move lines and the quantity set for their respective moves. When creating the move lines for the produce move, we use the original move of the MO (this is done to keep Lots consistent). If the quantity of product to unbuild is more than the quantity of product built by the MO, the quantity of the move lines will be less than expected. This will then create a backorder when the produce move is set to done. This backorder will then be unvalidatable because the unbuild it is linked to will be set to 'Done'. opw-5915981 opw-5449109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254016 Forward-Port-Of: odoo/odoo#248056