Tuesday, August 18, 2026
7 changes · 17.0
Enhancements to existing features
The Turkish chart of accounts keeps sales and sales returns on separate accounts, so a customer credit note may not reuse the income account of the sale. Backport the journal and product level default return from sales account from e7e46374b5, and make a credit note created from an existing customer invoice use it as well. Reversing an invoice copies `account_id` over from the invoice line and never recomputes it, so the return kept landing on the sales account. Dropping the copied value lets
Original PR description
The Turkish chart of accounts keeps sales and sales returns on separate accounts, so a customer credit note may not reuse the income account of the sale. Backport the journal and product level default return from sales account from e7e46374b5, and make a credit note created from an existing customer invoice use it as well. Reversing an invoice copies `account_id` over from the invoice line and never recomputes it, so the return kept landing on the sales account. Dropping the copied value lets `_compute_account_id` resolve it again on the credit note, against its own journal. Reversals made to cancel an entry are left alone, as those have to mirror the original move exactly for the two to net out. Task-6438412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
In France, some drom-com (Guadeloupe, Martinique and Réunion) needs to use pdp just like France. So we should add those 3 for the computation of `peppol_eas`, so it will autocomplete to **France FRCTC Electronic Address**. task-6344558
Original PR description
In France, some drom-com (Guadeloupe, Martinique and Réunion) needs to use pdp just like France. So we should add those 3 for the computation of `peppol_eas`, so it will autocomplete to **France FRCTC Electronic Address**. task-6344558
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
Documentation and clarification updates
Description of the issue/feature this PR addresses: Signed the Odoo Individual Contributor License Agreement to contribute to the Odoo repository. Current behaviour before PR: The CLA signature is missing for GitHub user `kshitij-nariya`, which will prevent future contributions from being accepted and merged. Desired behaviour after PR is merged: The CLA signature for `kshitij-nariya` is recorded in the repository, allowing future pull requests and contributions to be successfully merge
Original PR description
Description of the issue/feature this PR addresses: Signed the Odoo Individual Contributor License Agreement to contribute to the Odoo repository. Current behaviour before PR: The CLA signature is missing for GitHub user `kshitij-nariya`, which will prevent future contributions from being accepted and merged. Desired behaviour after PR is merged: The CLA signature for `kshitij-nariya` is recorded in the repository, allowing future pull requests and contributions to be successfully merged. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Problem:** Searching on free_qty can be slow when there are many stock.move and stock.quant. The search method uses _compute_quantities_dict() to compute the free_qty based on stock.move and stock.quant, which is expensive. **Solution:** A similar field, qty_available, has a faster search method based on stock.quant only. This method can be adapted to support fast searching on free_qty by also aggregating the reserved_qty and subtracting it from the qty_available. **Perf Table:** Reco
Original PR description
**Problem:** Searching on free_qty can be slow when there are many stock.move and stock.quant. The search method uses _compute_quantities_dict() to compute the free_qty based on stock.move and stock.quant, which is expensive. **Solution:** A similar field, qty_available, has a faster search method based on stock.quant only. This method can be adapted to support fast searching on free_qty by also aggregating the reserved_qty and subtracting it from the qty_available. **Perf Table:** Record: product.template, with ~20k stock.picking and most products w/o moves. |Record count|Time before|Queries before|Time after|Queries after| |------------|-----------|--------------|----------|-------------| |10k |2.14s |214 |370ms |45 | |50k |6.06s |644 |829ms |50 | |100k |11.42s |1196 |1.05s |46 | opw-6266096
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