Friday, March 13, 2026
10 changes · saas-18.3
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 payments without disrupting existing workflows. This simplifies Danish accounting processes within Odoo.
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 Forward-Port-Of: odoo/odoo#240829
Resolved issues and error corrections
This update fixes a calculation error in the equity reports. Previously, `equity_unaffected` accounts were incorrectly using 'historical' currency rates. The change reorders the CASE statement to ensure these accounts use the correct, current rate conversion, leading to more accurate financial reporting.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update resolves an issue preventing Argentinian companies with 'IVA Sujeto Exento' (VAT exempt) AFIP responsibility types from creating 'Export Invoices' documents. Previously, the system restricted this functionality. This change ensures compliance and allows businesses to properly generate export invoices as required by Argentinian tax regulations.
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 Forward-Port-Of: odoo/odoo#252232
This update corrects a naming error in the ZUGFeRD eInvoice XML file generated by our accounting module. Previously, the file was named incorrectly, causing validation issues with several key e-invoice validators. Now, the file name aligns with accepted standards, ensuring proper processing and compliance with German regulations.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252681
This update corrects a bug where combo items weren't printed using preparation printers if their category wasn't listed as restricted. The change ensures all preparation categories are loaded, guaranteeing that items are correctly printed regardless of their category assignment. This improves the reliability of preparation receipts.
Original PR description
Since this PR https://github.com/odoo/odoo/pull/225658, if the POS category of a combo item product was not listed under the restricted categories but was assigned to a preparation printer, the item would not be printed by the preparation printer. This commit ensures that preparation categories are loaded, preventing any used category from being missed. Enterprise PR: https://github.com/odoo/enterprise/pull/110470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231733
This update resolves a bug where combo items weren't printed correctly when assigned to preparation printers. The fix ensures that all relevant preparation categories are loaded, preventing missed categories and ensuring accurate printing of these items. This improves the reliability of the POS system.
Original PR description
Since this PR https://github.com/odoo/odoo/pull/225658, if the POS category of a combo item product was not listed under the restricted categories but was assigned to a preparation printer, the item would not be printed by the preparation printer. A test was already present to check this, but the validation method was incorrect (test_restricted_categories_combo_product) This commit ensures that preparation categories are loaded, preventing any used category from being missed. X-original-commit: b9cf922f9f4a29bc2e6d7d51c9698e8ff97a85c6
This update fixes an issue where the SVL (Stock Valuation Layer) values were incorrectly calculated for dropshipping backorders created with bills. The fix ensures that the SVL values accurately reflect the quantity of the product, preventing discrepancies in inventory valuation. This improves the accuracy of financial reporting for dropshipping transactions.
Original PR description
…order dropship **Problem:** when the backorder of the delivery (with a bill) of a dropshipped fifo/avco product is validated, the svl created don't have the right values **Steps to reproduce:** -…
…order dropship **Problem:** when the backorder of the delivery (with a bill) of a dropshipped fifo/avco product is validated, the svl created don't have the right values **Steps to reproduce:** - create a new product, with dropship and buy routes - in the purchase tab select "on ordered quantities" - add a vendor with a price of 10 - create a new quotation for a quantity of 10 - confirm and confirm the purchase order - click on "create bill" and confirm it - go back to the PO and click on the "dropship" smart button - change the quantity to 5, validate and create backorder - go back to the PO, click on the "dropship" smart button and select the picking of the backorder (with status ready) - validate - click on the "valuation smart" button **Current behavior:** the svl created for the backorder have a value of 100 and -100 **Expected behavior:** it should be 50 and -50 **Cause of the issue:** inside _get_dropshipped_svl_vals _get_price_unit is called https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/stock_account/models/stock_move.py#L219 because we created a bill and it's a backorder line.qty_invoiced is higher than received_qty and this condition is true https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L51 but because it's a dropship there is as much positive svl as negative svl linked to the move so receipt value is null https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L56-L63 and remaining value will be 100 instead of 50 (receipt value should have been 50) https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L80 **fix** the negative svl from the dropshipped move should not impact receipt value opw-4888827 Forward-Port-Of: odoo/odoo#224288 Forward-Port-Of: odoo/odoo#216899
This update ensures that Danish SEPA payments are correctly formatted with the necessary FIK reference information. The change refactors the XML generation process to handle country-specific reference formats, improving compliance and future-proofing the system.
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 Forward-Port-Of: odoo/enterprise#102612
This update resolves an issue where reconciling expenses linked to multiple legacy accounts would cause the system to crash. Now, when multiple expenses share a common account, the system correctly identifies it and allows reconciliation. This ensures accountants can accurately manage older expense data.
Original PR description
back port of #239539 The aim of this commit is to allow accountants to be able to reconcile legacy <account.move> linked to several expenses. Context: With the refactoring of the expense module, we made the assumption that an expense paid by the company will generate one <account.move>. This is True within the new system but is wrong regarding legacy data and those weren't adapted through an upgrade script. Before this commit: Trying to reconcile an <account.move.line> that is already linked to another one from which it's <account.move> is linked to several expenses will crash while we try to get the relevant account to compute the needed_terms on the <account.move>, even if all the expenses will result in giving back the same account. After this commit: We check if all the expense retrieve the same account. If they do, we just retrieve it. If not, we throw a UserError instead of a weird singleton error. opw-5930789 Forward-Port-Of: odoo/odoo#249132
This update fixes an issue where overpayments made via bank payment in Point of Sale didn't create accounting entries, leading to incorrect customer balances. The fix ensures that a necessary accounting line is created when a customer pays more than the order amount using a bank payment, accurately reflecting the transaction.
Original PR description
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the…
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the order amount with bank pm * Validate * Close register * Check customer > Observation: It says we owe the customer money, although change was given. Why the fix: ------------ Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it. Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted. opw-5149700 Forward-Port-Of: odoo/odoo#253311 Forward-Port-Of: odoo/odoo#247621