Tuesday, June 9, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This update resolves a critical issue preventing correct receipt printing in Austria, ensuring accurate financial records. It also addresses a deadlock during authentication with Fiskaly and FON, improving system stability and reliability. The original error message was discarded to maintain focus on core functionality.
Original PR description
In this task: -------------- - Fixed Austria closing receipt printing by calculating the offset from the last closed month instead of the current month. Closing records are returned in ascending order and exist only for completed months, so the latest month must use offset 0. - Prevent a deadlock during Fiskaly and FON authentication by checking for open sessions before starting any authentication flow, instead of after the first step of authentication. - The resp was used to show error which was not in the scope. task: 5420256 Forward-Port-Of: odoo/enterprise#102313
This update fixes an issue where DATEV customer exports incorrectly included EU-specific fields for customers outside the European Union. The change ensures that non-EU customers, like those in Switzerland, use the correct country code (`Land`) field, aligning with DATEV's data format requirements. This improves data accuracy and compliance for international reporting.
Original PR description
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries…
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors ### Cause: `_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR` ### Steps to reproduce: - Install `l10n_de_reports` and switch to the DE company - Create a customer in Switzerland with a valid VAT number - Create and confirm an invoice for that customer - Go to Accounting → Audit Reports → General Ledger - Select the full year - From the gear menu, export DATEV DATA (zip) - Open the `EXTF_customer_accounts` file ### Before the fix: `EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty ### After the fix: `EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled `Land` is filled using the following priority: 1. Partner country_code 2. Country extracted from the VAT number 3. Empty opw-5902565 Forward-Port-Of: odoo/enterprise#119593 Forward-Port-Of: odoo/enterprise#113835
This update resolves a minor visual issue where the name of the Sendcloud website delivery module was incorrectly displayed as 'Sendcould'. The fix ensures consistent and accurate module naming within the Odoo Enterprise platform. This change improves the user experience and avoids potential confusion.
Original PR description
The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.
opw-6239003
Forward-Port-Of: odoo/enterprise#118416
Forward-Port-Of: odoo/enterprise#118223This update resolves an issue where the commission report displayed empty groups when linked to inactive commission plans. By excluding these plans from the report's initial data processing, the report now accurately shows populated groups, providing a cleaner and more reliable view of commission achievements. This ensures sales teams have accurate data for their performance analysis.
Original PR description
Steps to reproduce: 1. create a commission plan 2. invoice an SO with the linked salesperson to the plan to progress towards the target 3. Archive the commission plan 4. Go to Sales > Commissions > Commissions 5. Remove all filters The `sale.commission.report` includes empty groups for `sale.commission.achievement.report` that are linked to inactive commission plans By excluding said plans from the initial join, the report would display populated groups only without the clutter. opw-6177132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#119695 Forward-Port-Of: odoo/enterprise#117615
This update fixes a potential problem where users could accidentally trigger mass email campaigns bypassing intended filters. The change prevents users from directly retrying failed emails linked to marketing automation, reducing the risk of unintended spam and ensuring emails are delivered correctly through the campaign's defined rules. A user interface update also hides the 'Retry' button to avoid confusion.
Original PR description
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing…
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam. This commit fixes the issue by: 1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`). 2. Hiding the "Retry" button in the frontend view to prevent confusion. 3. Adding a unit test to ensure this edge case is caught in the future. Steps to reproduce: 1. Create a marketing campaign with a filter and an email activity. 2. Run the activity and ensure at least one email trace fails. 3. Open the mailing template via the "Templates" smart button. 4. Click the "Retry" button on the template form. 5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model. OPW-6220106 Forward-Port-Of: odoo/enterprise#119517 Forward-Port-Of: odoo/enterprise#118759
This update fixes an issue where planned dates were lost when converting projects to project templates. The change ensures that the original planned dates are retained when creating a template, streamlining project management workflows. This prevents data loss and maintains accurate scheduling.
Original PR description
Steps to reproduce: -------- - Open a project with a planned date set. - Create Template of that project. - Observe the created project template. Issue: ---------- The planned dates of the project are lost when converting the project into a template. Cause: ----- When we create a project template from a project, the project gets archived.Because a new project template record is created, and the start and expiration fields have copy=False, those dates are not being copied. Fix: ------- Explicitly pass the planned date when copying the project, so the project template keeps the original planned date. task-5872500
This update prevents empty ICS calendar files from being generated when publishing shifts. Previously, the system created an empty file when a matching time slot wasn't found, which caused issues with calendar integrations. Now, the ICS file is only generated when a valid shift slot is linked to an employee.
Original PR description
**Step:** - install planning - create a resource - create an open shift for a future date - in Gantt view: - publish shift and select the created resource - click “Publish & Send” - check the email and click “Add to Calendar” **Issue:** Currently, clicking “Add to Calendar” generates an empty ics file. **Reason:** During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file. **Fix:** Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file. Forward-Port-Of: odoo/enterprise#118978
This update resolves a test failure caused by incorrectly formatted data being passed to the system. Specifically, raw PDF content was mistakenly treated as base64, leading to an error. This fix ensures data is correctly encoded, maintaining the stability of the system.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#118523