Monday, May 5, 2025
4 changes
Resolved issues and error corrections
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
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
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