Thursday, July 10, 2025
8 changes · saas-18.1
Resolved issues and error corrections
This fixes a gap where e-invoice XML files generated from the Send & Print wizard did not create the expected accounting document unless they were also emailed. Businesses using Peppol and document integration will now get the related document record even when choosing download-only flows, improving traceability and record keeping.
Original PR description
Event with the document integration correctly setup, e-invoice xml generated in the send&print wizard will not create an associated document unless the attachment is actually sent via mail Steps to reproduce: - Have a EU Company setup - Enable and configure Peppol Electronic Invoicing - Enable documents integration with accounting - Create an invoice to a Peppol enabled customer, confirm - Open send&print wizard, enable only 'Download' and 'BIS Billing 3.0' Issue: Document related to the xml attachment is not created. This will work as expected when the message is sent to the customer opw-4720588 Enterprise PR https://github.com/odoo/enterprise/pull/88746 Forward-Port-Of: odoo/odoo#216243
Online shop carts now refresh their tax rules when a customer updates an address outside checkout. This prevents customers from paying with outdated taxes when their address should trigger a different fiscal position.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a fiscal position with a country-based tax mapping; 2. go to `/shop` as a public user, 3. create a new account; 4. add a product to your cart; 5. go to…
Versions -------- - 16.0+ Steps ----- 1. Have a fiscal position with a country-based tax mapping; 2. go to `/shop` as a public user, 3. create a new account; 4. add a product to your cart; 5. go to user settings & add an address that matches the fiscal position; 6. go to checkout & pay for the cart. Issue ----- The fiscal position's taxes aren't applied to the order. Cause ----- The `_compute_fiscal_position_id` method is triggered when changing the `partner_id` or `partner_shipping_id` of an order. It does not trigger when modifying the address of the order's current partner. There is logic in place to recompute fiscal position & taxes when an address gets entered via checkout, but not via any other route. Solution -------- Adding address fields to the `api.depends` of the compute method could introduce the unintended behavior of changing taxes & fiscal position of confirmed sale orders. Instead, we can check for fields relevant to fiscal position in `write`, then search for unconfirmed website orders, and recompute their fiscal position & taxes if need be. opw-4844132 opw-4753332 Forward-Port-Of: odoo/odoo#217911 Forward-Port-Of: odoo/odoo#214588
This fixes how Mexican DIOT report columns calculate certain paid and import tax amounts. The report now uses corrected tax tags so tax columns show the right tax values instead of mixing in incorrect bases or multiple tax types.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. Current behavior before PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. Desired behavior after PR is merged: Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly. Likewise, the way of computing the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% has been simplified. Now it no longer adds up different types of taxes, but only one type. opw-4920577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217441
Swiss payroll ELM transmission monthly summaries now aggregate records correctly. This helps prevent incorrect payroll reporting totals when preparing monthly submissions.
Original PR description
Forward-Port-Of: odoo/enterprise#89839
This fixes a case where downloaded Peppol e-invoice XML files were not added to the Documents app unless they were also sent by email. Businesses using accounting document management now get the expected XML document record immediately when the attachment is created, improving audit completeness and retrieval.
Original PR description
Event with the document integration correctly setup, e-invoice xml generated in the send&print wizard will not create an associated document unless the attachment is actually sent via mail Steps to reproduce: - Have a EU Company setup - Enable and configure Peppol Electronic Invoicing - Enable documents integration with accounting - Create an invoice to a Peppol enabled customer, confirm - Open send&print wizard, enable only 'Download' and 'BIS Billing 3.0' Issue: Document related to the xml attachment is not created. This will work as expected when the message is sent to the customer It occurs because, in case of xml attachment, we don't create an associated document until some attachment have been registered on the move, effectively delaying document creation until the mail attachments are created opw-4720588 Forward-Port-Of: odoo/enterprise#89666 Forward-Port-Of: odoo/enterprise#88746
Amazon sales orders can now correctly recognize DPD, Hermes, and the renamed Royal Mail carrier values when they come through Sendcloud in Great Britain. This reduces shipping setup failures and helps orders move through fulfillment without manual correction.
Original PR description
For DPD and Hermes (not the others), Sendcloud adds an unnecessary ISO code. In order to keep it should it be necessary (e.g. rml_gb), we map them to the Amazon const instead of stripping the code. While testing, it was also found that royal mail seems to have been renamed and was thus not working. Forward-Port-Of: odoo/enterprise#87745
This fix ensures the Belgian POS Blackbox properly acknowledges status messages and avoids confusing startup status replies with command responses. It reduces repeated communication errors and helps prevent failed or incorrect fiscal device interactions during POS operation.
Original PR description
We did not send an `ACK` after asking for blackbox status, leading in BlackBox sending it again. This lead to situations where we sent requests to the BlackBox, and received the status instead of the actual response. In addition, the repeated status responses were missing the leading `ACK`, resulting in our log: `sent 1 NACKS without receiving response, giving up.` More, if we sent a command too soon to the BlackBox (before it finished instanciating), we were receiving its `certified ref` instead of the actual response, due to the `_push_status` method called from the `run` method of the BlackBox Driver parent class. This `run` method is now overridden by the BlackBox driver Task: 4750435 Backport of https://github.com/odoo/enterprise/pull/87659 Forward-Port-Of: odoo/enterprise#89883
The Swiss payroll employee form now shows work permit information again. This restores access to fields that Swiss HR teams rely on for payroll and compliance-related employee administration.
Original PR description
In this PR we reintroduce the work permit fields for the swiss localization, which is heavily used. Forward-Port-Of: odoo/enterprise#89864