Daily updates from Odoo
Thursday, July 23, 2026
6 changes · 19.0
Enhancements to existing features
Belgian VAT return users can once again add comments to the XML file before submitting or locking the return. This restores a previously available capability that had been removed by mistake, helping businesses include required context with their VAT filings.
Original PR description
This feature had been mistakenly removed.
Resolved issues and error corrections
Account reports opened from the VAT return button no longer fail when the page is refreshed. This prevents interruptions for users reviewing tax return information and keeps the report accessible after a browser reload.
Original PR description
Opening an account report through the VAT return button on an account.return.check record returns an inline client action whose report_id only exists in context. On refresh, Odoo will throw an error because it will try to rebuild the action context based off of the URL which is deficient. This will not effect reports opened via the menu since those follow a different pathway. This fix anchors the inline action to the "path" property stored on the client action. A helper method was added for deriving the action_id from a given report. opw-6366964
Electronic invoices sent from a Colombian branch now use the parent company's legal name in the DIAN XML. This helps DIAN correctly match invoices to the registered tax ID and avoids rejection caused by branch names not being recognized.
Original PR description
The correct behavior should be to use the original company name in this specific XML tag For the DIAN, branch names will not be recognized as related to the NIT. So, when sending electronic invoices from a branch, the XML should use the name of the parent company of that branch. Ticket [link](https://www.odoo.com/odoo/project.task/6074280) opw-6074280
Belgian POS receipts now show the VAT rate that was actually applied after fiscal position changes, instead of the product's default VAT. This prevents mismatches between the POS sale and the fiscal device receipt when tax mappings are used.
Original PR description
Steps to reproduce: =================== - Configure a product with a 12% VAT - Create a fiscal position that maps 12% → 6% - Open POS and apply the fiscal position to an order - Add the product and validate the sale - Download Receipt Issue: ====== - The POS correctly applies and displays the mapped 6% VAT - The payload sent to the FDM still uses the product's original 12% VAT - As a result, the receipt displays the wrong VAT rate Cause: ====== - VAT labels in the Blackbox payload were generated from product_id.taxes_id - Fiscal position tax mappings were ignored when building VAT inputs - Blackbox product prices were also computed without taking the fiscal position into account Fix: ==== - Use taxes after fiscal position mapping when generating VAT data for the Blackbox payload - Ensure VAT labels sent to the FDM match the taxes applied on the POS order - Apply fiscal position tax mapping when computing Blackbox product prices Task:6392006
This fixes Peppol document import settings so the purchase journal is only required when it is actually needed. It prevents non-French companies using Documents with Peppol from being blocked by French PDP-related requirements, and ensures imports go to the selected destination only.
Original PR description
Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120720
Product managers can now use barcode lookup to automatically fill product details without needing full administrator access. This keeps product creation workflows efficient while avoiding unnecessary admin privileges.
Original PR description
Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled. ## Steps to replicate: - Install stock with demo data -…
Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled. ## Steps to replicate: - Install stock with demo data - Barcode Database > Setup barcode lookup credentials - Users > Marc Demo > Give Marc Demo > Master Data > Products > Create - Login as `Marc Demo` - Products > Barcode: `850049670180` > Click anywhere else ## Observed Behaviour: Information on the product template is not autofilled, as it would be when using a System Admin user(Mitchell Admin). ## Root cause: This issue occurs because barcode lookup is gated behind a check for System Admin rights. Although users in the Product Manager group have permission to create products, they do not satisfy this condition, so the barcode lookup never executes at [1]. [1]- https://github.com/odoo/enterprise/blob/c66995fda83e19b28a38312af8efdc1601881cf0/product_barcodelookup/models/product_template.py#L17-L22 ## Why this is an issue: The original restriction (task [2] and commit [3]) was intended to limit barcode lookup to users who can create products, preventing unnecessary API calls. This was a valid assumption in 17.3-18.0, where creating products in POS required System Admin rights but now after commit [4] this is no longer the case. In v18, task [5] introduced the Product Manager group, making product creation independent of System Admin rights or module rights. Later, v18.3 exposed these Master Data access rights to non-debug users through commit [6]. As a result, there are users who are legitimately responsible for product creation and maintenance (regardless of POS usage) they can no longer use barcode lookup unless they are also granted full System Admin privileges, which provides broader access than required. ## Solution: Remove the group-based permission check so that access is determined solely by product edit permissions. This ensures that only users with the ability to modify products can use the API call, preserving the original security intent. As a result, users no longer need unnecessary administrative privileges toperform barcode lookups. [2]: https://www.odoo.com/odoo/project/49/tasks/3911024 [3]: https://github.com/odoo/enterprise/commit/444df3e48cb8d479d3b5d4a03a4bfefa48650910 [4]: https://github.com/odoo/odoo/commit/821bbc4504fd80a508e2412c7490ee60dd03f7b8 [5]: https://github.com/odoo/odoo/commit/d4886faf12ccaf63d5e899c20df2543d1ce046ab [6]: https://github.com/odoo/odoo/commit/e74eaf628498155243db73ea229eaf5e74c24f2a opw-6290999