Monday, May 5, 2025
12 changes · 18.0
Resolved issues and error corrections
This fix corrects Spanish localization tax data so automated checks no longer fail due to an incorrect tax classification. It helps keep Spanish accounting configurations reliable, including cases affected by the Canary Islands chart of accounts split.
Original PR description
…l10n_es_type Probably forgotten to update the agriculture changes when splitting the csv file for the Canary Islands CoA. Runbot error 161596 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
Italian electronic invoices in foreign currencies now keep unit prices consistent with line totals in the generated XML. This prevents mismatches that could cause validation issues or confusion when sending documents to the Italian SDI system.
Original PR description
### Steps to reproduce: - Install "l10n_it" and switch to an Italian company - Change the currency exchange rate so USD and EUR are not equal - Create a vendor bill or invoice in USD, with at least one product and a price higher than 0 - Confirm, send and inspect the XML generated for the SDI - The value of PrezzoTotale is different than PrezzoUnitario*Quantita ### Cause: "prezzo_unitario" is rounded during the currency conversion. ([see](https://github.com/odoo/odoo/blob/9a48804ed07779692da2952476d3906d1abfa302/addons/l10n_it_edi/models/account_move.py#L330)) But "prezzo_totale" is never rounded, it is taken directly from the tax details ### Solution: When converting "prezzo_unitario" avoid the rounding by adding `round=False`. opw-4720375
This fixes an issue where clearing cached Point of Sale order lines could leave some lines behind. The cleanup now removes all affected lines reliably, reducing the chance of checkout or order processing errors.
Original PR description
Before this commit, clearing lines in the sanitize data cache used a forward iteration, which caused some lines to be skipped due to index shifting when deleting items. This could result in only half of the lines being removed and potentially lead to errors. After this commit, order lines are deleted using a backward iteration, ensuring that all lines are properly removed without skipping any. opw-4770945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where customer review comments and message text could become hard to read when a website shop used a dark theme. The change keeps review text visible against the light review bubbles, improving the shopping experience for visitors and editors.
Original PR description
<b>Steps to reproduce:</b> 1. Website > shop > Open any product > Open Editor(Edit) 2. Customize → Navigate to Customer → Click on Rating. 3. Theme → Navigate to Colors → Navigate to Light & Dark >…
<b>Steps to reproduce:</b> 1. Website > shop > Open any product > Open Editor(Edit) 2. Customize → Navigate to Customer → Click on Rating. 3. Theme → Navigate to Colors → Navigate to Light & Dark > Choose Dark theme. <b>Issue:</b> Website Shop, when using a dark background, the text in write a message box and comment bubbles in reviews sections becomes white making it invisible. <b>Cause:</b> In light mode, the text appears black, making it easy to read. However, when switching to dark mode, the text changes to white, which makes it difficult to read against the light bubble background. <b>Solution:</b> This commit adds class text-black to the comment and description container to improve the visibility. <b>opw : 4724764</b> <b>BUG:</b>    <b>FIX:</b>   
Tasks created from sales orders will again include the relevant sales line description in their title. This makes generated tasks easier to identify and restores expected behavior from earlier versions.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue…
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue ----- The task only has the SO and service product name as title. This is different from earlier versions, where it would include the first line of the line's description. Cause ----- When creating a task from an order line, it uses the first line of the line name as part of the task name, and adds the rest to the description. Starting from 18.0, the product & description columns are merged in order & invoice views. A side-effect of this, is that the product name will always be present as the first line of the product, and any added description will start from the second line. Consequently, it's no longer possible to add a description to the line that would get used as task name. Solution -------- Use the first two lines of the sale line name to form a task title. opw-4634149 opw-4637902
This fixes an issue where Point of Sale could use the wrong numbering format for dates and times when a database uses a non-Latin numbering system. It helps ensure receipts, orders, and synchronized device data show date and time values consistently for affected locales.
Original PR description
When a database isn't in ltn format, the datetime numbering system is not set to the correct value. This commit fixes the issue by ensuring that the datetime numbering system is set to the correct value.
Fixed an issue where sale orders with delivered combo products could still appear ready to invoice after the invoice was confirmed. This keeps invoice status accurate for products billed on delivery and helps prevent duplicate or confusing invoicing actions.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product with only items that are invoiced on delivery; 2. add it to a sale order; 3. validate the delivery; 4. create & confirm an invoice. Issue ----- The sale order is still invoicable. Cause ----- The `qty_to_invoice` field for the combo item line isn't being updated when its linked lines were delivered. Solution -------- Add `linked_line_ids.qty_delivered` to the `api.depends` of the compute method. opw-4633972
Fixes an accounting issue where analytic distribution details could be cleared from tax lines when journal entries were saved and tax lines were synchronized. This helps keep reporting allocations accurate and prevents users from having to re-enter analytic information.
Original PR description
Analytic distribution is not tracked when synchronising the tax line Steps: - Have an income account X with a sale tax set - Create a journal entry with one line, having account X and debit xxx$ - Save the form, two lines should have been created, auto balancing line and tax line - Set an analytic distribution on these two lines and save the form -> The analytic distribution is unset from the tax line Before this commit, we were keeping values of `amount_currency` and `balance`, now we keep also `analytic_distribution` in the tracked fields opw-4662784
This change adjusts an internal automated test so it checks that only the valid customer payment is created, rather than relying on a less relevant status value. It helps keep SEPA direct debit quality checks stable without changing customer-facing behavior.
Original PR description
Here we don't really care about the state, we replaced it by just checking that there is only one payment and to the "agrolait" partner since it has a valid mandate. build_error-163134
This update adjusts an internal automated test for SEPA Direct Debit so it checks the important payment details rather than a status that can vary after demo data changes. It helps keep the test suite reliable without changing customer-facing behavior.
Original PR description
There's been quite a lot of refactoring of demo-data and stuff so now the setup may have been changed in the background Here we don't really care about the state, so we can replace it by just checking that there is 2 payments and to the "agrolait" partner and "china_export" partner build_error-163133
Mexican payroll now calculates payslips for hourly employees using the hourly wage and actual worked hours, including unpaid leave adjustments. This prevents incorrect monthly wage values from being applied to hourly contracts and improves payroll accuracy for Mexican companies.
Original PR description
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of…
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of monthly - Set a value for the wage/hour - Create some work entries for that employee - Generate a payslip for the employee in the duration you are testing - Edit the work entries you have to have some unpaid leaves - Generate another payslip for the employee Current Behavior: Payslip is generated without taking into consideration the number of hours actually worked and the unpaid leaves taken by the employee. It also generates the payslip with the value of the wage/month regardless of the value of the wage/hour you added. Issue: In df8f53b0cad4738537f18890e628c286dedaa141, Mexican localisation was implemented but with computing the amount of the `payslip_worked_days` using the `contract.wage` which is the fixed amount of wage/month. https://github.com/odoo/enterprise/blob/25caeeab01abc0b47f6bd6b02658c3bbbe0aba96/l10n_mx_hr_payroll_localisation/models/hr_payslip_worked_days.py#L19-L20 opw-4604675
Trial Balance end balances now calculate correctly when reports are grouped by analytic accounts or horizontal groups, preventing totals from being overstated. Romanian Trial Balance reports also no longer crash in the same analytic grouping scenario, improving reliability for accounting users.
Original PR description
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic…
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the account used in the analytic distribution in "Analytic" group option **Issue 1:** In the "End Balance" column, all the amounts are summed in the total column instead of being grouped by analytic accounts. It results on a total amount being twice what it should be as the total column of each period is also included in the sum. There is a similar issue with horizontal groups. **Cause 1:** The "End Balance" column is not computed via the SQL as all the data required to compute it are already retrieved. However, the case where there are groups by analytic is not handled. It results on the computation taking the value of a analytic group and also the value of the total group, which doubles the computed amount. **Solution 1:** As it is not possible to identify easily each different group in each period to sum the corresponding values together, the computation of the "End Balance" will be done in the SQL if the groupby analytic is done or if a horizontal group is set. **Issue 2:** - Install l10n_ro_reports - Switch to a Romanian company (RO Company) - Follow the same steps than issue 1 - Select "Trial Balance 4/5 col (RO)" as Report => A traceback is raised: "TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'" opw-4648009