Saturday, August 29, 2026
6 changes · saas-18.3
New functionality added to Odoo
Greek customer invoices can now be issued through e-invoo, an AADE-certified provider, instead of being sent directly to myDATA. This helps Greek businesses meet local legal requirements for electronic invoicing while keeping the process integrated in Odoo.
Original PR description
Greek customer invoices were transmitted directly to myDATA, but this is not legally compliant as odoo is not AADE-certified yet. Add a bridge module that routes outgoing Greek invoices through the Greek EDI IAP service and e-invoo, an AADE-certified YPAHES provider. IAP PR: [1788](https://github.com/odoo/iap-apps/pull/1788) task-[6395556](https://www.odoo.com/odoo/project/967/tasks/6395556) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281739
Enhancements to existing features
French electronic invoices to public-sector customers are now identified and routed through Chorus Pro instead of Peppol when the customer is listed behind the Chorus Pro platform. This improves compliance for business-to-government invoicing in France while reusing existing Chorus Pro invoice fields and statuses.
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 Forward-Port-Of: odoo/odoo#284677
Resolved issues and error corrections
Refreshing a Twitter/X social feed no longer shows a generic error when an account token has become invalid. Instead, the system can handle the invalid connection appropriately, helping users recover by reconnecting the account rather than facing a blocking message.
Original PR description
Bug === If the token because invalid, then an UserError is raised instead of disconnecting the account. This is because we "blind raise" all errors we get from X, instead of filtering the error linked to the stream configuration. Task-6499283 Forward-Port-Of: odoo/enterprise#129560 Forward-Port-Of: odoo/enterprise#129110
This fix stops Odoo from creating an extra reminder activity on a maintenance request after it has already been completed. Recurring maintenance requests still get the correct reminder for the next scheduled request, reducing clutter and avoiding confusion for responsible users.
Original PR description
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an…
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an activity is created for the responsible user. 3. Mark the activity as done. 4. Move the request to `Repaired`, or another done stage. 5. Check the newly generated request in the recurring series. When a recurrent maintenance request is moved to a done stage, Odoo creates the next request in the series. The existing activity on the completed request is marked as done and automatically unlinked by `activity_feedback()`. Previously, `activity_update()` was then called on all requests whose stage changed. Since the completed request no longer had a pending activity, this created a new one on that request. The newly generated recurring request also received its own activity, resulting in one activity on the completed request and another on the new request. Only call `activity_update()` for requests that remain in a non-done stage. This prevents a new activity from being created on a completed request while preserving the reminder on the next recurring request. opw-6409396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279470
Factur-X documents received through Peppol are now correctly read before checking whether they are self-billed. This prevents failed or incomplete invoice imports and improves reliability for French e-invoicing workflows.
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#285246 Forward-Port-Of: odoo/odoo#280714
Users configuring French e-invoicing now see a clear message when a migration has been requested. This avoids showing an inaccurate availability timeline and sets more realistic expectations for all affected users.
Original PR description
Currently when the user requested a migration, we don't show it in any way to the user, and the only timeline we give ("available tomorrow") is completely false. Because we don't have any field we could use for this client-side (maybe from 19.3 we can use the catch-all-json field) So just make the message same for everybody.
no-task
Forward-Port-Of: odoo/odoo#283702
Forward-Port-Of: odoo/odoo#283594