Wednesday, February 4, 2026
6 changes · 17.0
Resolved issues and error corrections
This update resolves an issue where closing a Point of Sale (POS) session would fail due to incorrect SEPA payment processing. The fix prevents the POS from attempting to process SEPA direct debit payments when a customer's partner and bank account information isn't provided, ensuring smoother session closures.
Original PR description
SEPA expects a partner and a bank account. But the POS allows the user to sell to generic customers without a partner id or bank account. When SEPA direct debit is selected as the first incoming/outgoint payment method for the journal, closing the POS session will try to pos a SEPA payment which will fail when no partner is selected for the payment. We've identified this before and excluded SEPA credit transfer from point of sales for issues with closing sessions, but the issue is still happening with SEPA direct debit. This fix will exclude the SEPA DD from the list of payment methods the POS is trying to use to post the transactions. Task-[5358590](https://www.odoo.com/odoo/project/1737/tasks/5358590) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in the calculation of VAT payable or refundable when generating Welsh tax returns. The previous formula was incorrect, leading to inaccurate reporting. The change updates the formula to accurately reflect the difference between output and input VAT, ensuring compliance with Welsh tax regulations.
Original PR description
**Steps to produce:** - Install the l10n_cy and accountant modules - Switch to `CY Company`. - Go to accounting > reports > Tax return. **Issue:** - The formula for VAT payable or refundable (difference between box 4 and 3) is incorrect. - box 3 refers to `Total output VAT` and box 4 refers to `Input VAT`. - Current formula: `cy_4.balance - cy_3.balance` **Fix:** - Formula for VAT payable or refundable should be output VAT - input VAT. - Update the formula to: `cy_3.balance - cy_4.balance` <img width="769" height="86" alt="image" src="https://github.com/user-attachments/assets/923a92f9-fc57-465a-9592-771730ee6870" /> opw-5751369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where credit notes with early payment discounts triggered schematron errors during Peppol validation. The fix corrects a calculation error within the system that was incorrectly increasing taxable amounts instead of decreasing them, aligning with Peppol rules. This ensures credit notes with discounts are correctly validated and submitted.
Original PR description
Submitting a credit note with an early payment discount fails with schematron errors `BR-CO-17` and `BR-S-09`. The issue occurs because `_get_early_payment_discount_grouped_by_tax_rate` returns negative values for credit notes, which is not accepted by the Peppol validation rules since we will increase the `TaxableAmount` instead of decreasing them. Steps to reproduce: - Create a payment term with a 2% discount (always) - Create a credit note using this payment term - Submit the document to Peppol - Observe the schematron validation error opw-5357180 opw-5499252
This update resolves an error that occurred when deleting documents linked to sign request templates. The fix prevents the deletion of these documents, ensuring the sign template functionality continues to operate smoothly and avoids data inconsistencies. This improves stability and prevents potential disruptions to the sign process.
Original PR description
Currently an error was generated when autovalume _gc_clear_bin tries to delete documents from trash. Stack Trace: ``` ForeignKeyViolation: update or delete on table "sign_template" violates foreign…
Currently an error was generated when autovalume _gc_clear_bin tries to delete documents from trash.
Stack Trace:
```
ForeignKeyViolation: update or delete on table "sign_template" violates foreign key constraint "sign_request_template_id_fkey" on table "sign_request"
DETAIL: Key (id)=(13) is still referenced from table "sign_request".
File "odoo/addons/base/models/ir_autovacuum.py", line 38, in _run_vacuum_cleaner
func(model)
File "home/odoo/src/enterprise/saas-17.2/documents/models/documents_document.py", line 739, in _gc_clear_bin
], limit=1000).unlink()
File "home/odoo/src/enterprise/saas-17.2/documents/models/documents_document.py", line 727, in unlink
removable_attachments.unlink()
File "odoo/addons/base/models/ir_attachment.py", line 612, in unlink
res = super(IrAttachment, self).unlink()
File "odoo/models.py", line 4286, in unlink
cr.execute(SQL(
File "odoo/sql_db.py", line 346, in execute
res = self._obj.execute(query, params)
```
This is because '_gc_clear_bin' tries to delete attachments that are related to the sign request template and it generates a foreign key violation error.
This commit fixed the above issue by preventing the deletion of the documents that are related to the templates.
sentry-5565143437This update resolves an issue preventing the legal validation of the annual VAT report for Luxembourg companies. The fix adds missing required fields to the XML export, ensuring compliance with Luxembourg tax regulations. This ensures accurate reporting and avoids potential validation errors.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920
This fix resolves an issue where Modelo 390 reports for past years were incorrectly generating empty BOE files. The update ensures the report period is accurately identified, pulling the correct data for the specified year. This guarantees accurate tax reporting for Spanish businesses.
Original PR description
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report`…
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report` options However, `section_reports` do not store the date or return periodicity of the selected report As a result, using their options always fetched data for the current period instead of the specified year ### Note: `_generate_mod_390_page2()` also had issues: some lines were missing or incorrectly indexed The mod 360 format, it strict in the structure with specific index so it may produce invalid documents The latest documentation for mod 390: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` and switch to ES Company - Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025) - Open Tax Return, switch to Mod 390, and set year to 2025 - You should see data in the 2 first sections - Use the gear icon, and download the BOE - Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report opw-5457374