Odoo Changelog — 2026-04-01

Wednesday, April 1, 2026

3 changes · master

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_co_edi_pos: DIAN qr crashes receipt

Enterprisemasterl10n_co_edi_posHigh impact

This fix resolves crashes that occurred when generating receipts for Colombian POS orders sent to DIAN (tax authority). The issue was caused by incorrect QR code paths and outdated code references. The fix ensures receipts generate properly without errors.

Original PR description

1. When generating the full receipt for a pos order sent to DIAN the receipt generation crashes because the qr code url is a relative path, which makes wkhtmltopdf crash.

2. For invoiced pos orders we were still using old code which would also crash because the `'barcode_src`' key is not returned by `_l10n_co_dian_get_extra_invoice_report_values` anymore

Forward-Port-Of: odoo/enterprise#112133

#Colombia#POS#DIAN#receipt#QR code

[FIX] purchase_{mrp, stock}: fix kit valuation after vendor bill posting

PR #256930

Coremasterpurchase_mrppurchase_stockstock_accountHigh impact

This fix corrects a valuation error that occurs when billing purchase orders containing kit products with multiple components. Previously, each component was incorrectly assigned the full kit cost instead of its proportional share, resulting in inflated inventory values. The fix ensures components receive the correct cost allocation based on their share of the kit's total cost.

Original PR description

**Issue**:
Billing a PO containing kit with several components can lead to incorrect
valuation of its components

**Steps to reproduce**:
- Create a kit product (by creating a BOM with 2 components) with AVCO valuation
- Create a PO for 1 unit at unit price 10
- Confirm PO and validate the receipt
- Go to the BOM of the kit product and check BOM overview
-> The cost of the two components are 5, which is correct
- Go to Accounting > Vendors > Bill
- Create a new bill by indicating the PO in "Auto-Complete" field and validate
- Go back to the BOM of the kit product and check BOM overview
-> The cost of the two components are 10, which is correct

This also occurs with FIFO valuation

**Cause**:
While computing the value of the move:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314
It checks the value of the Bill:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358
Which relies directly on the AML price of the kit:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170
This ignores the `cost_share` of each BOM component. As a result,
each component receives the full kit value instead of its proportional
share

This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393

**Aditionnal note**
The computation of the quantity is also incorrect:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169
since it assumes the quantity of component of the kit is the same than the quantity of the kit itself,
which is not true in the general case.

opw-5924940

Forward-Port-Of: odoo/odoo#252853
Forward-Port-Of: odoo/odoo#249264

#inventory valuation#kit products#vendor billing#cost accounting#AVCO#FIFO

[PERF] stock_account: ensure dates are compared with the right timezone

PR #256863

Coremasterstock_accountHigh impact

Fixed a timezone issue that was causing the Inventory Valuation report to run significantly slower than necessary. When users in certain timezones viewed the report, the system was unnecessarily recalculating the entire inventory history instead of using a quick calculation for today's data. This fix reduces report load time from over 40 seconds to just 3 seconds for large inventories.

Original PR description

When accessing the Inventory Valuation report, we check if the selected date correspond to the current day:…

When accessing the Inventory Valuation report, we check if the selected date correspond to the current day:

https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/report/stock_valuation_report.py#L33-L34

If the date is today, the method _run_average_batch() simply computes the value as qty_available * standard_price. But if it is not, it will replay the whole AVCO history which can be heavy.

https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/models/product.py#L394-L397

The "date" variable used in the comparison is the local date obtained from the browser while fields.Date.today() returns the UTC date. In certain case, when the local timezone is not on the same day as UTC anymore, this causes the report to be very slow to load because it replays the full history when it should not.

We propose to use the context_today() method instead to get the date from the user's timezone.

Benchmark:

| No AVCO Products | Before PR | After PR |
|------------------|-----------|----------|
|            12000 |    > 40 s |      3 s |

opw-6050007

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#256727
Forward-Port-Of: odoo/odoo#255841

#performance#timezone#inventory#report

1. When generating the full receipt for a pos order sent to DIAN the receipt generation crashes because the qr code url is a relative path, which makes wkhtmltopdf crash. 2. For invoiced pos orders we were still using old code which would also crash because the `'barcode_src`' key is not returned by `_l10n_co_dian_get_extra_invoice_report_values` anymore Forward-Port-Of: odoo/enterprise#112133

**Issue**: Billing a PO containing kit with several components can lead to incorrect valuation of its components **Steps to reproduce**: - Create a kit product (by creating a BOM with 2 components) with AVCO valuation - Create a PO for 1 unit at unit price 10 - Confirm PO and validate the receipt - Go to the BOM of the kit product and check BOM overview -> The cost of the two components are 5, which is correct - Go to Accounting > Vendors > Bill - Create a new bill by indicating the PO in "Auto-Complete" field and validate - Go back to the BOM of the kit product and check BOM overview -> The cost of the two components are 10, which is correct This also occurs with FIFO valuation **Cause**: While computing the value of the move: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282 https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314 It checks the value of the Bill: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358 Which relies directly on the AML price of the kit: https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170 This ignores the `cost_share` of each BOM component. As a result, each component receives the full kit value instead of its proportional share This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393 **Aditionnal note** The computation of the quantity is also incorrect: https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169 since it assumes the quantity of component of the kit is the same than the quantity of the kit itself, which is not true in the general case. opw-5924940 Forward-Port-Of: odoo/odoo#252853 Forward-Port-Of: odoo/odoo#249264

When accessing the Inventory Valuation report, we check if the selected date correspond to the current day: https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/report/stock_valuation_report.py#L33-L34 If the date is today, the method _run_average_batch() simply computes the value as qty_available * standard_price. But if it is not, it will replay the whole AVCO history which can be heavy. https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/models/product.py#L394-L397 The "date" variable used in the comparison is the local date obtained from the browser while fields.Date.today() returns the UTC date. In certain case, when the local timezone is not on the same day as UTC anymore, this causes the report to be very slow to load because it replays the full history when it should not. We propose to use the context_today() method instead to get the date from the user's timezone. Benchmark: | No AVCO Products | Before PR | After PR | |------------------|-----------|----------| | 12000 | > 40 s | 3 s | opw-6050007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256727 Forward-Port-Of: odoo/odoo#255841