Thursday, June 26, 2025
8 changes · 17.0
Enhancements to existing features
Hungarian electronic invoicing now carries the delivery date from the original invoice onto related credit and debit notes. This improves consistency in invoice corrections and helps keep Hungarian EDI documents aligned with expected reporting details.
Original PR description
This **PR** enhances the default values for Hungarian electronic invoicing (EDI) by ensuring the delivery date is copied from the original invoice to the corresponding credit or debit note. **task**-4818819
Resolved issues and error corrections
Romanian eTransport exports now convert Greece's country code from GR to the EU VAT-standard EL where required. This helps prevent validation errors when sending transport documents involving Greek partners or transporters.
Original PR description
Added a mapping for EU VAT country codes to ensure that the VAT prefix aligns with EU standards (e.g., 'GR' -> 'EL') in EDI exports. ## Description of the issue/feature this PR addresses: This PR…
Added a mapping for EU VAT country codes to ensure that the VAT prefix aligns with EU standards (e.g., 'GR' -> 'EL') in EDI exports. ## Description of the issue/feature this PR addresses: This PR adds country code mapping functionality to ensure compatibility with the format required by the Romanian eTransport system. Specifically, it adds the conversion of the country code "GR" (Greece) to "EL" according to European VAT standards and applies this mapping to relevant fields in transport documents. ## Current behavior before PR: Before this PR, the country code for Greece was sent as "GR" to the eTransport system, which could cause validation errors because in European VAT systems, Greece is identified by the code "EL". Also, there was no consistent mapping for country codes in different parts of the system. ## Desired behavior after PR is merged: After implementing this PR, country codes will be correctly mapped to comply with European VAT standards, especially the conversion of "GR" to "EL" for Greece. This ensures that documents sent through eTransport contain the correct country codes and will pass system validations. The mapping is applied to country codes for both commercial partners and transporters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
@moduon MT-10568 MT-10569 MT-10567 MT-10566 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214739
Original PR description
@moduon MT-10568 MT-10569 MT-10567 MT-10566 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214739
Hardware driver devices now check whether the filesystem is writable before attempting to change it back to read-only mode. This prevents unnecessary error messages during background system updates and helps keep device logs cleaner while maintaining read-only protection over time.
Original PR description
If a process was holding the filesystem in r/w mode (e.g. apt upgrade), we were getting a "mount point is busy" error polluting logs. We now check the filesystem mount mode (r/w or r/o) before trying to remount it. Also, we removed the lock, allowing multiple threads to use the context manager at the same time. This avoids many unnecessary `subprocess` calls, unnecessary remount r/o if another thread needs to write on the system, and avoids polluting the logs. To ensure system is remounted r/o after the background process is done, we now check and remount every 30 minutes. Task: 4551009
The fix restores the Commodity Code field for storable products when Intrastat is enabled. This helps businesses correctly classify goods for Intrastat reporting and avoids missing product data after installing inventory features.
Original PR description
**Steps to reproduce:** - Install account_accountant - In Accounting settings, activate Intrastat - When creating a product, it is possible to set a Commodity Code for a consumable product and a Service Code for a service product - Install stock - Create a product **Issue:** Commodity Code field is invisible for storable products. **Cause:** In "account_intrastat_services" module, the invisible property of "intrastat_code_id" field for non-service products is overridden to: `type != 'consu'` Therefore, the field is not displayed for storable products. opw-4886050
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number. Current behavior before PR: Duplicated sequence numbers are generated Desired behavior after PR is merged: Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number
Original PR description
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and…
Description of the issue/feature this PR addresses:
if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number.
Current behavior before PR:
Duplicated sequence numbers are generated
Desired behavior after PR is merged:
Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number duplication
Script I used to reproduce the issue:
```python
import threading
import xmlrpc.client
url = 'http://localhost:8069'
db = 'db_name'
username = 'admin'
password = 'admin'
common = xmlrpc.client.ServerProxy('{}/xmlrpc/2/common'.format(url))
uid = common.authenticate(db, username, password, {})
models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(url))
models.execute_kw(db, uid, password, 'ir.sequence', 'unlink', [models.execute_kw(db, uid, password, 'ir.sequence', 'search', [[('code', '=', 'test.sequence')]])])
models.execute_kw(db, uid, password, 'ir.sequence', 'create', [{
'name': 'Test Sequence',
'code': 'test.sequence',
'prefix': 'TEST-',
'suffix': '/%(month)s/%(range_year)s/10001',
'padding': 1,
'number_increment': 1,
'use_date_range': True,
}])
def get_sequence_number():
return models.execute_kw(db, uid, password, 'ir.sequence', 'next_by_code', ['test.sequence'])
for i in range(5):
threading.Thread(target=get_sequence_number).start()
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210277Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation. Forward-Port-Of: odoo/enterprise#88341
Original PR description
Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation. Forward-Port-Of: odoo/enterprise#88341
How to reproduce the issue: With l10n_es on an ES company: - Create an invoice from two months ago with a value of 1000. - Fully credit note this invoice on the current month. - On the mod 349 report, download the BOE report. The BOE report does not contains the rectification despite being mandatory as per: https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES). This commit also fixes an issue where invoice reve
Original PR description
How to reproduce the issue: With l10n_es on an ES company: - Create an invoice from two months ago with a value of 1000. - Fully credit note this invoice on the current month. - On the mod 349 report, download the BOE report. The BOE report does not contains the rectification despite being mandatory as per: https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES). This commit also fixes an issue where invoice reverted to draft where included in the boe report: - Create an invoice of 100 in January, credit note 50 in May. - Reset to draft both the invoice and the credit note. - Create another invoice of 888 in February, credit note 444 in May. - Generate the BOE report. The invoice reverted to draft is included in the boe report. opw-4653025 Forward-Port-Of: odoo/enterprise#86127