Friday, October 17, 2025
10 changes · saas-18.3
Enhancements to existing features
This update adjusts tax rounding so Mexican electronic invoices calculate totals more consistently with current requirements. It also aligns related point-of-sale tax handling, reducing discrepancies in invoice and receipt amounts.
Original PR description
Forward-Port-Of: odoo/enterprise#96809
Refreshing UrbanPiper webhooks from settings now detaches products from the point of sale before sending an updated menu to UrbanPiper. This helps ensure UrbanPiper receives a clean, current menu after a refresh, reducing mismatches between Odoo POS and the delivery platform.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
Bank journals now make invalid or outdated statements easier to spot and manage, including dashboard alerts, reconciliation warnings, and clearer statement form messages. This helps accounting teams avoid using unreliable statement data and protects valid statement transactions from accidental deletion.
Original PR description
This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473
Accounting users now get clearer warnings when bank statements are invalid, including dashboard alerts, reconciliation warnings, and form-level messages. This helps teams spot statement issues earlier, avoid using locked or empty statements in balances, and protect transactions linked to valid statements from accidental deletion.
Original PR description
* accountant|bank_statement_import This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473
Switching inventory valuation settings on very large product categories is now much faster. This reduces delays and timeouts for businesses managing many product variants, improving operational efficiency during accounting and inventory configuration changes.
Original PR description
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish…
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation. This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance. This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase. A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here. #### speedup In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231206
Updates Uruguay localization so businesses can configure and report reduced VAT rates that differ from the standard exempt, minimum, and basic rates. This helps comply with local e-invoicing and tax reporting requirements for cases such as reduced VAT on card or electronic money payments.
Original PR description
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and…
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and services to final consumers when payment is made by debit card or electronic money instrument (and other specific reductions in similar cases).
1. Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2. Modifying XML Output:
* In the <Totales> section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the <MntIVAOtra> tag.
* Example: xml <MntIVAOtra>140</MntIVAOtra> (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the <IndFact> tag to 4: xml <IndFact>4</IndFact>
*Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3. Tax Grid for Configuration:
*Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221073Uruguayan electronic invoices can now correctly identify and report VAT rates outside the standard exempt, minimum, and basic rates. This improves compliance by ensuring reduced-rate VAT is shown in the required invoice XML fields and available for tax configuration and reporting.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
Forward-Port-Of: odoo/enterprise#91392Adds automated test coverage for Indian electronic invoicing when exports are made without a Letter of Undertaking and prices include tax. This helps ensure invoice totals and taxable base amounts remain consistent, reducing the risk of incorrect compliance reporting.
Original PR description
Add test for export without LUT and price included tax, but base should be equal to invoice total. Forward-Port-Of: odoo/odoo#231943 Forward-Port-Of: odoo/odoo#231614
CODA bank statement imports now include clearer payment references for POS and SEPA transactions when that information is available. This helps matching payments to invoices automatically, reducing manual reconciliation work for accounting teams.
Original PR description
When importing a coda file, we deduce the payment ref depending on what is put in the coda. In the case of pos and sepa, we could add the reference in the payment ref to ease the process of auto reconcile. task-5065438
Spanish localization now separates Canary Islands purchase taxes for goods and services, allowing more accurate fiscal mapping. It also adds DUA tax data for Canary Islands operations, helping businesses apply the right tax treatment in local accounting flows.
Original PR description
We have splitted purchase taxes in goods and services because there are different mappings according to the scope. It has a similar functionality with spanish mainland taxes @jco-odoo There are doubts with the fiscal position `fp_nacional_canary_ns` as it is applied automatically to spanish non canarian partners but it should be similar to non-EU partners IMO. However, I think that the opinion fo some canary people would be nice to clarify it @Christian-RB --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228667