Daily updates from Odoo
Friday, January 16, 2026
308 changes
2 changes
Resolved issues and error corrections
This update fixes a potential issue where Odoo installations didn't consistently create foreign key relationships in the database. This resulted in 'Record missing' errors appearing later, often after weeks or months, due to inconsistencies. Merging this change will guarantee that Odoo installs with properly configured foreign keys, improving database stability and preventing these unexpected errors.
Original PR description
---- Description of the issue/feature this PR addresses: See related OPW Ticket [opw-5495025](https://www.odoo.com/my/tasks/5495025) Current behavior before PR: Odoo seems to install correctly, and works normally. However the database consistency is not ensured. Foreign Keys are not created. User receives `Record missing` errors after some time, when there was a Contact deleted, for example. Issue is dangerous, because it can be latent and be undetected for weeks or months. Desired behavior after PR is merged: Odoo installs *with* the Foreign Keys, and works normally. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr --- Ticket opw-5495025 Forward-Port-Of: odoo/odoo#243833
This update resolves a problem where Odoo invoices exported to the SII system (Chile) were being rejected due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential disruptions to the export process.
Original PR description
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system…
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600
2 changes
Resolved issues and error corrections
This update corrects a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it’s correctly linked to the Euro (EUR) reflecting Bulgaria’s adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for transactions involving Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update corrects a bug where overdue invoices were printed twice in follow-up PDF reports. The issue stemmed from how the system attached invoices during manual follow-up creation. Now, invoices appear only once in the generated PDF, ensuring accurate reporting and reducing potential confusion for users.
Original PR description
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this…
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this Partner then in the "Accounting" sheet, - Choose follow-up as manual, - Click on send, - In the wizard select Print and "Join invoices" ### Current behavior: The PDF display the reminder, the invoice, the report and the invoice again. ### Expected behavior: Invoice should appear only once in the follow-up PDF. ### Cause : When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again. In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices. opw-5368870 Forward-Port-Of: odoo/enterprise#102516
4 changes
Resolved issues and error corrections
This update ensures that newly created General(MISC) entries in Odoo automatically have 'no followup' enabled. This simplifies reporting and reduces the risk of unnecessary follow-up actions for these types of transactions, improving data clarity and efficiency.
Original PR description
General(MISC) entries should be no_followup by default. task-5489772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where a project was automatically created when ordering 0 units of a prepaid service product within a quotation. The change ensures that projects are only generated when a valid quantity of the service is ordered, streamlining the invoicing process and preventing unnecessary project creation. This resolves an issue reported by users.
Original PR description
--- ## Short functional explanation of the error Let's say we have a prepaid service as a product, generating a project upon order. When we order 0 units of this product as an optional product, a project is still created. ## Reproduction Steps 1. Create a product of type Service. Set Project in the field Create On Order. Set the Invoicing Policy at Prepaid. 2. Create a quotation containing an optional product with 0 units of this service and click on confirm. ### Expected behavior The quotation is confirmed, but no project is created. ### Unexpected behavior A project linked to the product and the quotation is created. ## Origin of the issue When creating projects linked to order lines, we don't check if such projects are linked to optional products. opw-5406118
This update fixes an issue where sale warnings weren't showing for customers linked to a company contact. The change ensures that warnings set on a company are correctly displayed when a customer from that company places an order. This improves the accuracy of sales alerts and prevents missed opportunities.
Original PR description
### Issue: Due to this issue, the sale warning message is only shown when the warning message is set on partner itself, not partner's company. #### Steps to reproduce (with demo data): 1- Enable `Sale warnings` from setting. 2- On `Contacts` app, open `Azure Interior`, and add a sale warning from `Notes` tab. 3- Create a SO with `Brandon Freeman` from `Azure Interior` as the customer. 4- No sale warning is shown. ### Cause: The IMP #192211 replaces warning popup with a message. However, it doesn't check for the warning from `partner_id.parent_id`, which was the case before that PR. This is the case with purchase as well. opw-5404983 Forward-Port-Of: odoo/odoo#242050
This update resolves a potential error in the accounting module that could occur when calculating tax distributions. The change ensures the system handles the rare scenario where all factors are zero, preventing a traceback and maintaining accurate calculations. This improves stability and reliability of financial transactions.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616