Saturday, May 30, 2026
2 changes · 19.0
New functionality added to Odoo
Adds support for France's mandatory electronic reporting and invoicing reforms, including period-based Flux 10 reports for B2C and international B2B transactions. It also strengthens compliance controls by requiring authentication, 2FA, and company identity checks before using regulated PDP services.
Original PR description
France’s electronic invoicing reform : The tax administration needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B…
France’s electronic invoicing reform : The tax administration needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C. This creates two complementary obligations: - **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow. - **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based). ## Scope Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information. Flux 10 is introduced for transactions that must be reported separately: - B2C transactions, where there is no buyer-side e-invoice exchange. - International B2B transactions, where the counterparty is outside the French domestic B2B mandate. - Payment reporting when VAT exigibility depends on collection. The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines. ## Corrections and Lifecycle Flux 10 supports both: - **Initial reports**, for the first declaration of a period. - **Rectificative reports**, when already reported data must be corrected or completed. This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted. ## Security and Eligibility This PR also enforces stronger safeguards before using PDP/PA services. - **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app. - **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure. Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform. Task-4603708 Forward-Port-Of: odoo/odoo#239576
Resolved issues and error corrections
This update fixes a performance issue in the VAT Books ES report that caused crashes due to excessive memory usage when processing large invoice volumes. By implementing batch processing and clearing the ORM cache, the report now runs reliably and efficiently, even with thousands of invoices, improving server stability and speed.
Original PR description
### Description of the issue/feature this PR addresses: This PR introduces batch processing to the VAT Books ES (Libros de IVA) report generation. When attempting to export the report for periods…
### Description of the issue/feature this PR addresses: This PR introduces batch processing to the VAT Books ES (Libros de IVA) report generation. When attempting to export the report for periods containing a massive volume of invoices, the ORM cache continuously accumulates records, leading to severe memory consumption. By implementing batching and explicitly clearing the environment cache, use memory use will remain stable and efficient. ### Current behavior before PR: Generating the VAT Books report loads all account move lines into memory at once. Because the ORM cache is never cleared during the iteration, RAM usage spikes continuously. On databases with tens or hundreds of thousands of invoices in a single period, this leads to significant performance degradation, worker timeouts, or complete Out-Of-Memory (OOM) crashes. ### Desired behavior after PR is merged: The report engine now splits the recordset into manageable batches (e.g., 50,000 accounts per batch). After processing each chunk to extract the income and expense line values, invalidate_model() is called to flush the ORM cache related to the searched records. This frees up memory continuously, keeping the server's RAM usage flat and allowing the successful export of massive datasets without crashing. ### Benchmark: The model is iterating through ~1.1M account move lines when generating the full report. For Memory: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~77,000 account move lines | 385 MB | 666 MB | | ~340,000 account move lines |1.2 GB | 1.5 GB | | ~1.2M account move lines | MemoryError | 1.5 GB | For Speed: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~77,000 account move lines | 32s | 12s | | ~340,000 account move lines | 2:29min | 1:11min | | ~1.2M account move lines | MemoryError | 4:11min | ### Reference opw-6037414 ----------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)