Daily updates from Odoo
Wednesday, August 12, 2026
3 changes · master
New functionality added to Odoo
A new DHL shipping connector is being added using DHL’s recommended MyDHL REST API, replacing the older XML-based approach that DHL is retiring. This helps keep DHL shipping services compatible with current provider standards and reduces future disruption risk for businesses using DHL delivery.
Original PR description
This new module should replace the existing implementation for DHL integration which uses XML and is no longer recommended by DHL: https://developer.dhl.com/dhl-express-xml-developer-portal-sunset. The new integration uses ["MyDHL API"](https://developer.dhl.com/api-reference/dhl-express-mydhl-ap) which is based on REST. Upgrade PR: odoo/upgrade#6090 Task-3759205
Enhancements to existing features
Indian GSTR-1 report exports now handle large accounting datasets much faster and with far less memory. This reduces the risk of export failures for high-volume businesses and makes compliance reporting more reliable.
Original PR description
Current Implementation: ======================= The current implementation of _get_l10n_in_gstr1_json relies on multiple iterations over ORM recordsets. Since the ORM loads multiple fields rather…
Current Implementation: ======================= The current implementation of _get_l10n_in_gstr1_json relies on multiple iterations over ORM recordsets. Since the ORM loads multiple fields rather than only the required fields, memory consumption grows significantly for large datasets (around 700 MB for 150K account move lines). Additionally, the method builds a single large dictionary from _get_tax_details that is tailored for the Indian GST reporting logic. Constructing and holding this intermediate data structure further increases memory usage. The combination of repeated Python loops, ORM overhead, and the large intermediate dictionary results in high execution time and memory consumption, causing the process to exceed the available time and memory limits for large exports. Solution: ========= Instead of processing tax details through the ORM, create a temporary table containing the GST tax details and query this subset directly for each GSTR-1 subsection. This approach bypasses the ORM, fetching only the required columns instead of entire records. Eliminates the need to build the large _get_tax_details dictionary. Reduces the number of Python-side iterations and intermediate data structures. Pushes the data aggregation and filtering to SQL, where it is more efficient. Restricts Python's responsibility to formatting the final JSON output. This significantly reduces memory usage, improves execution speed, and makes the implementation simpler and easier to maintain. Benchmark Performance Results: ============================== ```text +-----------+-------------+----------------------+------------------+ | Size | Parameter | Current Version | IMPROVED SQL + | | | | | Indian Reports | +-----------+-------------+----------------------+------------------+ | 150K AMLs | Time | 28.19s | 2.18s | | +-------------+----------------------+------------------+ | | Peak Memory | 711 MB | 34.7 MB | +-----------+-------------+----------------------+------------------+ | 250K AMLs | Time | 64s | 3.68s | | +-------------+----------------------+------------------+ | | Peak Memory | 1.4 GB | 58.5 MB | +-----------+-------------+----------------------+------------------+ | 500K AMLs | Time | 208s | 7.33s | | +-------------+----------------------+------------------+ | | Peak Memory | 2.7 GB | 114.8 MB | +-----------+-------------+----------------------+------------------+ | 1M AMLs | Time | Memory Limit (7 GB+) | 15.07s | | +-------------+----------------------+------------------+ | | Peak Memory | Memory Limit (7 GB+) | 230.7 MB | +-----------+-------------+----------------------+------------------+ | 2M AMLs | Time | Memory Limit (7 GB+) | 28.20s | | +-------------+----------------------+------------------+ | | Peak Memory | Memory Limit (7 GB+) | 461.4 MB | +-----------+-------------+----------------------+------------------+ ``` ref - https://drive.google.com/drive/folders/10I8gJmGgZVAMW8te_GFg5lleTUW1Nku1?usp=drive_link -------------------------- task-3941950 Community PR - https://github.com/odoo/odoo/pull/274381
Belgian payroll now automatically carries forward and recovers negative net salary amounts through payslip rules instead of relying on manual reporting. This reduces manual follow-up for payroll teams and adds targeted warnings when unrecovered amounts remain at year-end or employee departure.
Original PR description
Previously, payslips with negative net amounts relied on a manual reporting action (`action_report_negative_net_amount`) and a generic dashboard warning. This commit removes the legacy negative net reporting mechanism and replaces it with an automated salary-rule-based net recovery process in Belgian payroll: - Removed legacy `action_report_negative_net_amount`, warning helper, and `hr_payroll_warning_negative_net_to_report` record from `hr_payroll`. - Added `NET_TO_RECOVER` and `NET_ALREADY_RECOVERED` salary rules to automatically offset negative net salary and deduct prior debt. - Added `_get_net_to_recover_amount` helper method on `hr.payslip` to calculate and apply accumulated debt recovery across payslips. - Overrode `action_payslip_done` to automatically mark payslips with net amount <= 0 as 'paid'. - Added a Belgian payroll warning for December or departure payslips when an unrecovered net amount remains. Task: 6413612