Odoo Changelog — 2026-09-19

Saturday, September 19, 2026

5 changes · saas-19.1

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_pl_edi: correct NrKSeF and NrKSeFN tag logic

Coresaas-19.1l10n_pl_ediMedium

Credit notes for invoices already accepted in Poland's KSeF system now report the correct original KSeF number instead of incorrectly marking the invoice as issued outside KSeF. This helps keep Polish e-invoice XML exports compliant with official FA(3) requirements and avoids misleading tax reporting data.

Original PR description

### Issue before this commit: When generating a credit note for an invoice already accepted in the Polish KSeF system, the exported XML incorrectly includes the <NrKSeFN>1</NrKSeFN> tag. This tag…

### Issue before this commit:
When generating a credit note for an invoice already accepted in the Polish KSeF system, the exported XML incorrectly includes the <NrKSeFN>1</NrKSeFN> tag. This tag falsely indicates that the original invoice was issued outside of KSeF, and the official KSeF number of the corrected invoice is entirely omitted from the file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pl
2. Go to Settings > Polish Localization > Insert certificate
3. Go to Invoices > Create an invoice > Send it to KSeF
4. Create a credit note for that invoice, reverse it and send it to KSeF
5. Tag <NrKSeFN>1</NrKSeFN> should not be there

### Cause of the issue:
The tag <NrKSeFN>1</NrKSeFN> is emitted in every case without any rule handling it.

### Reason to introduce the fix:
To comply with the official FA(3) logical structure rules. According to the specifications, if the corrected invoice was issued and accepted in KSeF, the XML must include the <NrKSeF>1</NrKSeF> flag and additionally provide the original KSeF number in the <NrKSeFFaKorygowanej> field. Otherwise, if the original invoice was issued outside of KSeF, the system must enter "1" in the <NrKSeFN> field and strictly omit the <NrKSeF> and <NrKSeFFaKorygowanej> fields.

<img width="866" height="981" alt="image" src="https://github.com/user-attachments/assets/53b42f9f-aaab-4642-be38-2a5abc1d8539" />

opw-6541941

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#288286

#Poland#KSeF#e-invoicing#credit notes#compliance

[FIX] l10n_it: correct SP taxes imperfections

PR #289294

Coresaas-19.1l10n_itMedium

Italian Split Payment taxes are now reported with the correct VAT report calculation and invoice labels. This helps Italian companies produce more accurate VAT reports and clearer invoices for Split Payment transactions.

Original PR description

The`SP` (Split Payment) taxes have incorrect configurations: - **Tax Grid Tags on `SP` Taxes**: The ve38 grid tag was incorrectly assigned to the tax line instead of the base line. - **`VE38` VAT…

The`SP` (Split Payment) taxes have incorrect configurations:
- **Tax Grid Tags on `SP` Taxes**: The ve38 grid tag was incorrectly assigned to the tax line instead of the base line.
- **`VE38` VAT Report Formula**: In Tax Report > VAT Report, the line `VE38 - Transactions with parties referred to in Article 17-ter` was using a negative formula `-ve38` and should be `ve38`
- **Tax Group Invoice Label**: Updated the default label on invoices for the SP tax group to display 22% SP instead of 22%.

Steps to reproduce:
- Install `account` and `l10n_it`
- Switch to IT company
- Go to taxes and filter for `SP` taxes
- The tax grid is wrong for the negative taxes since `ve38` should be in the base line instead of in the tax line
- Go in the Tax report > VE VAT Report
- The line `VE38 - Transactions with parties referred to in Article 17-ter` has a negative formula `-ve38`, should be positive `ve38`
- The label on invoices of the tax group should be `4% SP`, `5% SP`, `10% SP` not `4%` etc.

References:
https://www.informazionefiscale.it/IMG/pdf/dichiarazione_modello_iva_2026_agenzia_delle_entrate.pdf
<img width="1413" height="141" alt="immagine" src="https://github.com/user-attachments/assets/7fa15859-beaa-4345-bf81-fedc3f0af2fa" />
https://fiscomania.com/quadro-ve-della-dichiarazione-iva/
<img width="705" height="154" alt="immagine" src="https://github.com/user-attachments/assets/4f23b407-0e4d-4104-9695-f9891ccfd2f2" />

