Saturday, October 11, 2025
4 changes · saas-18.3
Resolved issues and error corrections
Invoices in the Indian EDI flow that include a global discount are now reported with correct taxable and total values. This prevents government submission errors and helps discounted invoices be processed 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 suggest the correct export regime key instead of defaulting to the general regime. This helps businesses submit more accurate electronic invoice data and avoid manual corrections for export transactions.
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 that could prevent users from creating a new analytic distribution model when an expected text value was missing. The change adds a safeguard so the setup process continues reliably without affecting other behavior.
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 fix ensures time off hours in the French localization are calculated using the employee's own working schedule, even when it starts earlier or ends later than the company schedule. This prevents incorrect timesheet and work entry durations for employees whose schedules differ from the default company hours.
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