Monday, September 8, 2025
4 changes · 18.0
Resolved issues and error corrections
This fixes an error that blocked users from sending partially paid credit notes through electronic invoicing. Businesses can now complete the credit note sending process without a traceback in affected localization flows.
Original PR description
When User sends the partially paid credit note, A traceback will appear. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data and switch to CO Company - Create a Credit note > Confirm > Register a partial payment > Send > Send Traceback: ``ValueError: The following child node is not defined in the template: CreditNote/cac:PrepaidPayment`` https://github.com/odoo/odoo/blob/7136383f47f3f86bc803efaa3837f4879b211b11/addons/account_edi_ubl_cii/tools/ubl_21_credit_note.py#L26 Here, ``cac:PrepaidPayment`` node is missing in the CreditNote. So, It will raise the above traceback when sending the credit note. sentry-6814211355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects how Odoo evaluates access rules when a linked record field is empty. It prevents valid records from being incorrectly blocked during creation or recalculation, improving reliability for company-based access rules.
Original PR description
* STEP TO REPRODUCE: * -Model B , have **m2o** field call **'a'** from Model A, **'a'** field is not required and is a compute store field -Model B have company rule **[('a.company_id', 'in',…
* STEP TO REPRODUCE:
* -Model B , have **m2o** field call **'a'** from Model A, **'a'** field is not required and is a compute store field
-Model B have company rule **[('a.company_id', 'in', company_ids + [False])]**
-After create B record but without **'a'** field or trigger compute of 'a' field that make it become false, we will get access rule error because: **[('a.company_id', 'in', company_ids + [False])]** will transform into **[('a', 'any', [('company_id', 'in', company_ids + [False])])]** , but note that **'a'** field is empty during computation which make the result become wrong because we call filtered_domain again when **'comparator' == any**, the **'self'** in it is the relation value which is 'a' field (empty record so return self)
* SOLUTION: only when all relational value of self have value then we should use any comparator
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-prThis fix corrects an error in how factoring-related messages are posted and improves handling when Chilean tax authority responses are empty. When a response is invalid, the system now refreshes its authentication token, helping maintain a more reliable connection to SII.
Original PR description
Before the PR: Besides The syntax of message_post was wrong, there are situations where the response from SII is empty. After de PR: Fixed syntax in message_post and clear the token if the response was empty. This improves de connection by getting a new authentication from SII (new token) whenever the response is not a valid one.
This fix prevents subscription payments made through the portal from generating and sending the same EDI-signed invoice twice when automatic invoicing is enabled. Businesses using electronic invoicing localizations should see fewer duplicate documents and cleaner invoice processing.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Use a localization that uses EDI-signed invoices; 2. enable `sale.automatic_invoice` via `ir.config_parameter`; 3. pay for a subscription via the portal. Issue ----- Invoice is generated twice. Cause ----- Commit 7c5fd63729c1 added automatic EDI invoice signing for subscriptions paid via portal. This assumed that the `sale.automatic_invoice` parameter remained unset. If this parameter is set, the invoice is already generated when post-processing a transaction in `sale`. Solution -------- Don't send invoices whose `is_move_sent` field is set to `True`. Also, don't set `from_cron` to `True` on automatic payments, as this is only intended for moves that have `sending_data` filled by `account.move.send.batch.wizard`. opw-4648189