Daily updates from Odoo
Monday, June 1, 2026
13 changes
1 change
New functionality added to Odoo
This update implements French electronic invoicing reporting (Flux 10) to comply with new tax regulations. It handles B2C and international B2B transactions, ensuring accurate tax data is reported to the French authorities on a periodic basis. Enhanced security measures, including 2FA and KYC, are also included.
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
2 changes
New functionality added to Odoo
This update enables Odoo to comply with new French regulations requiring electronic reporting of B2C and international B2B transactions. It introduces a ‘Flux 10’ system for sending structured data to tax authorities, enhancing data accuracy and security through mandatory 2FA and KYC verification.
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
This update streamlines KPI data retrieval across our servers by using a simplified SQL approach. Instead of loading separate registry data for each database, a new API endpoint accepts credentials and calls KPI providers directly. This significantly speeds up KPI generation and reporting.
Original PR description
In order to improve speed of KPI retrieval on servers hosting many databases, we need to avoid loading a registry for each of them. With this commit, we introduce a route /kpi/summary that accepts a list of credentials in the form of pairs of database name and API key. The API key needs to be local to the database. Modules providing KPIs need to declare a method named `get_kpi_summary` in a file named `models/kpi_provider.py`, and it will return the exact same structure as the previous API `kpi.provider:get_kpi_summary`. The existing ORM-called methods now call the SQL version in order to avoid divergences in the future. Task-id: [5167731](https://www.odoo.com/odoo/project.task/5167731) Forward-Port-Of: odoo/odoo#267347 Forward-Port-Of: odoo/odoo#258050
1 change
New functionality added to Odoo
This update implements French e-reporting requirements for B2C and international B2B transactions, ensuring compliance with new tax regulations. It introduces a period-based system for reporting transaction data to the French tax authorities, enhancing data accuracy and security through stronger authentication measures.
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
1 change
New functionality added to Odoo
This update enables Odoo to comply with new French tax regulations requiring electronic reporting of business transactions. It introduces a system for sending transaction and payment data to the tax authorities in a structured format, specifically for B2C and international B2B sales, ensuring accurate tax reporting and compliance.
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
6 changes
New functionality added to Odoo
This update introduces a new module, `obox_pos`, to seamlessly integrate Obox connected scales into the Point of Sale (PoS) system. This allows for accurate weight-based product tracking and order processing within Obox, improving operational efficiency and data accuracy.
Original PR description
We add a new `obox_pos` module to integrate Obox connected scales to PoS.
This update integrates Obox receipt printers into the Point of Sale (POS) system. Leveraging the Obox's ePOS format compatibility, the change simplifies printer configuration and utilizes existing EpsonPrinter code, improving POS functionality. This allows for seamless printing of receipts from Obox printers.
Original PR description
See: odoo/obox#152 This commit adds support for Obox receipt printers in the POS. Since the Obox now supports the ePOS format, most of the ePOS code can be reused. Configuring an Obox printer simply prefills the IP with the correct path and the POS just uses the same EpsonPrinter class as normal. task-6241706
This update introduces a new Kanban view within the Obox app, allowing users to easily manage and track all connected devices grouped by their respective Obox. When an Obox is paired, the system automatically initiates a device discovery process, streamlining device setup and management. This improves the overall user experience for Obox device integration.
Original PR description
This commit adds a 'Devices' menu item to the Obox app, which links to a Kanban view of all the devices grouped by Obox. In addition, a device discovery is automatically started once an Obox has been paired. <img width="892" height="340" alt="image" src="https://github.com/user-attachments/assets/42d4a421-0185-4cdf-982f-55eb241e60de" /> task-6241705
This update introduces support for calculating the 'Cotisation Wijninckx,' a Belgian payroll tax related to group insurance. Eligibility is determined by a government letter and the tax rate is 12.5% of the declared amount. This ensures accurate tax reporting for employees with qualifying group insurance.
Original PR description
Purpose: When you have a group insurance and the amount of the group insurance is exceeding a specific amount, you'll be eligible to the "Cotisation Wijninckx" To know if you're eligible or not, it's based on a letter sent by the government to you, or to your payroll company. If you're eligible, they'll communicate you the amount to tax for that cotisation, the amount to pay is 12.5% of the declared amount. Current Behavior: - add a new salary rule input for Cotisation Wijninckx - add a rule parameter for the rate of the cotisation with value 12.5% starting on 1/1/2026 - declare the Cotisation Wijninckx under code 868 in the DMFA if it's present task-id: 6201188
This update allows companies to configure and manage employee contributions towards hospitalization insurance premiums. It automatically deducts these contributions from employee salaries via payroll, providing greater flexibility and control over benefits. The changes standardize settings and improve data management for company-specific insurance configurations.
Original PR description
**Purpose** In some companies, employees pay part of the hospitalization insurance premium themselves. This contribution must: - be configurable at the company level - be automatically applied to employees enrolled in hospitalization insurance, - and be deducted from the employee’s net salary through payroll computation. **Specifications** This PR implements the employee contribution workflow as follows: - Add a company level setting defining the default employee contribution amount. - Initialize the employee contribution field from company settings when hospitalization insurance is enabled on the employee. - Allow editing the contribution per employee. - Add a salary rule that deducts the employee contribution from the payslip. - Ensure the rule is computed before `NET` salary. task-6111061
This update adds a new report, MUHSGK V2 (1003B), required for Turkish clients to submit monthly payroll data to the SGK and GİB authorities. This ensures compliance with Turkish regulations regarding withheld taxes and social insurance contributions, streamlining reporting processes.
Original PR description
On a monthly basis, all clients in Turkey are obligated to submit reports to the social insurance entity (SGK) and the revenue authority (GİB). The reports include details about the employee, employer, and amounts deducted from the employee's salary to be submitted to the authorities. The main report for this task is the MUHSGK V2 (1003B), which is a combined report for both withheld taxes from employees' salaries and withheld amounts for social insurance. task-id: 4966571
1 change
New functionality added to Odoo
This update introduces a new reporting tool for finance teams to analyze sales profitability after month-end closing. It provides post-period margin analysis by partner, product, and invoice, leveraging existing accounting and stock data without altering core accounting processes. This allows for deeper insights into sales performance.
Original PR description
### Sales Contribution Margin Reporting (CM1–CM5) This PR introduces a contribution margin reporting layer on top of Accounting and Stock valuation data. The report provides post-period margin…
### Sales Contribution Margin Reporting (CM1–CM5) This PR introduces a contribution margin reporting layer on top of Accounting and Stock valuation data. The report provides post-period margin analysis for CFO/controller use after month-end closing. It is a read-only reporting extension and does not modify any accounting or stock entries. **Scope** Adds Sales Contribution Margin report under Accounting reporting: - Sales Contribution Margin (By Partner) - By Product - By Invoice **Margin model** CM1 Direct margin based on accounting and stock valuation: - FIFO / AVCO: stock valuation layers - Standard cost fallback: standard_price * qty - Services / dropship: zero direct cost CM2–CM5 Optional cost layers based on account tags: - cm2_cost - cm3_cost - cm4_cost - cm5_cost **Overhead allocation** - Pro-rata allocation based on revenue share - Period-based (accounting date) **Configuration** Account tags defined in: Accounting > Configuration > Account Tags Tag names: - cm2_cost - cm3_cost - cm4_cost - cm5_cost **Design constraints** - Read-only reporting layer - No changes to accounting entries - No impact on posting or valuation logic - No demo data dependency
1 change
New functionality added to Odoo
This update enables Odoo to comply with new French regulations requiring electronic invoicing via an approved platform. It introduces support for the French Peppol standard, utilizing a specific identifier format and XML invoice formats, and integrates a 2FA requirement for registration and invoice sending.
Original PR description
On September 1 electronic invoicing will become mandatory in France. For this we need to send our invoices to an approved platform. Before the Septemer 1 the users can participate in the pilot phase…
On September 1 electronic invoicing will become mandatory in France. For this we need to send our invoices to an approved platform. Before the Septemer 1 the users can participate in the pilot phase to test if they wish. This module adds support to connect to do the e-invoicing via the Odoo approved platform. The electronic invoicing is a 5-corner peppol model. So it is basically Peppol and the access points send regulatory information to the government. The Regulatory information are tax information (XML extracted from the invoice XML) and some lifecycle messages. The French e-invoicing uses a dedicated peppol identifier format. - The `0225` peppol scheme is reserved for French tax payers and managed by the French authorities and the approved platform network. - The peppol identifier for this scheme has one of the following formats: SIREN, SIREN_SIRET, SIREN_SIRET_CodeRoutage or SIREN_SuffixeAdressage. There the CodeRoutage and SuffixeAdressage are new and free identifiers respectively. The annuaire is a place that lists all peppol identifiers for French tax payers. It's role is to track the platform each tax payer is using to send / receive their electronic invoices. So i.e. it is used to associate a platform to each peppol identifier with scheme `0225`. This module depends on / extends the standard Peppol module `account_peppol` to work. So it basically works the same except that - we are connected to the Odoo approved platform instead of the Odoo peppol acces point - we look up the partners in the annuaire when they are french taxpayers (instead of via peppol directly) - (some) lifecycle messages are mandatory to support - it uses special XML formats for invoices and lifecycle messages In terms of XML formats this commit adds - the special French UBL invoicing format in model "account.edi.xml.ubl_21_fr" - support for parsing for lifecycle messages in the format CDAR (CrossDomainAcknowledgementAndResponse) The code for the Odoo approved platform is added in the IAP PR https://github.com/odoo/iap-apps/pull/1435 task-4603737 task-5060323 task-5183084 task-6193378