Daily updates from Odoo
Sunday, May 17, 2026
10 changes
2 changes
Resolved issues and error corrections
This update fixes an issue where Material Orders (MOs) weren't being properly valued when validated in a different company than the one they were initially created in. Specifically, raw and finished moves were incorrectly assigned a value of zero, leading to inaccurate costing. This ensures MOs are accurately valued regardless of the company context, improving financial reporting.
Original PR description
Validating an MO while env.company differs from mo.company_id read company-dependent fields (product.standard_price, product.cost_method) in the wrong company: raw moves are valued at 0 and the finished move's price_unit collapses, so the MO ends up with no valuation. Steps to reproduce: 1. User with access to companies A and B. 2. Product whose standard_price is set in A only. 3. Confirm an MO of company A. 4. Validate it while env.company is B. -> Raw + finished moves stored with value 0. opw-6205741 Forward-Port-Of: odoo/odoo#264285
This fix resolves an issue where credit notes sent to jofatora failed due to mismatched customer information. The system incorrectly populated credit notes with default values instead of the original invoice details, causing submission errors. This ensures accurate invoice processing and compliance with local regulations.
Original PR description
…t note and original invoice
**STEP TO REPRODUCE**
1. Create an invoice and send it to jofatora.
2. Create a credit note for the invoice, send it to jofatora.
3. Sending the credit note will fail with the following error: `Request failed: {"EINV_RESULTS":{"status":"ERROR","INFO":[],"WARNINGS":[],"ERRORS":[{"type":"ERROR","status":"ERROR","EINV_CODE":"invoice-persist","EINV_CATEGORY":"Invoice","EINV_MESSAGE":"invoice: Credit invoice buyer info does not match the original invoice"}]},"EINV_STATUS":"NOT_SUBMITTED","EINV_SINGED_INVOICE":null,"EINV_QR":null,"EINV_NUM":null,"EINV_INV_UUID":null}`
**CAUSE**
In `account_edi_xml_ubl_21_jo.py` if the document is a credit note (`is_refund`), we fill the customer party with some default value. However, the documentation states that the credit note customer party should have the exact same values as the original invoice.
opw-6183573
Forward-Port-Of: odoo/odoo#264836
Forward-Port-Of: odoo/odoo#2641032 changes
Resolved issues and error corrections
This update fixes an issue where Material Outlines (MOs) weren't being properly valued when validated in a different company than the one they were initially created in. Specifically, raw and finished moves were incorrectly assigned a value of zero, leading to inaccurate financial reporting. The fix ensures MOs are accurately valued regardless of the company setting.
Original PR description
Validating an MO while env.company differs from mo.company_id read company-dependent fields (product.standard_price, product.cost_method) in the wrong company: raw moves are valued at 0 and the finished move's price_unit collapses, so the MO ends up with no valuation. Steps to reproduce: 1. User with access to companies A and B. 2. Product whose standard_price is set in A only. 3. Confirm an MO of company A. 4. Validate it while env.company is B. -> Raw + finished moves stored with value 0. opw-6205741 Forward-Port-Of: odoo/odoo#264285
This update fixes an issue where credit notes generated for invoices sent to jofatora were failing due to mismatched customer information. The system was incorrectly using default values for credit notes instead of the original invoice details, causing submission errors. This ensures credit notes are correctly formatted for submission.
Original PR description
…t note and original invoice
**STEP TO REPRODUCE**
1. Create an invoice and send it to jofatora.
2. Create a credit note for the invoice, send it to jofatora.
3. Sending the credit note will fail with the following error: `Request failed: {"EINV_RESULTS":{"status":"ERROR","INFO":[],"WARNINGS":[],"ERRORS":[{"type":"ERROR","status":"ERROR","EINV_CODE":"invoice-persist","EINV_CATEGORY":"Invoice","EINV_MESSAGE":"invoice: Credit invoice buyer info does not match the original invoice"}]},"EINV_STATUS":"NOT_SUBMITTED","EINV_SINGED_INVOICE":null,"EINV_QR":null,"EINV_NUM":null,"EINV_INV_UUID":null}`
**CAUSE**
In `account_edi_xml_ubl_21_jo.py` if the document is a credit note (`is_refund`), we fill the customer party with some default value. However, the documentation states that the credit note customer party should have the exact same values as the original invoice.
opw-6183573
Forward-Port-Of: odoo/odoo#264836
Forward-Port-Of: odoo/odoo#2641033 changes
Resolved issues and error corrections
This update fixes a potential crash during bank statement imports caused by incorrect journal selection. The system now automatically validates currency and IBAN matches, ensuring the correct journal is used and preventing user errors. This improves the reliability and accuracy of the import process.
Original PR description
Behavior before: The import flow could crash with an "Expected singleton" error if multiple journals shared an IBAN. Additionally, the system blindly accepted the current context ('self') as the…
Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.
Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.
Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.
Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.
opw-5462037
Forward-Port-Of: odoo/enterprise#117376
Forward-Port-Of: odoo/enterprise#115475This update fixes an issue where MOs were not being properly valued when validated in a different company than the one they were initially created in. Specifically, raw and finished moves were incorrectly assigned a value of zero, leading to inaccurate inventory reporting. This ensures consistent and reliable MO valuation across all company settings.
Original PR description
Validating an MO while env.company differs from mo.company_id read company-dependent fields (product.standard_price, product.cost_method) in the wrong company: raw moves are valued at 0 and the finished move's price_unit collapses, so the MO ends up with no valuation. Steps to reproduce: 1. User with access to companies A and B. 2. Product whose standard_price is set in A only. 3. Confirm an MO of company A. 4. Validate it while env.company is B. -> Raw + finished moves stored with value 0. opw-6205741 Forward-Port-Of: odoo/odoo#264285
This update fixes an issue where credit notes generated for invoices were failing due to mismatched customer information. The system was incorrectly using default values for credit notes instead of the original invoice details. This change ensures credit notes accurately reflect the original invoice, preventing submission errors and improving invoice processing.
Original PR description
…t note and original invoice
**STEP TO REPRODUCE**
1. Create an invoice and send it to jofatora.
2. Create a credit note for the invoice, send it to jofatora.
3. Sending the credit note will fail with the following error: `Request failed: {"EINV_RESULTS":{"status":"ERROR","INFO":[],"WARNINGS":[],"ERRORS":[{"type":"ERROR","status":"ERROR","EINV_CODE":"invoice-persist","EINV_CATEGORY":"Invoice","EINV_MESSAGE":"invoice: Credit invoice buyer info does not match the original invoice"}]},"EINV_STATUS":"NOT_SUBMITTED","EINV_SINGED_INVOICE":null,"EINV_QR":null,"EINV_NUM":null,"EINV_INV_UUID":null}`
**CAUSE**
In `account_edi_xml_ubl_21_jo.py` if the document is a credit note (`is_refund`), we fill the customer party with some default value. However, the documentation states that the credit note customer party should have the exact same values as the original invoice.
opw-6183573
Forward-Port-Of: odoo/odoo#264836
Forward-Port-Of: odoo/odoo#2641031 change
Resolved issues and error corrections
This update resolves an issue where the bank statement import process could fail due to incorrect journal selections. The fix ensures the system accurately matches currency and IBAN details, preventing errors and improving the reliability of importing bank statements. It now automatically selects the correct journal based on the statement's information, enhancing data accuracy.
Original PR description
Behavior before: The import flow could crash with an "Expected singleton" error if multiple journals shared an IBAN. Additionally, the system blindly accepted the current context ('self') as the…
Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.
Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.
Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.
Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.
opw-5462037
Forward-Port-Of: odoo/enterprise#117376
Forward-Port-Of: odoo/enterprise#1154751 change
Resolved issues and error corrections
This update fixes an issue where credit notes were failing to send due to mismatched customer information. The system incorrectly populated credit notes with default values instead of using the original invoice details. This prevented successful credit note submissions, impacting invoice processing.
Original PR description
…t note and original invoice
**STEP TO REPRODUCE**
1. Create an invoice and send it to jofatora.
2. Create a credit note for the invoice, send it to jofatora.
3. Sending the credit note will fail with the following error: `Request failed: {"EINV_RESULTS":{"status":"ERROR","INFO":[],"WARNINGS":[],"ERRORS":[{"type":"ERROR","status":"ERROR","EINV_CODE":"invoice-persist","EINV_CATEGORY":"Invoice","EINV_MESSAGE":"invoice: Credit invoice buyer info does not match the original invoice"}]},"EINV_STATUS":"NOT_SUBMITTED","EINV_SINGED_INVOICE":null,"EINV_QR":null,"EINV_NUM":null,"EINV_INV_UUID":null}`
**CAUSE**
In `account_edi_xml_ubl_21_jo.py` if the document is a credit note (`is_refund`), we fill the customer party with some default value. However, the documentation states that the credit note customer party should have the exact same values as the original invoice.
opw-6183573
Forward-Port-Of: odoo/odoo#264669
Forward-Port-Of: odoo/odoo#2641031 change
Resolved issues and error corrections
This update fixes a potential crash during bank statement imports caused by incorrect journal selection. The system now automatically validates currency and IBAN details, ensuring the correct journal is assigned and preventing user errors. This improves the reliability and accuracy of the import process.
Original PR description
Behavior before: The import flow could crash with an "Expected singleton" error if multiple journals shared an IBAN. Additionally, the system blindly accepted the current context ('self') as the…
Behavior before:
The import flow could crash with an "Expected singleton" error if multiple
journals shared an IBAN. Additionally, the system blindly accepted the
current context ('self') as the target journal, even if its currency or
bank account mismatched the statement, often leading to avoidable
UserErrors.
Behavior after:
The system now validates 'self' against the statement's currency and IBAN
before assignment. If a mismatch is found, it automatically searches for
the correct journal. The search is now restricted by currency and includes
a limit=1 to prevent crashes and ensure accurate selection.
Root Cause:
In _find_additional_data(), 'journal = self' was assigned without validation.
Furthermore, the fallback search lacked a record limit and currency matching
logic, allowing multiple records to be returned when duplicates or
multi-currency setups existed.
Fix:
- Added validation for the initial 'self' candidate (currency and IBAN match).
- Refined the search domain to include currency matching (journal or
company fallback).
- Added limit=1 to the search to guarantee a singleton recordset.
opw-5462037
Forward-Port-Of: odoo/enterprise#117376
Forward-Port-Of: odoo/enterprise#115475