Odoo Changelog — 2026-05-17

Sunday, May 17, 2026

3 changes · saas-19.2

Bug Fixes(3)

Resolved issues and error corrections

[FIX] mrp{account,}, stock_account: Fix MO valuation

Coresaas-19.2mrpmrp_accountstock_accountMEDIUM

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

#valuation#inventory#accounting

[FIX] l10n_jo_edi: fixes customer party being different between credi…

PR #264878

Coresaas-19.2l10n_jo_ediMEDIUM

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#264103

#accounting#jo#edi#credit note

[FIX] l10n_cl_edi_pos: prevent error when loading the paid orders

PR #117500

Enterprisesaas-19.2l10n_cl_edi_pos

This 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

#pos#edi#cl

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

…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#264103

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