Saturday, September 19, 2026
3 changes · saas-19.1
Resolved issues and error corrections
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
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
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