Friday, May 16, 2025
10 changes · 18.0
Enhancements to existing features
Odoo can now recognize UBL AttachedDocument wrapper files and extract the original invoice or document inside for normal processing. This improves compatibility with electronic invoicing systems, including Colombian EDI flows and other UBL-compliant platforms that send bundled documents.
Original PR description
AttachedDocuments are a wrapper filetype in the UBL 2.0/2.1 specification that allows for multiple documents to be bundled together. Colombia uses it as a way to return back values from the EDI but it is in the standard and can therefore be used by any UBL 2.0/2.1 compliant system. To be able to parse the documents inside correctly, we must obtain the original record which is stored in the outermost Attachment node either under the EmbeddedDocumentBinaryObject element or the ExternalReference/Description node. Once we find it we send it to the normal decoder process. Specification: https://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AttachedDocument-2.1.html task-4299222
Odoo’s Colombian localization now includes standard consumption taxes and related accounts needed for products such as alcohol. This prepares Colombian businesses to use upcoming point-of-sale capabilities with the required taxes available out of the box, including migration support for existing databases.
Original PR description
Consumption taxes are required for alcohol and other products, withthe POS module for Colombia coming out soon it's necessary to support such taxes out of the box for when it's released. A migration script has been added to automatically load these new taxes and accounts that will be necessary. task-4634313 Enterprise PR: https://github.com/odoo/enterprise/pull/84717
Uruguayan electronic invoice PDFs now better match the customer’s language preference by requesting English reports when the customer is not set to Spanish. Longer addenda, such as terms and mandatory disclosures, are now placed on a dedicated page when needed so important text is not cut off.
Original PR description
This fixes two issues with the report. The first one is automatically requesting an English report if the customer's preferred language is not Spanish. This way the lang field on the partner is somewhat respected for these externally generated reports too. The second fix requests a dedicated addenda page when appropriate. By default, the addenda (e.g. terms and conditions) is added in a small box at the bottom of the standard PDF report. This can only accomodate roughly 6 lines of 140 characters. If the addenda exceeds that, the remainder is silently cut off which is problematic for mandatory disclosures etc. It's possible to request a dedicated addenda page in the PDF that fixes this issue. We considered always requesting it, but it looks strange to have a whole page in the PDF if the addenda is very short. We therefore make a best effort attempt to figure out if the addenda will fit in the standard report or not. task-4750717
Colombian electronic invoicing now handles the special tax calculation required for alcoholic beverages, similar to existing support for sugary drink taxes. Product tax data was generalized so businesses can provide the required tax component details for different product-specific taxes, helping invoices comply with DIAN rules.
Original PR description
Like the sugar tax, alcohol is also taxed differently in Colombia such that we need a special case for how to compute it. The Per Unit Amount is the total tax amount divided by the alcohol percentage. To facilitate this change, the field that was previously used for the volume in ml for sugary drinks has been made into a generic "Specific Component Nominal Tax" field which can be used for any extra tax data depending on what type of tax is on the product. Comm PR: https://github.com/odoo/odoo/pull/208500 task-4634313
Odoo can now import Colombia DIAN AttachedDocument files received from vendors, which include the original invoice and related regulatory information. This helps businesses process supplier billing documents more directly and reduces manual handling of compliant Colombian e-invoicing files.
Original PR description
AttachedDocument is a specific XML format used in Colombia, generated by the DIAN regulatory body. These Documents are commonly received from vendors as they contain complete billing information. While Odoo 18.0+ can generate AttachedDocument records for outgoing invoices, it lacks import functionality. This document format contains nested XML documents that represent related records such as DIAN responses, Commercial Events data, and the orignal vendor invoice. The DIAN specifications state that for an AttachedDocument with specified DocumentType must contain the original invoice within the top-most <cac:Attachment> node. (All other documents attached with this file are wrapped in <cac:ParentDocumentLineReference> tags which differentiates it) Specifications: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Techico-Factura-Electronica-de-Venta-vr-1-9.pdf task-4299222
Resolved issues and error corrections
This fixes an unnecessary warning that asked users to create a warehouse when making certain purchase orders, such as dropship purchases, for a company without a warehouse. Users can now proceed without being forced into extra setup that is not needed for that purchasing flow.
Original PR description
Usecase: - Create a new company without warehouse - Create a purchase.order with a dropship type You got a redirect warning asking for a warehouse. But in this case it's not needed and force the user to create a warehouse. (which is not the purpose of commit 6516ab61927a63e3f2d804cf1b5baa43a151ca19) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents new Odoo databases from failing when they are created with certain regional languages, such as Argentinian Spanish. It ensures language settings are applied in the right order so setup completes successfully without duplicate language code errors.
Original PR description
**Steps to reproduce:** 1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR` **Result:** ``` 2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading…
**Steps to reproduce:**
1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR`
**Result:**
```
2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading base/data/res_bank.xml
2025-01-03 11:41:28,057 54 INFO langdb odoo.modules.loading: loading base/data/res.lang.csv
2025-01-03 11:41:28,076 54 INFO langdb odoo.modules.loading: loading base/data/res_lang_data.xml
2025-01-03 11:41:28,091 54 ERROR langdb odoo.sql_db: bad query: b' UPDATE "res_lang"\n
SET "url_code" = "__tmp"."url_code"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4\n
FROM (VALUES (68, \'es\', \'2025-01-03T11:41:26.517428\'::timestamp, 1)) AS "__tmp"("id", "url_code", "write_date", "write_uid")\n
WHERE "res_lang"."id" = "__tmp"."id"\n'
ERROR: duplicate key value violates unique constraint "res_lang_url_code_uniq"
DETAIL: Key (url_code)=(es) already exists.
```
**Explanation:**
When initializing a new database with a specific language, the language is activated on `install_lang`, and since it's the only active language of the "es_*" family, its url_code is set to the short version. [^1]
By the time the url_code switch in `res_lang_data.xml` is executed, the `base.lang_es` language is no longer the one with "es" as url_code. It's actually the recently activated es_AR language.
**Solution:**
We must perform the `url_code` switch before calling `install_lang`
[^1]: https://github.com/odoo/odoo/blob/c042e1ba/odoo/addons/base/models/res_lang.py#L339-L356
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes how fixed-rate IEPS taxes are reported on Mexican electronic invoices and related payment documents. This helps ensure tax values are sent correctly to the tax authority, reducing validation errors and manual follow-up.
Original PR description
See test in this commit. opw-4744627
Customer follow-up emails now correctly include the overdue invoice attachments again. This ensures customers receive the documents they need to understand and pay outstanding amounts, including when automated follow-ups are run.
Original PR description
### Steps to reproduce:
- Create an invoice with a due date past for long time
- Accounting > Customers, click on the partner of the invoice
- In the page "Accounting" the "Follow-up Status" should be "In need of action"
- Go to the Scheduled Action "Account Report Followup; Execute followup" and Run manually
- Go back to the partner
- The follow-up is send without the invoices
### Cause:
This [commit](https://github.com/odoo/enterprise/pull/84114) moved a part of code to fix a bug but it also changed it: it moved `'attachment_ids' not in options` from the end to the beginning. By doing that the line
`options.get('attachment_ids', self._get_invoices_to_print(options).message_main_attachment_id.ids)`
does not work anyore because `attachment_ids` is always in `options` so `_get_invoices_to_print` is never called.
### Solution:
Use `setdefault` instead of `get`.
opw-4716458This fixes an issue where newly selected Knowledge cover images could be incorrectly linked to an older cover record. As a result, the system cleanup process could delete the active cover image; the change ensures covers remain visible after cleanup.
Original PR description
The overhaul of html editor into knowledge introduced an issue involving the auto-vaccuum. This commit https://github.com/odoo/enterprise/commit/08d84f8b61450a0ebd0d2aadfe8f227bda283edd passes the res_id value of the currently existing knowledge.cover record. However, when we set a new cover image, we will always create a new cover record and the new cover image attachments are linked to the previous cover record. The auto-vaccuum then deletes unused cover images and any attachments linked, which will delete the actual cover image. The web_unsplash/attachment/add does not need to pass in a res_id of the cover image since we always create a new record at the end of the workflow. opw-4629300