Daily updates from Odoo
Sunday, May 17, 2026
18 changes
4 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 update fixes an issue where service templates imported with 'tracking=none' incorrectly showed a 'Quantity on Hand' value. The fix ensures that the 'is_storable' flag is correctly determined based on the template type, preventing inaccurate stock calculations. This improves the reliability of stock management for service products.
Original PR description
_set_tracking does write(is_storable=bool(tracking)) without looking at type. A service template imported manually with tracking='none' thus flips to is_storable=True. Restrict the inverse to consu templates. Steps to reproduce: - Import a CSV with type=service,tracking=none - You will visually see the Quantity on Hand field on the form view opw-6203593 Forward-Port-Of: odoo/odoo#264357
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#264103This update resolves an issue where the system incorrectly loaded account moves when processing paid orders in the Point of Sale module. By removing a redundant loading step, the system now correctly utilizes data already available, improving order processing reliability. This ensures accurate financial reporting related to Point of Sale transactions.
Original PR description
Before this commit, when loading the paid orders it would load the account move with the "account_move" key, but this key is wrong as the account move model is loaded with the "account.move". Also, the account move is already loaded by the "read_pos_data" method in the point_of_sale module, so we can just remove it from here. opw-6218467 Forward-Port-Of: odoo/enterprise#117422
3 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#264103This update resolves an issue that occurred when loading paid orders in the Point of Sale module. The previous process incorrectly loaded account moves, leading to errors. This change streamlines the loading process by leveraging existing functionality within the Point of Sale module, ensuring accurate order data.
Original PR description
Before this commit, when loading the paid orders it would load the account move with the "account_move" key, but this key is wrong as the account move model is loaded with the "account.move". Also, the account move is already loaded by the "read_pos_data" method in the point_of_sale module, so we can just remove it from here. opw-6218467 Forward-Port-Of: odoo/enterprise#117422
5 changes
Resolved issues and error corrections
This update corrects a UI issue where changes to cloned website snippets weren't immediately reflected. The fix ensures that duplicated snippets are flagged as needing updates, preventing outdated content and improving the accuracy of the website editor. This enhances the user experience and data consistency.
Original PR description
Steps to reproduce: 1. Open the website editor 2. Add a snippet containing text content 3. Clone the snippet 4. Change the website language 5. Switch to translation mode 6. Modify the content of the original snippet => The cloned snippet reflects updates from the original snippet due to shared content, but is not marked as `o_dirty` and remains in a clean (yellow) state. Expected behavior: Cloned snippets should be marked as `o_dirty` when their content changes indirectly, ensuring the UI accurately reflects the modified state. This fix ensures duplicated snippets are flagged as `o_dirty` on indirect updates, preventing silent UI inconsistencies and improving state visibility. task-6176337 Forward-Port-Of: odoo/odoo#261916
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 CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to currency differences. The system now prioritizes journals with a specific currency ID, and falls back to the company currency if no match is found, ensuring accurate statement processing. This improves the reliability of financial data integration.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931 Forward-Port-Of: odoo/enterprise#117332 Forward-Port-Of: odoo/enterprise#114590
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#2641032 changes
Resolved issues and error corrections
This update resolves a technical issue where the payroll amount calculation wasn't working correctly when a default value was set for a specific field. The change ensures the calculation is triggered properly, addressing a potential discrepancy in how payroll amounts are determined. This improves the accuracy of payroll processing.
Original PR description
The compute is not triggered when a default value is assigned to a field. So all property inputs default to 'fix' for amount_select. This removes the default parameter from the field and adds the default value to the compute method. task-6126332 Forward-Port-Of: odoo/enterprise#116854 Forward-Port-Of: odoo/enterprise#113102
This update resolves an issue where the system incorrectly loaded account moves when processing paid orders. By removing redundant loading steps, the system now accurately retrieves the necessary data, ensuring paid orders are processed correctly within the point-of-sale module. This improves order processing reliability.
Original PR description
Before this commit, when loading the paid orders it would load the account move with the "account_move" key, but this key is wrong as the account move model is loaded with the "account.move". Also, the account move is already loaded by the "read_pos_data" method in the point_of_sale module, so we can just remove it from here. opw-6218467 Forward-Port-Of: odoo/enterprise#117422
2 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 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#115475This update fixes an issue where CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to differing currency settings. The system now prioritizes journals with explicit currency IDs, ensuring statements are accurately assigned to the correct currency-specific account. This improves the reliability of financial data reporting.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931 Forward-Port-Of: odoo/enterprise#117332 Forward-Port-Of: odoo/enterprise#114590