Daily updates from Odoo
Saturday, April 11, 2026
8 changes
2 changes
Resolved issues and error corrections
This update fixes an issue where users could bypass settings to create serial numbers on the shopfloor, even when serial number creation was disabled for manufacturing operations. This change ensures that the system correctly enforces the configured settings, preventing unintended serial number creation and maintaining data integrity.
Original PR description
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to…
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to reproduce**: - Enable "Lots & Serial Numbers", on the global settings - Create two products, one tracked by unique serial number - Go to Inventory > Configuration > Warehouse Management > Operations Types - Select Manufacturing and disable "Create New Lots/Serial Numbers for Components" - Create and confirm a MO using the tracked product as component - Go to shopfloor - Click the "+" button next to the component, then "New" -> No error is raised when creating a serial number **Cause**: The `_check_create` constraint relies on `active_mo_id`: https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19 However, the shopfloor does not pass this, in context: https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199 As a result, the check is bypassed. opw-6041241 Forward-Port-Of: odoo/enterprise#111408
This update fixes a potential issue where importing bills could cause a system crash due to excessive data processing. The change prevents Odoo from incorrectly matching purchase orders based on empty vendor references, which were causing a large number of purchase orders to be processed simultaneously. This improves the stability and performance of bill import operations.
Original PR description
Description of the issue/feature this PR addresses:
A Peppol message contains a reference with a trailing comma.
```
<cac:OrderReference>
<cbc:ID> Uw bestelling,</cbc:ID>
</cac:OrderReference>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID> Uw bestelling,</cbc:ID>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
```
Current behavior before PR:
A MemoryError occurs in `_cron_peppol_get_new_documents` because the trailing comma leads to a fetching hundreds of thousands of purchase orders with domain `[('partner_ref', 'in', [('Uw bestelling', '')]`
Desired behavior after PR is merged:
Purchase orders are not matched by empty reference.
opw-6102641
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258454
Forward-Port-Of: odoo/odoo#2578511 change
Resolved issues and error corrections
This update resolves issues with the Fiskaly integration by refining retry logic and ensuring correct SCU usage. Specifically, it now only retries on critical server errors, preventing masking of important API responses. Additionally, the configuration of the cash register is now more robust, improving the connection between the local and Fiskaly systems.
Original PR description
- Retry only on server errors (5xx) instead of client errors (4xx) to avoid masking meaningful API responses with a confusing RetryError. - Reuse the existing active SCU when E_SCU_LIMIT_REACHED is returned, since Fiskaly only allows one active SCU per account. - Pass the pos.config id as metadata when creating a cash register on Fiskaly, making it easier to match Fiskaly register IDs back to their config when the local link is broken. - Hide the test mode toggle once the company is registered with Fiskaly (l10n_at_fiskaly_organization_id is set) to prevent mode changes after registration. opw-5958673 Forward-Port-Of: odoo/enterprise#113496
1 change
Resolved issues and error corrections
This update resolves an issue preventing credit notes from being correctly exported to Mojeracun when a recipient bank account isn't specified. The fix addresses two underlying problems: a data handling error and an incorrect XML structure, ensuring credit notes are now generated without errors.
Original PR description
**Steps to reproduce:** * Install `l10n_hr_edi` module. * Generate an invoice and validate it. * Generate a credit note from that invoice. * Without a recipient bank account, try to send the credit…
**Steps to reproduce:**
* Install `l10n_hr_edi` module.
* Generate an invoice and validate it.
* Generate a credit note from that invoice.
* Without a recipient bank account, try to send the credit note to Mojeracun.
**Observed behavior:**
* Two errors are raised before the XML is generated:
1. `AttributeError: 'NoneType' object has no attribute 'get'` in `_invoice_constraints_eracun_new` when checking for whitespace in the bank account number.
2. `ValueError: The following child node is not defined in the template: CreditNote/cac:BillingReference/cbc:IssueDate` during XML serialization.
**Cause:**
* issue 1 : https://github.com/odoo/odoo/commit/96cf6626d2b3e75637b908244cf2fa4da615c16b#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R81
* In the mentioned commit `_invoice_constraints_eracun_new`, `node.get('cac:PayeeFinancialAccount', {})` returns `None` instead of `{}` when the key exists but its value is explicitly set to `None` (which happens when no bank account is set). Chaining `.get()` on `None` raises `AttributeError`.
* issue 2 : https://github.com/odoo/odoo/commit/47ef0c2cb96be9fffdc4985255661807980839c6#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R146
* In the mentioned commit in `_ubl_add_billing_reference_nodes`, `cbc:IssueDate` was added as a direct child of `cac:BillingReference`. The UBL template only allows `cac:InvoiceDocumentReference` as a child of `BillingReference`, while `cbc:IssueDate` belongs inside `cac:InvoiceDocumentReference`.
**Fix:**
* Replace `.get('cac:PayeeFinancialAccount', {})` with `.get('cac:PayeeFinancialAccount')` to safely handle an explicitly `None` value before chaining further calls.
* Move `cbc:IssueDate` inside `cac:InvoiceDocumentReference` in the `BillingReference` node, matching the structure defined in `ubl_21_common.py`.
opw-6088424
Forward-Port-Of: odoo/odoo#2580572 changes
Enhancements to existing features
This update enhances financial reporting by providing a 'coverage ratio' for each analytic plan. This allows users to easily identify if journal items are fully distributed across their planned analytics, which is crucial for accurate audit trails and financial reporting. It bridges a gap in reporting caused by Odoo's partial analytic distribution capabilities.
Original PR description
The objective is to bridge the gap between journal items and analytic items in the reporting. As Odoo allows for partial analytic distribution, this creates discrepancies in the P&L and BS when filtered by an analytic plan. This features aims to provide users with a clear 'coverage ratio' per plan to identify incomplete distributions during audits. task-5887978 Forward-Port-Of: odoo/enterprise#106750
Resolved issues and error corrections
This update fixes an issue where closing entries for OSS reports were incorrectly generated as standard tax returns. The change simplifies a process that previously caused a mismatch in document types, ensuring that OSS reports are now correctly identified and processed after posting. This improves accuracy in financial reporting for EU VAT compliance.
Original PR description
### Issue: When closing an OSS report, the generated tax closing entry was incorrectly identified as a standard Tax Return After posting, the document type remained `Tax Return` instead of the…
### Issue: When closing an OSS report, the generated tax closing entry was incorrectly identified as a standard Tax Return After posting, the document type remained `Tax Return` instead of the expected OSS report type ### Cause: In this PR: https://github.com/odoo/enterprise/pull/95775, a condition was simplified to unify closing moves across report variants However, this caused OSS reports to be treated as standard tax reports As a result, only one closing move could be created and reused for both Tax Reports and OSS Reports for the same period The document was also incorrect because of this simplification ### Steps to reproduce: - Install `l10n_nl` and switch to NL Company - Activate `EU Intra-Community Distance Selling` in Settings (reload taxes if needed) - Confirm invoices for a Belgian Customer using the tax 21% BE VAT - Go in Accounting > Reports > Tax Return - Select the report type OSS Sales and the quarterly period - Click `Closing Entry` - Post the entry A Tax Return document is created instead of an OSS report ### Other Fix: If a standard Tax Report closing entry is created first, the closing move becomes linked to it and is then incorrectly reused for the OSS report opw-5489822 opw-5882188 Forward-Port-Of: odoo/enterprise#112306
1 change
Resolved issues and error corrections
This update enhances the stability of the Odoo integration with Fiskaly, the Australian point-of-sale system. Specifically, it fixes issues with retry logic, ensures correct SCU limits are managed, and simplifies configuration tracking for easier troubleshooting. The changes also prevent test mode toggles after Fiskaly registration, improving data accuracy.
Original PR description
- Retry only on server errors (5xx) instead of client errors (4xx) to avoid masking meaningful API responses with a confusing RetryError. - Reuse the existing active SCU when E_SCU_LIMIT_REACHED is returned, since Fiskaly only allows one active SCU per account. - Pass the pos.config id as metadata when creating a cash register on Fiskaly, making it easier to match Fiskaly register IDs back to their config when the local link is broken. - Hide the test mode toggle once the company is registered with Fiskaly (l10n_at_fiskaly_organization_id is set) to prevent mode changes after registration. opw-5958673 Forward-Port-Of: odoo/enterprise#113496
1 change
Enhancements to existing features
This update enhances financial reporting by providing a 'coverage ratio' for each analytic plan. This allows users to easily identify if journal items are fully distributed across their planned analytics, which is crucial for accurate audit trails and financial analysis. It addresses discrepancies caused by Odoo's partial analytic distribution capabilities.
Original PR description
The objective is to bridge the gap between journal items and analytic items in the reporting. As Odoo allows for partial analytic distribution, this creates discrepancies in the P&L and BS when filtered by an analytic plan. This features aims to provide users with a clear 'coverage ratio' per plan to identify incomplete distributions during audits. task-5887978