Saturday, October 11, 2025
8 changes · saas-18.4
Resolved issues and error corrections
This fix prevents duplicate extra discount lines from appearing when multiple global discounts are applied to a sales order. It keeps order and tax calculations cleaner and avoids confusing totals for sales users and customers.
Original PR description
Because of the grouping on the computation_key in the taxes engine, when a second global discount was applied on a SO, it was creating two additional lines instead of one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230494
Reports now correctly show one-to-many field values instead of leaving them improperly formatted or missing. This improves report accuracy for users who rely on related line-item information in generated documents.
Original PR description
For now, `One2Many` fields are not displayed correctly in reports. This is because for other types of fields (`ManyToMany`, `ManyToOne`, etc.), there are Converter classes (`ManyToManyConverter`) `ir.qweb.field.many2many` that implement `value_to_html`. However, for `OneToMany` fields, no implementation is present. This commit adds a `OneToManyConverter`, which is essentially the same as the `ManyToMany `one. opw-5098466 Forward-Port-Of: odoo/odoo#231057 Forward-Port-Of: odoo/odoo#229289
Batch invoice sending now keeps Peppol only on invoices that are actually eligible for it. This prevents invoices meant to be sent by email, such as non-Peppol partners, from failing because Peppol was incorrectly applied.
Original PR description
…ng methods When sending invoices in batch with multiple sending methods (for example 1 by Peppol, 2 by Email), Peppol was wrongly set on invoices where it didn't make sense. Steps to reproduce: 1. Go into a Peppol compatiable company (Eg: Belgium) 2. Go into settings, enable Peppol. 3. Create & post two invoices: one to an US partner, the other one to a Peppol partner (For example a belgian partner with a vat set.). Make sure to set the email on both. 4. Send them in batch: the wizard says 1 by Peppol, 2 by Email, which is correct. 5. If you send them, the one to the US partner that is not supposed to go through Peppol will end up in error, with the email not sent either. Root cause: We are doing some Peppol checks before checking if it actually make sense to apply this sending method on the move. task-none (reported from our production) Forward-Port-Of: odoo/odoo#230880
Indian e-invoice submissions now calculate invoice values correctly when a global discount is applied. This prevents government EDI validation errors that could block affected invoices from being submitted successfully.
Original PR description
Submitting an EDI for an invoice containing a global discount line (negative amount line without tax) raised the following errors: 1. 2182 – Taxable value of all items must be equal to total taxable value 2. 2189 – Invalid total Invoice Value This occurred due to the `account_tax` refactor in version 18.0, where lines without taxes are no longer included in `_aggregate_base_line_tax_details`. As a result, the `global_discount_line` in `l10n_in_edi` was excluded from the base_amount computation. This fix adjusts the following JSON fields: - `AssVal` → Previously added global_discount_amount to restore the base. Now remains directly aligned with base_amount. - `TotInvVal` → Previously skipped discount deduction. Now explicitly deducts the discount. **task**-5158762 Forward-Port-Of: odoo/odoo#230962
Spanish Veri*Factu invoices for customers outside Spain now receive the correct export regime key instead of being marked as general regime operations. This helps businesses produce more accurate tax reporting data and avoid manual correction for export invoices.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice for a partner outside Spain (or with the tax "0% EX G") - Check the "Veri*Factu Regime Key" under the page "Veri*Factu" - It should be "Export" (02) but it's "General Regime Operation" (01) ### Cause: `_l10n_es_edi_verifactu_get_suggested_clave_regimen()` is called on the tax "0% EX G". The line ```taxes.filtered(lambda tax: (tax.l10n_es_type not in main_tax_types or tax._l10n_es_edi_verifactu_get_applicability() != forced_tax_applicability))``` doesn't do what the comment says: remove the main taxes with a different applicability. ### Solution: Change the `!=` to `==` so that the line does the same thing as the comment. opw-5071665 Forward-Port-Of: odoo/odoo#230823
This fixes an issue where creating a new journal entry with the same accounting date as the previous entry could fail to refresh required information. Users should now see the expected draft title and be able to save records without them remaining incorrectly marked as unsaved.
Original PR description
Steps to reproduce ================== - Install accounting - Go to Accounting > Accounting > Journal Entries - Create a new record - Select an Accounting Date in the previous month - An onchange is called and the title is changed to draft - Save the record - Click on New - Select the same date - The onchange isn't triggered - Save the record - The record stays dirty and the title is missing Cause of the issue ================== https://github.com/odoo/odoo/commit/44f69ae726b1ff8876c38e858c64fed0f5b1a766 lastAppliedStringValue should be reset inside computeBasePickerProps Solution ======== We backport the code from 19.0 where this was fixed opw-5145113 Forward-Port-Of: odoo/odoo#230774
This fixes a small issue that could stop users from creating a new analytic distribution model when expected text data was missing. The change adds a safeguard so the process continues normally without affecting other analytic features.
Original PR description
Current behavior before PR: When trying to create a new analytic distribution model might fail because string might not be defined and substr() could fail. <img width="1139" height="435" alt="odoo" src="https://github.com/user-attachments/assets/2be5a35c-600e-4484-af72-91f778681bcf" /> Desired behavior after PR is merged: We could check if there is string before de substr method. That would solve the problem and will not affect anywhere else. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230481
This fixes French leave reporting when an employee's working hours differ from the company's default schedule. Time off entries now use the employee's actual schedule, helping payroll and timesheet records show the correct leave duration.
Original PR description
This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry (`account.analytic.line`) creation, and the duration field is created using the company schedule.…
This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry (`account.analytic.line`) creation, and the duration field is created using the company schedule. The reason is the case which the employee schedule starts before company scheudle or ends after it. To reproduce the bug: 1- Make a db with fr company (install l10n_fr) 2- Make two working schedule: - Company schedule with working day on Monday from 8:00-12:00 13:00-17:00 - Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15 3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee 4- Allocate some time off to the employee and take a time off on Monday 5- Check the work entries for the day you took the day off on timesheet app 6- 7:24 `Worked Hour` is shown instead of 7:40 The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered. opw-4868643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230621 Forward-Port-Of: odoo/odoo#222262