Friday, March 27, 2026
5 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where invoices generated from timesheets incorrectly displayed the total hours instead of the correct number of days. The change ensures that timesheet hours are converted to the Sale Order Line's unit of measure (Days) before being applied to the invoice quantity, resulting in accurate invoice calculations. This improves the reliability of invoicing for timesheet-based products.
Original PR description
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm…
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm the quotation and click on the smart button Recorded. 4. Record 16 hours of timesheets. 5. Create an invoice using a timesheet period (starting from SO date) 6. Check the invoice quantity Issue: ----------- The invoice quantity is incorrect. It assigns the hour value (e.g., 16) to the invoice line even though the SOL is configured in "Days" (expected 2 days for 16 hours). Cause: ----------- After this commit c3b6053, The `_recompute_qty_to_invoice` method sums timesheet `unit_amount` (in hours) and assigns it directly to `qty_to_invoice` without converting it to the sale order line UoM when a timesheet period is applied. Solution: --------------- Convert the aggregated timesheet hours into the SOL UoM before assigning it to qty_to_invoice. opw-6024804 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255790 Forward-Port-Of: odoo/odoo#254273
This update fixes an issue where tax returns were incorrectly including Italian pension fund taxes, leading to discrepancies between reports and the backend view. The change excludes these taxes from the tax return domain, ensuring accurate calculations and consistent reporting for Italian customers. This resolves a prior inconsistency.
Original PR description
The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407
This update ensures that customer invoices can be properly updated by regenerating the associated XML file during import. Previously, the system reused imported XML, causing issues when invoices were modified. This change guarantees accurate invoice data and proper processing.
Original PR description
Problem --------- Currently, when importing a move, `ubl_cii_xml_file` gets set with said XML. This XML is then re-used during the export rather that regenerate a new XML each time. This is fine for customer bills as those are not meant to be modified. This is not the case of customer invoices. Client may import an invoice XML and later update that invoice. In such a case, we want to regenerate the XML and not reuse the imported version. Solution --------- Only set `ubl_cii_xml_file` for purchase move during the import. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256052
This update fixes an issue where invoices with 0% taxes incorrectly displayed "Not subject to VAT" in XML reports, violating ZATCA standards. The changes add support for zero-rated and exempt taxes, ensuring accurate VAT reporting and compliance, while maintaining compatibility with existing 0% tax configurations.
Original PR description
Issue: - The field `l10n_sa_exemption_reason_code` was not mapped for zero-rated, zero-rated export, and exempt taxes. - As a result, invoices using 0% taxes incorrectly showed "Not subject to VAT" in the XML, which misrepresented the actual nature of the supply. Imp: - Added new zero-rated and exempt taxes with proper ZATCA/UN CEFACT codes. - Kept legacy 0% taxes unchanged for backward compatibility. - Added Invoice Legal notes to make exemption reason visible in pdf also. - Improved error spacing and removed redundant comma text. Impact: - Ensures full compliance with ZATCA XML standards. - Prevents misleading VAT data representation. Backport of https://github.com/odoo/odoo/pull/234096 taskID-5494997 Forward-Port-Of: odoo/odoo#255922 Forward-Port-Of: odoo/odoo#244656
This update corrects a bug where loyalty programs weren't functioning correctly when pricelists were disabled. Previously, loyalty points continued to accumulate even when a program was restricted to a specific pricelist. This change ensures accurate point tracking and rewards for customers regardless of pricelist settings.
Original PR description
When `use_pricelist` is disabled, `available_pricelist_ids` retains previously configured pricelists. This caused loyalty programs restricted to a specific pricelist to still match and accumulate points incorrectly. opw-5952960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253865 Forward-Port-Of: odoo/odoo#252718