Thursday, March 12, 2026
9 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.
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 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 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