Tuesday, August 18, 2026
3 changes · 17.0
Resolved issues and error corrections
## Steps to reproduce: - Enable ship later for the PoS - Create a product A, tracked by lots - Create a kit product, include a component A - Go to the PoS, order this kit product - Also order the component A - Tick the ship later option --> A traceback appears ## Why the fix: With the ship later option activated, we do not compute the lines_data in the same way we do when asking for an invoice. For the invoice, https://github.com/odoo/odoo/blob/7676723dbb47c09a71925831b13ced97eb
Original PR description
## Steps to reproduce: - Enable ship later for the PoS - Create a product A, tracked by lots - Create a kit product, include a component A - Go to the PoS, order this kit product - Also order the…
## Steps to reproduce: - Enable ship later for the PoS - Create a product A, tracked by lots - Create a kit product, include a component A - Go to the PoS, order this kit product - Also order the component A - Tick the ship later option --> A traceback appears ## Why the fix: With the ship later option activated, we do not compute the lines_data in the same way we do when asking for an invoice. For the invoice, https://github.com/odoo/odoo/blob/7676723dbb47c09a71925831b13ced97eb855297/addons/point_of_sale/models/stock_picking.py#L37 We take every stockable line that is positive, but with the ship later option, we only take the lines that are tracked, meaning in this exemple we do not take the Kit line in lines_data. https://github.com/odoo/odoo/blob/7676723dbb47c09a71925831b13ced97eb855297/addons/point_of_sale/models/pos_order.py#L1525-L1532 The result of this is that we do not get the kit line in **_get_lot_line_qty**, explaining the traceback, as we are trying to access it. Instead of relying on **lines_data** that could change depending on the context, we now use the pos order to fetch the line(s) with our kit product. Adding the kit line to **lines_data** will most likely result in unwanted changes because lots of operations are done on each of it's items. opw-6431457
The view 'res.partner.property.form.inherit.ubl.tr' references external ID 'account_edi_ubl_cii.view_partner_property_form' but module 'account_edi_ubl_cii' is only available because of auto_install-links in the module graph. This causes an error when auto_install is skipped on runbot. The error is fixed since saas-19.2(https://github.com/odoo/odoo/pull/248034) where the view is moved but no backport for saas-19.1 and earlier has been made. Adding the explicit dependency is valid because '
Original PR description
The view 'res.partner.property.form.inherit.ubl.tr' references external ID 'account_edi_ubl_cii.view_partner_property_form' but module 'account_edi_ubl_cii' is only available because of auto_install-links in the module graph. This causes an error when auto_install is skipped on runbot. The error is fixed since saas-19.2(https://github.com/odoo/odoo/pull/248034) where the view is moved but no backport for saas-19.1 and earlier has been made. Adding the explicit dependency is valid because 'account_edi_ubl_cii' is indirectly installed at the same time. This is the effect chain: 1. 'l10n_tr_nilvera_einvoice' is auto_install'ed after 'l10n_tr_nilvera' installs 2. 'l10n_tr_nilvera_einvoice' has explicit dependency on 'account_edi_ubl_cii'.
When the FIFO vacuum creates the "Expenses Revaluation" journal entry for an anglo-saxon delivery whose cost is adjusted by a later receipt, the JE was built using `env.company` instead of the company of the vacuumed SVL. Steps to reproduce: - Enable multi-company and activate anglo-saxon accounting on two companies A and B. - In company B, on the product category: set FIFO costing + Automated valuation, and set the stock input / stock output / stock valuation accounts and the stock journa
Original PR description
When the FIFO vacuum creates the "Expenses Revaluation" journal entry for an anglo-saxon delivery whose cost is adjusted by a later receipt, the JE was built using `env.company` instead of the…
When the FIFO vacuum creates the "Expenses Revaluation" journal entry for an anglo-saxon delivery whose cost is adjusted by a later receipt, the JE was built using `env.company` instead of the company of the vacuumed SVL. Steps to reproduce: - Enable multi-company and activate anglo-saxon accounting on two companies A and B. - In company B, on the product category: set FIFO costing + Automated valuation, and set the stock input / stock output / stock valuation accounts and the stock journal. The Stock Output account must have "Allow Reconciliation" enabled. - In company B, on the product: set an Expense Account and set the Cost (e.g. 10.0) this is the price the delivery will be valued at while the stock is negative. The product must have no quantity on hand in company B. - While working in company B, sell and deliver 1 unit of that product: the delivery is valued at 10.0 and creates a negative valuation layer. - Still in company B, create and post the customer invoice of that sale, so the Stock Output line of the delivery entry gets reconciled with the Stock Output line of the anglo-saxon COGS entry of the invoice. - Switch the active company to A, and from there create a purchase order of that product for company B at a different price (e.g. 15.0), then validate the linked receipt into company B's warehouse. - The vacuum compensates the negative layer, but the resulting "Expenses Revaluation of ..." journal entry is posted in company A instead of company B. This fix forces the company context to `vacuum_svl.company_id` when fetching the product accounts and preparing the move lines so the JE is always created in the company of the SVL being vacuumed. opw-6066970 opw-6419188