Ticket [link](https://www.odoo.com/odoo/project.task/6543520)
opw-6543520

Forward-Port-Of: odoo/odoo#287238

[FIX] stock_account: Prevent cross-company last_in stock move search

PR #289295

Coresaas-19.1stock_accountMedium

Manufacturing costs now stay within the correct company when FIFO costing is used. This prevents products shared between companies from accidentally using purchase costs from another company, improving cost accuracy in multi-company setups.

Original PR description

**Problem**:
In a multi-company environment, while manufacturing a product, if the component of the product is visible for both company and there is no last_in stock move for the component in the current company, then the last_in stock move of the other company is used to compute the cost of the component. This only happens when the costing method of the product is FIFO

**Steps to reproduce:**
1. Create company A and company B.
1. Create a product A and set FIFO costing method to it.
2. Make a purchase order of product A in company A and receive it.
3. Create a product B with product A as its BOM material.
4. Create a MO of product B in company B and produce it.
5. The unit cost of product A in company B is using the unit cost from the purchase order of product A in company A.

**Fix**:
Add a company domain to the last_in stock move search to prevent cross-company last_in stock move search.

opw-6411216

Forward-Port-Of: odoo/odoo#280074

#fifo#multi-company#inventory valuation#manufacturing

[FIX] l10n_ar: apply refund sign once on report totals

PR #287483

Coresaas-19.1l10n_ar

Refund totals on certain Argentine invoice reports now show with the correct negative sign, matching the invoice lines. This prevents confusing or misleading totals for document types where VAT is not separately detailed.

Original PR description

Follow-up of #212153.

`_l10n_ar_get_invoice_totals_for_report` applies `_apply_refund_adjustments` twice on the same dict: once at the beginning and again right before excluding the tax groups that must not be detailed on the report. For document types where VAT is not detailed (letters B, C, X, R, e.g. codes 188 and 189 "Liquidación de compra directa sector pecuario") the second call undoes the first one, so the totals are printed in positive while the lines are printed in negative.

This PR removes the second call so the sign is applied only once, and adds a test covering the VAT-included path with document type 188.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#argentina#refunds#invoicing#reports

[FIX] base: let res.lang.flag_image_url be computed by an override

PR #289100

Coresaas-19.1base

Odoo now lets customizations change which flag image is shown for a language without redefining the whole field. This matters for businesses that need regional or market-specific language presentation while keeping upgrades simpler.

Original PR description

Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a…

Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a different flag for a language it offers, a regional one or the flag of the country it actually serves rather than the one the code names, has to compute that URL its own way.

That is not possible today. The field passes the compute as the function object:

    flag_image_url = fields.Char(compute=_compute_field_flag_image_url)

`determine()` takes the `callable` branch and calls that object with the recordset. A plain function is not bound, so the implementation of `base` runs whatever class the record has: a module that inherits res.lang and defines `_compute_field_flag_image_url` changes nothing, and nothing says so. No error, no warning, and the field keeps answering the same URL. Getting around it means redeclaring the field only to replace its compute, which is more than the situation calls for.

Passing the method name puts the computation back on the MRO and costs nothing else: `Field.get_depends` resolves a string with `resolve_mro` and collects `_depends` from every implementation it finds, so the `@api.depends('code', 'flag_image')` declared here keeps applying, to this implementation and to an override alike.

This is the same kind of fix as #185419, which made the `domain` of a field reachable by an override for the same reason. Two field declarations in the codebase still pass a function object this way; the other is `website.menu.is_mega_menu`, which passes `inverse` the same way and is left alone here.

Forward-Port-Of: odoo/odoo#288686

### Issue before this commit: When generating a credit note for an invoice already accepted in the Polish KSeF system, the exported XML incorrectly includes the <NrKSeFN>1</NrKSeFN> tag. This tag falsely indicates that the original invoice was issued outside of KSeF, and the official KSeF number of the corrected invoice is entirely omitted from the file. ### Steps to reproduce the issue: 1. Download Accounting and l10n_pl 2. Go to Settings > Polish Localization > Insert certificate 3. Go to Invoices > Create an invoice > Send it to KSeF 4. Create a credit note for that invoice, reverse it and send it to KSeF 5. Tag <NrKSeFN>1</NrKSeFN> should not be there ### Cause of the issue: The tag <NrKSeFN>1</NrKSeFN> is emitted in every case without any rule handling it. ### Reason to introduce the fix: To comply with the official FA(3) logical structure rules. According to the specifications, if the corrected invoice was issued and accepted in KSeF, the XML must include the <NrKSeF>1</NrKSeF> flag and additionally provide the original KSeF number in the <NrKSeFFaKorygowanej> field. Otherwise, if the original invoice was issued outside of KSeF, the system must enter "1" in the <NrKSeFN> field and strictly omit the <NrKSeF> and <NrKSeFFaKorygowanej> fields. <img width="866" height="981" alt="image" src="https://github.com/user-attachments/assets/53b42f9f-aaab-4642-be38-2a5abc1d8539" /> opw-6541941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288286

The`SP` (Split Payment) taxes have incorrect configurations: - **Tax Grid Tags on `SP` Taxes**: The ve38 grid tag was incorrectly assigned to the tax line instead of the base line. - **`VE38` VAT Report Formula**: In Tax Report > VAT Report, the line `VE38 - Transactions with parties referred to in Article 17-ter` was using a negative formula `-ve38` and should be `ve38` - **Tax Group Invoice Label**: Updated the default label on invoices for the SP tax group to display 22% SP instead of 22%. Steps to reproduce: - Install `account` and `l10n_it` - Switch to IT company - Go to taxes and filter for `SP` taxes - The tax grid is wrong for the negative taxes since `ve38` should be in the base line instead of in the tax line - Go in the Tax report > VE VAT Report - The line `VE38 - Transactions with parties referred to in Article 17-ter` has a negative formula `-ve38`, should be positive `ve38` - The label on invoices of the tax group should be `4% SP`, `5% SP`, `10% SP` not `4%` etc. References: https://www.informazionefiscale.it/IMG/pdf/dichiarazione_modello_iva_2026_agenzia_delle_entrate.pdf <img width="1413" height="141" alt="immagine" src="https://github.com/user-attachments/assets/7fa15859-beaa-4345-bf81-fedc3f0af2fa" /> https://fiscomania.com/quadro-ve-della-dichiarazione-iva/ <img width="705" height="154" alt="immagine" src="https://github.com/user-attachments/assets/4f23b407-0e4d-4104-9695-f9891ccfd2f2" /> Ticket [link](https://www.odoo.com/odoo/project.task/6543520) opw-6543520 Forward-Port-Of: odoo/odoo#287238

**Problem**: In a multi-company environment, while manufacturing a product, if the component of the product is visible for both company and there is no last_in stock move for the component in the current company, then the last_in stock move of the other company is used to compute the cost of the component. This only happens when the costing method of the product is FIFO **Steps to reproduce:** 1. Create company A and company B. 1. Create a product A and set FIFO costing method to it. 2. Make a purchase order of product A in company A and receive it. 3. Create a product B with product A as its BOM material. 4. Create a MO of product B in company B and produce it. 5. The unit cost of product A in company B is using the unit cost from the purchase order of product A in company A. **Fix**: Add a company domain to the last_in stock move search to prevent cross-company last_in stock move search. opw-6411216 Forward-Port-Of: odoo/odoo#280074

Follow-up of #212153. `_l10n_ar_get_invoice_totals_for_report` applies `_apply_refund_adjustments` twice on the same dict: once at the beginning and again right before excluding the tax groups that must not be detailed on the report. For document types where VAT is not detailed (letters B, C, X, R, e.g. codes 188 and 189 "Liquidación de compra directa sector pecuario") the second call undoes the first one, so the totals are printed in positive while the lines are printed in negative. This PR removes the second call so the sign is applied only once, and adds a test covering the VAT-included path with document type 188. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a different flag for a language it offers, a regional one or the flag of the country it actually serves rather than the one the code names, has to compute that URL its own way. That is not possible today. The field passes the compute as the function object: flag_image_url = fields.Char(compute=_compute_field_flag_image_url) `determine()` takes the `callable` branch and calls that object with the recordset. A plain function is not bound, so the implementation of `base` runs whatever class the record has: a module that inherits res.lang and defines `_compute_field_flag_image_url` changes nothing, and nothing says so. No error, no warning, and the field keeps answering the same URL. Getting around it means redeclaring the field only to replace its compute, which is more than the situation calls for. Passing the method name puts the computation back on the MRO and costs nothing else: `Field.get_depends` resolves a string with `resolve_mro` and collects `_depends` from every implementation it finds, so the `@api.depends('code', 'flag_image')` declared here keeps applying, to this implementation and to an override alike. This is the same kind of fix as #185419, which made the `domain` of a field reachable by an override for the same reason. Two field declarations in the codebase still pass a function object this way; the other is `website.menu.is_mega_menu`, which passes `inverse` the same way and is left alone here. Forward-Port-Of: odoo/odoo#288686