Friday, July 25, 2025
7 changes · saas-18.3
Enhancements to existing features
Swiss businesses selling goods directly to EU consumers can now more easily configure EU One Stop Shop reporting. The update adds Switzerland-to-EU tax mappings, reducing setup effort and improving discoverability for cross-border B2C sales compliance.
Original PR description
Make it easy for any Swiss company that wants to operate B2C sales of goods to customers located in the EU to take advantage of the EU One Stop Shop (OSS) Module, aka l10n_eu_oss_reports. We will ease the discoverability and the configuration Adding the Tax Mapping between Switzerland and the rest of the EU countries task-4943589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220260 Forward-Port-Of: odoo/odoo#219380
Resolved issues and error corrections
This fix ensures Spanish TicketBAI credit notes created using the differences method report negative line, tax, and total amounts as required. It helps businesses submit accurate electronic tax documents and avoid reporting inconsistencies.
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 Forward-Port-Of: odoo/odoo#220300 Forward-Port-Of: odoo/odoo#217172
This fix prevents errors when moving floating orders to another order or table in Point of Sale and Restaurant workflows. Staff can now transfer orders consistently regardless of whether they are tied to a table, reducing interruptions during service.
Original PR description
While transferring a floating order to another or a table, a traceback was raised. Is now possible to transfer orders to anything independent of the table or order type. taskId: 4948719 Forward-Port-Of: odoo/odoo#219236
Fixes an issue in the website editor where pressing backspace after selecting text across paragraphs could delete content outside the selection. This helps prevent accidental loss of nearby content when editing pages or emails.
Original PR description
Problem: Given content like: ``` <p>keep<br>[delete</p> <p>delete<br>delete<br>]</p> <p>keep</p> ``` Pressing backspace removes the last "keep" as well, which is incorrect. Cause: The merge logic uses `range.endContainer` as `joinWith`, but does not account for `range.endOffset`. When `range.endContainer` is a `<p>` with a non-zero offset, the condition `next.previousSibling && next.previousSibling === joinWith` fails. During merging, `next` may go inside `joinWith`, making the logic invalid. Solution: Prevent merging when `next` is positioned exactly at `range.endOffset`, preserving the correct boundary. Steps to reproduce: - Add the sample HTML to the editor - Select from `[delete` to `delete]` - Press backspace -> The final `<p>keep</p>` is deleted incorrectly opw-4905047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220163 Forward-Port-Of: odoo/odoo#219392
Subscription renewals that move customers between recurring plans now calculate commissions using transfer activity, so sales compensation better reflects the plan change. The update also prevents duplicate achievement lines when no currency is set and improves commission report loading performance.
Original PR description
PURPOSE In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs SPECIFICATIONS Take into account transfer logs…
PURPOSE
In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs
SPECIFICATIONS
Take into account transfer logs in achievements computation. Source should be clear that it's a transfer log of a renewal
Example:
If you have a Monthly sub to 100$/month but the yearly of 1000/year (MRR = 83.33) With a commission plan rewarding: 80% MRR of Monthly and 100% MRR of yearly
If you renew a montlhy into a yearly --> MRR that was 100 become 83,33 so you have a negative MRR so a negative commission and a negative on yearly so with more weight (100% instead of 80)
Current:
Renew in into yearly: 100% of MRR change -16.67 = -$16.67
New monthly 80% of MRR change $100 = $80
Total = 63.33 (modifié)
New
New monthly 80% of MRR change $100 = $80
Transfer 1 : 80% of MRR change -100 = -$80
Transfer 2 : 100% of MRR change +100 = +$100
Contraction of MRR: 100% of MRR change -16.67 = -$16.67
Total = 83.33
Moreover this PR:
- fix a bug when achievements were duplicated when no currency was set.
- improve performances by creating a temporary table for invoice rules.
taskid-4783929This fixes an issue where failing part of a quality check could incorrectly mark related receipt moves as picked. The change keeps stock receipt status accurate after quality failures, reducing confusion and preventing incorrect warehouse processing.
Original PR description
Steps to reproduce the bug:
- Create two storable products: "P1" and "P2"
- create a quality control point:
- operation: receipt
- products: “P1” and “P2”
- Failure location: any one
- Create a receipt for 1 unit of P1 and 2 units of P2
- Pass the quality check for P1
- For P2, pass 1 unit and fail the other
Problem:
A new move for P2 is created to the failure location, but as a result, both moves for P2 are marked as picked, whereas the move for P1 is not. Solution:
We shouldn’t mark any move as picked during the quality check.
Partial backport of: https://github.com/odoo/enterprise/pull/77985/commits/48bfc8a860fa4b5b5e9ea153932f34b47bdcec6c
opw-4902059
Forward-Port-Of: odoo/enterprise#90178
Forward-Port-Of: odoo/enterprise#89634Mexico payroll calculations now handle employees who do not yet have an initial contract start date. This prevents salary configurator and payslip errors during recruitment or offer creation, helping payroll processes continue reliably.
Original PR description
Before this fix, various computations relying on `employee.first_contract_date` fails if the value was missing, notably: - `_compute_integration_factor` in payslips - Python expressions in MX salary rules (holiday bonus, ISR, etc.) Steps to reproduce: Install the following modules: - Recruitments, Payroll, Salary Configurator - Mexico - Payroll, Mexico - Payroll - Localisation, EDI for Mexico Go to Recruitment -> create or click on application in any offer -> click on generate offer(create a contract templates if needed) -> Click on Salary Configurator, notice the Invalid Operation Error After fix: - Default the integration factor to 1 and years worked to 0 when no start date exists - Safely guard salary rule conditions and computations with proper checks This ensures robust payroll calculation even for employees without an initial contract date. opw-4853613 Forward-Port-Of: odoo/enterprise#90648