Daily updates from Odoo
Thursday, May 8, 2025
13 changes · 18.0
New functionality added to Odoo
Adds support for Colombian mandate invoices in electronic invoicing, including product settings and the required invoice XML details. This helps businesses in Colombia issue compliant mandate-related invoices through Odoo.
Original PR description
Extension of l10n_co_edi to allow creation of mandate invoices. - Adding mandate-related fields for product_template. - Adding relevant EDI XML section for mandate products. Task [link](https://www.odoo.com/odoo/project/967/tasks/4302423) task-4302423
Enhancements to existing features
The Guatemala localization now supports local CUI and NIT identification types and includes Guatemala-specific fuel taxes. This helps companies operating in Guatemala keep partner records and tax calculations aligned with local requirements, with updated demo data to reflect the new setup.
Original PR description
Added support for CUI and NIT identification types, added GT-specific fuel taxes (requiring a dependancy on account_tax_python), updated demo data. CUI for demo_partner set to an obviously fake 1111111100000 for the moment as the originally provided one doesn't pass the validation. To work alongside l10n_co, requires the fix in https://github.com/odoo/enterprise/pull/81216 (temporary branch for 18.0 to work with the runbot is added here https://github.com/odoo/enterprise/pull/80671) task-4318265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Deleting expenses is now much faster when accounting records are large. This reduces waiting time for users and improves day-to-day performance without changing how expenses work.
Original PR description
Description ----------- Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`. Benchmark: ---------- On odoo.com, unlinking an expense took: | Before | After | |--------|-------| | 10s | 58ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents point of sale order lines with different prices from being combined. It helps keep receipts and order records accurate when the same product is sold at different prices.
Original PR description
Before this commit, the can_be_merged_with method did not work correctly because an incorrect argument was passed to floatIsZero. As a result, orderlines with different prices could be merged together, leading to inaccurate order information. opw-4778629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where increasing the quantity of a sold kit could create too many delivery quantities when the kit included both made-to-order and standard components. Businesses can now update kit sale orders without causing incorrect deliveries or extra stock movements.
Original PR description
### Steps to reproduce: - In the settings enable Multi-Step - Unarchive the MTO route - Create a storable product P with bom of type kit: - 1 x MTO COMP: with routes MTO and buy and set vendor - 1 X…
### Steps to reproduce:
- In the settings enable Multi-Step
- Unarchive the MTO route
- Create a storable product P with bom of type kit:
- 1 x MTO COMP: with routes MTO and buy and set vendor
- 1 X not MTO COMP: without routes
- Create and confirm a sale order for 1 units of P
- Update the quantity of the sale order line from 1 to 5
#### > The delivery is now for 6 units of both kit component
### Cause of the issue:
Updating the quantity on the SOL will launch a call of the `_action_launch_stock_rule`.The quantity of the new procurement is then processed by these lines based on the kit data's: https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_stock/models/sale_order_line.py#L359 https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_mrp/models/sale_order_line.py#L153-L160 However, since one component uses the MTO route and the other does not the filter based on rules will fail since one of the component move refer to the mto rule and the other one to the delivery rule. In particular the computation will always lead to a result of 0 no matter how many are really processed because only one of the 2 moves can respect the filter.
opw-4700925
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prStripe subscription payments now only request saved payment method setup when it is actually needed and supported. This prevents customers from seeing an error during payment when saving payment methods is disabled or unavailable.
Original PR description
To reproduce: - Enable Stripe payment provider, and disable "Allow Saving Payment Methods" - Create a subscription and 'Sent' it - Click on "Preview" and try to paid using payment method provided by Stripe. An error is raised: ``` The provided setup_future_usage (null) does not match the expected setup_future_usage (off_session). Try confirming with a Payment Intent that is configured to use the same parameters as Stripe Elements. ``` This commit ensure we only request for tokenization if it's required and both the provider and the payment method support it. opw-4605528 opw-4723230
This fixes scheduled automation rules that used relative date filters such as “is within the last month.” These rules will now run reliably instead of failing silently when processed in the background.
Original PR description
# Bug: Currently, base automations that use filters constructed by the front-end using `context_today` and `relativedelta` will fail. These are for example constructed when using the "is within"…
# Bug:
Currently, base automations that use filters constructed by the front-end using `context_today` and `relativedelta` will fail.
These are for example constructed when using the "is within" operator for filter domains, producing search domains like: "Created on is within -1 months"
```
["&", ("create_date", ">=", datetime.datetime.combine(context_today() +
relativedelta(months = -1), datetime.time(0, 0, 0)).to_utc().strftime("%Y-%m-%d %H:%M:%S")),
("create_date", "<=", datetime.datetime.combine(context_today(),
datetime.time(0, 0, 0)).to_utc().strftime("%Y-%m-%d %H:%M:%S"))]
```
When running the CRON for the automation rules, it will silently fail throwing a `NameError: name 'context_today' is not defined` error.
# Proposed solution:
Extend the `eval_context` dictionnary in `_get_eval_context` to whitelist the needed methods to resolve such filter domains. Additionally replace `.to_utc()` calls that only make sense when evaluating the filter domain in thre front-end JS
opw-4763409
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prRazorpay payment records can no longer have key reference or payment method details changed once a transaction is authorized or completed. This helps protect payment accuracy and prevents accidental or unauthorized changes after confirmation.
Original PR description
This measure prevents any accidental or unauthorized modifications to these critical fields after the transition has been done or authorized, thereby ensuring data accuracy and consistency. task - 4680092 you can check this for reference  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers using self-ordering with payment after each order can now cancel an incorrect order and start again instead of getting stuck. This reduces frustration and helps keep self-service point-of-sale flows moving smoothly.
Original PR description
When configuring a self-ordering PoS in pay after each, if the user made an error in the order and wants to modify it, the user is blocked and cannot modify the order. This commit fixes this behavior by allowing the user to cancel the order and recreate it if needed.
Fixed a rounding mismatch in Mexican electronic invoices for external trade when product prices use more than two decimal places. This prevents valid USD invoices from being rejected during CFDI validation because line totals and invoice totals no longer disagree.
Original PR description
Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502…
Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502 Magnesium Mg - UMT Aduana: kg - Make an Invoice as follows: - Customer: Deco Addict - Currency USD - Product: [TEST] - Price: 3,114.515000 - Qty UMT: 11 - Incoterm: EX WORKS - External Trade: Definitive - Confirm Invoice - Send CFDI Issue: Validation will fail with error """ Code : CCE122 Message : El atributo cce20:ComercioExterior:TotalUSD no coincide con la suma de ValorDolares de las mercancías. """ In the xml, the ValorDolares for the sold item will be 3114.5150 but the attribute TotalUSD will be 3114.52 This occurs because ValorDolares are emitted as unrounded amount, but TotalUSD is rounded to 2 decimals. When working with 3+ digits the amounts might not add up correctly. Note: Before version 18, ValorDolares (`product_values['total']`) amount was already rounded according to the currency decimals (2) and there was no issue opw-4662692 opw-4686226
Batch payments without linked accounting entries now use the correct company-currency conversion during bank reconciliation. This prevents misleading debit and credit amounts when matching foreign-currency vendor batch payments, improving accuracy for accounting teams.
Original PR description
Steps to reproduce: - Activate foreign currency EUR (main company in USD) - Have a Bank journal in EUR - Create one Vendor "Send" payment of 100 EUR - Create a new Vendor batch payment and add the payment. - Open EUR Bank and register an outgoing transaction of 100 EUR - Match the transaction with the Batch payment Issue: Looking at the debit/credit columns it can be seen that the transaction amount is properly converted in company currency, but the batch amount is not converted (rate 1.00) This occurs because when the payments in a batch don't have an associated move, the amount residual is converted from payment currency (EUR) to batch currency (still EUR) and not company currency (USD) opw-4656807
The UK CIS report now rounds total payments and materials costs to whole pounds. This ensures the report values match HMRC requirements, so businesses can submit valid CIS returns.
Original PR description
Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost. The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values. opw-4686819
Uploading a file from a shared Documents folder now attaches it to the specific request the user selected. This prevents files from being incorrectly added to another available folder or request when multiple upload options are present.
Original PR description
Step to reproduce : - Create a folder with a sub folder and a request or two requests. - Share the parent folder with edit permission to anyone. - Go to the public folder view. - Upload a file for the last request document. - The file will be uploaded to the first editable folder/request found. This was due to a hidden form tag to upload file to sub folders which was using the same class as the one used by the request documents (o_request_upload). Using class instead of id also means that it wasn't possible to share more than one request document. Task-4718126