Daily updates from Odoo
Thursday, March 12, 2026
14 changes · 17.0
New functionality added to Odoo
This update enables Danish companies to automatically generate official FIK payment references on customer invoices through their sales journals. Users simply configure their bank's FIK creditor number, ensuring compliant Danish FIK payments without disrupting existing workflows. This improves financial reporting and reduces manual effort for Danish customers.
Original PR description
Before: - Danish companies had to rely on manual or non-standard payment communication on invoices. - They could not generate official FIK payment references. After: - Sales journals can now generate Danish FIK payment references automatically. - Users configure an 8-digit bank-issued FIK creditor number on sales journal. Impact: - Enables compliant Danish FIK payments without changing user workflows. Related PR: https://github.com/odoo/enterprise/pull/102612 taskID-5401553
This update incorporates new required fields for Section F of Uruguayan tax regulations (DGI version 25). These changes ensure compliance with the latest tax reporting requirements, specifically for businesses operating in Uruguay. This addition is crucial for accurate financial reporting and avoiding potential penalties.
Original PR description
Regards to DGI new spec version 25.
Enhancements to existing features
This update makes it easier to customize the look and feel of invoice reports. By adding an ID to the report template, other Odoo modules can now use standard styling methods (CSS or XML) to modify the report's appearance. This enhances flexibility and allows for tailored invoice reports.
Original PR description
This commit adds an id to some html element in report_invoice. This allows other modules to easily target, style, and override the contents of this section using standard CSS selectors or XML/XPath overrides, improving the template's extensibility. task-5162891
Resolved issues and error corrections
This update ensures that changes to stock move quantities, such as adding lot names, are correctly saved and reflected in the system. Previously, this functionality was missing, leading to data inconsistencies. This fix restores a key feature for accurate stock tracking.
Original PR description
This commit make use of `_action_assign()` to populate extra stock move lines when increasing the quantity of a stock move. This feature was available in v16 but lost from https://github.com/odoo-dev/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81. Also back-port https://github.com/odoo/odoo/commit/bf4bdbe775f8f49b2aaac069fc65bc03593b95df to make sure any change on `quantity` on stock move will trigger a `save` to update the stock move line accordingly at the openning of the detailed operations Task : 4308181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures Odoo correctly includes Danish FIK references in SEPA payment XMLs, aligning with local regulations. The change improves the accuracy of payment communications and makes the system more adaptable to future country-specific requirements. This ensures compliant Danish SEPA payments.
Original PR description
Issue: - A related PR introduced Danish FIK payment references on customer invoices. - The generated SEPA payment XML did not include this reference, resulting in missing structured communication for Danish payments. IMP: - Extended the SEPA payment XML generation to include the Danish FIK reference when present. - Refactored the structured reference XML builder to use lxml elements instead of string-based XML construction, ensuring proper escaping of structured references. Impact: - Ensures compliant Danish SEPA payments with correct FIK references. - Makes SEPA XML generation future-proof for country-specific structured references containing non-numeric characters. Related PR: https://github.com/odoo/odoo/pull/240829 Task: 5401553
This update resolves an issue where currency exchange rates impacted the accuracy of discount calculations on customer invoices, leading to unbalanced journal entries. The change ensures discounts are handled with greater precision, regardless of the exchange rate's accuracy, guaranteeing correct financial reporting.
Original PR description
When a separate discount account is set on customer invoices and a foreign currency is used with a highly precise rate, rounding issues could cause the journal entry to become unbalanced. Steps to…
When a separate discount account is set on customer invoices and a foreign currency is used with a highly precise rate, rounding issues could cause the journal entry to become unbalanced. Steps to reproduce: - Set a separate discount account for customer invoices. - Create a currency with rate 0.019560839590356895. - Create a customer invoice in that currency with the following lines: - Line 1: price 480.00, discount 10% - Line 2: price 150.00, discount 30% - Line 3: price 700.00, discount 20% - Line 4: line with negative amount -322.00 - Use the default revenue account on lines 1, 2, and 4. - Use a different account on line 3. - Validate the invoice, error raised due to unbalanced journal entry. Before this PR: - Discounts on lines sharing the same account were summed in foreign currency, then converted together to company currency. This could cause rounding issues when using precise exchange rates. After this PR: - Each line’s discount is converted then rounded individually before grouping, ensuring accurate and balanced journal entries regardless of rate precision. opw-4756076
This update fixes an issue where invoices were incorrectly displaying lot numbers due to how reversed account moves were handled. The change ensures that only relevant reversed account moves are considered when calculating invoiced quantities, preventing incorrect lot reporting on printed invoices. This improves invoice accuracy and consistency.
Original PR description
Problem: When trying to compute the `previous_qties_invoiced` we filter out previous account move lines if they have been reversed.…
Problem: When trying to compute the `previous_qties_invoiced` we filter out previous account move lines if they have been reversed. https://github.com/odoo/odoo/blob/9c494d8dab26a1d0901cd593f7479de899d5a93f/addons/sale_stock/models/account_move.py#L50 The issue occurs when the reversed account move line is from a previous date and new invoices have been created since then. In this scenario it will remove the reversed account move line, but leave the reversal’s account move line. This will lead to an incorrect `previous_qties_invoiced` and cause the incorrect lots to be printed on the invoice. Purpose: To only remove the reversed account move lines if their reversed account move line is not in the `previous_amls`. Steps to Reproduce on Runbot: 1. Enable Lots on printed invoices. 2. Create a storable product tracked by lots. 3. Create 2 lots with 100 units each. 4. Create a sale order for 10 units of our test product. 5. Deliver 7 units of lot 1 and create a backorder for the rest. 6. Invoice the 7 units with the invoice date set to yesterday. 7. Create a credit note dated yesterday as well with reverse and create invoice. 8. Deliver the 3 remaining units with lot 2. 9. Create an invoice for the 3 remaining units dated today. 10. Print the latest invoice and observe it shows 3 units of lot 1. opw-6011050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where presence notifications were sent incorrectly for records that were being removed from the system. Now, notifications are only sent after the record is fully unlinked, ensuring accurate 'offline' status updates are broadcast. This improves the reliability of presence status information.
Original PR description
Before this commit, presence channel notifications for unlinked records were sent before the records were actually removed from the database. This caused `im_status` to be calculated using stale data, occasionally resulting in statuses other than "offline" being broadcast. This commit ensures notifications are sent only after the presences have been unlinked, guaranteeing an accurate status.
This update prevents unnecessary timesheet entries from being created when public holidays are edited or deleted. Previously, deleting a holiday would incorrectly generate timesheets for all related leave requests, even if they were refused. Now, timesheets are only created for valid, approved leave requests, streamlining the process and reducing potential errors.
Original PR description
…d leaves Description of the issue/feature this PR addresses: When a public holiday is edited or deleted, the timesheet re-creation is erroneously done for *all* leaves, even those which are canceled or still in draft. Steps to Reproduce: 1. Create a Time Off request for a timesheet-creating leave type (i.e. `timesheet_generate = True`) that overlaps with a public holiday. 2. Refuse the Time Off request. 3. Delete the public holiday the request overlaps with. Current behavior before PR: The deletion of the holiday causes timesheet entries to be created, even though it's a refused request. Desired behavior after PR is merged: The deletion or editing of the public holiday only re-creates the timesheets for the leaves that are actually valid and thus need timesheet entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing Argentinian companies with 'IVA Sujeto Exento' (VAT exempt) from creating 'Export Invoices' documents. The fix ensures that companies with this VAT status can still generate and export invoices, aligning with AFIP regulations. This improves accounting flexibility for Argentinian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Create a Argentinian company with "AFIP Responsibility Type" set to "IVA Sujeto Exento" (VAT exempt) - Switch to the created company - In Accounting settings, set up "AFIP Web Services" - Create a journal for export invoices - Create a customer with "AFIP Responsibility Type" set to "Cliente del Exterior" - Create an invoice - Select the created customer - Try to set the document type for export invoices **Issue:** It is not possible to select "(19) EXPORT INVOICES" as "Document Type" for companies having "AFIP Responsibility Type" set to "IVA Sujeto Exento". It is not because the company is "VAT exempt" that it should not be able to create an export invoice. opw-5974268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where a regex used in UBL invoice processing would fail when encountering non-string values. The fix ensures the regex only operates on valid strings, preventing errors during invoice import and improving the stability of the account_edi_ubl_cii module. This resolves previous issues related to vendor bill imports.
Original PR description
The issue occurred because a test regex was applied to a non-string value. In some cases the value was False, which caused the operation to fail. Steps to reproduce: - Import a vendor bill - Remove the product and the label from one line, then post the bill - Import another bill (or the same bill)from the same supplier - An error occurs when the regex tries to match a non-string value This change ensures the regex is only applied to valid strings. It also improves the code by extracting the static part of the regex into a dedicated variable. opw-6019298 opw-6030364 opw-6033013 opw-6032608 opw-6032546
This update resolves an issue where Amazon replacement orders couldn't be processed correctly due to a lack of currency information. The system now leverages the currency of the original order to ensure compatibility with Odoo's pricing structure. This ensures accurate order processing and avoids potential errors when receiving replacement orders from Amazon.
Original PR description
Backport of a9215c1825e2a254f47664cca406204478f87da3. Original commit message: Amazon replacement orders have no currency (and a zero amount). This is problematic because all Odoo orders have pricelists and all pricelists require a currency. However, Amazon stores a reference to the replaced order, so we can use the replaced order's currency as the replacement order's currency. opw-5952984
This update fixes an issue where General Ledger exports to XLSX files didn't correctly include transactions when the 'cash basis' reporting method was selected. The fix ensures that transactions are accurately exported based on payment dates, resolving a discrepancy between front-end and export functionality. This improves reporting accuracy for users utilizing the cash basis accounting method.
Original PR description
The General Ledger has two methods of reporting. Accrual and cash basis. Accrual uses the journal entry date, whereas the cash basis uses the payment date. Displaying this on the front end works with the correct logic if using cash basis. However, when exporting to XLSX, the query to collect accounts always uses an accrual-based logic. If a user were to have cash basis selected, resulting in lines that would otherwise not appear with accrual. (Due to the journal item dated for 2025, but the payment is being received in 2026). These lines would then not be included in an XLSX export. To fix, check if report_cash_basis is true when exporting and alter the logic accordingly. opw-5489371
Documentation and clarification updates
This pull request updates the Therp company CLA to reflect current employee contributions. Previously, the CLA contained outdated information. After this change, the CLA will accurately represent all Therp company contributors, ensuring legal compliance.
Original PR description
Description of the issue/feature this PR addresses: It makes our company CLA up to date with the reality Current behavior before PR: Our company CLA had some old employees in it, and didn't have some new ones Desired behavior after PR is merged: Our company CLA is up to date --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr