Friday, August 28, 2026
9 changes · 18.0
Enhancements to existing features
Companies sharing the same French SIREN in one database can now benefit from an already completed PDP registration check. This avoids repeating the same identity verification process for many branches or related companies, reducing manual work and speeding up onboarding.
Original PR description
We have some clients that have several hundreds of companies/branches on the same db, with the same SIREN (incubateur or the like). They will need to do the kyc (that will be identical, as it's the same SIREN) for all the companies. It's especially cumbersome if it needs manual intervention So, if one company on that database, with the same SIREN, managed to register, then it means it has succeded the kyc. Meaning we can bypass the kyc for the other identifiers as well. task-6515315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285236
French B2G invoices are now identified through the official directory and routed to Chorus Pro instead of Peppol when the customer is linked to that government platform. Users will see minimal workflow changes, but must provide the Chorus Pro-specific invoice details needed for compliant public-sector e-invoicing.
Original PR description
B2G invoices are not sent via Peppol but to Chorus Pro (via the approved platform). Chorus Pro is the platform with ID 9999 on the annuaire. Any invoice to partner associated with that platform on…
B2G invoices are not sent via Peppol but to Chorus Pro (via the approved platform). Chorus Pro is the platform with ID 9999 on the annuaire. Any invoice to partner associated with that platform on the annuaire is considered B2G (business to government). From a user point of view nothing much changes, except that they have to set some additional fields for which we rely on the existing module `l10n_fr_facturx_chorus_pro`. From a technical PoV we store the information whether a partner is behind Chorus Pro in the `peppol_supported_documents` field. (By putting the special document identifier for Chorus Pro invoices there.) We retrieve the information whether a partner is behind Chorus Pro / B2G from the annuaire lookup. The following new lifecycle statuses have been added. They are required for the functional tests for the Chorus Pro connection. - Sent (sent by the platform) - Suspended - Completed (to "resume" the "Suspended" state) See the related IAP PR: https://github.com/odoo/iap-apps/pull/1804 task-6278159
This update improves inventory and sales workflows by adding clearer delivery information, customer contact details, and export support for ADT orders. Business users should see more complete shipping addresses, simplified inventory screens, and better order data handling.
Original PR description
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
Resolved issues and error corrections
The Assets list view now avoids a repeated reload loop when an asset contains outdated or invalid analytic distribution data. This keeps the asset list accessible for users, even if some underlying analytic account references need cleanup.
Original PR description
Issue - If there are any account.asset records with analytic distributions with accounts that do not exist, it causes a recursive traceback when opening the list view of the `account.asset` model. The issue stems from `jsonToData` attempting to save the distributions json via the `save` call, where one (or multiple) accounts are non existent, which in turn runs `jsonToData` after refetching via the `load` call - overwriting `record.data` with the original, still-corrupt JSON. This creates a loop with no exit condition. Solution - In the Assets list every row is readonly, so `save()` is never reached, so `root.load()` never fires, so there is no reload to re-read the corrupt JSON. Makes the list accessible, even though the JSON values for the `analytic_distribution` are invalid. opw-6500446
Fixes an issue where Factur-X e-invoices received through Peppol could fail to import properly because the embedded XML was not read before checking the invoice type. This prevents empty or incomplete records from being created and improves handling of self-billed invoices in the French e-invoicing flow.
Original PR description
When importing new documents from Peppol into the database, we determine whether they are self-billed by checking a Type Code in the XML file. Factur-X is an hybrid format where the XML is embedded inside a PDF. Currently, we are not extracting the XML before searching for that Type Code, and it leads to an error that prevents the document from being imported correctly: - V17, V18: An empty invoice is created and linked with the attachment. - V19+: Only the attachment is created. Additionnaly, we only check for InvoiceTypeCode or CreditNoteTypeCode, but the CII XML format embedded inside the hybrid Factur-X format use TypeCode instead. This PR aims at fixing both these issues. Ticket: opw-6417682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280714
This fix corrects Malaysian payroll calculations for SOCSO and Employment Insurance contributions so employee net pay matches expected official contribution amounts. It also resolves duplicated deductions and aligns employer contribution display signs, improving payroll accuracy and reporting clarity.
Original PR description
There was a difference between the actual and expected NET. **Causes** - rules existed for both SOCSO Act 800 and EIS, but Act 800 seems to be the official name of the Employment Insurance System…
There was a difference between the actual and expected NET. **Causes** - rules existed for both SOCSO Act 800 and EIS, but Act 800 seems to be the official name of the Employment Insurance System (source: https://www.perkeso.gov.my/images/dokumen/Rate_of_Contribution_ACT_800.pdf). Keep the ACT 800 one as its matches the expected amount. - there was a double counting of the SOCSO employee contributions (4 and 800) , as `l10n_my_rule_socso_employee` (the sum of both) was added to the total deductions. **Change** Before: 3500/month wage results in a 3108 NET. <img width="1181" height="533" alt="before" src="https://github.com/user-attachments/assets/cdf4420f-e2cf-4dc7-9488-6bde3f1f9961" /> After: 3500/month wage results in a 3090.85 NET: - 6.90 SOCSO Act 800 Employee - 6.90 SOCSO Act 800 Employer - 17.25 SOCSO Act 4 Employee - 60.35 SOCSO Act 4 Employer Which seems consistent with online sources (https://payroll.my/) <img width="1181" height="425" alt="after" src="https://github.com/user-attachments/assets/7fb41186-dbb4-4d7a-ac9a-14fb56efc4bc" /> Other fix: while not affecting the calculation, 'SOCSO Employer Share' appeared as incorrect, the two rules SOCSO_800_EMPLR and SOCSO_4_EMPLR should have the same sign. opw-5976362
This fixes a navigation problem in Helpdesk where opening tickets from a team reached through an email alias could show an error instead of the ticket list. The system now uses the correct Helpdesk Team information, so users can access related tickets normally.
Original PR description
### Steps to Reproduce: 1. In Debug mode, go to Aliases 2. Click on any active Alias, ex. customer-care 3. Click on "Open Parent Document" smart button 4. Click on "Tickets" smart button and observe…
### Steps to Reproduce: 1. In Debug mode, go to Aliases 2. Click on any active Alias, ex. customer-care 3. Click on "Open Parent Document" smart button 4. Click on "Tickets" smart button and observe error ### Description of the issue/feature this PR addresses: **Issue:** When navigating from an email alias to its parent document (e.g., a Helpdesk Team), the web client incorrectly retains the `active_id` and `active_model` of the alias in the context. **Solution:** We updated the `action_view_ticket` method in `helpdesk.team` to explicitly inject the correct `active_model` and `active_id` into the context before calling `_for_xml_id`. This overwrites the polluted Alias data before the window action is evaluated. ### Current behavior before PR: Clicking the "Tickets" smart button passes the old alias context into the action. This bad data flows into the ticket view, which attempts to look up a Helpdesk Team using the Alias's ID to generate the empty list help message, resulting in a `MissingError`. ### Desired behavior after PR: The Python action sanitizes the context at the source, ensuring that the XML action and subsequent view evaluations receive the correct Helpdesk Team ID. Ultimately, the view will load normally without crashing. opw-6395638
This fix keeps timesheet entries connected to the correct replacement invoice when an invoice is reversed and recreated through a credit note. It helps ensure businesses retain accurate billing traceability for timesheet-based services and prevents replacement invoices from losing their supporting timesheet references.
Original PR description
### Description of the issue/feature this PR addresses: Fixes an issue where timesheets lose their invoice reference when reversing and re-creating an invoice via a credit note. ### Current behavior…
### Description of the issue/feature this PR addresses: Fixes an issue where timesheets lose their invoice reference when reversing and re-creating an invoice via a credit note. ### Current behavior before PR: When reversing an invoice tied to timesheets and creating a replacement via a credit note, the timesheets linked to the original invoice have their timesheet_invoice_id cleared. Because the modify_moves function builds the replacement invoice directly via copy_data()/create(), it bypasses the normal sale order invoicing flow. As a result, the unbilled timesheets are left permanently unlinked from the newly created invoice, leaving the new invoice with no reference to the timesheets linked to the original sale order. ### Desired behavior after PR is merged: When a replacement invoice is created, each timesheet is properly relinked to the corresponding line on the new invoice. This linkage matches on the sale order line (so_line) rather than line position, ensuring accuracy since line order and count are not guaranteed to be preserved between the original and modified invoices. opw-6449995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283104
Fixes an error that could block updates to manufacturing work orders when one task had already started and another task's duration was changed. This keeps production teams able to start, pause, complete, and adjust work orders reliably from the list view.
Original PR description
On a not-planned manufacturing order with at least 2 workorders:
- start one of them (this makes 'is_planned' true)
- change the duration of another one
This gives the error:
TypeError:
'<' not supported between instances of 'datetime.datetime' and 'bool'
Origin is within _set_duration where no leave is created when changing
the state for 'progress'.
This issue occurs within _plan_workorders when a workorder is ready
with no leave_id, so fix in this function to handle future origins.
Note that if none of the workorders are started, the error does not occur.
Workorders list view has been fixed to accomodate Start, Pause & Done buttons on such workorders.
opw-4497704
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr