Daily updates from Odoo
Sunday, May 17, 2026
4 changes · saas-19.3
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