Monday, March 16, 2026
5 changes · saas-18.2
New functionality added to Odoo
This update enables direct electronic invoicing for POS sales and returns in Colombia, streamlining the process for businesses. It avoids creating intermediate invoices and leverages existing DIAN EDI technology, reducing complexity and costs associated with document management. This improves compliance and efficiency for Colombian retailers.
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
Resolved issues and error corrections
This update ensures that tax calculations in reports related to Indian GST (GSTR) are accurate. Previously, the system incorrectly applied taxes to invoices even when they were not fully posted. This change now only applies taxes to invoices that have been finalized, improving the reliability of financial reporting.
Original PR description
if bill is not available then we also create new bill without line so we check taxes only on posted one Forward-Port-Of: odoo/enterprise#110461
This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The fix removes these rental amounts, ensuring more accurate reporting of employee income as required by Hong Kong tax regulations. This improves the reliability of payroll data.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636 Forward-Port-Of: odoo/enterprise#109919
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#110373 Forward-Port-Of: odoo/enterprise#106902
Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was successfully delivered. This update corrects this issue by ensuring that Odoo now properly handles multiple attachments, preventing data loss and improving the reliability of file sharing within WhatsApp. The fix prevents the system from silently discarding additional files.
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#107424